shana
shana
The current custom BN fork sends the block building trigger for every valid payload received. This will support the use case of building on top of many heads in parallel.
I think opt-in is a good idea, it would notify validators to update mev-boost that may be hard to reach or not monitoring communication channels.
can this be closed now we have a stable branch?
bump on this issue, with the introduction of blobs seeing client timeouts in the devnets when max blob payloads are returned to the beacon node. ``` "error":"write tcp : write:...
https://github.com/flashbots/builder/tree/deneb
👍 feel free to fork the builder to build images for kurtosis. Let me know if you need me to rebase the builder from the latest geth electra branch
in this model, wouldn't the validator's IP information be exposed from the incoming getHeader request to the builder?
as the endpoint is unauthenticated, builders will probably obscure the validator IP when querying for each other's bids. Its possible that builders could ddos the getHeader endpoint to prevent proposers...
this seems to be an issue on mev-boost losing information about the bids. Is it possible that mev-boost restarted after the header call but before the get payload call?