The perception seems to be that Core adding the full RBF option is increasing the risk to zero-conf users, but I'm not convinced that that is the case.
If this "perception" were not true, RBF & full-RBF would not be necessary at all. Think about it.
It's always been the risk of getting double-spent out of hundreds or thousands of bitcoins that's worth seriously worrying about, which is much more the kind of attack a determined attacker is able to carry out.
The risk exposure to merchants providing zero-conf acceptance as a service is finite, capped by their risk-tolerance, and capped by the current block exposure. Merchants cap their exposure to be an amount worth less than the value of this service.
It is highly inefficient and difficult for a miner to pull off an industry-wide attack across diverse merchants to capture the current maximum exposure in any given block, not to mention the enormous surface area of legal risk across jurisdictions...
I don't think zero-conf opponents properly grasp that the risk exposure is exact and perfectly, trustlessly manageable. I would like the opportunity to spec the methods Bitrefill, Synonym, and most such merchants, use to make it standard practice, as it is cheaper for merchants and more convenient to Bitcoin consumers when merchants behave this way.
As has been pointed out by may others before, full RBF is aligned with miner (and user) economic incentives
This is a theory, not a fact. I can refute this theory by pointing out several aspects:
1. RBF is actually a fee-minimization feature that allows users to game the system to spend the *least* amount in fees that correlates to their time-preference. Miners earn less when fees can be minimized (obviously). This feature also comes at an expense (albeit small) to nodes providing replacement service and propagation.
2. Miners care about max fees per block, not slightly increased fees on a minority % of incidentally replaced txns when they happen to need it. They want the most txns for the highest price per *block*. In order to qualify for zero-conf acceptance, merchants require that the fee rate match or exceed an amount that makes the txn likely to be included in the very next block. This creates a priority competition from users with high time-preference. This creates not only more fees for miners, but more txns from more people using the chain for commerce. This is evidenced by stats provided recently to this mailing list, but here are more numbers from Bitrefill:
https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-13328232823. Miners ultimately want what users want, as more users = more txns = more fees = higher BTC price. For all of Bitcoin's history, more users have wanted zero-conf than replacements. This is evidenced by first-seen policy thriving for years without disruption (until engineers actively disrupted it, using fallible theories as justification). This is also evidenced by the UASF battle where miners capitulated to providing the type of blocks that users demanded, to avoid uncertainty.
4. A replaceable mempool is inherently less valuable than a first-seen policy mempool in that Bitcoin is ultimately a ledger for a *payments* system where people are trying to pay and be paid with certainty. A full-RBF system would result in more real-world doublespends to existing merchants and p2p commerce, as it is impossible to fully teach all aspects of Bitcoin dynamics to users, particularly when they have enjoyed many years of first-seen behavior as status quo.
Zero-conf and first-seen policies are clearly more incentive-compatible than RBF outright for these reasons.
The long-term 'what to do about it' is to use Lightning if you want fast payments with risk-free instant settlement
Many zero-conf proponents work on the bleeding edge of supporting Lightning, including myself. Lightning is not risk-free and the base layer should not be assuming it as a primary dependency for commercial payments. The UX and complexity of supporting Lightning is still considerable, adoption is still very low, and there are many unsolved attack vectors and risks that remain untested due to Lightning's low prevalence.
Further, zero-conf is also useful as a tool in improving Lightning onboarding, rebalancing, splicing, and UX overall. Bitcoin second-layers are only as good as the base layer, everything else is a tradeoff.
Bitcoin core 24 with the full RBF option is already out in the wild at around 5%+ of running nodes and growing, so it's too late to kill it.
This is pure speculation. If Bitcoin Core publishes an update without the mistakenly-rushed feature, the mempoolfullrbf movement is likely to die on the vine as users opt into the latest versions more and more, as evidenced by all older versions decreasing in usage over time. The incentive to run old versions, just to be able to force non-RBF txns to be treated as RBF, is lower than the incentive and likelihood of updating. Frankly, such an incentive is mostly obscure, vindictive, and perverse, IMO.
This mistake demands correction, and no one has provided a rational beneficial argument so far for breaking the user space and disrupting mempool harmony.
Thank you,
Date: Mon, 05 Dec 2022 12:21:44 +0000
From: angus <angus@toaster.cc>
To: Daniel Lipshitz <daniel@gap600.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
danger
Message-ID:
<-C_sX7ApYy_2MgXfl7e1ONddIi9gtET5jV4MTl_F_CstCvTuV0vTFfazF7tKBd53o6QbZ1xygayPIaCVjDyV-9yklnfk_t0IH23rw2LtqKQ=@toaster.cc>
Content-Type: text/plain; charset="utf-8"
Core adding full RBF is a change of node policy that may be highly inconvenient for zero-conf users, but there has always been and will always be a risk of a double-spend for anyone that treats zero-confirmation transactions as settled. It's literally in the name - this transaction has zero confirmations and no guarantee it'll make it into a block, and so has not yet settled.
The perception seems to be that Core adding the full RBF option is increasing the risk to zero-conf users, but I'm not convinced that that is the case - someone wanting to double-spend attack you isn't going to be bothered to do so over a few thousand sats (unless they can do it thousands of times), and losing a few thousand sats to a double-spend isn't the biggest deal.
It's always been the risk of getting double-spent out of hundreds or thousands of bitcoins that's worth seriously worrying about, which is much more the kind of attack a determined attacker is able to carry out. Such a determined attacker is much more likely to attempt and succeed at a sybil attack, or directly colluding with a miner. So your zero-conf risk increases non-linearly as the amount of bitcoin being transacted grows. (caveat: this paragraph is opinion).
There does, however, seem to be a legitimate business for providing insurance/risk management for people that are willing to accept the zero-conf risk - it is pretty similar to accepting credit cards with a chargeback risk or any payment card with a capture risk, though there's no-one to mediate a dispute. On-chain is final.
But what doesn't make any sense is trying to avoid Bitcoin Core and nodes from adopting a full RBF policy to try to protect this use case. As has been pointed out by may others before, full RBF is aligned with miner (and user) economic incentives and is a node policy, not consensus, so you can't even tell which nodes are doing it nor can you prevent them from doing so. Second, Bitcoin core 24 with the full RBF option is already out in the wild at around 5%+ of running nodes and growing, so it's too late to kill it.
So my point is that relying on node policy as part of your protection for zero-conf transaction acceptance is fragile, and should not be relied upon. The protocol rules have always tacitly allowed double-spending before a confirmation, and it has always been clear that there's no consensus on which transactions have occurred until they have in a block and have at-least one confirmation.
The long-term 'what to do about it' is to use Lightning if you want fast payments with risk-free instant settlement, or as above, accept the zero-conf risk and cover yourself with an insurance premium (e.g. a margin on transactions that goes into an insurance fund, and limiting max transaction amount so you're not exposed to uncoverable losses if you do get double-spend attacked)
Angus