Full RBF

[o_e_l_e_o]

Looks like full RBF will be coming to bitcoin sooner rather than later, and I've not seen any discussion about it yet on the forum.

Here are some relevant links and discussions:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
https://github.com/bitcoin/bitcoin/pull/25353
https://github.com/bitcoin/bitcoin/pull/25373

The TL;DR for anyone out of the loop is to implement a new setting for nodes, so that the node treats all unconfirmed transactions in its mempool as RBF enabled, regardless of whether or not that transactions signals for RBF. The default behavior (for now) will be to have this setting disabled, so the current opt-in RBF rules will apply, but nodes will be free to enable this setting and switch from opt-in RBF to full RBF if they choose.

There are a number of good reasons to do this, including benefits and more security for multi-party funded transactions including coinjoins, Lightning, and other layer 2 solutions. However, it also essentially stops any business from accepting zero confirmation transactions for small values, since all transactions (even those opted out of RBF) could potentially be replaced using RBF.

I'm also curious as to what is going to happen when (for example) 50% of nodes have enabled full RBF, 50% of nodes have not enabled full RBF, and I try to replace a transaction which is opted out of RBF. What about if I'm using a hot wallet and not my own node? Will I have to connect to different servers to find one which will relay my replacement transaction? And then presumably some block explorers will show the original transaction while some will show the replacement, and I'll have no idea which one will actually get mined until one of them is mined?

[1715342045]

1715342045

[1715342045]

1715342045

[1715342045]

1715342045

[1715342045]

1715342045

[1715342045]

1715342045

[Cookdata]

I'm also curious as to what is going to happen when (for example) 50% of nodes have enabled full RBF, 50% of nodes have not enabled full RBF, and I try to replace a transaction which is opted out of RBF. What about if I'm using a hot wallet and not my own node? Will I have to connect to different servers to find one which will relay my replacement transaction?

It is likely that most nodes will implement the Full RBF and here are my reasons:
The mining Nodes will benefit in this aspect because having transaction default with Full RBF allows signers to boost transactions with more fees whenever the mempool becomes congested making them earn more sats from transactions fees.
There is also a high chance that other SPV wallets will follow the adoption just to keep their customers in the circle so that they don't move to other hots wallets that run their own nodes with full RBF feature for users but how soon I can't say.

And then presumably some block explorers will show the original transaction while some will show the replacement, and I'll have no idea which one will actually get mined until one of them is mined?

If a transaction has been flagged as RBF by a node, does block explorer has the ability to exclude it from transaction details? If the node you are connected has an RBF enable, that shouldn't be a problem with any explorer or is there going to be a change in RBF when nodes relay transactions within the network?

[Charles-Tim]

It is likely that most nodes will implement the Full RBF and here are my reasons:

What I am thinking too, also just because of what you stated already, it will also help the mempool to be less congested as some people will be able to pump the fee and increase the chance for the unconfirmed transaction'to be included into a block.

But that is not what o_e_l_e_o is asking. Even if 90% nodes signal for it, there will be a time at the start that just less than 50% nodes will signal for it and the number of nodes that will be signalling it will be increasing. If it is 50% to 50% of the nodes that signal and that do not signal, that it is possible some transactions in the mempool of the signal nodes to flag the transaction as RBF while those that did not signal will have the transaction as non RBF. So which one will be included into a block and be confirmed?

If a transaction has been flagged as RBF by a node, does block explorer has the ability to exclude it from transaction details? If the node you are connected has an RBF enable, that shouldn't be a problem with any explorer or is there going to be a change in RBF when nodes relay transactions within the network?

Yes, just like https://www.blockchain.com/explorer?view=btc do exclude it while some do include it. The thing is it is possible an unconfirmed transaction which is non RBF will be flagged as RBF on some mempool (mempool of the nodes that have signalled for it already) and remain not flagged as RBF on some other mempool (mempool of the nodes that have not signalled for it).

[NeuroticFish]

I'm also curious as to what is going to happen when (for example) 50% of nodes have enabled full RBF, 50% of nodes have not enabled full RBF, and I try to replace a transaction which is opted out of RBF. What about if I'm using a hot wallet and not my own node? Will I have to connect to different servers to find one which will relay my replacement transaction? And then presumably some block explorers will show the original transaction while some will show the replacement, and I'll have no idea which one will actually get mined until one of them is mined?

I guess that for a while there may look like a lottery. A replacement transaction of a non-RBF may have a bigger (than 50%) chance to get rejected even if 50% of the nodes are using the new code (unless I misunderstood something). But it should be pretty much okay, we do know that if we want RBF it should be signaled and we do know that a transaction cannot be trusted unless it's mined.

