PayToInclude/Exclude aka PayToCensor

[seresistvanandras]

Just thinking out loudly.

There are a few papers that talk about censorship attacks on Ethereum from a game theoretic point of view, e.g., this great work by Berger et al., but they don't say a word, how to implement these censorship attacks in practice (if at all possible). I think, they are not entirely trivial as there are some technical issues the briber and bribee need to solve and coordinate over. Here are some rough initial thoughts, in case somebody want to add these contracts to the this great bribery zoo repository.

PayToInclude

This is most commonly solved by offering a large enough transaction fee to the validators. This is essentially what people use in most real-world use cases to incentivise validators for transaction inclusion. However, naturally, one could also, implement and deploy a bribery contract for this problem. A bribery contract may be justified for this problem for this simple transaction inclusion problem by several arguments:

• The validator wishes to receive not ether for compensation but some other (ERC20) tokens.
• A bribery contract could support an inclusion logic much more elaborate than just a single bit, i.e., included in the block or not. For instance, the bribee only wants to ensure transaction inclusion if certain on-chain conditions are satisfied, e.g., the price levels on a DEX. These conditions could be easily checked by the bribery contract.

The PayToInclude contract logic would be simple (in the most simplest version): whenever a validator includes a certain transaction with a txHash in their proposed block, they could claim some money from the bribery contract by issuing a Merkle-Patricia trie inclusion proof with respect to a state root hash present in one of the previous block headers .

PayToExclude aka PayToCensor

Where I have some doubts is the implementation of a bribery contract for PayToCensor. This is because, this time the simple idea of using a transaction hash to identify the to-be-excluded transaction will simply not work, as the transaction hash is malleable since ECDSA is not a deterministic signature. Thus, the victim can fight back the bribee and re-broadcast the transaction with a randomized ECDSA signature, resulting in a different transaction hash. I don't see a simple technical solution to solve the problem of implementing a bribery contract for PayToCensor. so any ideas are welcome....