From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 73F08C0022 for ; Wed, 30 Jun 2021 14:07:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 515A940648 for ; Wed, 30 Jun 2021 14:07:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Jmj3tP0Ek-VQ for ; Wed, 30 Jun 2021 14:07:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by smtp4.osuosl.org (Postfix) with ESMTPS id 0D7334017A for ; Wed, 30 Jun 2021 14:07:02 +0000 (UTC) Received: by mail-yb1-xb30.google.com with SMTP id m9so5190318ybo.5 for ; Wed, 30 Jun 2021 07:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vlQTSWFTdP3jxv9o+cSsEzNdQj4Q5VrsbQlpi1vJDXk=; b=piDhLvoSSGgziqzJ44Wr+JbIyDOMq40Y9maDsMUiKMs4NrZrGP2XuswodvbRLZj1ZC xBcxcIpFp2MI4ylXlQl5vimEJnxv+nqVNiYwlLq+pEGyYO0dyN4joAphSAqaisTsEGV5 7c27aQ9xwmhHOckRHpfdpkbxSFIrI2xoqYZkWXz+ObMppQ49l4Dk6BqkyYxkuHYKL69v Ftz3bS5jPPsBkgZy70ML3QdJ1BxmPTXjgpb621gpWf+5+G8spi1xWCLvUqC5MPWGD9ab wLYiLln4HX2ghGW1q6PT5FhuiEcGsL899kZ4i2hZQ8nfSt11x6SKAmar1+QMN+Br6jNh X+2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vlQTSWFTdP3jxv9o+cSsEzNdQj4Q5VrsbQlpi1vJDXk=; b=AFkIhDY8ad2DbUVPZmMKcR3B5PROh6u6sMoi7btyFYtycxP48IA5//FDQpsJIy1yWc 9nYp90aOahvKMlV8VUeTpeYBf+LoSD77aLG1GPTvJu66yXboXIwBi6xQD3sMdYf9aE78 n5e8hmRIjxtbB5uHqTYeT+B/IVFQIDINaaXLhCPz//n0gKnRdNbznv2m9Kdl4+rqlgeT FNgiDYpBk7gXNBl0lLGDrOFwjqB9SODw/hyrO9KFtEa+yVCUz8x/+Fjj/WKRfmP1bw9f JlT1Vd/5z7PKCGNUEe5F4gJHiMkPl0S9CT3HcbmYGE+xvwC7kmgcJZ5v13w51Ai/HD98 ytsw== X-Gm-Message-State: AOAM532SXWx7kYBJtrPL2p/NaCXb3uomzlxBpCu4pP6ex0VNEgnZXlfP 0u5dS9btN7EBtQBlK4SYPmysOLORpGqOS7uWqwE= X-Google-Smtp-Source: ABdhPJy7GuPYeIQhl8IePTxoWRPMBsyrz0nyCrpPu3bLT5rfc8K/pI1trebubY49foN7Z288QWCH7nl0LcBN50Sn7EM= X-Received: by 2002:a25:348f:: with SMTP id b137mr23330677yba.183.1625062021899; Wed, 30 Jun 2021 07:07:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Corey Haddad Date: Wed, 30 Jun 2021 10:06:50 -0400 Message-ID: To: Jeremy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000008da7f605c5fc3ce9" 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: Wed, 30 Jun 2021 14:07:07 -0000 --0000000000008da7f605c5fc3ce9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We cannot prevent people from choosing to take an action based on an unconfirmed transaction. Even though it is trivial to have a double-spending transaction confirmed, accepting a 0-conf tx can be rational in many cases. 0-conf can be interpreted as the customer signaling their 'intent to pay', and where there is an established relationship between customer and merchant, or where there merchant is providing a cancelable e-service, signaling intent may be enough. These use cases do not depend on making it difficult for the user to attempt to double-spend the merchant. Bitcoin is a system designed around a consensus on the blockchain, not the mempool. I am in favor of providing the spender of bitcoins with all possible tools and methods to help them submit their transactions - double-spending or not - to miners for consideration. More than making RBF the default, I would prefer to see nodes forward any transaction conflicting transaction, so long as it has a higher fee. Is there a reason this would be undesirable? Corey On Sat, Jun 26, 2021 at 3:00 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > If the parties trust each other, rbf is still opt-in. Just don't do it? > > On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > services providers are offering zero-conf channels, where you can >> start to spend instantly [0]. I believe that's an interesting usage >> >> I agree those are interesting and useful cases. I suppose I should >> clarify that when I asked if bitcoin should continue supporting 0-conf >> transactions, I meant: should we make design decisions based on whether = it >> makes raw 0-conf transactions more or less difficult to double spend on?= I >> do think 0-conf transactions can be useful in situations where there is >> some level of trust (either direct trust between the interacting parties= , >> or disperse trust that most people won't try to double spend, perhaps >> because the transaction is small or their identity is tied to it). Fidel= ity >> bonds sound like an interesting way to mitigate sybil attacks in a >> reputation system. >> >> On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard >> wrote: >> >>> > Do we as a community want to support 0-conf payments in any way at th= is >>> > point? It seems rather silly to make software design decisions to >>> > accommodate 0-conf payments when there are better mechanisms for fast >>> > payments (ie lightning). >>> >>> Well, we have zero-conf LN channels ? Actually, Lightning channel >>> funding transactions should be buried under a few blocks, though few >>> services providers are offering zero-conf channels, where you can start= to >>> spend instantly [0]. I believe that's an interesting usage, though IMHO= as >>> mentioned we can explore different security models to make 0-conf safe >>> (reputation/fidelity-bond). >>> >>> > One question I have is: how does software generally inform the user >>> about >>> 0-conf payment detection? >>> >>> Yes generally it's something like an "Unconfirmed" annotation on >>> incoming txn, though at least this is what Blockstream Green or Electru= m >>> are doing. >>> >>> > But I >>> suppose it would depend on how often 0-conf is used in the bitcoin >>> ecosystem at this point, which I don't have any data on. >>> >>> There are few Bitcoin services well-known to rely on 0-conf. Beyond how >>> much of the Bitcoin traffic is tied to a 0-conf is a hard question, a l= ot >>> of 0-confs service providers are going to be reluctant to share the >>> information, for a really good reason you will learn a subset of their >>> business volumes. >>> >>> I'll see if I can come up with some Fermi estimation on this front. >>> >>> [0] https://www.bitrefill.com/thor-turbo-channels/ >>> >>> Le mer. 16 juin 2021 =C3=A0 20:58, Billy Tetrud a >>> =C3=A9crit : >>> >>>> Russel O'Connor recently opined >>>> >>>> that RBF should be standard treatment of all transactions, rather than= as a >>>> transaction opt-in/out. I agree with that. Any configuration in a >>>> transaction that has not been committed into a block yet simply can't = be >>>> relied upon. Miners also have a clear incentive to ignore RBF rules an= d >>>> mine anything that passes consensus. At best opting out of RBF is a we= ak >>>> defense, and at worst it's simply a false sense of security that is li= kely >>>> to actively lead to theft events. >>>> >>>> Do we as a community want to support 0-conf payments in any way at thi= s >>>> point? It seems rather silly to make software design decisions to >>>> accommodate 0-conf payments when there are better mechanisms for fast >>>> payments (ie lightning). >>>> >>>> One question I have is: how does software generally inform the user >>>> about 0-conf payment detection? Does software generally tell the user >>>> something along the lines of "This payment has not been finalized yet.= All >>>> recipients should wait until the transaction has at least 1 confirmati= on, >>>> and most recipients should wait for 6 confirmations" ? I think unless = we >>>> pressure software to be very explicit about what counts as finality, u= sers >>>> will simply continue to do what they've always done. Rolling out this >>>> policy change over the course of a year or two seems fine, no need to = rush. >>>> But I suppose it would depend on how often 0-conf is used in the bitco= in >>>> ecosystem at this point, which I don't have any data on. >>>> >>>> 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-par= ty >>>>> 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 att= acker >>>>> 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 wil= d 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 bec= ome >>>>> 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 th= ere is >>>>> a preliminary stage where batch participants are locked-in their fund= s >>>>> 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, simp= ly >>>>> broadcasting a double-spend with a feerate equivalent to the honest >>>>> transaction. However, it tightens the attack scenario to a scorched e= arth >>>>> approach, where the attacker has to commit equivalent fee-bumping res= erve >>>>> 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 the= n 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 re= lies >>>>> on block confirmation, though other fee estimators designs deployed a= cross >>>>> 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, deploy= ment >>>>> of second-layer >>>>> protocols, heavily relying on sanity of a local mempool for >>>>> fee-estimation and robust propagation of their time-sensitive transac= tions >>>>> might lead to reconsider this position. Acknowledging this, RBF opt-o= ut is >>>>> a low-cost partitioning tool, of which the existence nullifies most o= f >>>>> 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 dese= rve >>>>> 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 qua= lity >>>>> 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 t= o >>>>> 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 s= ubset, >>>>> 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 n= o 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, an= d >>>>> even one can throw flame at it because it over consumes network resou= rces >>>>> (bandwidth, connection slots, ...), it does procure a security advant= age 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. Exp= ected >>>>> deployment of package-relay as a p2p mechanism/mempool policy in Bitc= oin >>>>> 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 pro= vider, >>>>> 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 ad= opted >>>>> by the LN ecosystem to patch the risks when you enter in a channel/HT= LC >>>>> 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 transac= tion >>>>> 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 upcomi= ng >>>>> 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-o= n by >>>>> Bitcoin users, if we do so let sets a precedent satisfying as many fo= lks as >>>>> we can. >>>>> >>>>> Cheers, >>>>> Antoine >>>>> >>>>> [0] >>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00= 3033.html >>>>> >>>>> [1] See scenario 3 : >>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/0= 02758.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 >>>>> >>>> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000008da7f605c5fc3ce9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We cannot=C2=A0prevent people from choosing=C2=A0to take a= n action based on an unconfirmed=C2=A0transaction. Even though it is trivia= l to have a double-spending transaction confirmed, accepting a 0-conf tx ca= n be rational in many cases.=C2=A0=C2=A00-conf can be interpreted as the customer signaling their &= #39;intent to pay', and where there is an established relationship betw= een customer and merchant, or where there merchant=C2=A0is providing a canc= elable e-service, signaling intent may be enough. These use cases do not de= pend on making it difficult for the user to attempt to double-spend the mer= chant.

