Small idea: ease into getting rid of full-rbf by keeping the flag working, but make enforcement of non-replaceability something that happens n seconds after first seen. this reduces the ability to partition the mempools by broadcasting irreplaceable conflicts all at once, and slowly eases clients off of relying on non-RBF. we might start with 60 seconds, and then double every release till we get to 600 at which point we disable it. -- @JeremyRubin On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > I'm writing to propose deprecation of opt-in RBF in favor of full-RBF as > the Bitcoin Core's default replacement policy in version 24.0. As a > reminder, the next release is 22.0, aimed for August 1st, assuming > agreement is reached, this policy change would enter into deployment phase > a year from now. > > Even if this replacement policy has been deemed as highly controversial a > few years ago, ongoing and anticipated changes in the Bitcoin ecosystem are > motivating this proposal. > > # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions > > As explained in "On Mempool Funny Games against Multi-Party Funded > Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party > funded transactions by propagating an RBF opt-out double-spend of its > contributed input before the honest transaction is broadcasted by the > protocol orchester. DoSes are qualified in the sense of either an attacker > wasting timevalue of victim's inputs or forcing exhaustion of the > fee-bumping reserve. > > This affects a series of Bitcoin protocols such as Coinjoin, onchain DLCs > and dual-funded LN channels. As those protocols are still in the early > phase of deployment, it doesn't seem to have been executed in the wild for > now. That said, considering that dual-funded are more efficient from a > liquidity standpoint, we can expect them to be widely relied on, once > Lightning enters in a more mature phase. At that point, it should become > economically rational for liquidity service providers to launch those DoS > attacks against their competitors to hijack user traffic. > > Beyond that, presence of those DoSes will complicate the design and > deployment of multi-party Bitcoin protocols such as payment > pools/multi-party channels. Note, Lightning Pool isn't affected as there is > a preliminary stage where batch participants are locked-in their funds > within an account witnessScript shared with the orchestrer. > > Of course, even assuming full-rbf, propagation of the multi-party funded > transactions can still be interfered with by an attacker, simply > broadcasting a double-spend with a feerate equivalent to the honest > transaction. However, it tightens the attack scenario to a scorched earth > approach, where the attacker has to commit equivalent fee-bumping reserve > to maintain the pinning and might lose the "competing" fees to miners. > > # RBF opt-out as a Mempools Partitions Vector > > A longer-term issue is the risk of mempools malicious partitions, where an > attacker exploits network topology or divergence in mempools policies to > partition network mempools in different subsets. From then a wide range of > attacks can be envisioned such as package pinning [1], artificial > congestion to provoke LN channels closure or manipulation of > fee-estimator's feerate (the Core's one wouldn't be affected as it relies > on block confirmation, though other fee estimators designs deployed across > the ecosystem are likely going to be affected). > > Traditionally, mempools partitions have been gauged as a spontaneous > outcome of a distributed systems like Bitcoin p2p network and I'm not aware > it has been studied in-depth for adversarial purposes. Though, deployment > of second-layer > protocols, heavily relying on sanity of a local mempool for fee-estimation > and robust propagation of their time-sensitive transactions might lead to > reconsider this position. Acknowledging this, RBF opt-out is a low-cost > partitioning tool, of which the existence nullifies most of potential > progresses to mitigate malicious partitioning. > > > To resume, opt-in RBF doesn't suit well deployment of robust second-layers > protocol, even if those issues are still early and deserve more research. > At the same time, I believe a meaningful subset of the ecosystem are still > relying > on 0-confs transactions, even if their security is relying on far weaker > assumptions (opt-in RBF rule is a policy rule, not a consensus one) [2] A > rapid change of Core's mempool rules would be harming their quality of > services and should be > weighed carefully. On the other hand, it would be great to nudge them > towards more secure handling of their 0-confs flows [3] > > Let's examine what could be deployed ecosystem-wise as enhancements to the > 0-confs security model. > > # Proactive security models : Double-spend Monitoring/Receiver-side > Fee-Topping with Package Relay > > From an attacker viewpoint, opt-in RBF isn't a big blocker to successful > double-spends. Any motivated attacker can modify Core to mass-connect to a > wide portion of the network, announce txA to this subset, announce txA' to > the > merchant. TxA' propagation will be encumbered by the privacy-preserving > inventory timers (`OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of which an > attacker has no care to respect. > > To detect a successful double-spend attempt, a Bitcoin service should run > few full-nodes with well-spread connection graphs and unlinkable between > them, to avoid being identified then maliciously partitioned from the rest > of the network. > > I believe this tactic is already deployed by few Bitcoin services, and > even one can throw flame at it because it over consumes network resources > (bandwidth, connection slots, ...), it does procure a security advantage to > the ones doing it. > > One further improvement on top of this protection could be to react after > the double-spend detection by attaching a CPFP to the merchant transaction, > with a higher package feerate than the double-spend. Expected deployment of > package-relay as a p2p mechanism/mempool policy in Bitcoin Core should > enable it to do so. > > # Reactive security models : EconomicReputation-based Compensations > > Another approach could be to react after the fact if a double-spend has > been qualified. If the sender is already known to the service provider, the > service account can be slashed. If the sender is a low-trusted > counterparty to the merchant, "side-trust" models could be relied on. For > e.g a LN pubkey with a stacked reputation from your autopilot, LSATs, stake > certificates, a HTLC-as-a-fidelity-bond, ... The space is quite wide there > but I foresee those trust-minimized, decentralized solutions being adopted > by the LN ecosystem to patch the risks when you enter in a channel/HTLC > operation with an anonymous counterparty. > > What other cool new tools could be considered to enhance 0-confs security ? > > To conclude, let's avoid replaying the contentious threads of a few years > ago. What this new thread highlights is the fact that a transaction > relay/mempool acceptance policy might be beneficial to some class of > already-deployed > Bitcoin applications while being detrimental to newer ones. How do we > preserve the current interests of 0-confs users while enabling upcoming > interests of fancy L2s to flourish is a good conversation to have. I think. > > If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds > too early, let's defer it to 0.25 or 0.26. I don't think Core has a > consistent deprecation process w.r.t to policy rules heavily relied-on by > Bitcoin users, if we do so let sets a precedent satisfying as many folks as > we can. > > Cheers, > Antoine > > [0] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html > > [1] See scenario 3 : > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html > > [2] https://github.com/bitcoin/bitcoin/pull/10823#issuecomment-466485121 > > [3] And the LN ecosystem does have an interest to fix zero-confs security, > if "turbo-channels"-like become normalized for mobile nodes > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >