Author: Erik Aronesty 2022-12-05 17:00:56
Published on: 2022-12-05T17:00:56+00:00
In a discussion on the bitcoin-dev mailing list, members were discussing an attack on Bitcoin's opt-in replace-by-fee (RBF) and 0-conf usage. One solution proposed was to work on a Bitcoin core implementation that stops propagation of full-RBF replaced blocks. However, implementing such a rule could lead to unintended chainsplits, and it is not feasible to make a consensus rule that enforces mempool consistency. Additionally, Bitcoin does not promise consistency across mempools. The risk of double-spending remains when conflicting transactions are broadcasted with minimal fees, leading to a situation where the miner creates a block with a different transaction from what one sees in their mempool. Peter Todd, who had been attacking opt-in RBF, had received donations worth a few hundred dollars for his efforts to double-spend. He had raised the reward to about 0.02 BTC or $400 USD at current prices. He turned it back on when the mempool settled down, but there was a risk of the mempool filling up again. The second full-RBF double-spend was initiated by Bob's calendar. There is no significant hash rate mining with full-RBF policies, despite the bounty having been collected. While there was good reason to think some miners were mining full-RBF before a few years back, they probably did not bother to reapply their patches each upgrade, making mempoolfullrbf=1 much simpler to use.
Updated on: 2023-06-16T02:48:00.979416+00:00