pull down to refresh
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.
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.
The short of a short: if a tx doesn't have at least 3 or 6 confirmations, is not your bitcoins.
So 3, 6 or... 9?
Joking :)
Is there any risk of spamming the mempool by continuously updating the transaction fee?
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.
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.
any reads on those business models and why "forced RBF" breaks them?
The risk of accepting 0-conf transactions increases at the point it is not acceptable anymore, so they cannot operate "real time".
Here, the best simple explanation.
https://i.postimg.cc/6pCjLd2B/bitcoiners-rbf.jpg
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.