Here, the best simple explanation.
RBF was in Bitcoin for years, but people ignore it. Now suddenly everybody is trying to "explain" it, but I don't know why. Is just noise for nothing.
As I understand it, the impetus for revived debate is that there was a recent change to Bitcoin Core having to do with RBF and some disagree with the change.
I’ve seen several “pieces” of both arguments but still struggling to find a good comprehensive overview of the entire disagreement.
reply
In short: before it was a matter of the sender to enable RBF for the single transaction, now there is a config (default set to false) that enable a node to treat all the transaction as RBF. If the option will be largely activated this will kill the 0-conf practice, used by some business.
reply
The short of a short: if a tx doesn't have at least 3 or 6 confirmations, is not your bitcoins.
reply
So 3, 6 or... 9? Joking :)
reply
any reads on those business models and why "forced RBF" breaks them?
reply
The risk of accepting 0-conf transactions increases at the point it is not acceptable anymore, so they cannot operate "real time".
reply
Is there any risk of spamming the mempool by continuously updating the transaction fee?
reply
Nodes should only be propagating txs increasing the fee, but yeah, the possibility of spamming the network through increasing the fee by 1 sat steps seems to be worse.. But users can already do it with RBF transactions. Only ancient pre-RBF nodes would not propagate the tx.
reply
Nodes do not propagate RBF replacements unless they pay a minimum threshold of additional funds per byte. The cost is high enough that it'd be a lot cheaper to just buy cloud servers and DoS attack the entire P2P network directly.
reply