HTTP Status 400: Invalid Signature

Relays
1

Are there any known issues with mev-boost-relay related to invalid signatures a la https://collective.flashbots.net/t/impact-of-the-prysm-invalid-signature-bug-on-the-mev-boost-ecosystem-at-the-shapella-fork/1623?

I have been running a builder on sepolia for quite some time but I consistently get a 400 status code with error message “invalid signature” when trying to submit a block to the relay.

Is there something I may have overlooked that can cause this error?

2

There are no such bugs in the relay that we are aware of or have been notified about.

It’s probably your builder configuration; please share your builder startup arguments.

3

With Prysm as CL

BUILDER_TX_SIGNING_KEY=<private key> ./build/bin/geth \
  --sepolia \
  --http \
  --http.api=engine,eth,web3,net,debug,flashbots \
  --http.corsdomain=* \
  --http.addr=0.0.0.0 \
  --ws \
  --ws.api=engine,eth,web3,net,debug \
  --authrpc.jwtsecret=/etc/jwt.hex \
  --authrpc.vhosts=* \
  --authrpc.addr=0.0.0.0 \
  --metrics \
  --metrics.builder \
  --metrics.addr=127.0.0.1 \
  --builder \
  --builder.algotype=greedy \
  --builder.secret_key=<same private key as above> \
  --builder.beacon_endpoints=http://127.0.0.1:3500,http://prysm:3500 \
  --builder.remote_relay_endpoint=https://boost-relay-sepolia.flashbots.net \
  --miner.extradata='Illuminate' \
  --bootnodes=enode://9246d00bc8fd1742e5ad2428b80fc4dc45d786283e05ef6edbd9002cbc335d40998444732fbe921cb88e1d2c73d1b1de53bae6a2237996e9bfe14f871baf7066@18.168.182.86:30303,enode://ec66ddcf1a974950bd4c782789a7e04f8aa7110a72569b6e65fcd51e937e74eed303b1ea734e4d19cfaec9fbff9b6ee65bf31dcb50ba79acce9dd63a6aca61c7@52.14.151.177:30303
4

Is there some kind of relay registration that I should do which is similar to https://docs.flashbots.net/flashbots-auction/quick-start#how-to-send-your-first-flashbots-bundle?

I also noticed that there is a --builder.relay_secret_key parameter that I have left default. The description says that this is the Builder local relay API key used for signing headers.
Is this also being used for remote relays and might this be the source of the invalid signature issue?

Appreciate any insight!