Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7BC62C002D for ; Mon, 17 Oct 2022 22:15:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 4238D82A72 for ; Mon, 17 Oct 2022 22:15:07 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4238D82A72 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=FK/i1GeN 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 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 VqWPg2BCehLZ for ; Mon, 17 Oct 2022 22:15:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org AF4FB81425 Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) by smtp1.osuosl.org (Postfix) with ESMTPS id AF4FB81425 for ; Mon, 17 Oct 2022 22:15:04 +0000 (UTC) Received: by mail-il1-x134.google.com with SMTP id o13so6571926ilc.7 for ; Mon, 17 Oct 2022 15:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Z/6o7KrBA18MHRph2aXF6ZMhwTM3u0p6UoggGqTUyMA=; b=FK/i1GeNhTxcebU3TPvHwSQ4I3WrV4Gg850guwtVXxoyNnlJOjiKKLud1mM8oy2CWU WdPx9KU9+8iIqfGHsFsAOUkj6uzKed0i82x60xrwTQL6OT72K4vDRf1YsO535I5GIrgU ZjNHHNdO3H/8sQIQSOyi8Z/KqjZNreWWrejK4YmVZeu/vcGpdv9Ew38bxrmt6XsuK8kx HeVoUCle73HR+/SyE94MSCapdqJj/o97oAC/mzRA1ZpeWaxy8Goy9FzCUE5jtBq3bSux E4g61MWZb43SgdA7yTypmTvCK3gZI+HIavkgZnHGifk2U2OLqXXKQbOsNAJyBTUOGy6Q 4OlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Z/6o7KrBA18MHRph2aXF6ZMhwTM3u0p6UoggGqTUyMA=; b=SpEFWlq/U4XpnoIElWJLvZG3kjWstbPKoiwaQdOAB7g9S7oQvGKljJ7PctVRgAwFVx XH8uXnfW5A+PC9Moua+fFlczwGJU4ITLUQtfjUshfVQatahpWVL6NsA1TkfGdEYkLNvx d0LtEUvG0jpxR/JPfOlRpen6Y2gVJMQz51LnynCbRWNhidcs7XmKmq2lPbUjt5BrLP/E yGuzWqq3Mfnb5O300R8P2AGwF1+eZpq0KI+vkMcX7KGfSVo29H6Y+s+5O9DYt90EGmYm OFZQTIGWjr3uaPxH6TGIlN2jlnD9zJ/2+FbLC8GXVNfLBfaO8efEMNZLyZ/HdkEHx69q 0pxQ== X-Gm-Message-State: ACrzQf2gtFLElZqOpddhEpFQQs6SKQLs+rEWj6OWF1f+l9Y2osI27UoM oyouWwC+OWGPyG/MWZ01mNDSfEornqRu91norn2tWQ81TyRbHA== X-Google-Smtp-Source: AMsMyM6uKKeEjftPnqPa7AREdoWwKhABcAImh+X4y76HArLzIOGKKxJWMZpK3wy+FVJM838uYile3ee0JoWotOxJ4i0= X-Received: by 2002:a05:6e02:18c6:b0:2fa:5726:e869 with SMTP id s6-20020a056e0218c600b002fa5726e869mr31862ilu.250.1666044903582; Mon, 17 Oct 2022 15:15:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Mon, 17 Oct 2022 18:14:52 -0400 Message-ID: To: "john@synonym.to" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a8742d05eb424ee6" X-Mailman-Approved-At: Mon, 17 Oct 2022 22:16:39 +0000 Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 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: Mon, 17 Oct 2022 22:15:07 -0000 --000000000000a8742d05eb424ee6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, I hear your worry about RBF issuing concerns for 0conf acceptance merchants. I don't think it has been denied in the first communication of this opt-in rbf proposal back in June. Merchants/0confs builders have been invited to bring voices to the surface at that time [0]. So this new full-RBF proposal has at least tried to bind to best communication standards towards the community at large. If you think about more community venues (Reddit, podcast, newsletter, ...) that developers may weigh in when proposing Core policy changes, we can improve for next time. About the kernel of the concern I understand, I think the whole discussion would benefit from clarifications in precising zero-conf security bounds. Relying only on first-seen and lack of RBF as a solo ground to estimate the safety of an incoming transaction isn't that robust in a distributed system like the p2p network. However, building management risks framework on top, as additional security layers sound a far more compelling approach from a developer perspective. A year ago, when I initially proposed full-rbf, I noted a few ideas that could be implemented such as double-spend monitoring or staked reputation to enhance zero-conf security [1]. For sure, there is a wide solution space to explore and build on to improve the 0conf flows, and it would marginally benefit LN, as we have now zero-conf channels [2]. That said, saying RBF causes more problems than it resolves sounds hard to hold as a line from my perspective. As LN security relies on a reactive model, where time-sensitive transactions must be included before a given height to ensure funds safety, the ability to replace-by-fee previous bids and have them propagating well on the network is fundamental. While I think this is correct to say that today 0conf might be still a more significant economic traffic than Lightning, the bitcoin user of tomorrow is likely to expect both 0conf and Lightning, without caring that much about the quibbles of the security mechanisms backing them. Overall, RBF is far from being a "black-and-white" thing, dependending of the perspective you're coming from, and thanks to everyone for patience in this discussion. Best, Antoine [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.ht= ml [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.ht= ml [2] https://github.com/lightning/bolts/pull/910 Le ven. 7 oct. 2022 =C3=A0 12:43, Dario Sneidermanis via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > Hello list, > > I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For > the past > few days we've been reviewing the latest bitcoin core release candidate, > and we > found some troubling facts related to the opt-in full-RBF deployment. > > We first learned about the opt-in full-RBF proposal last June when it was > announced on the mailing list. Closing the gap between the protocol's rel= ay > policies and the miner incentives is inevitable, so it was a welcomed > addition. > Furthermore, allowing transaction replacements that remove the opt-in RBF > flag > was deeply problematic. > > At the time, we understood we had at least a year from the initial opt-in > deployment until opt-out was deployed, giving us enough time to adapt Muu= n > to > the new policies. However, when reviewing the 24.0 release candidate just > a few > days ago, we realized that zero-conf apps (like Muun) must *immediately > turn > off* their zero-conf features. > > I understand this wasn't the intention when designing the opt-in deployme= nt > mechanism. Given this new information, do you see a path where we can > delay the > opt-in deployment and find a safer way to deploy full-RBF? > > It'd be great for this deployment to be a success so that we can continue > fixing > the remaining relay policy problems, such as package relay and the RBF > rules. > Maybe we could go straight to an opt-out deployment locked by code at a > certain > height in the future to give time to everyone and, at the same time, avoi= d > a > huge mempool divergence event? > > Below is our analysis of how zero-conf apps break with opt-in full-RBF. I > hope > it helps. > > Cheers, > Dario > > > # How do zero-conf apps work > > While the workings and trade-offs of zero-conf applications might be know= n > by > many in this list, it's useful to define precisely how they work to > understand > how they break. > > We call zero-conf applications to entities that accept on-chain payments > from > *untrusted parties* and will sometimes deliver the paid-for product or > service > without waiting for the transaction to be included in a block. > > Some examples of zero-conf apps: > > - Muun's submarine swaps for outgoing lightning payments > - Bitrefill's on-chain payments for gift cards and phone top-ups > - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at > least > the two biggest bitcoin ATM manufacturers support this: Genesis Coin an= d > General Byte) > > All of these applications are receiving incoming on-chain transactions fo= r > which > they don't control the inputs, and performing a risk analysis to decide > whether > they are ok with accepting the payment without confirmation. > > In practice, this works because once the bitcoin P2P network has fully > propagated a non-RBF transaction, you need the collaboration of a miner t= o > replace it, which isn't easy to get today. Even though many of the bigges= t > miners offer off-band transaction broadcasting services, they currently > won't > process conflicting transactions. > > Roughly, the risk analysis goes like this: > > 1. if an incoming transaction is RBF (direct or inherited) > --> too risky, wait for 1 conf (or more) since it can be replaced at > any time > 2. if the payment is for an amount greater than X > --> too risky, wait for 1 conf (or more), since the amount is worthy o= f > a > sophisticated attacker > 3. wait for full(ish) propagation of the incoming transaction > 4. if there's no double-spend attempt > --> accept 0-conf > > As with any other risk analysis, there's always a false-negative detectio= n > rate, > leading to an expected loss, which the zero-conf app should be willing to > bear. > Notice that the expected loss is tunable via the amount X in the above > analysis. > > > # Why are zero-conf apps not protected with an opt-in deployment > > Full-RBF adoption works on three different layers: > > - The transaction application layer > - The transaction relaying layer > - The transaction mining layer > > If an application wants to replace with full-RBF an *outgoing* > transaction, it > will need: > > - An upgraded node that opted into full-RBF, from which it can broadcast > the > replacement transaction > - A connected component of upgraded nodes that opted into full-RBF, that > can > relay the replacement transaction > - A miner in that connected component with an upgraded node that opted in= to > full-RBF, that can mine the replacement transaction > > However, an application cannot control whether a replacement to an > *incoming* > transaction is relayed via full-RBF. As soon as a single application can > generate replacements easily via full-RBF, all other applications have to > assume > that any incoming transaction from an untrusted party might be replaced v= ia > full-RBF. That is, for the application layer this is a forced upgrade. > > As soon as an unsophisticated attacker can use opt-in full-RBF, the risk > analysis performed by zero-conf applications stops working because the > transactions to analyze are all incoming transactions from untrusted > parties. > Since some wallets already implement cancel functionality for opt-in RBF > transactions, enabling the same functionality for every transaction > wouldn't > require much work, making canceling any unconfirmed transaction a one-cli= ck > experience. After this, the security model of zero-conf applications goes > from > "susceptible to attacks from miners" to "anyone can perform an attack, > with an > easy-to-use interface". > > That is, the opt-in deployment of full-RBF doesn't protect zero-conf > applications from having to turn off their zero-conf features very soon > after > the initial deployment. All mitigations are mostly ineffective against > untrusted parties. > > > # Other things we have to fix > > While it's clear how full-RBF breaks zero-conf applications, other more > subtle > things break in *many* wallets (Muun included). If given the opportunity, > we > would like to fix them before deployment. One could argue that these thin= gs > were already broken, but they get considerably worse as the network adopt= s > full-RBF (even with an opt-in deployment), so we should fix them. > > ## Mental model for unconfirmed incoming transactions > > Many wallets with support for on-chain payments (Muun included) show > incoming > external transactions in some way to their users before they confirm. Thi= s > is a > common practice because not showing them leads users to worry that their > money > disappeared (exchanges doing this is the #1 issue we have to deal with in > our > customer support channels). > > With full-RBF, wallets should make it extremely clear to users that > unconfirmed > funds are not theirs (yet). Otherwise, protocol-unaware users that are > transacting on-chain with untrusted parties can be easily scammed if they > don't > know they have to wait for a confirmation. Eg. in Argentina, it's pretty > common > to meet someone in person to buy bitcoin P2P for cash, even for newcomers= . > > ## Block explorers as payment receipts > > Most wallets with support for on-chain payments (Muun included) use the > transaction view of a block explorer as a shareable payment receipt. The > sender > of an on-chain transaction usually shares this link with the receiver to > let > them know they made a payment. Protocol-unaware receivers sometimes take > this > link as proof of payment. > > Most explorers currently don't track payment replacements and, more > importantly, > don't warn users that unconfirmed funds are not theirs (yet). With > full-RBF, > wallets should either stop relying on explorers for this functionality or > wait > for them to support it explicitly. > > > # Impact at Muun > > Work to transition Muun from using zero-conf submarine swaps to using > payment > channels is ongoing, but we are still several months away from being > production > ready. This means we would have to turn off outgoing lightning payments f= or > +100k monthly active users, which is a good chunk of all users making > non-custodial lightning payments today. > > Furthermore, the more subtle fixes imply non-trivial amounts of product > work > that we cannot reasonably deploy before they start affecting users. > > While I cannot talk for other applications, there are many impacted in on= e > way > or another, and none of the ones I checked with were aware of this change= , > or > its implications. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000a8742d05eb424ee6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

