pull down to refresh
0 sats \ 7 replies \ @xz 16 Feb freebie \ on: Over 70% of hash power has enabled Full-RBF; Bitcoin Core has not bitcoin
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.
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!
reply
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.
Thanks.
ACK
reply
reply
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.
reply
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.
reply
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.
reply
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.
reply