Guiding Transaction Fees Towards a more Censorship Resistant Outcome

This is summary for a submission by Ruben Somsen on bitcoin-dev on censorship resistant transactions.


Bitcoin transactions with light client wallets involve addition of transaction fees as incentive for miners to include the transaction to the blockchain through the process of mining. This creates a win-win situation.

First, without any specific conditions, miners get paid the fees provided the transaction gets included in a valid chain with the most proof-of-work.

Secondly, the user enjoys the benefit of his transaction being added to the blockchain. The fees also ensure the security of transaction on the network as miners cannot ignore the transactions or other miners will process it because it has a reward attached.

For the full node Bitcoin Core however, conditions for adding transactions to the blockchain are more specific, one of which is that transactions can only be added to a block with a block height that is one higher than the last.

This is meant to ensure that miners continue to build on top of the last block to prevent forking of the chain when they go back to add transactions at random. Transaction fees in the future will be higher than block rewards so this will be particularly helpful to ensure the blockchain is properly organised as priority will be given to fees and not block reward.

Luke-jr proposed an even more specific BIP 115 protocol which allows users to create transactions that must be added to specific blocks to in order be valid. This deters miners from reorganizing the block because if they orphan a block by reorganizing the blockchain, transactions that demand inclusion of the orphaned block will be invalidated and that makes it costly to reorganize the blockchain.

A higher level of specificity is achieved by Conjoin transactions in which payments of multiple users are combined into one and broadcast to the network at the same time. In this case, whatever happens to one of the payments happens to all the others and so censorship of a single payment is not possible unless miners reject the entire transaction and forfeit the associated fees, which is not likely. With Mimblewimble, coinjoin transactions become non-interactive thus making the process simpler.

For instance imagine a situation where every block contains only a single coinjoin transaction whose validity depends on the inclusion of a specific previous block and the transaction fee is significantly higher than the block reward. Miners will hardly attempt to undo a single transaction two blocks older because then they will have to go back and create three new blocks to get ahead of the current chain, which is tasking with negligible reward. On top of that users may not allow their transactions to be mined on top of empty blocks anyway so this discourages the censorship of transactions.

This idea shows that users can have more influence over their transactions in the future than they have today, it might however be difficult in practice like for example resolving natural forks. Generally though, the more specific a user is about how their transactions should be mined, the less likely it is for the transactions to get mined.

In the end the most powerful force against censorship is anonymity. If miners cannot tell one transaction from another then censoring single payments becomes impossible and miners will have to censor the entire transaction thus losing the reward.

Resources

Support us and the authors of this article by donating to the following address:

3BrxQoxN831WhtRkw6EMmtN2aALSJzEu8e

Comments powered by Talkyard.