Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B4BFFC002D for ; Mon, 17 Oct 2022 20:32:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 7AC2D400E4 for ; Mon, 17 Oct 2022 20:32:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7AC2D400E4 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=RmWwnN/j 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMra7a2p5KNK for ; Mon, 17 Oct 2022 20:32:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 583ED400D0 Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by smtp2.osuosl.org (Postfix) with ESMTPS id 583ED400D0 for ; Mon, 17 Oct 2022 20:32:03 +0000 (UTC) Received: by mail-io1-xd2c.google.com with SMTP id e15so10129215iof.2 for ; Mon, 17 Oct 2022 13:32:03 -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=C5JgC0NJy6cNFMbDvqmexS3ZxwfbzIEy7PbAy5ELhaU=; b=RmWwnN/j7sw+vmnc+qWR19/dDFPby4j4e/HWWyCXhl/tMJlUtkO/tCFoBJDfabO4NK EtQiljPWnbgj8AQX60yHDhfTOwXxv2TNTlpQrYcPXHhksWOtoC5N7zUCAtJVTAc4tQnN BApXwVCXV3eX5B2dtcnIC/ubhfrgkyN2lAFk6nz99ZNzUke5/5ldlOeR80mQObOjfLf1 dMi/eeVCuyQC9bRFr0Wfxivjs854m+prErBRyOd0GE8h4jKciuDxjckE7k9XyW+NGn77 sqUG1ZVOmM9hBSbBgMDxZLn44gPRtpzrS+jYFkhtq1Xkccx11pZsQD0uDdFDSc9DQhY4 D5RQ== 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=C5JgC0NJy6cNFMbDvqmexS3ZxwfbzIEy7PbAy5ELhaU=; b=28d6XfrvP0GFNKtzeSn5f76MXECuf0kTpZUfsiGOqIVF1fn8MHjK7v5RjMTWvNrlif BCMRsWrxDUz64B1EKuAyrfwmbEc94m0QvwASWU+gUnr2Cxn1av7MCZZfQxueUOnhsJ4V QDb9XLS8lJGQOxQPxFbiMVVGGoErO65BijwHYXLeZXTVfti+qlp1ESsmohti+3azJwg8 sBW6LJ/Jzf/HV/4sRNIgf9n/nsw4jmVqC+Klhl5IprWn4i3vdCKn2TRoPxtp5Mg9Jk1b 1ZLytAkyAOHmGGalAzZQgfPSpPP8lesLy5o6zrH/Ie04xG0LpR8b41G/9qdWf10KrEB6 CXgA== X-Gm-Message-State: ACrzQf2fvvKfWFxucqMgnnQ7iROwuMQu3e0pY5kUNw4frhSewtYf72Bv hEG0SfOCfywa1uJfklm4p4N1/h+jYouYZA0w80joxEEQeCs4RQ== X-Google-Smtp-Source: AMsMyM4yDjGv3ZlqV1+MCszxxovLHynC6ZZehSOOX1wxF4W6oo+4Mfp4Sxjxp8DjGKbJ1wlpJVRTwE6ZLhTgGLonsoo= X-Received: by 2002:a5e:d506:0:b0:6a4:b8b3:a6f0 with SMTP id e6-20020a5ed506000000b006a4b8b3a6f0mr5354617iom.138.1666038722346; Mon, 17 Oct 2022 13:32:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Mon, 17 Oct 2022 16:31:50 -0400 Message-ID: To: Dario Sneidermanis , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003a44fe05eb40de6b" X-Mailman-Approved-At: Mon, 17 Oct 2022 20:34:15 +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 20:32:05 -0000 --0000000000003a44fe05eb40de6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dario, Sorry for the latency in reply to the reaction about the full-rbf setting I've initially pushed in 0.24, TABConf week has been a busy one. From my understanding, there is no disagreement from Muun wallet about the gradual deployment of full-rbf by Bitcoin Core nodes, this is more a question of timeline to allow the zero-conf apps ecosystem to do the overhaul required. To recall, my initial motivation to deprecate opt-in RBF over the whole network is to mitigate a low-cost and easy DoS vector affecting the funding phase of multi-party contracting protocols: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.h= tml As of current, upcoming Bitcoin Core 0.24 release, a `mempoolfullrbf` setting is introduced defaulting to false. This option allows a node to accept transaction replace-by-fee without requiring replaceability signaling. If we assume a reasonable social inertia among Bitcoin Core node operators, full-rbf transaction-relay paths should be rare. To palliate to this concern, the introduction of a temporary `NODE_FULL_RBF` service bit and automated preferential peering is proposed with: https://github.com/bitcoin/bitcoin/pull/25600 This PR doesn't make the assumption that full-rbf is wished by the majority of the network of node operators and rather favors an opt-in full-rbf deployment. The existence of few full-rbf transaction-relay paths and mining hashrate is sufficient to achieve mitigation of the DoS vector. As #25600 boosts the deployment of full-rbf transaction-relay paths, and induces a side-effect of a weakening of zero-conf apps, I can understand this is not the approach offering the more visibility and predictability to zero-conf operators. Since then two more approaches have been proposed, a 1st one turning on by default `mempoolsetting`, at best to land in 25.0, i.e ~6 months now following the usual Core release schedule: https://github.com/bitcoin/bitcoin/pull/26305 A 2nd one making full-rbf by default at a flag day target, 1st May 2023, aimed to land in 0.24, and as such giving a clear time point to zero-conf node operators now. A third option proposed has been to withdraw `mempoolfullrbf` setting for 0.24, now withdrawn by its author: https://github.com/bitcoin/bitcoin/pull/26287 While in theory, the release process about new policy changes should stay flexible to correct the unforeseen impacts of policy changes, in the present case the implications on zero-conf services have been raised early on when the changes were brought in Bitcoin Core, i.e 4 months ago. Communication has been posted on this venue to invite zero-conf node operators to express concerns at that time: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.ht= ml On a procedural point, I think this is a reasonable standard, navigating in an area where there are not that many precedents about the deprecation of a Core policy rule. Asking to the wider community of zero-conf node operators, among all the approaches, what has the most likes and what other decision-making factors should be considered. It is especially interesting if a 6 month time buffer from now is sufficient for the zero-conf applications to upgrade, and if not what are the concrete engineering or operational bottlenecks. Best, Antoine 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 > --0000000000003a44fe05eb40de6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dario,

