pull down to refresh
340 sats \ 9 replies \ @cointastical 13 Nov 2022 \ on: A bit confused around Full RBF bitcoin
Let me ask this question.
If every wallet and service were to already have enabled opt-in RBF and set it as the default, would there be anyone left arguing against simply going the final step and applying Full-RBF into Bitcoin Core?
Anyway, my feeling towards this is that there is today an advantage given a miner or pool over me with regards to replacement transactions. They can cause a transaction to confirm (even one that would be considered by the zeroconf merchant to be a "double spend") that I cannot. All Full FBF does is give me essentially the same power that a miner or pool already has as far getting a replacement transaction confirmed.
Thank you for your answer!
If everyone had opt-in-RBF enabled by default, 0-conf services can still see for each transaction whether it will (probably) be able to be replaced or not. We all agree the service has no certainty, but they can do risk management by evaluating how much funds they have sitting in unconfirmed transactions not signalling for replacement, the same amount sitting in unconfirmed transactions actively signalling for replacement, and set global thresolds (ex: no more than 1 BTC in the mempool in transactions not signalling replacement) and per-transaction theresold (ex: wait for N confirmations for amounts bigger than X).
Regarding miners having more power than you, I'm not sure I understand. If a miner is able to run software that considers all transactions in their mempool as replaceable, you certainly can too (for example, by running Bitcoin Knots instead of Bitcoin Core).
reply
but they can do risk management by evaluating how much funds they have sitting in unconfirmed transactions not signalling for replacement
Would anyone even expend the effort if effectively all of the transactions are signalling for replacement (once all wallets have opt-in RBF enabled by default)?
In other words, this could be forced through at the wallet app/edge device level, but that would take longer -- rather than this change to the relay policy that the bitcoin core client implements.
If a miner is able to run software that considers all transactions in their mempool as replaceable
I confirm no blocks, I have no power to include a transaction that other miners will not.
Today miners and pools (or cartel of miners and pools) can include any valid transaction in a block.
and set global thresolds (...) and per-transaction
That doesn't prevent attacks, it just makes the weakest and most obvious attacks to be less likely to be successful. Zeroconf is simply not safe and the sooner it is put to rest (i.e., communicate that it will be financial suicide for anyone that continues to implement it) the better, in my opinion.
reply
You have the option of using RBF if you want , not sure why you want to force others .
The miner power you are saying you want to have is just mental gymnastics to me.
Sorry if I’m being rude but it is what it is …
reply
The miner power you are saying you want to have is just mental gymnastics to me.
Back when Satoshi Dice was paying out on zeroconf (2012), and again when some Bitcoin ATMs dispensed cash on zeroconf (2019) there was the expectation that there would be miners that would exploit the obvious risk that existed with zeroconf implementations. And indeed both of those ended with losses being taken due to their reliance on zeroconf.
About the only reason it didn't happen on day one is it took a while for some miners to realize there was the opportunity to profit from doing this, and weighed the reward was risk (being ID'd and labeled as a bad actor) versus the reward and eventually deeming the reward to be sufficient relative to the risk.
So miners have the opportunity to profit by exploiting zeroconf but I do not. It's not that I want to profit from this vulnerability, it's that zerconf is a flawed approach, and that flaw should be fully exposed as a flaw, which can be done by making it so that Core v24.0 and later will simply relay replacement transactions regardless of RBF signaling.
reply
Good point!
But again; mempoolfullrbf is only removing funcitonality.
Since there's large businesses creating superior user experiences with 0-conf transactions (e.g. Bitrefill, 0-conf-channels), and everyone can use RBF TODAY without any issues, why do we need to enforce this?
I honestly don't understand it. Incredibly stupid...
reply
Does this superior user experience go beyond not having to wait for 10 minutes to have the tx included in the next block?
reply
Oh, so you're implying there's no need for instant payments?
Sorry to disappoint you, but there's a thing called Lightning Network that's quite popular I believe.
reply
Exactly, people should use the Lightning Network for such cases.
reply
You do realize that we need flexibility in onboarding funds onto lightning, right?
Turbo channels are immense onboarding ux improvements.
reply