I hear your worry about RBF issuing concer= ns for 0conf acceptance merchants. I don't think it has been denied in = the first communication of this opt-in rbf proposal back in June. Merchants= /0confs builders have been invited to bring voices to the surface at that t= ime [0]. So this new full-RBF proposal has at least tried to bind to best c= ommunication standards towards the community at large. If you think about m= ore community venues (Reddit, podcast, newsletter, ...) that developers may= weigh in when proposing Core policy changes, we can improve for next time.=

About the kernel of the concern I understand, I think the whole dis= cussion would benefit from clarifications in precising zero-conf security b= ounds. Relying only on first-seen and lack of RBF as a solo ground to estim= ate the safety of an incoming transaction isn't that robust in a distri= buted system like the p2p network. However, building management risks frame= work on top, as additional security layers sound a far more compelling appr= oach from a developer perspective. A year ago, when I initially proposed fu= ll-rbf, I noted a few ideas that could be implemented such as double-spend = monitoring or staked reputation to enhance zero-conf security [1]. For sure= , there is a wide solution space to explore and build on to improve the 0co= nf flows, and it would marginally benefit LN, as we have now zero-conf chan= nels [2].

That said, saying RBF causes more problems than it resolve= s sounds hard to hold as a line from my perspective. As LN security relies = on a reactive model, where time-sensitive transactions must be included bef= ore a given height to ensure funds safety, the ability to replace-by-fee pr= evious bids and have them propagating well on the network is fundamental. W= hile I think this is correct to say that today 0conf might be still a more = significant economic traffic than Lightning, the bitcoin user of tomorrow i= s likely to expect both 0conf and Lightning, without caring that much about= the quibbles of the security mechanisms backing them.