Sorry for the latency in reply to the rea= ction about the full-rbf setting I've initially pushed in 0.24, TABConf= week has been a busy one.

From my understanding, there is no disagr= eement from Muun wallet about the gradual deployment of full-rbf by Bitcoin= Core nodes, this is more a question of timeline to allow the zero-conf app= s ecosystem to do the overhaul required.

To recall, my initial motiv= ation to deprecate opt-in RBF over the whole network is to mitigate a low-c= ost and easy DoS vector affecting the funding phase of multi-party contract= ing protocols:

https://lists.linuxfoundation.org/pip= ermail/lightning-dev/2021-May/003033.html

As of current, upcomin= g Bitcoin Core 0.24 release, a `mempoolfullrbf` setting is introduced defau= lting to false. This option allows a node to accept transaction replace-by-= fee without requiring replaceability signaling. If we assume a reasonable s= ocial inertia among Bitcoin Core node operators, full-rbf transaction-relay= paths should be rare. To palliate to this concern, the introduction of a t= emporary `NODE_FULL_RBF` service bit and automated preferential peering is = proposed with:

https://github.com/bitcoin/bitcoin/pull/25600

This PR doesn= 't make the assumption that full-rbf is wished by the majority of the n= etwork of node operators and rather favors an opt-in full-rbf deployment. T= he existence of few full-rbf transaction-relay paths and mining hashrate is= sufficient to achieve mitigation of the DoS vector.

As #25600 boost= s the deployment of full-rbf transaction-relay paths, and induces a side-ef= fect of a weakening of zero-conf apps, I can understand this is not the app= roach offering the more visibility and predictability to zero-conf operator= s.

Since then two more approaches have been proposed, a 1st one turn= ing on by default `mempoolsetting`, at best to land in 25.0, i.e ~6 months = now following the usual Core release schedule:

https://github.com/bitcoin/bitcoin/pul= l/26305

A 2nd one making full-rbf by default at a flag day targe= t, 1st May 2023, aimed to land in 0.24, and as such giving a clear time poi= nt to zero-conf node operators now.

A third option proposed has been= to withdraw `mempoolfullrbf` setting for 0.24, now withdrawn by its author= :

https://= github.com/bitcoin/bitcoin/pull/26287

While in theory, the relea= se process about new policy changes should stay flexible to correct the unf= oreseen impacts of policy changes, in the present case the implications on = zero-conf services have been raised early on when the changes were brought = in Bitcoin Core, i.e 4 months ago. Communication has been posted on this ve= nue to invite zero-conf node operators to express concerns at that time:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev= /2022-June/020557.html

On a procedural point, I think this is a = reasonable standard, navigating in an area where there are not that many pr= ecedents about the deprecation of a Core policy rule.

Asking to the = wider community of zero-conf node operators, among all the approaches, what= has the most likes and what other decision-making factors should be consid= ered. It is especially interesting if a 6 month time buffer from now is suf= ficient for the zero-conf applications to upgrade, and if not what are the = concrete engineering or operational bottlenecks.

Best,
Antoine

Le=C2=A0ven. 7 oct. 2022 =C3=A0=C2=A012:43, Dario Sneidermanis via bitcoin= -dev <bitcoin-d= ev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
Hello list,
I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. F= or the past
few days we've been reviewing the latest bitcoin core re= lease candidate, and we
found some troubling facts related to the opt-in= full-RBF deployment.

We first learned about the opt-in full-RBF pro= posal last June when it was
announced on the mailing list. Closing the g= ap between the protocol's relay
policies and the miner incentives is= inevitable, so it was a welcomed addition.
Furthermore, allowing transa= ction replacements that remove the opt-in RBF flag
was deeply problemati= c.

At the time, we understood we had at least a year from the initia= l opt-in
deployment until opt-out was deployed, giving us enough time to= adapt Muun to
the new policies. However, when reviewing the 24.0 releas= e candidate just a few
days ago, we realized that zero-conf apps (like M= uun) must *immediately turn
off* their zero-conf features.

