Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id BC787C000B for ; Thu, 17 Jun 2021 22:29:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 9739C415D8 for ; Thu, 17 Jun 2021 22:29:00 +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 GluUvPieVhKk for ; Thu, 17 Jun 2021 22:28:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) by smtp4.osuosl.org (Postfix) with ESMTPS id 1F960415D7 for ; Thu, 17 Jun 2021 22:28:58 +0000 (UTC) Received: by mail-qk1-x72b.google.com with SMTP id j184so6145039qkd.6 for ; Thu, 17 Jun 2021 15:28:58 -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 :cc; bh=7Hs2FnxLh4oYosGifygrFiTdHGARb6y8guMjva9OlNY=; b=BK8u7Lmze0x0Ts28wgDh68Uq+A/CApUXiXHssMWGTxSOIEP5fzP6g3BdWt44SuILKp qE6oMVuv589aoIGFKGprWLNlST/Kcr03jY8SNRh5tdyFZM8p1aHTkNZIqi/OpsUW5JRn MorbGLteSmfaeaNiSBwmk4zAT3/sc0LFNS/0oyqh0OfLWbdVl/ZhPNiBEhw31eO++zEk YIMlkHEAf13n9/6T0EllIhf1K34j9pAYGHjYACWH5vDBR3S4KNJyz82rlmpxOWNXWUoY m2wx+zBO8Rr0aOHDXI62L3U2fqZHK0TzZ6VndVLzYTjA2ebKAYnGcjC4EM0Vx411Xvl1 WBEQ== 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:cc; bh=7Hs2FnxLh4oYosGifygrFiTdHGARb6y8guMjva9OlNY=; b=UeTLMnKZCGgv4kkuO7KHKi8fbWe95UicgKLZ9iOgQzIEpT44deFPv9D/bmEVlG8m4G c03vsNUK3S4282gcAZ08QXMSW4gAOZK/FPaPEvG4uPtvYJqdiNlZae2zXBx7ISpy0z0Z F9K+AOKUwjOV0Frufliz7LnDTNT8tjeA5n/66n1L74D3FHyXVBvCW9lPVZ1gRe/laj0o MZkWsKDYAuhNNekF3U9L+RNO6FKSNeQ+CywH8Y/Ehx9ow1/FU7M0veP1NrWausgaN0Vx teYu83Rxp+cSmFSJwRuAubt6SLLnZITZRf3ey8Audhv5yndaipwTId/q83wFKlxbLJQQ Pznw== X-Gm-Message-State: AOAM530yIpE789A+GX21k1E5GvfVeAVgUeyF/OI/kNwXdoBjQEEJaqZ7 OyiPqHmdsRz47PB7pwsJ9IUy1GjJeqcsauTcnpE= X-Google-Smtp-Source: ABdhPJw0WJo47f9N4NPghWee8U/mhnf+FX0kglh0OppKhn7cjFk/Xyr5gMkqB1H3YUkhQh70HCgdZCGEYLbGCh5aK3s= X-Received: by 2002:a25:d290:: with SMTP id j138mr9004610ybg.468.1623968936912; Thu, 17 Jun 2021 15:28:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Fri, 18 Jun 2021 06:28:45 +0800 Message-ID: To: Billy Tetrud , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000009c6ad705c4fdbb28" 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: Thu, 17 Jun 2021 22:29:00 -0000 --0000000000009c6ad705c4fdbb28 Content-Type: text/plain; charset="UTF-8" Transaction analysis tools do take the signal into account, but I'm unsure if retail, non-custodial wallets use this information. Historically the biggest pushback has been from services like Bitrefill which have had quite a bit of success with 0-conf payments, but perhaps LN adoption is at a point where it's less of an impact? On Fri, Jun 18, 2021 at 4:15 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 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 >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000009c6ad705c4fdbb28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Transaction analysis tools do take the signal into account= , but I'm unsure if retail, non-custodial wallets use this information.=

Historically the biggest pushback has been from service= s like Bitrefill which have had quite a bit of success with 0-conf payments= , but perhaps LN adoption is at a point where it's less of an impact?

On Fri, Jun 18, 2021 at 4:15 AM Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.org> wrote:
Russel O'Connor recently opined that RBF should=C2=A0be standard treatment of a= ll 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 blo= ck 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 o= f security that is likely to actively=C2=A0lead to theft events.=C2=A0
<= div>
Do we as a community want to support 0-conf payments in = any way at this point? It seems rather silly=C2=A0to make software design d= ecisions to accommodate=C2=A00-conf payments when there are better mechanis= ms for fast payments (ie lightning).=C2=A0

One que= stion I have is: how does software generally inform the user about 0-conf p= ayment detection? Does software generally tell the user something along the= lines of "This payment has not been finalized yet. All recipients sho= uld wait until the transaction has at least 1 confirmation, and most recipi= ents should wait for 6 confirmations" ? I think unless we pressure sof= tware 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 suppos= e it would depend on how often 0-conf is used in the bitcoin ecosystem at t= his point, which I don't have any data on.=C2=A0

On Tue, Jun 15, 2= 021 at 10:00 AM Antoine Riard via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
Hi,

