Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

From: Jeremy <jlrubin@mit•edu>
To: Antoine Riard <antoine.riard@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
Date: Sat, 18 Dec 2021 08:51:46 -0800	[thread overview]
Message-ID: <CAD5xwhjVkxgu2+M+Ft576GYM6Tv=ZEwtV82v1cLeYaoU5mSRnA@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 8523 bytes --]

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 <https://twitter.com/JeremyRubin>
<https://twitter.com/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
>

[-- Attachment #2: Type: text/html, Size: 10418 bytes --]