Announcement: Full-RBF Miner Bounty



Summary:

The discussion on the bitcoin-dev mailing list revolves around opt-in RBF and 0Conf bitcoin usage. The user suggests working on a bitcoin core implementation that stops propagation of full-rbf replaced blocks, which would add a risk to miners that enable full-rbf, thus serving as an incentive against that. However, implementing this option in bitcoin core is politically difficult. Alternatively, a sufficiently incentivized actor could work on a fork and run several nodes with such functionality. According to the percolation model, with 10 to 20 nodes running such a rule, it would create a significant risk for full-rbf miners. Peter Todd mentions getting a few hundred dollars worth of donations to this effort and raising the reward to about 0.02 BTC or $400 USD at current prices. He also mentions that it is easy to double spend with the obvious low-fee/high-fee method as the min relay fee keeps shifting. Additionally, he discusses how he double-spent the txin of the high fee tx that got mined but mistakenly had RBF enabled in that double-spend, so while it propagated initially, he believes it was replaced when something (someone?) rebroadcast the high-fee 397dcb tx.The timeline shows the blocks that were mined and the mempool ages of different transactions. Miningpool.observer reports both 397dcbe4 and ba967010 as missing in the first three blocks, and gives similar mempool ages for those txs to what my logs report. The user suggests that this presumably means those pools (AntPool twice and "unknown") are running with large mempools that didn't keep the earlier 1.2sat/vb txs. The txs were mined by Foundry, suggesting no significant hashrate mining with fullrbf policies despite the bounty having been collected. However, Peter Todd argues that we can put much lower bounds on that, as he has been running OTS calendars with full-rbf replacements for a few months without clear evidence of a full-rbf replacement. While there was good reason to think some miners were mining full-rbf before a few years back, they probably didn't bother to reapply their patches each upgrade. `mempoolfullrbf=1` is much simpler to use.


Updated on: 2023-05-22T22:50:43.263057+00:00