Quote from: DireWolfM14 on Today at 02:09:00 PM

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.

Quote from: DireWolfM14 on Today at 02:09:00 PM

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.

Quote from: DireWolfM14 on Today at 02:09:00 PM

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:

Quote from: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

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.

Quote from: DireWolfM14 on Today at 02:09:00 PM

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.