And I do think that after this implementation (when the vast majority will have it in use) the way the mempool works will be more predictable.
Yeah, it's a somewhat bad news for the services that were boasting 0-confirmation deposits. But they can use LN now.

[o_e_l_e_o]

There is also a high chance that other SPV wallets will follow the adoption just to keep their customers in the circle so that they don't move to other hots wallets that run their own nodes with full RBF feature for users but how soon I can't say.

Most SPV wallets, such as Electrum, do not run their own nodes. It will be entirely up to the individuals running Electrum servers whether they enable full RBF, or leave it turned off (as is the default). There will also be plenty of nodes running older software and plenty of nodes who simply don't bother to enable it because they don't see the point, can't be bothered, are unaware of the change, etc. We will probably get to a network wide enabled scenario eventually (if not through individual nodes enabling it then through it becoming enabled by default in future versions), but we must still move through the part-enabled part-disabled phase to get there.

If a transaction has been flagged as RBF by a node, does block explorer has the ability to exclude it from transaction details?

The transaction won't be flagged as RBF by a node. A transaction is only ever flagged as RBF by the person who creates that transaction. Nodes with full RBF enabled will treat all transactions as RBF enabled even if a transaction is not RBF flagged.

I guess this might have not been proposed if many SPV wallets support RBF transaction by default like on Electrum wallet

That wouldn't have made a difference. Read from "# 2nd issue : RBF opt-out by a Counterparty Double-Spend" on this link: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html. The very ability to broadcast a non-RBF transaction, whether or not some wallets use it by default or not, creates an attack vector for such transactions.

Yeah, it's a somewhat bad news for the services that were boasting 0-confirmation deposits. But they can use LN now.

Speaking from personal experience, the number of merchants I use which accept zero confirmations for low value transactions is much higher than the number of merchants I use which use Lightning. I suppose this change will force them to adapt.

[ABCbits]

I'm also curious as to what is going to happen when (for example) 50% of nodes have enabled full RBF, 50% of nodes have not enabled full RBF, and I try to replace a transaction which is opted out of RBF. What about if I'm using a hot wallet and not my own node? Will I have to connect to different servers to find one which will relay my replacement transaction? And then presumably some block explorers will show the original transaction while some will show the replacement, and I'll have no idea which one will actually get mined until one of them is mined?

If you use light wallet and managed to connect to server which relay full RBF transaction, it's likely your transaction will receive on miner mempool. Each node connect to at least 8 other node, so in average 4 of them will continue to relay your transaction.

Yeah, it's a somewhat bad news for the services that were boasting 0-confirmation deposits. But they can use LN now.

It's also bad news for user who only occasionally spend their Bitcoin on such services. It's unlikely they'll bother use LN wallet or lock their Bitcoin on LN channel when they only make transaction once in a month.

[dkbit98]

However, it also essentially stops any business from accepting zero confirmation transactions for small values, since all transactions (even those opted out of RBF) could potentially be replaced using RBF.

I didn't see much talk about this RBF news outside bitcointalk forum, maybe because everyone is talking about crash and bear market now  
I think there is a good chance that companies and regular members will rather accept Lightning payments for smaller values instead of using Bitcoin on main chain.
Fees are smaller this way especially during the time when there is congestion in mempool like we saw recently.

[DireWolfM14]

The TL;DR for anyone out of the loop is to implement a new setting for nodes, so that the node treats all unconfirmed transactions in its mempool as RBF enabled, regardless of whether or not that transactions signals for RBF. The default behavior (for now) will be to have this setting disabled, so the current opt-in RBF rules will apply, but nodes will be free to enable this setting and switch from opt-in RBF to full RBF if they choose.

Does this mean that the RBF will be the default only if the majority of node operators enable the setting?  The other question is if this the first step, and  will the default setting eventually become RBF enabled?  Probably too early to say.

There are a number of good reasons to do this, including benefits and more security for multi-party funded transactions including coinjoins, Lightning, and other layer 2 solutions.