Bitcoin is a system designed around a consensus= =C2=A0on the blockchain, not the mempool. I am in favor of providing the sp= ender of bitcoins with all possible tools and methods to help them submit t= heir transactions - double-spending or not - to miners for consideration. M= ore than making RBF the default, I would prefer to see nodes forward=C2=A0a= ny transaction conflicting transaction, so long as it has a higher fee. Is = there a reason this would be undesirable?

Corey

On Sat, Jun 26, 2021 at 3:00 PM Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.org> wrote:
If the pa= rties trust each other, rbf is still opt-in. Just don't do it?
On Sat, J= un 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.lin= uxfoundation.org> wrote:
= >=C2=A0 services providers are offering zero-conf channels, where you can start to = spend instantly [0]. I believe that's an interesting usage

I agree those are interesting and useful cases. I suppose I should c= larify that when I asked if bitcoin should continue supporting 0-conf trans= actions, I meant: should we make design decisions based on whether it makes= raw 0-conf transactions more or less difficult to double spend on? I do th= ink 0-conf transactions=C2=A0can be useful in situations where there is som= e level of trust (either direct trust between the interacting parties, or d= isperse trust that most people won't try to double spend, perhaps becau= se the transaction is small or their identity is tied to it). Fidelity bond= s sound like an interesting way to mitigate=C2=A0sybil attacks in a reputat= ion system.

On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard <an= toine.riard@gmail.com> wrote:
> Do we as a community want to support 0-conf payments in any way a= t this
> point? It seems rather silly to make software design decisio= ns to
> accommodate 0-conf payments when there are better mechanisms = for fast
> payments (ie lightning).

Well, we have zero-conf LN= channels ? Actually, Lightning channel funding transactions should be buri= ed under a few blocks, though few services providers are offering zero-conf= channels, where you can start to spend instantly [0]. I believe that's= an interesting usage, though IMHO as mentioned we can explore different se= curity models to make 0-conf safe (reputation/fidelity-bond).

> O= ne question I have is: how does software generally inform the user about0-conf payment detection?

Yes generally it's something like an = "Unconfirmed" annotation on incoming txn, though at least this is= what Blockstream Green or Electrum are doing.

> But I
suppose= it would depend on how often 0-conf is used in the bitcoin
ecosystem at= this point, which I don't have any data on.

There are few Bitco= in services well-known to rely on 0-conf. Beyond how much of the Bitcoin tr= affic is tied to a 0-conf is a hard question, a lot of 0-confs service prov= iders are going to be reluctant to share the information, for a really good= reason you will learn a subset of their business volumes.

I'll = see if I can come up with some Fermi estimation on this front.

[0] <= a href=3D"https://www.bitrefill.com/thor-turbo-channels/" rel=3D"noreferrer= " target=3D"_blank">https://www.bitrefill.com/thor-turbo-channels/
<= /div>
L= e=C2=A0mer. 16 juin 2021 =C3=A0=C2=A020:58, Billy Tetrud <billy.tetr= ud@gmail.com> a =C3=A9crit=C2=A0:
Russel O'Connor recently opined that RBF should=C2=A0be standard treatment of all= transactions, rather than as a transaction opt-in/out. I agree with that. = Any configuration in a transaction that has not been committed into a block= yet simply can't be relied upon. Miners also have a clear incentive to= ignore RBF rules and mine anything that passes consensus. At best opting o= ut of RBF is a weak defense, and at worst it's simply a false sense of = security that is likely to actively=C2=A0lead to theft events.=C2=A0

Do we as a community want to support 0-conf payments in an= y way at this point? It seems rather silly=C2=A0to make software design dec= isions to accommodate=C2=A00-conf payments when there are better mechanisms= for fast payments (ie lightning).=C2=A0

One quest= ion I have is: how does software generally inform the user about 0-conf pay= ment detection? Does software generally tell the user something along the l= ines of "This payment has not been finalized yet. All recipients shoul= d wait until the transaction has at least 1 confirmation, and most recipien= ts should wait for 6 confirmations" ? I think unless we pressure softw= are to be very explicit about what counts as finality, users will simply co= ntinue to do what they've always done. Rolling out this policy change o= ver the course of a year or two seems fine, no need to rush. But I suppose = it would depend on how often 0-conf is used in the bitcoin ecosystem at thi= s point, which I don't have any data on.=C2=A0

On Tue, Jun 15, 202= 1 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 p= olicy in version 24.0. As a reminder, the next release is 22.0, aimed for A= ugust 1st, assuming agreement is reached, this policy change would enter in= to deployment phase a year from now.

Even if this replacement polic= y has been deemed as highly controversial a few years ago, ongoing and anti= cipated changes in the Bitcoin ecosystem are motivating this proposal.
<= br># RBF opt-out as a DoS Vector against Multi-Party Funded Transactions
As explained in "On Mempool Funny Games against Multi-Party Funde= d Transactions'', 2nd issue [0], an attacker can easily DoS a multi= -party funded transactions by propagating an RBF opt-out double-spend of it= s contributed input before the honest transaction is broadcasted by the pro= tocol orchester. DoSes are qualified in the sense of either an attacker was= ting timevalue of victim's inputs or forcing exhaustion of the fee-bump= ing =C2=A0reserve.

This affects a series of Bitcoin protocols such a= s Coinjoin, onchain DLCs and dual-funded LN channels. As those protocols ar= e still in the early phase of deployment, it doesn't seem to have been = executed in the wild for now.=C2=A0 That said, considering that dual-funded= are more efficient from a liquidity standpoint, we can expect them to be w= idely relied on, once Lightning enters in a more mature phase. At that poin= t, it should become economically rational for liquidity service providers t= o launch those DoS attacks against their competitors to hijack user traffic= .

Beyond that, presence of those DoSes will complicate the design an= d deployment of multi-party Bitcoin protocols such as payment pools/multi-p= arty channels. Note, Lightning Pool isn't affected as there is a prelim= inary stage where batch participants are locked-in their funds within an ac= count witnessScript shared with the orchestrer.

Of course, even assu= ming 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 a= ttack scenario to a scorched earth approach, where the attacker has to comm= it equivalent fee-bumping reserve to maintain the pinning and might lose th= e "competing" fees to miners.

# RBF opt-out as a Mempools = Partitions Vector

A longer-term issue is the risk of mempools malici= ous partitions, where an attacker exploits network topology or divergence i= n mempools policies to partition network mempools in different subsets. Fro= m 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 deplo= yed across the ecosystem are likely going to be affected).

