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.

Few suggestions, feel free to take it or leave it.

perhaps most especially users of the so-called zero conf acceptance policy.

Maybe "perhaps most especially users of the so-called zero conf transaction acceptance policy".
May add link to Dario's mailing post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020980.html

The Bitcoin protocol does not

I think it could be "the Bitcoin transaction-relay p2p network" to dissociate from the consensus rules. I assume the readers of this note are not experts in protocol dev.

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.

Maybe "allowing users to replace any of their older unconfirmed transactions with newer transactions, and thus independently of any signaling replacement, a feature called full-RBF".

and several contributors to Bitcoin Core are advocating for enabling full-RBF by default in a future version of Bitcoin Core

After the weeks of discussions, I think the opinions are far more nuanced. At the very least sounds to me we're back to the whiteboard on some question if we should adopt policy regime per-use-case, or even if Core standpoint should be to allow policy options when the range of options might be harmful for network equilibrium. I don't know how to capture it. I think something like "The contributors to Bitcoin Core are open to collect more constructive feedback if such option should persist or not in Core, or if a default-on should be coordinated across the ecosystem".

"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.

Looks great to me, thank you for the write-up. I agree with the gist all of @ariard's suggestions, except:

I think it could be "the Bitcoin transaction-relay p2p network" to dissociate from the consensus rules. I assume the readers of this note are not experts in protocol dev.

Imo for practical purposes, I don't think we need to be overly precise here. Keeping it simple and actionable is more important than being 100% terminologically correct. "The Bitcoin Protocol" sufficiently captures it in my view.

A few minor suggestions:

The Bitcoin Protocol does not, and cannot, provide any

"The Bitcoin Protocol does not, cannot, and has never provided any"

zero conf

nit: slight inconsistency between "zero conf" and "zero-conf" later on, I prefer the latter as in a full sentence it's easier to see that they together form the term.

Several alternative node implementations have already begun enabling full-RBF by default

Is there data backing up this claim? I know that Knots has enabled it for a long time, libbitcoin apparently never implemented non-trivial policy rules at all (https://twitter.com/evoskuil/status/1590799813578457089) and I don't know about other implementations. Are there any that have recently switched to full-RBF?

I believe I've addressed all comments in this edit, except one described below. Thanks for the constructive feedback! Some notes below:

@ariard

Maybe "allowing users to replace any of their older unconfirmed transactions with newer transactions, and thus independently of any signaling replacement, a feature called full-RBF".

The previous text didn't describe the opt-in mechanism, so I also added a sentence about that so that the text about signal-indepedent replacement would make sense.

and several contributors to Bitcoin Core are advocating for enabling full-RBF by default in a future version of Bitcoin Core

After the weeks of discussions, I think the opinions are far more nuanced.

I agree, although I think there are still people strongly in favor of default full-RBF and it's still a real possibility that merchants should prepare for. To try to address your feedback without substantially rewriting the text, I changed to the past tense: s/are advocating/have advocated/.

"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.

Yeah, I don't know of any good resources to which we can point zero-conf merchants at this time. If any exist, I'd be happy to add a link, but for now I've made no edit for this feedback.

@mzumsande

Several alternative node implementations have already begun enabling full-RBF by default

Is there data backing up this claim? [...] Are there any that have recently switched to full-RBF?

I changed this to "at least one" and removed "begun". For the number of implementations, I was thinking about Peter Todd's long-circulated patches for full-RBF (with optional preferential peering) as a separate implementation; also ghost42/sombernight said they run several bitcoinds in public use with the opt-in only RBF line commented out, which might could as an implementation, I dunno.

As for "recently switched", I didn't mean "begun" to imply recentness, but you're the second person to have that interpretation, so I changed it.

@stickies-v Thanks for the comments! Yours were straightforward, so I don't have anything extra to say after making edits. :-)

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.