Humour me please, Where you say "create transactions which are only valid if they are mined on top of a specific block." - in practice, does that usually means at any height above a specific block? ________________________________ From: bitcoin-dev-bounces@lists.linuxfoundation.org on behalf of Ruben Somsen via bitcoin-dev Sent: Sunday, 2 September 2018 3:26:54 AM To: bitcoin-dev@lists.linuxfoundation.org Subject: [bitcoin-dev] Guiding transaction fees towards a more censorship resistant outcome When a user creates a transaction with a fee attached, they are incentivizing miners to add this transaction to the blockchain. The task is usually not very specific -- as long as it ends up in a valid chain with the most Proof-of-Work, miners get paid. The payment is an incentive for miners to act in the way that users desire. To the user, there’s an individual benefit: their transaction gets added. To the network, there’s a shared benefit: all fees add to the security of other transactions in the chain. Miners can choose to ignore the incentives, but they would be leaving money on the table (and eventually get replaced by more competitive miners). Transactions from Bitcoin Core are slightly more specific about what they ask miners to do. Every transaction is only valid at a block height that is one higher than the last block. This incentivizes miners to build on top of the last block, instead of going back and reorganizing the blockchain. This is especially important in a future scenario where the fee reward is larger than the block reward. BIP 115* by Luke-jr is even more specific. It enables users to create transactions which are only valid if they are mined on top of a specific block. While originally designed as a form of replay protection, it actually serves as a deterrent for miners to reorganize the blockchain. If they orphan a block, it will invalidate transactions that demanded the inclusion of the orphaned block. This increases the cost of intentionally reorganizing the blockchain. Coinjoin**, the act of combining payments of multiple users into a single transaction, can be seen as yet another method for users to be more specific. The fate of their payments are now intertwined with that of others. If miners wish to censor a single payment, they have to reject the entire transaction, and the associated fee amount. Techniques like mimblewimble simplify this process, by making coinjoin non-interactive. This brings us to a theoretical scenario where: - every block contains only a single coinjoin transaction - the validity of this transaction depends on the inclusion of a specific previous block - the block reward is negligible compared to transaction fees In this scenario, if miners wish to undo a specific transaction that happened two blocks ago, they would have to create three empty blocks (receiving negligible compensation) in order to overtake the longest chain. And even then, users can still refuse to let their new transactions be mined on top of the empty blocks, disincentivizing such behavior completely. While not easy to achieve in practice (e.g. resolving natural forks becomes more complicated), it demonstrates that users can become more empowered than they are today, benefitting censorship resistance***. It is this line of thinking that I wish to convey. Perhaps it may inspire further ideas in this direction. -- Ruben Somsen * BIP 115: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbitcoin%2Fbips%2Fblob%2Fmaster%2Fbip-0115.mediawiki&data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&sdata=req4KYOcztXLAG%2Fu4RrmhLREGBF28JNTe45pO86kRd4%3D&reserved=0 ** Coinjoin: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitcointalk.org%2Findex.php%3Ftopic%3D279249.0&data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&sdata=d%2B06jxrKubWhLwoInFEgo8eHvI9f1j74QN8WH7xrVos%3D&reserved=0 *** Risk sharing principle: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibbitcoin%2Flibbitcoin%2Fwiki%2FRisk-Sharing-Principle&data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&sdata=NA3HxqI5PnuyaI9hyCaw0rcaFsrhD%2FXQB8biWJXej8g%3D&reserved=0 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-dev&data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&sdata=9P7UetPmKWngjgjNPE0%2BAMgdzuL2DgqBLoLti82f23M%3D&reserved=0