I'm writing to propose dep= recation of opt-in RBF in favor of full-RBF as the Bitcoin Core's defau= lt replacement policy in version 24.0. As a reminder, the next release is 2= 2.0, aimed for August 1st, assuming agreement is reached, this policy chang= e would enter into deployment phase a year from now.

Even if this r= eplacement policy has been deemed as highly controversial a few years ago, = ongoing and anticipated changes in the Bitcoin ecosystem are motivating thi= s proposal.

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

As explained in "On Mempool Funny Games against M= ulti-Party Funded Transactions'', 2nd issue [0], an attacker can ea= sily DoS a multi-party funded transactions by propagating an RBF opt-out do= uble-spend of its contributed input before the honest transaction is broadc= asted 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 =C2=A0reserve.

This affects a series of Bitcoin = protocols such as Coinjoin, onchain DLCs and dual-funded LN channels. As th= ose protocols are still in the early phase of deployment, it doesn't se= em 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 exp= ect them to be widely relied on, once Lightning enters in a more mature pha= se. At that point, it should become economically rational for liquidity ser= vice providers to launch those DoS attacks against their competitors to hij= ack user traffic.

Beyond that, presence of those DoSes will complica= te the design and deployment of multi-party Bitcoin protocols such as payme= nt pools/multi-party channels. Note, Lightning Pool isn't affected as t= here is a preliminary stage where batch participants are locked-in their fu= nds within an account witnessScript shared with the orchestrer.

Of c= ourse, even assuming full-rbf, propagation of the multi-party funded transa= ctions can still be interfered with by an attacker, simply broadcasting a d= ouble-spend with a feerate equivalent to the honest transaction. However, i= t tightens the attack scenario to a scorched earth approach, where the atta= cker has to commit equivalent fee-bumping reserve to maintain the pinning a= nd might lose the "competing" fees to miners.

# RBF opt-ou= t 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 differ= ent subsets. From then a wide range of attacks can be envisioned such as pa= ckage 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 estimato= rs designs deployed across the ecosystem are likely going to be affected).<= br>
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 mem= pool for fee-estimation and robust propagation of their time-sensitive tran= sactions might lead to reconsider this position. Acknowledging this, RBF op= t-out is a low-cost partitioning tool, of which the existence nullifies mos= t of potential progresses to mitigate malicious partitioning.


To= resume, opt-in RBF doesn't suit well deployment of robust second-layer= s 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
on 0-confs transactions, even if their security is relyin= g on far weaker assumptions (opt-in RBF rule is a policy rule, not a consen= sus one) [2] A rapid change of Core's mempool rules would be harming th= eir quality of services and should be
weighed carefully. On the other ha= nd, 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 secu= rity models : Double-spend Monitoring/Receiver-side Fee-Topping with Packag= e Relay

From an attacker viewpoint, opt-in RBF isn't a big block= er to successful double-spends. Any motivated attacker can modify Core to m= ass-connect to a wide portion of the network, announce txA to this subset, = announce txA' to the
merchant. TxA' propagation will be encumber= ed by the privacy-preserving inventory timers (`OUTBOUND_INVENTORY_BROADCAS= T_INTERVAL`), of which an attacker has no care to respect.

To detect= a successful double-spend attempt, a Bitcoin service should run few full-n= odes with well-spread connection graphs and unlinkable between them, to avo= id being identified then maliciously partitioned from the rest of the netwo= rk.

I believe this tactic is already deployed by few Bitcoin service= s, and even one can throw flame at it because it over consumes network reso= urces (bandwidth, connection slots, ...), it does procure a security advant= age to the ones doing it.

One further improvement on top of this pro= tection could be to react after the double-spend detection by attaching a C= PFP to the merchant transaction, with a higher package feerate than the dou= ble-spend. Expected deployment of package-relay as a p2p mechanism/mempool = policy in Bitcoin Core should enable it to do so.

# Reactive securit= y models : EconomicReputation-based Compensations

Another approach c= ould be to react after the fact if a double-spend has been qualified. If th= e sender is already known to the service provider, the service account can = be slashed.=C2=A0 If the sender is a low-trusted counterparty to the mercha= nt, "side-trust" models could be relied on. For e.g a LN pubkey w= ith a stacked reputation from your autopilot, LSATs, stake certificates, a = HTLC-as-a-fidelity-bond, ... The space is quite wide there but I foresee th= ose trust-minimized, decentralized solutions being adopted by the LN ecosys= tem to patch the risks when you enter in a channel/HTLC operation with an a= nonymous counterparty.

What other cool new tools could b= e considered to enhance 0-confs security ?

To conclude, l= et's avoid replaying the contentious threads of a few years ago. What t= his new thread highlights is the fact that a transaction relay/mempool acce= ptance policy might be beneficial to some class of already-deployed
Bit= coin applications while being detrimental to newer ones. How do we preserve= the current interests of 0-confs users while enabling upcoming interests o= f 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 con= sistent deprecation process w.r.t to policy rules heavily relied-on by Bitc= oin 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 : htt= ps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.htm= l

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

[3] And the LN ecosyste= m 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/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000009c6ad705c4fdbb28--