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.
that was a great read. I didn’t know what RBF was and now I definitely do!
Full-RBF reduces legal risks for all miners. We want to clearly set the standard that miners can mine what they want, and aren’t responsible for protecting users from unconfirmed double-spends.
that seems like a very good case for miners.
but, he said at the beginning of the article that he would explain the arguments against it. But, I didn’t see that. What the arguments against full-RBF?
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.
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 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.
Yes, at this point in time the idea that disabling full-RBF by default can protect "transactions for grocieries" is very much nonsense with >70% of hash power running full-RBF. I personally haven't actually run into any merchants lately that even accept on-chain BTC - in my recent time in El Salvador, South Africa, etc. all the merchants accepting BTC are using Lightning to do so.
Bitcoin ATM's are usually accepting on-chain BTC, at great expense. But in my experience even the AML/KYC ones usually require at least 1 confirmation. The only exception I've seen is the government-run Chivo ATM's in El Salvador that would sometimes, quite inconsistently, give money without a confirmation. But they'd do this whether or not the RBF flag was set!
It's weird that there's any objection to this, as far as I can tell, being mempool policy. I say that even as I could well imagine myself using mempoolfullrbf=0 on some of my own nodes where I want to keep mempool overhead low.
If you've run a lightning node for any length of time, or even if you haven't and you've sat and watched your tx sat in the mempool for days, it seems a nobrainer.
I've never payed for groceries or anything that wasn't lightning enabled in years.
Point is, Chivo ATM's give you money without a confirmation based on trust and their AML/KYC. They're accepting transactions with the BIP-125 RBF flag enabled, which means 100% of miners will replace them if double-spent. Full-RBF isn't relevant at all in that case. So Chivo ATM's are not a reason not to enable full-RBF by default.
Oh I see. Chivo ATM allows withdrawing and converting to and from Peso at current rates, and is being converted with full-RBF enabled before confirmations.
In that case, it's out-of-band mining with ability to accelerate.
I saw somebody make the point that miners need to align to node runners, not the other way around. That seemed to ring true.
Actually Chivo ATMs are allowing BTC to be converted to dollars; El Salvador uses the US dollar and BTC as their two official currencies.
I saw somebody make the point that miners need to align to node runners, not the other way around.
That argument is nonsense. People are fully able to run their own nodes, with their own policies. Full-RBF is in fact an example of that: I have a full-RBF peering fork of Bitcoin Core that ensures full-RBF replacements get to miners who are interested in mining them.
I see, Thanks again for breaking down some of these arguments.
Obviously I'm not a Core developer, so I just wanted to know what's going on as I can only look at it from my own view and usage and wonder if I missed something.
Now I feel like this whole debate in nonsensical.
if I opened Bitcoin Core QT and on IBD a pop up asked:
"do you want mempoolfullrbf=0, or mempoolfullrbf=1"
This would be the only way to stop hurting sensitivities. Anyone who runs CLI is going to know how to change defaults anyway.
mempoolfullrbf=0on some of my own nodes where I want to keep mempool overhead low.