pull down to refresh

12 sats \ 7 replies \ @dtonon 3 Dec 2022 \ parent \ on: Any good RBF debate explainers out there? bitcoin
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.
write
preview
33 sats \ 1 reply \ @DarthCoin 3 Dec 2022
The short of a short: if a tx doesn't have at least 3 or 6 confirmations, is not your bitcoins.
reply
11 sats \ 0 replies \ @dtonon 3 Dec 2022
So 3, 6 or... 9? Joking :)
reply
11 sats \ 1 reply \ @Tony 3 Dec 2022
any reads on those business models and why "forced RBF" breaks them?
reply
11 sats \ 0 replies \ @dtonon 3 Dec 2022
The risk of accepting 0-conf transactions increases at the point it is not acceptable anymore, so they cannot operate "real time".
reply
11 sats \ 2 replies \ @jp 3 Dec 2022
Is there any risk of spamming the mempool by continuously updating the transaction fee?
reply
11 sats \ 1 reply \ @Lumor 3 Dec 2022
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
35 sats \ 0 replies \ @petertodd 4 Dec 2022
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