Over 70% of hash power has enabled Full-RBF; Bitcoin Core has not \ stacker news ~bitcoin

Okay thanks, that is one side of the argument.

Are there any articles from the other side of the argument?

31 sats \ 1 reply \ @petertodd OP 16 Feb

There have been some arguments against in the pull-req I linked to in this submission. I'd suggest you read those comments.

Note that at the moment, all arguments against full-RBF on the basis of protecting unconfirmed transactions are invalid: with >70% of hash power mining full-RBF, it's technically trivial to replace any transaction by simply double-spending it with a higher fee.

0 sats \ 0 replies \ @joda 16 Feb

Good point.

10 sats \ 1 reply \ @brandonsbytes 16 Feb

deleted by author

21 sats \ 0 replies \ @petertodd OP 16 Feb freebie

Arguments against full-RBF are here: https://github.com/bitcoin/bitcoin/pull/28132

10 sats \ 0 replies \ @bitentrepreneur 16 Feb

probs a good idea, pools and block explorers keep mempools with no upper limits soooo

0 sats \ 0 replies \ @joda 16 Feb

I don't see a problem with RBF now but it seems like there could be potential issues with covenants or other future OPcodes. Doubtful they would be insurmountable though.

0 sats \ 4 replies \ @oliverweiss 16 Feb

The situation in December was crazy, some of my transactions were stuck in the mempool for a couple of weeks (yeah, I am greedy and don’t want to pay high fees), neither cancellation nor fee bumping was possible.

22 sats \ 3 replies \ @kristapsk 16 Feb

neither cancellation nor fee bumping was possible

Fee bumping is almost always possible using CPFP.

0 sats \ 2 replies \ @025738dda8 16 Feb

However, CPFP leads to involving other unrelated utxo(s) which can mean an unwanted/unexpected deanonymization. With RBF, you can just use the already exposed change output for paying higher fee.

5 sats \ 1 reply \ @kristapsk 16 Feb

Devil is in details, but more or less RBF means similar privacy loss as 1 input, 1 output CPFP. Basically you give more hints to the world in a different ways which output was for recipient and which was change.

0 sats \ 0 replies \ @025738dda8 16 Feb

True. It depends on the particular case. That's why I don't say one or the other. Both mechanisms are useful in specific scenarios.

0 sats \ 7 replies \ @xz 16 Feb freebie

I used to have your nodes listed in my .conf before I enabled it. Seems to make sense to me. Reading over the thread, someone posted

How long do you want Bitcoin users to stand waiting in a store before they can leave with their groceries?

Am I right in understanding the only objection is 0conf transactions rely on this not-being enabled? But this would not be a problem anyway because the option to opt out is always there.

0 sats \ 0 replies \ @Eobard 16 Feb

deleted by author