diff options
| author | Billy Tetrud <billy.tetrud@gmail.com> | 2021-06-16 17:58:22 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-06-17 00:58:42 +0000 |
| commit | 8affe12bf270232e95979300d526f35a55ee7ea0 (patch) | |
| tree | f6599c2fb6a924b9028144374cd016e746078756 | |
| parent | 1cd6b0248ae25af3e87ce1adbb6cb6d0b04dc9c6 (diff) | |
| download | pi-bitcoindev-8affe12bf270232e95979300d526f35a55ee7ea0.tar.gz pi-bitcoindev-8affe12bf270232e95979300d526f35a55ee7ea0.zip | |
Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
| -rw-r--r-- | ac/e075d917a1dc4b1875bb7f408517c9430ff1d2 | 422 |
1 files changed, 422 insertions, 0 deletions
diff --git a/ac/e075d917a1dc4b1875bb7f408517c9430ff1d2 b/ac/e075d917a1dc4b1875bb7f408517c9430ff1d2 new file mode 100644 index 000000000..952a1edb5 --- /dev/null +++ b/ac/e075d917a1dc4b1875bb7f408517c9430ff1d2 @@ -0,0 +1,422 @@ +Return-Path: <fresheneesz@gmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id CBBECC000B + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 17 Jun 2021 00:58:42 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id B2EC440560 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 17 Jun 2021 00:58:42 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.099 +X-Spam-Level: +X-Spam-Status: No, score=-2.099 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_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp2.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Csg3FzLlsEsl + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 17 Jun 2021 00:58:41 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com + [IPv6:2a00:1450:4864:20::52a]) + by smtp2.osuosl.org (Postfix) with ESMTPS id A762C4055D + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 17 Jun 2021 00:58:40 +0000 (UTC) +Received: by mail-ed1-x52a.google.com with SMTP id z12so1589011edc.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 16 Jun 2021 17:58:40 -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=4D77NgL+0rnfOc79cNLUoT4QHuj120rWe/atZB0hIgE=; + b=LPZFhy4S5liYINGWsX8uTEbeHdkCJuVCzaARZ9mQSNh2foZR8cgJY7s98xinVneu06 + 3BgEViis4UrlbsRoTFZixKnmJAWqpcNxZswwKZa4bEid+YJTLphmzt/zymYSJZKhOPXz + GRTgZEH4H0YGuGuuZ/p1JuA/BNWdpUx5x0vT7GmV93beC844vpMLq4M+qXQzLbUgcYeD + QYvWPjKjRo5bEY2oABq756I2feJgUmhq/YHmvipq8mDmC9SAKv8b00AYKiztzjE4Gkxx + vW5bbb7D9zZsp/+7ze88ahXfaxKCmoa2UbfrLCyNZ0wVBMGK2F5al3FVbFyW/XflnlSq + OfDQ== +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=4D77NgL+0rnfOc79cNLUoT4QHuj120rWe/atZB0hIgE=; + b=g64P6pLn9fdgmPLtvbu0smVUhqWIWSky+d8rdCJsJh7Fo+O6cXUgHC4UJccLgSs26B + D0xwi/KUKeyLDtwXq3VgE3/UP0DE5JkJAK+lu9gISjKOTBfFUYPHgRVfOk4EZdBZ1mEW + MkDoyJ0diqt7ozySFZMGbFvuMWUEC7AiYkGse1WfJItcskKduNrkGAdnur/ISNi1sL5w + snoBUbfc0l16OP7xa6CeePG4U9MedU8Ufi1p2w+S58SqcVyr60uNUorPqALbSRewC7ln + gv5saIupYJB6imuXhNoo0E9XnNqbc44Cm46HZvD9tKL3IAt6rPYe5lYNG5jowlZcrV2G + IJ7A== +X-Gm-Message-State: AOAM5322sQrePNgS4jG6CUVBTXpVMXLFIvYL30GuVJwbUaTeBIPd60Xx + SVkIk2Aa/V/E66qQjRC7BqCrC5pa2u+L0dYbe/A= +X-Google-Smtp-Source: ABdhPJx7TDBpH3cgeZWwfgH6muCPWL/23p7kffC7yw7zLNj7ui8BIqnDsRjA+foHLs/HPO7YGpxjk8Z1iN1Ft0NB9Y4= +X-Received: by 2002:a05:6402:22fa:: with SMTP id + dn26mr2966593edb.230.1623891518662; + Wed, 16 Jun 2021 17:58:38 -0700 (PDT) +MIME-Version: 1.0 +References: <CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com> +In-Reply-To: <CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com> +From: Billy Tetrud <billy.tetrud@gmail.com> +Date: Wed, 16 Jun 2021 17:58:22 -0700 +Message-ID: <CAGpPWDbpg=sLN9rNze+mYaWP=0_Q64neh-Hj1V-=vU6NdEr__Q@mail.gmail.com> +To: Antoine Riard <antoine.riard@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000001fa9ff05c4ebb56a" +X-Mailman-Approved-At: Thu, 17 Jun 2021 20:14:21 +0000 +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: Thu, 17 Jun 2021 00:58:42 -0000 + +--0000000000001fa9ff05c4ebb56a +Content-Type: text/plain; charset="UTF-8" + +Russel O'Connor recently opined +<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019061.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 and +mine anything that passes consensus. At best opting out of RBF is a weak +defense, and at worst it's simply a false sense of security that is likely +to actively lead to theft events. + +Do we as a community want to support 0-conf payments in any way at this +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 confirmation, and most +recipients should wait for 6 confirmations" ? I think unless we pressure +software to be very explicit about what counts as finality, users 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 bitcoin +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-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 +> + +--0000000000001fa9ff05c4ebb56a +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Russel O'Connor <a href=3D"https://lists.linuxfoundati= +on.org/pipermail/bitcoin-dev/2021-June/019061.html">recently opined</a> tha= +t 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 transa= +ction that has not been committed into a block yet simply can't be reli= +ed upon. Miners also have a clear incentive to ignore RBF rules and mine an= +ything that passes consensus. At best opting out of RBF is a weak defense, = +and at worst it's simply a false sense of security that is likely to ac= +tively=C2=A0lead to theft events.=C2=A0<br><div><br></div><div>Do we as a c= +ommunity want to support 0-conf payments in any way at this point? It seems= + rather silly=C2=A0to make software design decisions to accommodate=C2=A00-= +conf payments when there are better mechanisms for fast payments (ie lightn= +ing).=C2=A0</div><div><br></div><div>One question I have is: how does softw= +are generally inform the user about 0-conf payment detection? Does software= + generally tell the user something along the lines of "This payment ha= +s not been finalized yet. All recipients should wait until the transaction = +has at least 1 confirmation, and most recipients should wait for 6 confirma= +tions" ? I think unless we pressure software to be very explicit about= + what counts as finality, users will simply continue to do what they've= + always done. Rolling out this policy change over the course of a year or t= +wo seems fine, no need to rush. But I suppose it would depend on how often = +0-conf is used in the bitcoin ecosystem at this point, which I don't ha= +ve any data on.=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D= +"ltr" class=3D"gmail_attr">On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard v= +ia bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"= +>bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote = +class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol= +id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi,<br><br>I= +9;m writing to propose deprecation of opt-in RBF in favor of full-RBF as th= +e Bitcoin Core's default replacement policy in version 24.0. As a remin= +der, 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 n= +ow. <br><br>Even if this replacement policy has been deemed as highly contr= +oversial a few years ago, ongoing and anticipated changes in the Bitcoin ec= +osystem are motivating this proposal.<br><br># RBF opt-out as a DoS Vector = +against Multi-Party Funded Transactions<br><br>As explained in "On Mem= +pool Funny Games against Multi-Party Funded Transactions'', 2nd iss= +ue [0], an attacker can easily DoS a multi-party funded transactions by pro= +pagating an RBF opt-out double-spend of its contributed input before the ho= +nest transaction is broadcasted by the protocol orchester. DoSes are qualif= +ied in the sense of either an attacker wasting timevalue of victim's in= +puts or forcing exhaustion of the fee-bumping =C2=A0reserve.<br><br>This af= +fects 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 dep= +loyment, 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 liqui= +dity 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 again= +st their competitors to hijack user traffic.<br><br>Beyond that, presence o= +f those DoSes will complicate the design and deployment of multi-party Bitc= +oin protocols such as payment pools/multi-party channels. Note, Lightning P= +ool isn't affected as there is a preliminary stage where batch particip= +ants are locked-in their funds within an account witnessScript shared with = +the orchestrer.<br><br>Of course, even assuming full-rbf, propagation of th= +e multi-party funded transactions can still be interfered with by an attack= +er, simply broadcasting a double-spend with a feerate equivalent to the hon= +est transaction. However, it tightens the attack scenario to a scorched ear= +th approach, where the attacker has to commit equivalent fee-bumping reserv= +e to maintain the pinning and might lose the "competing" fees to = +miners.<br><br># RBF opt-out as a Mempools Partitions Vector<br><br>A longe= +r-term issue is the risk of mempools malicious partitions, where an attacke= +r exploits network topology or divergence in mempools policies to partition= + network mempools in different subsets. From then a wide range of attacks c= +an be envisioned such as package pinning [1], artificial congestion to prov= +oke 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 lik= +ely going to be affected).<br><br>Traditionally, mempools partitions have b= +een gauged as a spontaneous outcome of a distributed systems like Bitcoin p= +2p network and I'm not aware it has been studied in-depth for adversari= +al purposes. Though, deployment of second-layer<br>protocols, heavily relyi= +ng on sanity of a local mempool for fee-estimation and robust propagation o= +f 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.<br><br><br>To resume, opt-in RBF doesn't suit well deploy= +ment 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 =C2=A0are still relying<br>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 mempoo= +l rules would be harming their quality of services 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 c= +ould be deployed ecosystem-wise as enhancements to the 0-confs security mod= +el.<br><br># Proactive security models : Double-spend Monitoring/Receiver-s= +ide Fee-Topping with Package Relay<br><br>From an attacker viewpoint, opt-i= +n RBF isn't a big blocker to successful double-spends. Any motivated at= +tacker can modify Core to mass-connect to a wide portion of the network, an= +nounce txA to this subset, announce txA' to the<br>merchant. TxA' p= +ropagation will be encumbered by the privacy-preserving inventory timers (`= +OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of which an attacker has no care t= +o respect.<br><br>To detect a successful double-spend attempt, a Bitcoin se= +rvice should run few full-nodes with well-spread connection graphs and unli= +nkable between them, to avoid being identified then maliciously partitioned= + from the rest of the network.<br><br>I believe this tactic is already depl= +oyed by few Bitcoin services, and even one can throw flame at it because it= + over consumes network resources (bandwidth, connection slots, ...), it doe= +s procure a security advantage to the ones doing it.<br><br>One further imp= +rovement 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 p= +ackage 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= +.<br><br># Reactive security models : EconomicReputation-based Compensation= +s<br><br>Another approach could be to react after the fact if a double-spen= +d has been qualified. If the sender is already known to the service provide= +r, the service account can be slashed.=C2=A0 If the sender is a low-trusted= + counterparty to the merchant, "side-trust" models could be relie= +d on. For e.g a LN pubkey with a stacked reputation from your autopilot, LS= +ATs, stake certificates, a HTLC-as-a-fidelity-bond, ... The space is quite = +wide there but I foresee those trust-minimized, decentralized solutions bei= +ng adopted by the LN ecosystem to patch the risks when you enter in a chann= +el/HTLC operation with an anonymous counterparty. <br><br></div><div>What o= +ther cool new tools could be considered to 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 tra= +nsaction relay/mempool acceptance policy might be beneficial to some class = +of already-deployed <br>Bitcoin applications while being detrimental to new= +er ones. How do we preserve the current interests of 0-confs users while en= +abling upcoming interests of fancy L2s to flourish is a good conversation t= +o have. I think.<br><br>If there is ecosystem agreement on switching to ful= +l-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 rule= +s heavily relied-on by Bitcoin users, if we do so let sets a precedent sati= +sfying as many folks as we can.<br><br>Cheers,<br>Antoine<br><br>[0] <a hre= +f=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003= +033.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lig= +htning-dev/2021-May/003033.html</a><br><br>[1] See scenario 3 : <a href=3D"= +https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.= +html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightni= +ng-dev/2020-June/002758.html</a><br><br>[2] <a href=3D"https://github.com/b= +itcoin/bitcoin/pull/10823#issuecomment-466485121" target=3D"_blank">https:/= +/github.com/bitcoin/bitcoin/pull/10823#issuecomment-466485121</a><br><br></= +div>[3] And the LN ecosystem does have an interest to fix zero-confs securi= +ty, if "turbo-channels"-like become normalized for mobile nodes<b= +r></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> + +--0000000000001fa9ff05c4ebb56a-- + |