beetrootkid

I'd probably argue that proofs or verification that the payment was what was promised sit in a different issue (and potentially should be handled by the consensus layer client(?)). The...

On further thinking, the most obvious addition would be a payload containing the proposer's (validator's) public key... but then that might create all kinds of privacy issues? However, most (if...

hmm.. .I mean that works, of course, but I know that we (and I suspect this is a broader principle across the ecosystem) rely solely upon on-chain data rather logging...

I think that feels more like proof it was paid where it should’ve been paid. All this issue was intended to focus on was understanding that something was paid for...

I'm not a coder so not qualified to comment on the code snippet. However, this does appear to address the core issue of deterministically identifying the transaction to the validator...

Ah - so, should I raise this at the builder-spec repo? A specific example: - One customer "trusts" relays 3,4,5 as sources of MEV - Another customer "trusts" relays 1,2,3...

How does the proposer learn about "possibly censored" transactions? Does the idea assume use of the public mempool? Is that realistic?