What are the arguments in the `mempoolfullrbf` debate?

Question

In the past months there has been a debate about the new mempoolfullrbf startup option released in Bitcoin Core v24.0.1. The debate seems to be overlapping with debates whether full-rbf and 0-conf are desirable, and what implications it would have on the network if some nodes and miners started using mempoolfullrbf=1. Could you please give an overview of the arguments in the debate?

Answer 1

Replace-by-fee (RBF) is the ability to broadcast, propagate and ultimately get a replacement transaction in a mined block instead of the original competing transaction that you originally broadcast. It has been possible to do this from the very first Satoshi client because when presented with two competing transactions that meet the consensus rules miners can choose which transaction they include in a block they attempt to mine. Generally it makes sense for the miner to include the transaction with the higher fee rate in the block regardless of whether it was first seen or not.

BIP125 formalized RBF into a specification back in 2015. It introduced the ability for a transaction to signal whether the sender wanted the transaction to be replaceable or not. It wasn't a consensus rule change so miners could still choose which transaction to include a block and ignore the transaction signaling assuming it saw both. However, Bitcoin Core and other Bitcoin implementations (with some exceptions e.g. Bitcoin Knots) implemented the ability for full nodes to check whether the original transaction was replaceable before including a replacement transaction in its mempool and ultimately propagating the replacement transaction across the network.

Zero confirmation merchant acceptance ensures a better UX for a merchant's customers as you don't force the merchant's customer to wait for confirmation(s) before the customer can leave with their purchased item or service. The security it offers the merchant is significantly less than the security of a single confirmation let alone multiple confirmations. With zero confirmation one can construct a competing transaction ("double spend") that doesn't send any funds to the merchant and send it to a particular miner. It is then a race to see which transaction gets included in a mined block and whether the merchant receives the funds they are entitled to. However, merchants have argued that this doesn't happen as commonly as one would think and it is possible to manage this risk in the same way as credit cards manage chargeback risk in the fiat economy. It is difficult to assess why it hasn't happened that much historically (assuming it hasn't). Transaction fees have generally been low and most miners haven't offered a service for users to send transactions directly to them bypassing the P2P network and mempool policy enforcement of RBF transaction signaling. These may have contributed to zero conf risk being manageable in the past but clearly aren't guaranteed to continue in the future.

Second layer protocols such as Lightning rely on the ability for a user to get a transaction confirmed in a timely fashion in an emergency scenario such as a channel counterparty broadcasting a revoked state in a Lightning channel. Hence Bitcoin protocol and Lightning protocol developers have been studying what default mempool policy would be optimal to bolster the security model of those protocols. Many of them have assessed that the RBF signaling introduced in BIP125 overcomplicates this work and introduces unnecessary edge cases which would be eradicated if the RBF signaling was simply ignored by Bitcoin full nodes. Recall that miners can already ignore the RBF signaling without contradicting the consensus rules of the network and risking being forked off the network or causing chain splits.

Hence a -mempoolfullrbf option was introduced in the Bitcoin Core 24.0.1 release which would allow full node operators to ignore RBF signaling on transactions and accept replacement transactions into their mempools regardless of whether the original transaction was signaling for RBF or not. In Bitcoin Core 24.0.1 it is off by default but node operators can turn it on to ignore the RBF signaling of transactions. The proportion of node operators that turn this option on will determine how likely it is for a replacement transaction (for an original transaction that didn't initially signal for RBF) to ultimately reach a miner's mempool via the P2P network. There has also been a derivative of Bitcoin Core (Full-RBF Peering Bitcoin Core v24.0.1) released by Peter Todd which will advertise that you have the option switched on and to connect to other peers that also have the option switched on. If you run this derivative it would increase the likelihood of a RBF transaction reaching a miner's mempool via the P2P network.

An alternative would have been to turn it on by default and allow full node operators to be able to turn it off but with multiple merchants currently providing a zero confirmation UX to customers this could have resulted in many more replacement transactions or "double spends" being propagated across the network than if the option was turned off. It is possible the default could be changed in a future release but that would be subject to the Bitcoin Core review process. Merchants relying on zero confirmations clearly aren't enthusiastic at the prospect of more replacement transactions potentially being propagated across the network and so have opposed this change. This is unfortunate but it is a rare example of a change where multiple trade-offs have to be weighed. Post the block size war in 2015-17 it was generally accepted that Bitcoin needed to scale on higher layers such as Lightning and so the security of those protocols was prioritized here over what many consider to be a flawed business model in the long term. It is important to stress again that this a mempool policy discussion and not a consensus discussion. There is no chain split risk with mempool policy changes and so from the vantage point of the blockchain and the network this is a low risk issue. However, for merchants relying heavily on zero confirmations this is something they need to take seriously going forward. Arguably they should have been planning to reduce their dependence on zero confirmations regardless in the long term but the introduction of the -mempoolfullrbf option in Bitcoin Core has brought this issue to the forefront.

Thanks to Orange Surf for providing feedback on the original post.