Overall, RBF = is far from being a "black-and-white" thing, dependending of the = perspective you're coming from, and thanks to everyone for patience in = this discussion.

Best,
Antoine

[0] https://= lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html[1] https://lists.linuxfoundation.org/pipermail/bitcoin-de= v/2021-June/019074.html
[2] https://github.com/lightning/bolts/pull/910
Le=C2=A0= ven. 7 oct. 2022 =C3=A0=C2=A012:43, Dario Sneidermanis via bitcoin-dev <= bitcoin-dev@lists.= linuxfoundation.org> a =C3=A9crit=C2=A0:
Hello list,

I'= m Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For the p= ast
few days we've been reviewing the latest bitcoin core release ca= ndidate, and we
found some troubling facts related to the opt-in full-RB= F deployment.

We first learned about the opt-in full-RBF proposal la= st June when it was
announced on the mailing list. Closing the gap betwe= en the protocol's relay
policies and the miner incentives is inevita= ble, so it was a welcomed addition.
Furthermore, allowing transaction re= placements that remove the opt-in RBF flag
was deeply problematic.
At the time, we understood we had at least a year from the initial opt-in=
deployment until opt-out was deployed, giving us enough time to adapt M= uun to
the new policies. However, when reviewing the 24.0 release candid= ate just a few
days ago, we realized that zero-conf apps (like Muun) mus= t *immediately turn
off* their zero-conf features.