I unde= rstand this wasn't the intention when designing the opt-in deploymentmechanism. Given this new information, do you see a path where we can del= ay 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 conti= nue fixing
the remaining relay policy problems, such as package relay an= d the RBF rules.
Maybe we could go straight to an opt-out deployment loc= ked by code at a certain
height in the future to give time to everyone a= nd, at the same time, avoid a
huge mempool divergence event?

Belo= w is our analysis of how zero-conf apps break with opt-in full-RBF. I hope<= br>it helps.

Cheers,
Dario


# How do zero-conf apps wor= k

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 t= hey work to understand
how they break.

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

Some examples of z= ero-conf apps:

- Muun's submarine swaps for outgoing lightning p= ayments
- 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: Genesis Coin and
=C2=A0 General Byte)

All of these applicat= ions are receiving incoming on-chain transactions for 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 prac= tice, this works because once the bitcoin P2P network has fully
propagat= ed a non-RBF transaction, you need the collaboration of a miner to
repla= ce it, which isn't easy to get today. Even though many of the biggestminers offer off-band transaction broadcasting services, they currently w= on't
process conflicting transactions.

Roughly, the risk anal= ysis goes like this:

1. if an incoming transaction is RBF (direct or= inherited)
=C2=A0 =C2=A0--> too risky, wait for 1 conf (or more) sin= ce it can be replaced at any time
2. if the payment is for an amount gre= ater than X
=C2=A0 =C2=A0--> too risky, wait for 1 conf (or more), si= nce the amount is worthy of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0sophisticated a= ttacker
3. wait for full(ish) propagation of the incoming transaction4. if there's no double-spend attempt
=C2=A0 =C2=A0--> accept 0-= conf

As with any other risk analysis, there's always a false-neg= ative detection rate,
leading to an expected loss, which the zero-conf a= pp should be willing to bear.
Notice that the expected loss is tunable v= ia the amount X in the above analysis.


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

Full-RBF adoption works on t= hree different layers:

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

If an a= pplication wants to replace with full-RBF an *outgoing* transaction, it
= will need:

- An upgraded node that opted into full-RBF, from which i= t can broadcast the
=C2=A0 replacement transaction
- A connected comp= onent of upgraded nodes that opted into full-RBF, that can
=C2=A0 relay = the replacement transaction
- A miner in that connected component with a= n upgraded node that opted into
=C2=A0 full-RBF, that can mine the repla= cement transaction

However, an application cannot control whether a = replacement to an *incoming*
transaction is relayed via full-RBF. As soo= n as a single application can
generate replacements easily via full-RBF,= all other applications have to assume
that any incoming transaction fro= m an untrusted party might be replaced via
full-RBF. That is, for the ap= plication layer this is a forced upgrade.

As soon as an unsophistica= ted attacker can use opt-in full-RBF, the risk
analysis performed by zer= o-conf applications stops working because the
transactions to analyze ar= e all incoming transactions from untrusted parties.
Since some wallets a= lready implement cancel functionality for opt-in RBF
transactions, enabl= ing the same functionality for every transaction wouldn't
require mu= ch work, making canceling any unconfirmed transaction a one-click
experi= ence. 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 fr= om having to turn off their zero-conf features very soon after
the initi= al deployment. All mitigations are mostly ineffective against
untrusted = parties.


# Other things we have to fix

While it's cle= ar how full-RBF breaks zero-conf applications, other more subtle
things = break in *many* wallets (Muun included). If given the opportunity, we
wo= uld like to fix them before deployment. One could argue that these thingswere 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.
<= br>## Mental model for unconfirmed incoming transactions

Many wallet= s with support for on-chain payments (Muun included) show incoming
exter= nal transactions in some way to their users before they confirm. This is a<= br>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 s= hould make it extremely clear to users that unconfirmed
funds are not th= eirs (yet). Otherwise, protocol-unaware users that are
transacting on-ch= ain 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 com= mon
to meet someone in person to buy bitcoin P2P for cash, even for newc= omers.

## Block explorers as payment receipts

Most wallets wi= th support for on-chain payments (Muun included) use the
transaction vie= w of a block explorer as a shareable payment receipt. The sender
of an o= n-chain transaction usually shares this link with the receiver to let
th= em know they made a payment. Protocol-unaware receivers sometimes take this=
link as proof of payment.

Most explorers currently don't tra= ck payment replacements and, more importantly,
don't warn users that= unconfirmed funds are not theirs (yet). With full-RBF,
wallets should e= ither stop relying on explorers for this functionality or wait
for them = to support it explicitly.


# Impact at Muun

Work to transi= tion 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 for=
+100k monthly active users, which is a good chunk of all users makingnon-custodial lightning payments today.

Furthermore, the more subt= le fixes imply non-trivial amounts of product work
that we cannot reason= ably deploy before they start affecting users.

While I cannot talk f= or other applications, there are many impacted in one way
or another, an= d none of the ones I checked with were aware of this change, or
its impl= ications.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000003a44fe05eb40de6b--