Tradition= ally, mempools partitions have been gauged as a spontaneous outcome of a di= stributed systems like Bitcoin p2p network and I'm not aware it has bee= n studied in-depth for adversarial purposes. Though, deployment of second-l= ayer
protocols, heavily relying on sanity of a local mempool for fee-est= imation and robust propagation of their time-sensitive transactions might l= ead to reconsider this position. Acknowledging this, RBF opt-out is a low-c= ost partitioning tool, of which the existence nullifies most of potential p= rogresses 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 tim= e, I believe a meaningful subset of the ecosystem =C2=A0are still relyingon 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 r= apid change of Core's mempool rules would be harming their quality of s= ervices 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 enhancem= ents to the 0-confs security model.

# Proactive security models : Do= uble-spend Monitoring/Receiver-side Fee-Topping with Package Relay

F= rom 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 privac= y-preserving inventory timers (`OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of= which an attacker has no care to respect.

To detect a successful do= uble-spend attempt, a Bitcoin service should run few full-nodes with well-s= pread connection graphs and unlinkable between them, to avoid being identif= ied then maliciously partitioned from the rest of the network.

I bel= ieve 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 merch= ant transaction, with a higher package feerate than the double-spend. Expec= ted deployment of package-relay as a p2p mechanism/mempool policy in Bitcoi= n Core should enable it to do so.

# Reactive security models : Econo= micReputation-based Compensations

Another approach could be to react= after the fact if a double-spend has been qualified. If the sender is alre= ady known to the service provider, the service account 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 pubkey with a stacked = reputation from your autopilot, LSATs, stake certificates, a HTLC-as-a-fide= lity-bond, ... The space is quite wide there but I foresee those trust-mini= mized, decentralized solutions being adopted by the LN ecosystem to patch t= he risks when you enter in a channel/HTLC operation with an anonymous count= erparty.

What other cool new tools could be considered t= o 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 applicati= ons while being detrimental to newer ones. How do we preserve the current i= nterests of 0-confs users while enabling upcoming interests of fancy L2s to= flourish is a good conversation to have. I think.

If there is ecosy= stem 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 deprec= ation 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.

Ch= eers,
Antoine

[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00= 3033.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-4664851= 21

[3] And the LN ecosystem does have an interest to fix z= ero-confs security, if "turbo-channels"-like become normalized fo= r mobile nodes
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000008da7f605c5fc3ce9--