Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id A99C9C000E for ; Fri, 25 Jun 2021 00:23:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8BF1583BD5 for ; Fri, 25 Jun 2021 00:23:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIiNslz-u0Bu for ; Fri, 25 Jun 2021 00:23:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by smtp1.osuosl.org (Postfix) with ESMTPS id 7F5A783BD3 for ; Fri, 25 Jun 2021 00:23:14 +0000 (UTC) Received: by mail-wm1-x32f.google.com with SMTP id w13so5135316wmc.3 for ; Thu, 24 Jun 2021 17:23:14 -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=qgcO5FKe3DqrvPf6sa/gvPa3E9Ro6Lwc8c1mKLkI5kA=; b=XkDLe3Q/VDGQrPexjly8t6r3zziTnYKXfAB1B8+Vml2fwlT4hlTIbAGqcHzU5riG2z O/NcO4uBYCF2+Mz7ej4fLEDY0HjFotu+RrMkV2Z/zAU+lbFHtDxsKPW02mzLwJfmG4dk gz4ctdI/1kZv4kSjipTKuCpbP0sNw5r2qx9WueZQpj2X/bpr6LRMH+k5D/6DQ5Fn+FKd YSreripsFXU6UygdC98sZgpnnmNqHvI9gmFB3cXjjlHM25Xq8JN559yddUMQDggRrVlI w/4OrbrIqbcjhMV1IXrwOw4z34tWsUaCaY9L/atBWgYj2uFY/zERSWv+mubShjt/VcWp dQVw== 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=qgcO5FKe3DqrvPf6sa/gvPa3E9Ro6Lwc8c1mKLkI5kA=; b=Juh8jg/FuAiSQKoAd/JGCWn/QZ7WZprmf1HmO2VojB+9aQ3ZGrSY3sgYzhrneFblUL 6RJFL0ia/92HJespg+VVbIyXvo6gdZWh2TfWB8eWY8AcXef09CkNnfgNpko6to1Yz1+v TgwCiInqjOW8KXpGvgbJDIJZ4D/wAwT0vQLZnwwxyTxBAW7m4LgEvpZEhJm0gqeHBQVn qT+aJK8lmMTHmyHqqg/l5YHipvbXmOioyZI6nNdUu4fyp+4uAeNIrsyIceJ2hnt1J/pj FpBF4iJZXWhefoZ01QsDyfntbggMuM2dNeHkHp3fROzlHbexOndSbvFzSZg/28lkmtte TR6A== X-Gm-Message-State: AOAM532JvwI8TsZqkfQS1Bxe1fFV9SWWia9A4EZ38YWrCxMdcha+31wN zEPCWcQlw2naeYAMCXZ9Yp51Ld9KQCe/AMqBNXs= X-Google-Smtp-Source: ABdhPJw1pt53kFNmvf9wlcOw6Ozpxmp6JfC4Ajbsj3nVkBf8Tsmpvn/M0RD/irKX1tSIfzw3ahAq/iiO4lSZ932U1KI= X-Received: by 2002:a05:600c:22cf:: with SMTP id 15mr7293371wmg.177.1624580592742; Thu, 24 Jun 2021 17:23:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Thu, 24 Jun 2021 20:23:01 -0400 Message-ID: To: Billy Tetrud Content-Type: multipart/alternative; boundary="00000000000023b3ad05c58c2546" X-Mailman-Approved-At: Fri, 25 Jun 2021 07:29:02 +0000 Cc: Bitcoin Protocol Discussion 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: Fri, 25 Jun 2021 00:23:16 -0000 --00000000000023b3ad05c58c2546 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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). 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 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 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 lot 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 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 likel= y > 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 recipien= ts > 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 pha= se >> 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 attack= er >> 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 DLC= s >> 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 f= or >> 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 Do= S >> 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 eart= h >> approach, where the attacker has to commit equivalent fee-bumping reserv= e >> 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 relie= s >> on block confirmation, though other fee estimators designs deployed acro= ss >> 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 aw= are >> it has been studied in-depth for adversarial purposes. Though, deploymen= t >> of second-layer >> protocols, heavily relying on sanity of a local mempool for >> fee-estimation and robust propagation of their time-sensitive transactio= ns >> 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 ru= n >> few full-nodes with well-spread connection graphs and unlinkable between >> them, to avoid being identified then maliciously partitioned from the re= st >> 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 resource= s >> (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 afte= r >> the double-spend detection by attaching a CPFP to the merchant transacti= on, >> 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. Fo= r >> e.g a LN pubkey with a stacked reputation from your autopilot, LSATs, st= ake >> certificates, a HTLC-as-a-fidelity-bond, ... The space is quite wide the= re >> but I foresee those trust-minimized, decentralized solutions being adopt= ed >> 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 securit= y >> ? >> >> To conclude, let's avoid replaying the contentious threads of a few year= s >> 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 thi= nk. >> >> If there is ecosystem agreement on switching to full-RBF, but 0.24 sound= s >> too early, let's defer it to 0.25 or 0.26. I don't think Core has a >> consistent deprecation process w.r.t to policy rules heavily relied-on b= y >> Bitcoin users, if we do so let sets a precedent satisfying as many folks= as >> we can. >> >> Cheers, >> Antoine >> >> [0] >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00303= 3.html >> >> [1] See scenario 3 : >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/0027= 58.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 >> > --00000000000023b3ad05c58c2546 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Do we as a community want to support 0-conf payments = in any way at this
> point? It seems rather silly to make software de= sign 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 sh= ould be buried under a few blocks, though few services providers are offeri= ng zero-conf channels, where you can start to spend instantly [0]. I believ= e 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 u= ser about
0-conf payment detection?

Yes generally it's someth= ing like an "Unconfirmed" annotation on incoming txn, though at l= east 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 a= re few Bitcoin services well-known to rely on 0-conf. Beyond how much of th= e Bitcoin traffic is tied to a 0-conf is a hard question, a lot 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.
<= br>I'll see if I can come up with some Fermi estimation on this front.<= br>
[0] https= ://www.bitrefill.com/thor-turbo-channels/

Le=C2=A0mer. 16 juin 2021 = =C3=A0=C2=A020:58, Billy Tetrud <billy.tetrud@gmail.com> a =C3=A9crit=C2=A0:
Russel O'Connor = recently opined that RBF should=C2=A0b= e 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 als= o 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=C2=A0lead to= theft events.=C2=A0

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

One question I have is: how does software generally infor= m the user about 0-conf payment detection? Does software generally tell the= user something along the lines of "This payment has not been finalize= d yet. All recipients should wait until the transaction has at least 1 conf= irmation, and most recipients should wait for 6 confirmations" ? I thi= nk unless we pressure software to be very explicit about what counts as fin= ality, users will simply continue to do what they've always done. Rolli= ng out this policy change over the course of a year or two seems fine, no n= eed to rush. But I suppose it would depend on how often 0-conf is used in t= he bitcoin ecosystem at this point, which I don't have any data on.=C2= =A0

On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev <= ;bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi,

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.

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.

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

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.

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.

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.

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.

# RBF opt-out as a Mempools Partitions Vector

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).

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
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.


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
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
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 c= ould be deployed ecosystem-wise as enhancements to the 0-confs security mod= el.

# Proactive security models : Double-spend Monitoring/Receiver-s= ide Fee-Topping with Package Relay

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
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.

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.

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.

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= .

# Reactive security models : EconomicReputation-based Compensation= s

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.

What o= ther 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 tra= nsaction relay/mempool acceptance policy might be beneficial to some class = of already-deployed
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.

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.

Cheers,
Antoine

[0] https://lists.linuxfoundation.org/pipermail/lig= htning-dev/2021-May/003033.html

[1] See scenario 3 : https://lists.linuxfoundation.org/pipermail/lightni= ng-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 securi= ty, 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
--00000000000023b3ad05c58c2546--