diff options
| author | Corey Haddad <corey3@gmail.com> | 2021-06-30 10:06:50 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-06-30 14:07:07 +0000 |
| commit | 496d8edb009673c667365ff341ae83909fb54d75 (patch) | |
| tree | 73fbe17c111a53f2d9ce49d1161d00c6c0490cd8 | |
| parent | 87a7391aa1b42f6a71ec017e2b183a5c8a0d09d9 (diff) | |
| download | pi-bitcoindev-496d8edb009673c667365ff341ae83909fb54d75.tar.gz pi-bitcoindev-496d8edb009673c667365ff341ae83909fb54d75.zip | |
Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
| -rw-r--r-- | 79/7d7a2e6b2e1c4d4b1043adc3027808d6473142 | 691 |
1 files changed, 691 insertions, 0 deletions
diff --git a/79/7d7a2e6b2e1c4d4b1043adc3027808d6473142 b/79/7d7a2e6b2e1c4d4b1043adc3027808d6473142 new file mode 100644 index 000000000..b8fd5b140 --- /dev/null +++ b/79/7d7a2e6b2e1c4d4b1043adc3027808d6473142 @@ -0,0 +1,691 @@ +Return-Path: <corey3@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 73F08C0022 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 30 Jun 2021 14:07:02 +0000 (UTC) +Received: by mail-yb1-xb30.google.com with SMTP id m9so5190318ybo.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com> + <CAGpPWDbpg=sLN9rNze+mYaWP=0_Q64neh-Hj1V-=vU6NdEr__Q@mail.gmail.com> + <CALZpt+FuoVPt_GeT6_MSSpTJ9H1XqqVzDmviYcdJF_AuRNQTfA@mail.gmail.com> + <CAGpPWDZDhusi0Dq_LLmvXG=Ef6fUX4Xw_7DTBTWiGgDwxBQ_AQ@mail.gmail.com> + <CAD5xwhiH19VYNQoT03JNfgetRcU82cEW1sR2CmatRKoQ7jWoCA@mail.gmail.com> +In-Reply-To: <CAD5xwhiH19VYNQoT03JNfgetRcU82cEW1sR2CmatRKoQ7jWoCA@mail.gmail.com> +From: Corey Haddad <corey3@gmail.com> +Date: Wed, 30 Jun 2021 10:06:50 -0400 +Message-ID: <CAK_HAC8ogK_1aT840_TFScHjVGdyu-ipmb5fqDy+CL-Y_RmfTQ@mail.gmail.com> +To: Jeremy <jlrubin@mit.edu>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <antoine.riard@gmail.com> +>> 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 <billy.tetrud@gmail.com= +> a +>>> =C3=A9crit : +>>> +>>>> Russel O'Connor recently opined +>>>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019= +061.html> +>>>> 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 + +<div dir=3D"ltr">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<span class=3D"gmail-Apple-converted-spac= +e">=C2=A0</span>0-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.<div><br></div><div>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?</div><div><br></div><div>Corey</d= +iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att= +r">On Sat, Jun 26, 2021 at 3:00 PM Jeremy via bitcoin-dev <<a href=3D"ma= +ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati= +on.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m= +argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;borde= +r-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto">If the pa= +rties trust each other, rbf is still opt-in. Just don't do it?</div><br= +><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, J= +un 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev <<a href=3D"mailto:bit= +coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin= +uxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" = +style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s= +olid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">= +>=C2=A0 + +services providers are offering zero-conf channels, where you can start to = +spend instantly [0]. I believe that's an interesting usage<div><br></di= +v><div>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.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas= +s=3D"gmail_attr">On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard <<a href= +=3D"mailto:antoine.riard@gmail.com" rel=3D"noreferrer" target=3D"_blank">an= +toine.riard@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_qu= +ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st= +yle:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"= +ltr">> Do we as a community want to support 0-conf payments in any way a= +t this<br>> point? It seems rather silly to make software design decisio= +ns to<br>> accommodate 0-conf payments when there are better mechanisms = +for fast<br>> payments (ie lightning).<br><br>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).<br><br>> O= +ne question I have is: how does software generally inform the user about<br= +>0-conf payment detection?<br><br>Yes generally it's something like an = +"Unconfirmed" annotation on incoming txn, though at least this is= + what Blockstream Green or Electrum are doing.<br><br>> But I<br>suppose= + it would depend on how often 0-conf is used in the bitcoin<br>ecosystem at= + this point, which I don't have any data on.<br><br>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.<br><br>I'll = +see if I can come up with some Fermi estimation on this front.<br><br>[0] <= +a href=3D"https://www.bitrefill.com/thor-turbo-channels/" rel=3D"noreferrer= +" target=3D"_blank">https://www.bitrefill.com/thor-turbo-channels/</a><br><= +/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">L= +e=C2=A0mer. 16 juin 2021 =C3=A0=C2=A020:58, Billy Tetrud <<a href=3D"mai= +lto:billy.tetrud@gmail.com" rel=3D"noreferrer" target=3D"_blank">billy.tetr= +ud@gmail.com</a>> a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmai= +l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef= +t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir= +=3D"ltr">Russel O'Connor <a href=3D"https://lists.linuxfoundation.org/p= +ipermail/bitcoin-dev/2021-June/019061.html" rel=3D"noreferrer" target=3D"_b= +lank">recently opined</a> 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<br><di= +v><br></div><div>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</div><div><br></div><div>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</div></div><br><div clas= +s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 15, 202= +1 at 10:00 AM Antoine Riard via bitcoin-dev <<a href=3D"mailto:bitcoin-d= +ev@lists.linuxfoundation.org" rel=3D"noreferrer" target=3D"_blank">bitcoin-= +dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"= +gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border= +-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div= + dir=3D"ltr"><div>Hi,<br><br>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. <br><br>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><= +br># RBF opt-out as a DoS Vector against Multi-Party Funded Transactions<br= +><br>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.<br><br>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= +.<br><br>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.<br><br>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.<br><br># RBF opt-out as a Mempools = +Partitions Vector<br><br>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).<br><br>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<br>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.<br><br><br>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 relying<b= +r>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 r= +apid change of Core's mempool rules would be harming their quality of s= +ervices and should be<br>weighed carefully. On the other hand, it would be = +great to nudge them towards more secure handling of their 0-confs flows [3]= +<br><br>Let's examine what could be deployed ecosystem-wise as enhancem= +ents to the 0-confs security model.<br><br># Proactive security models : Do= +uble-spend Monitoring/Receiver-side Fee-Topping with Package Relay<br><br>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<br>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.<br><br>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.<br><br>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.<br><br>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.<br><br># Reactive security models : Econo= +micReputation-based Compensations<br><br>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. <br><br></div><div>What other cool new tools could be considered t= +o enhance 0-confs security ?<br></div><div><br>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 <br>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.<br><br>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.<br><br>Ch= +eers,<br>Antoine<br><br>[0] <a href=3D"https://lists.linuxfoundation.org/pi= +permail/lightning-dev/2021-May/003033.html" rel=3D"noreferrer" target=3D"_b= +lank">https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00= +3033.html</a><br><br>[1] See scenario 3 : <a href=3D"https://lists.linuxfou= +ndation.org/pipermail/lightning-dev/2020-June/002758.html" rel=3D"noreferre= +r" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightning-= +dev/2020-June/002758.html</a><br><br>[2] <a href=3D"https://github.com/bitc= +oin/bitcoin/pull/10823#issuecomment-466485121" rel=3D"noreferrer" target=3D= +"_blank">https://github.com/bitcoin/bitcoin/pull/10823#issuecomment-4664851= +21</a><br><br></div>[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<br></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"= + target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati= +on.org/mailman/listinfo/bitcoin-dev</a><br> +</blockquote></div> +</blockquote></div> +</blockquote></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"= + target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati= +on.org/mailman/listinfo/bitcoin-dev</a><br> +</blockquote></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--0000000000008da7f605c5fc3ce9-- + |