From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B94A5C0012 for ; Sat, 18 Dec 2021 16:52:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id A0476405E7 for ; Sat, 18 Dec 2021 16:52:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PJC71b1AtrK for ; Sat, 18 Dec 2021 16:52:01 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp4.osuosl.org (Postfix) with ESMTPS id B3E7C4049C for ; Sat, 18 Dec 2021 16:52:00 +0000 (UTC) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BIGpv18016204 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 18 Dec 2021 11:51:58 -0500 Received: by mail-lf1-f46.google.com with SMTP id l22so11457939lfg.7 for ; Sat, 18 Dec 2021 08:51:58 -0800 (PST) X-Gm-Message-State: AOAM532hEUXD/n+sOd/P2uGtlkspDZ6rJdjVI/GtH98LCeE8rXItMwEG hyp+JAzZ56h8oUQHDQ2BjZx0lS7lwcCzvCMkZfI= X-Google-Smtp-Source: ABdhPJzQZHvSlgziIvCFUHPMxxw8KgRDZuFpzWQRuNZhUGZedbisxaaisTcNgANh8lAFGlb87o97S2/wBLG6Gj6GsIc= X-Received: by 2002:a05:6512:1287:: with SMTP id u7mr7983770lfs.226.1639846317219; Sat, 18 Dec 2021 08:51:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Sat, 18 Dec 2021 08:51:46 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Antoine Riard , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003964ef05d36e7990" Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2021 16:52:02 -0000 --0000000000003964ef05d36e7990 Content-Type: text/plain; charset="UTF-8" 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 > --0000000000003964ef05d36e7990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Small idea:

ease in= to getting rid of full-rbf by keeping the flag working, but make enforcemen= t of non-replaceability something that happens n seconds after first seen.<= /div>

this reduces the ability to partition the mempools by broadcasting ir= replaceable=C2=A0conflicts all at once, and slowly eases clients off of rel= ying on non-RBF.

we might start with 60 seconds, and then double ever= y release till we get to 600 at which point we disable it.


=
On Tue, Jun 15, 2021 at 10:00 AM Anto= ine Riard via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
Hi,

I'm writing to propose= deprecation of opt-in RBF in favor of full-RBF as the Bitcoin Core's d= efault 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 c= hange would enter into deployment phase a year from now.

Even if th= is replacement policy has been deemed as highly controversial a few years a= go, ongoing and anticipated changes in the Bitcoin ecosystem are motivating= this proposal.

# RBF opt-out as a DoS Vector against Multi-Party Fu= nded Transactions

As explained in "On Mempool Funny Games again= st Multi-Party Funded Transactions'', 2nd issue [0], an attacker ca= n easily DoS a multi-party funded transactions by propagating an RBF opt-ou= t double-spend of its contributed input before the honest transaction is br= oadcasted by the protocol orchester. DoSes are qualified in the sense of ei= ther an attacker wasting timevalue of victim's inputs or forcing exhaus= tion of the fee-bumping =C2=A0reserve.

This affects a series of Bitc= oin protocols such as Coinjoin, onchain DLCs and dual-funded LN channels. A= s those protocols are still in the early phase of deployment, it doesn'= t seem to have been executed in the wild for now.=C2=A0 That said, consider= ing 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 comp= licate the design and deployment of multi-party Bitcoin protocols such as p= ayment pools/multi-party channels. Note, Lightning Pool isn't affected = as there is a preliminary stage where batch participants are locked-in thei= r funds within an account witnessScript shared with the orchestrer.

= Of course, even assuming full-rbf, propagation of the multi-party funded tr= ansactions can still be interfered with by an attacker, simply broadcasting= a double-spend with a feerate equivalent to the honest transaction. Howeve= r, it tightens the attack scenario to a scorched earth approach, where the = attacker has to commit equivalent fee-bumping reserve to maintain the pinni= ng and might lose the "competing" fees to miners.

# RBF op= t-out as a Mempools Partitions Vector

A longer-term issue is the ris= k of mempools malicious partitions, where an attacker exploits network topo= logy or divergence in mempools policies to partition network mempools in di= fferent subsets. From then a wide range of attacks can be envisioned such a= s package pinning [1], artificial congestion to provoke LN channels closure= or manipulation of fee-estimator's feerate (the Core's one wouldn&= #39;t be affected as it relies on block confirmation, though other fee esti= mators designs deployed across the ecosystem are likely going to be affecte= d).

Traditionally, mempools partitions have been gauged as a spontan= eous outcome of a distributed systems like Bitcoin p2p network and I'm = not aware it has been studied in-depth for adversarial purposes. Though, de= ployment 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, RB= F 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-l= ayers protocol, even if those issues are still early and deserve more resea= rch. At the same time, I believe a meaningful subset of the ecosystem =C2= =A0are 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 harm= ing their quality of services and should be
weighed carefully. On the ot= her hand, it would be great to nudge them towards more secure handling of t= heir 0-confs flows [3]

Let's examine what could be deployed ecos= ystem-wise as enhancements to the 0-confs security model.

# Proactiv= e 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 Cor= e to mass-connect to a wide portion of the network, announce txA to this su= bset, announce txA' to the
merchant. TxA' propagation will be en= cumbered by the privacy-preserving inventory timers (`OUTBOUND_INVENTORY_BR= OADCAST_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 s= ervices, and even one can throw flame at it because it over consumes networ= k resources (bandwidth, connection slots, ...), it does procure a security = advantage to the ones doing it.

One further improvement on top of th= is protection could be to react after the double-spend detection by attachi= ng a CPFP to the merchant transaction, with a higher package feerate than t= he double-spend. Expected deployment of package-relay as a p2p mechanism/me= mpool policy in Bitcoin Core should enable it to do so.

# Reactive s= ecurity models : EconomicReputation-based Compensations

Another appr= oach 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 accoun= t can be slashed.=C2=A0 If the sender is a low-trusted counterparty to the = merchant, "side-trust" models could be relied on. For e.g a LN pu= bkey with a stacked reputation from your autopilot, LSATs, stake certificat= es, a HTLC-as-a-fidelity-bond, ... The space is quite wide there but I fore= see those trust-minimized, decentralized solutions being adopted by the LN = ecosystem to patch the risks when you enter in a channel/HTLC operation wit= h an anonymous counterparty.

What other cool new tools c= ould be considered to enhance 0-confs security ?

To concl= ude, let's avoid replaying the contentious threads of a few years ago. = What this new thread highlights is the fact that a transaction relay/mempoo= l acceptance policy might be beneficial to some class of already-deployed <= br>Bitcoin applications while being detrimental to newer ones. How do we pr= eserve the current interests of 0-confs users while enabling upcoming inter= ests of fancy L2s to flourish is a good conversation to have. I think.
<= br>If there is ecosystem agreement on switching to full-RBF, but 0.24 sound= s 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 b= y 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/0= 03033.html

[1] See scenario 3 : https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/0027= 58.html

[2] https://github.com/bitcoin/b= itcoin/pull/10823#issuecomment-466485121

[3] And the LN ec= osystem does have an interest to fix zero-confs security, if "turbo-ch= annels"-like become normalized for mobile nodes
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000003964ef05d36e7990--