I read the post by Antoine Riard, much of the technical stuff is over my head.  I'm not sure how RBF adds security to Multi-Party transactions, is just to get people used the fact that a transaction isn't guaranteed (or on it's way to becoming guaranteed) until there's at least one confirmation?

However, it also essentially stops any business from accepting zero confirmation transactions for small values, since all transactions (even those opted out of RBF) could potentially be replaced using RBF.

For brick and mortar shops who've been accepting bitcoin already I don't think this is a big deal as most people tend to be honest when dealing locally and face to face.  For online retailers it may be an issue if they're selling digital items that customers want to download instantly.  As LN becomes more and more common, it'll become a non-issue.

I'm also curious as to what is going to happen when (for example) 50% of nodes have enabled full RBF, 50% of nodes have not enabled full RBF, and I try to replace a transaction which is opted out of RBF. What about if I'm using a hot wallet and not my own node? Will I have to connect to different servers to find one which will relay my replacement transaction? And then presumably some block explorers will show the original transaction while some will show the replacement, and I'll have no idea which one will actually get mined until one of them is mined?

This is an interesting question.  It seems like it's up to the node operators to enable this feature, and it's purely democratic i.e. it'll take a majority of nodes enabling the feature to make the whole network full RBF.  Am I correct in my understanding?  Or will clients be able to pick and choose regardless of how may nodes enable the feature?

[NeuroticFish]

Speaking from personal experience, the number of merchants I use which accept zero confirmations for low value transactions is much higher than the number of merchants I use which use Lightning. I suppose this change will force them to adapt.

I don't really have experience with that, I use RBF even when I shouldn't really, so I am used to wait for confirmations.
If the use of LN is that good, that's a good news.

It's also bad news for user who only occasionally spend their Bitcoin on such services. It's unlikely they'll bother use LN wallet or lock their Bitcoin on LN channel when they only make transaction once in a month.

Good point. People will have to wait for at least one confirmation if they go on-chain.
If I'd do that I would at least consider using a custodian LN wallet (like blue wallet). Not a perfect solution, but it does the job once in a while.

[o_e_l_e_o]

Does this mean that the RBF will be the default only if the majority of node operators enable the setting?

The default is for full RBF to not be enabled. Individual nodes can choose to enable it for transactions in their mempool, but if I enable it and you don't, then you will continue to run with the current opt-in RBF rules. Even if every other node enables it and you don't, then you will continue to run with the current rules.

The other question is if this the first step, and  will the default setting eventually become RBF enabled?  Probably too early to say.

I think almost certainly yes.

I read the post by Antoine Riard, much of the technical stuff is over my head.  I'm not sure how RBF adds security to Multi-Party transactions, is just to get people used the fact that a transaction isn't guaranteed (or on it's way to becoming guaranteed) until there's at least one confirmation?

Here is the relevant section. I'll try to simplify it below:

Current bip125 RBF rules make signaling mandatory to enable replacement, otherwise even a better-feerate candidate won't replace a conflicting transaction with a finalized nSequence field [4]. A L2 client might be in possession of better-feerate multi-party funded transactions but it won't propagate on today's network if a opt-out double-spend is already present.

In the model described above, Alice might provide a consensus-and-standard valid input to Bob and Caroll, they will verify and accept it, finish the transaction finalization and broadcast. Meantimes, Alice will mass-connect to the network and announce a double-spend of its input with nSequence=0xffffffff. Alice-Bob-Caroll's funding transaction won't propagate on the network as it's an attempt to double-spend a rbf opt-out transaction.

A L2 client, with only a view of its mempool at best, won't understand why the transaction doesn't confirm and if it's responsible for the fee-bumping, it might do multiple rounds of feerate increase through CPFP, in vain. As the fee-bumping algorithm is assumed to be known if the victim client is open source code, the attacker can predict when the fee-bumping logic reaches its upper bound. When this bound is reached, the attacker might evict its own malicious opt-out double-spend by replacing an unconfirmed parent. At the next rebroadcast attempt by the L2 client, the funding transaction should propagate associated with a maliciously inflated feerate.

Consider any transaction which requires inputs from more than one party. Coinjoins and Lightning channels are the most common examples. I can DoS such a transaction by providing my input, and then while all the other inputs are being collated, double spend that input in a non-RBF transaction, meaning the original transaction will fail and the other parties will all have wasted their time.

The next step up is to consider your layer two client which is connected to your node. You submit the Lightning channel transaction (for example) to your node, but I'm already spreading my non-RBF double spend through the rest of the network. Your client then repeatedly tries to use CPFP to bump the fee since it just sees the transaction not confirming, at which point I can invalidate my non-RBF double spend by replacing an RBF enabled unconfirmed parent, allowing your transaction to propagate and forcing you to pay the full excessive CPFP fee.

This could become a serious issue if various wallets, services, platforms, etc. decide to start DoSing their competitors in order to attract business to themselves.

It seems like it's up to the node operators to enable this feature, and it's purely democratic i.e. it'll take a majority of nodes enabling the feature to make the whole network full RBF.  Am I correct in my understanding?

No. This isn't a case of signalling for a network wide change, but rather a case of node operators choosing the behavior for their own node.

[BlackHatCoiner]

Consider any transaction which requires inputs from more than one party. Coinjoins and Lightning channels are the most common examples. I can DoS such a transaction by providing my input, and then while all the other inputs are being collated, double spend that input in a non-RBF transaction, meaning the original transaction will fail and the other parties will all have wasted their time.

Why don't we utilize first-seen-safe RBF then? If the problem is to annoy the other party/parties by cancelling the CoinJoin or channel opening transaction, we can give a solution by accepting only transactions that spend to the same outputs, equal or greater amounts.

at which point I can invalidate my non-RBF double spend by replacing an RBF enabled unconfirmed parent

I don't understand this part. Since you've let a non-RBF transaction been propagated, how can you cancel it with an RBF unconfirmed parent?

[hosseinimr93]

I don't understand this part. Since you've let a non-RBF transaction been propagated, how can you cancel it with an RBF unconfirmed parent?

If I have got o_e_l_e_o correctly:
The non-RBF transaction is invalidated with double-spending its unconfirmed parent (which is RBF-enabled).
With invalidating the parent, the child (which was spending the same UTXO as the coinjoin transaction) is removed from the mempool and the coinjoin transaction can be propagated and confirmed.

[DireWolfM14]

Consider any transaction which requires inputs from more than one party. Coinjoins and Lightning channels are the most common examples. I can DoS such a transaction by providing my input, and then while all the other inputs are being collated, double spend that input in a non-RBF transaction, meaning the original transaction will fail and the other parties will all have wasted their time.

Why don't we utilize first-seen-safe RBF then? If the problem is to annoy the other party/parties by cancelling the CoinJoin or channel opening transaction, we can give a solution by accepting only transactions that spend to the same outputs, equal or greater amounts.

I might be missing something too, but I don't think the purpose is merely to annoy/harass the other parties, but to delay confirmations until the RBF/CPFP algorithm gets close to maximum fee range, then the attacker sends his own RBF transaction and forces everyone to pay that high fee.  The attack vector would require a a miner with a lot of hashing power to take advantage of the attack.  I don't know how practical/profitable of an attack vector it really is, I mean if the miner's equipment is as finicky as mine I'm sure he's got bigger fish to fry.

[o_e_l_e_o]

Why don't we utilize first-seen-safe RBF then?

With FSS, if the rest of the network sees my malicious double spend first (which is how the attack takes place), then they will refuse to replace it even with the higher fee paying multi-party transaction (coinjoin, Lightning channel, etc.)

I don't understand this part. Since you've let a non-RBF transaction been propagated, how can you cancel it with an RBF unconfirmed parent?

hosseinimr93 is correct. For further expansion:

I make Transaction A, which spends UTXO 1 and creates UTXO 2, and is opted-in to RBF. I then use UTXO 3 to join a multi-party transaction. At the same time, I make Transaction B, which spends the unconfirmed UTXO 2 and UTXO 3 and is opted-out of RBF, and broadcast Transaction 2 to the rest of the network. As the rest of the network has seen Transaction 2 first, which is non-RBF, they consider the multi-party transaction to be a double spend and reject it. Once the affected party has maxed out their fee reserves with repeated CPFP attempts, I can then replace Transaction A (which is RBF enabled), send UTXO 1 somewhere else which means UTXO 2 no longer exists, means Transaction B is now invalid, frees up UTXO 3 to be used by the multi-party transaction, and the rest of the network will now accept the multi-party transaction and its excessively high fee paying CPFP children.

I might be missing something too, but I don't think the purpose is merely to annoy/harass the other parties, but to delay confirmations until the RBF/CPFP algorithm gets close to maximum fee range, then the attacker sends his own RBF transaction and forces everyone to pay that high fee.

It can be either - wasting time or wasting fees.

The attack vector would require a a miner with a lot of hashing power to take advantage of the attack.

It doesn't require any mining power at all. The attack can take place as I've described just above in this post.

[witcher_sense]

I'm also curious as to what is going to happen when (for example) 50% of nodes have enabled full RBF, 50% of nodes have not enabled full RBF, and I try to replace a transaction which is opted out of RBF. What about if I'm using a hot wallet and not my own node? Will I have to connect to different servers to find one which will relay my replacement transaction? And then presumably some block explorers will show the original transaction while some will show the replacement, and I'll have no idea which one will actually get mined until one of them is mined?

Wait, if I don't upgrade my full node to a newer version, I am risking getting an incomplete (wrong) version of mempool and, therefore, won't be able to verify independently everything that happens in the blockchain? It all sounds like, with this change, we are doing intentional hardfork forcing everyone to upgrade to modified software, albeit without changing consensus rules. That still may cause network partition and a decrease in decentralization because part of the nodes (pre-full RBF ones) will lose their status as being considered full nodes since they no longer will be able to conduct full verification of valid transactions.

[hosseinimr93]

It all sounds like, with this change, we are doing intentional hardfork forcing everyone to upgrade to modified software, albeit without changing consensus rules.

Even if some nodes don't enable full RBF, there won't be any new chain and we won't have any hard fork.
It's possible that a transaction exists in a mempool while it doesn't exist in another mempool, but all nodes will still have the same blockchain.

[o_e_l_e_o]

Here's the way I see it:

Let's say Alice does not enable full RBF, but Bob does. Carol broadcasts a transaction which is not opted in to RBF, which propagates to both Alice and Bob's mempools. Carol then broadcasts a replacement transaction. Alice, running the old rules, rejects the replacement transaction as a double spend, while Bob, running the new rules, accepts the replacement transaction as an RBF. Alice therefore has the old transaction in her mempool, while Bob has the new transaction in his.

At some point, one of these two transactions will be mined in to a block. Which one is mined will depend on a variety of factors, such as how many nodes are running the old or the new rules, how much hashrate sees the original transaction or the new transaction, the fees both transactions pay, which miner is lucky enough to find the next block, and so on.

Once the next block is found, then all nodes, regardless of which rule set they are using, will be able to validate the transaction which was included in the block, and if necessary, remove the other one from their mempools. If the original transaction confirms, full RBF enabled nodes like Bob will eject the replacement, and if the replacement confirms, full RBF disabled nodes like Alice will eject the original.

[witcher_sense]

<…>

The only problem is that Alice verifies the confirmed transaction post factum, and, therefore, plays less significant role in enforcing the consensus rules. If all transactions are to be replaced using full RBF rules, then Alice is basically cut off from the rest of the network.

[ranochigo]

Why don't we utilize first-seen-safe RBF then? If the problem is to annoy the other party/parties by cancelling the CoinJoin or channel opening transaction, we can give a solution by accepting only transactions that spend to the same outputs, equal or greater amounts.

This was the primary way of RBF at that time when there were plans to either get FSS-RBF or Opt-in RBF on the network. There are many different risks and hassle with FSS-RBF, namely with it being subjective to the different miners and that it provides a false sense of security with no security benefits whatsoever. It was only adopted by Discus Fish (AKA. F2Pool) and dropped shortly afterwards. RBF (Opt-in or not) does not prevent fraud or anything like that, merely making it slightly harder for the average person but doesn't make them immune.

I don't foresee it to be a problem. Users generally do update their nodes, and currently 18% of the network runs 0.23 and 50% of the network runs 0.22. The number of hops that it takes to reach a miner should still be acceptable and you shouldn't have a case where it gets stuck due to nodes stopping the propagation of the transaction. Miners are generally very well connected to a myriad of nodes. However, the main concern should be whether the miners are willing to change their policy and start accepting these kind of transactions.

Peering should be a no issue because it is usually done by recognizing the service flags of their peers. It shouldn't be too difficult to have a service flag where the node attempts to connect to another which has full-rbf enabled.

[LoyceV]

However, it also essentially stops any business from accepting zero confirmation transactions for small values, since all transactions (even those opted out of RBF) could potentially be replaced using RBF.

That's unfortunate, I do like the occasional zero confirmation transaction that's instantly accepted.

it will also help the mempool to be less congested as some people will be able to pump the fee and increase the chance for the unconfirmed transaction'to be included into a block.

RBF doesn't empty mempool, for every transaction that gets into a block because of the increased fee, there's another transaction that doesn't make it anymore.

~ I'll have no idea which one will actually get mined until one of them is mined?

Isn't that the same now? If you use RBF, there are 2 valid signed transactions out there, and it's up to the miner to choose which one to include. The one with the highest fee is most likely to get confirmed, but there are no guarantees.

For brick and mortar shops who've been accepting bitcoin already I don't think this is a big deal as most people tend to be honest when dealing locally and face to face.  For online retailers it may be an issue if they're selling digital items that customers want to download instantly.  As LN becomes more and more common, it'll become a non-issue.

I admire your confidence in people's honesty And even though I agree most people would be honest, I fear this would attract dishonest people who see an opportunity to scam a shop.