I understand t= his wasn't the intention when designing the opt-in deployment
mechan= ism. Given this new information, do you see a path where we can delay theopt-in deployment and find a safer way to deploy full-RBF?

It'= d be great for this deployment to be a success so that we can continue fixi= ng
the remaining relay policy problems, such as package relay and the RB= F rules.
Maybe we could go straight to an opt-out deployment locked by c= ode at a certain
height in the future to give time to everyone and, at t= he same time, avoid a
huge mempool divergence event?

Below is our= analysis of how zero-conf apps break with opt-in full-RBF. I hope
it he= lps.

Cheers,
Dario


# How do zero-conf apps work
While the workings and trade-offs of zero-conf applications might be known= by
many in this list, it's useful to define precisely how they work= to understand
how they break.

We call zero-conf applications to = entities that accept on-chain payments from
*untrusted parties* and will= sometimes deliver the paid-for product or service
without waiting for t= he transaction to be included in a block.

Some examples of zero-conf= apps:

- Muun's submarine swaps for outgoing lightning payments<= br>- Bitrefill's on-chain payments for gift cards and phone top-ups
= - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at= least
=C2=A0 the two biggest bitcoin ATM manufacturers support this: Ge= nesis Coin and
=C2=A0 General Byte)

All of these applications are= receiving incoming on-chain transactions for which
they don't contr= ol the inputs, and performing a risk analysis to decide whether
they are= ok with accepting the payment without confirmation.

In practice, th= is works because once the bitcoin P2P network has fully
propagated a non= -RBF transaction, you need the collaboration of a miner to
replace it, w= hich isn't easy to get today. Even though many of the biggest
miners= offer off-band transaction broadcasting services, they currently won't=
process conflicting transactions.

Roughly, the risk analysis goe= s like this:

