Topic: Full RBF - page 7. (Read 2271 times)

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.

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.


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.

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.

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.

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.

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

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?

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

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.


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?

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?