full-rbf-notice.md

Notice of new option for transaction replacement affecting zero-conf

This version of Bitcoin Core adds a new mempoolfullrbf configuration option which allows users to change the policy their individual node will use for relaying and mining unconfirmed transactions. The option defaults to the same policy that was used in previous releases and no changes to network behavior will occur if everyone uses the default. But, if enough nodes (including nodes used by miners) change their behavior using this option (or a related option provided by other software), other users on the network who depend on the previous relay policy may be affected---perhaps most especially users of the so-called zero-conf acceptance policy.

Some Bitcoin services today expect that the first version of an unconfirmed transaction that they see will be the version of the transaction that ultimately gets confirmed---a transaction acceptance policy sometimes called "zero-conf".

It is not possible to provide any assurance that the first version of an unconfirmed transaction seen by a particular node will be the version that gets confirmed. If there are multiple versions of the same unconfirmed transaction available, only the miner who includes one of those transactions in a block gets to decide which version of the transaction gets confirmed.

Despite this lack of assurance, multiple merchants and services today use zero-conf acceptance policies. This seems reliable because Bitcoin Core, the most widely used node implementation, included a simplification for a long time where it only relayed and attempted to mine the first version of a transaction it saw, ignoring any alternative versions of the transaction.

There are several benefits to users from removing this first-seen simplification. One key benefit, the ability for the sender of a transaction to replace it with an alternative version paying higher fees, was realized in Bitcoin Core 0.12.0 (February 2016) with the introduction of BIP125 opt-in Replace By Fee (RBF). Spenders have to opt-in to allowing BIP125 replacement by setting a flag on every transaction they may want to replace in the future.

Since then, there has been discussion about completely removing the first-seen simplification and allowing users to replace any of their older unconfirmed transactions with newer transactions, a feature called full-RBF. Spenders don't need to set a flag on their transactions in order later replace them if full-RBF is available. This release includes a mempoolfullrbf configuration option that allows enabling full-RBF, although it defaults to off (allowing only opt-in RBF).

At least one alternative node implementation already enables full-RBF by default, and several contributors to Bitcoin Core have advocated for enabling full-RBF by default in a future version of Bitcoin Core.

As more nodes that participate in relay and mining begin enabling full-RBF, zero-conf transaction acceptance policies that previously seemed reliable (although were never assured) may suddenly become unreliable. It only takes one moderate-sized miner or mining pool to enable full-RBF to allow anyone to steal from unprepared zero-conf merchants, and neither the miner nor any attackers are under any obligation to announce their intents in advance.

Members of this project strongly recommend that zero-conf merchants and services take the appropriate steps to prepare for full-RBF.

It only takes one moderate-sized miner or mining pool to enable full-RBF to allow anyone to steal from unprepared zero-conf merchants, and neither the miner nor any attackers are under any obligation to announce their intents in advance.

You should add something like:

Miners can also achieve the same effect as full-RBF via changing mempool configuration options from their defaults, such as using a higher than normal minimum relay fee, lower than normal max mempool size, chaning the datacarriersize, etc.

We should be clear that full-RBF is just one of many ways that zero-conf can suddenly become very unsafe. It might even be worth pointing out that zero-conf attackers can do things like flood the mempool with transactions and sybil attack the P2P network/miners' nodes, as well as simultaneously broadcasting conflicting txs.

@ariard

"Members of this project strongly recommend that zero-conf merchants and services take the appropriate steps to prepare for full-RBF"
I don't know if there are "best practices" we could point to as "appropriate steps". Mempools monitoring system might not be appreciable due to scalability concerns on network resources.

The best practice is to stop accepting zero-conf. The scalability concerns re: mempool monitoring is a good reason to support full-rbf: to get rid of the incentive to sybil attack the network to do "risk management" of zero-conf txs.

Personally, I'd be inclined to just take that line out and not officially recommend those merchants do anything. There are very few of them and they can decide for themselves.