1. if an incoming transaction is RBF (direct or inherit= ed)
=C2=A0 =C2=A0--> too risky, wait for 1 conf (or more) since it ca= n be replaced at any time
2. if the payment is for an amount greater tha= n X
=C2=A0 =C2=A0--> too risky, wait for 1 conf (or more), since the = amount is worthy of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0sophisticated attacker<= br>3. wait for full(ish) propagation of the incoming transaction
4. if t= here's no double-spend attempt
=C2=A0 =C2=A0--> accept 0-conf
=
As with any other risk analysis, there's always a false-negative de= tection rate,
leading to an expected loss, which the zero-conf app shoul= d be willing to bear.
Notice that the expected loss is tunable via the a= mount X in the above analysis.


# Why are zero-conf apps not prot= ected with an opt-in deployment

Full-RBF adoption works on three dif= ferent layers:

- The transaction application layer
- The transact= ion relaying layer
- The transaction mining layer

If an applicati= on wants to replace with full-RBF an *outgoing* transaction, it
will nee= d:

- An upgraded node that opted into full-RBF, from which it can br= oadcast the
=C2=A0 replacement transaction
- A connected component of= upgraded nodes that opted into full-RBF, that can
=C2=A0 relay the repl= acement transaction
- A miner in that connected component with an upgrad= ed node that opted into
=C2=A0 full-RBF, that can mine the replacement t= ransaction

However, an application cannot control whether a replacem= ent to an *incoming*
transaction is relayed via full-RBF. As soon as a s= ingle application can
generate replacements easily via full-RBF, all oth= er applications have to assume
that any incoming transaction from an unt= rusted party might be replaced via
full-RBF. That is, for the applicatio= n layer this is a forced upgrade.

As soon as an unsophisticated atta= cker can use opt-in full-RBF, the risk
analysis performed by zero-conf a= pplications stops working because the
transactions to analyze are all in= coming transactions from untrusted parties.
Since some wallets already i= mplement cancel functionality for opt-in RBF
transactions, enabling the = same functionality for every transaction wouldn't
require much work,= making canceling any unconfirmed transaction a one-click
experience. Af= ter this, the security model of zero-conf applications goes from
"s= usceptible to attacks from miners" to "anyone can perform an atta= ck, with an
easy-to-use interface".

That is, the opt-in depl= oyment of full-RBF doesn't protect zero-conf
applications from havin= g to turn off their zero-conf features very soon after
the initial deplo= yment. All mitigations are mostly ineffective against
untrusted parties.=


# Other things we have to fix

While it's clear how f= ull-RBF breaks zero-conf applications, other more subtle
things break in= *many* wallets (Muun included). If given the opportunity, we
would like= to fix them before deployment. One could argue that these things
were a= lready broken, but they get considerably worse as the network adopts
ful= l-RBF (even with an opt-in deployment), so we should fix them.

## Me= ntal model for unconfirmed incoming transactions

Many wallets with s= upport for on-chain payments (Muun included) show incoming
external tran= sactions in some way to their users before they confirm. This is a
commo= n practice because not showing them leads users to worry that their moneydisappeared (exchanges doing this is the #1 issue we have to deal with in= our
customer support channels).

With full-RBF, wallets should ma= ke it extremely clear to users that unconfirmed
funds are not theirs (ye= t). Otherwise, protocol-unaware users that are
transacting on-chain with= untrusted parties can be easily scammed if they don't
know they hav= e to wait for a confirmation. Eg. in Argentina, it's pretty common
t= o meet someone in person to buy bitcoin P2P for cash, even for newcomers.
## Block explorers as payment receipts

Most wallets with suppo= rt for on-chain payments (Muun included) use the
transaction view of a b= lock explorer as a shareable payment receipt. The sender
of an on-chain = transaction usually shares this link with the receiver to let
them know = they made a payment. Protocol-unaware receivers sometimes take this
link= as proof of payment.

Most explorers currently don't track payme= nt replacements and, more importantly,
don't warn users that unconfi= rmed funds are not theirs (yet). With full-RBF,
wallets should either st= op relying on explorers for this functionality or wait
for them to suppo= rt it explicitly.


# Impact at Muun

Work to transition Muu= n from using zero-conf submarine swaps to using payment
channels is ongo= ing, but we are still several months away from being production
ready. T= his means we would have to turn off outgoing lightning payments for
+100= k monthly active users, which is a good chunk of all users making
non-cu= stodial lightning payments today.

Furthermore, the more subtle fixes= imply non-trivial amounts of product work
that we cannot reasonably dep= loy before they start affecting users.

While I cannot talk for other= applications, there are many impacted in one way
or another, and none o= f the ones I checked with were aware of this change, or
its implications= .
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000a8742d05eb424ee6--