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?

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.

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.

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.



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?



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.



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?

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.

I think almost certainly yes.

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

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.

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.

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.

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

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.

It can be either - wasting time or wasting fees.

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

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.

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.

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

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.

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.

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.