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.
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.
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.
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.
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.
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.
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
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.
What Full-RBF is and why you should enable it on your node
Okay thanks, that is one side of the argument.
Are there any articles from the other side of the argument?
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.
Good point.
deleted by author
Arguments against full-RBF are here: https://github.com/bitcoin/bitcoin/pull/28132
probs a good idea, pools and block explorers keep mempools with no upper limits soooo
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.
Fee bumping is almost always possible using CPFP.
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.
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.
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.
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.
deleted by author