path: root/78/3701011b7410674bda233010384b6d689653e5

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B4BFFC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 20:32:03 +0000 (UTC)
Received: by mail-io1-xd2c.google.com with SMTP id e15so10129215iof.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>
In-Reply-To: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 17 Oct 2022 16:31:50 -0400
Message-ID: <CALZpt+H6sS75KWvHTxjhgRnCWM8rTbyUD+um6rUk4W1ev4DHLg@mail.gmail.com>
To: Dario Sneidermanis <dario@muun.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: 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

<div dir=3D"ltr">Hi Dario,<br><br>Sorry for the latency in reply to the rea=
ction about the full-rbf setting I&#39;ve initially pushed in 0.24, TABConf=
 week has been a busy one.<br><br>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.<br><br>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:<br><br><a href=3D"https://lists.linuxfoundation.org/pipermai=
l/lightning-dev/2021-May/003033.html">https://lists.linuxfoundation.org/pip=
ermail/lightning-dev/2021-May/003033.html</a><br><br>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:<br><br><a href=3D"https://github.com/bitcoin/bitcoin/pull/25=
600">https://github.com/bitcoin/bitcoin/pull/25600</a><br><br>This PR doesn=
&#39;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.<br><br>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.<br><br>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:<br><br><a href=3D"https://gi=
thub.com/bitcoin/bitcoin/pull/26305">https://github.com/bitcoin/bitcoin/pul=
l/26305</a><br><br>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.<br><br>A third option proposed has been=
 to withdraw `mempoolfullrbf` setting for 0.24, now withdrawn by its author=
:<br><br><a href=3D"https://github.com/bitcoin/bitcoin/pull/26287">https://=
github.com/bitcoin/bitcoin/pull/26287</a><br><br>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:<br=
><br><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
2-June/020557.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2022-June/020557.html</a><br><br>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.<br><br>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.<br><br>Best,<br>Antoine<br=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>Le=C2=A0ven. 7 oct. 2022 =C3=A0=C2=A012:43, Dario Sneidermanis via bitcoin=
-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hello list,<br><b=
r>I&#39;m Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. F=
or the past<br>few days we&#39;ve been reviewing the latest bitcoin core re=
lease candidate, and we<br>found some troubling facts related to the opt-in=
 full-RBF deployment.<br><br>We first learned about the opt-in full-RBF pro=
posal last June when it was<br>announced on the mailing list. Closing the g=
ap between the protocol&#39;s relay<br>policies and the miner incentives is=
 inevitable, so it was a welcomed addition.<br>Furthermore, allowing transa=
ction replacements that remove the opt-in RBF flag<br>was deeply problemati=
c.<br><br>At the time, we understood we had at least a year from the initia=
l opt-in<br>deployment until opt-out was deployed, giving us enough time to=
 adapt Muun to<br>the new policies. However, when reviewing the 24.0 releas=
e candidate just a few<br>days ago, we realized that zero-conf apps (like M=
uun) must *immediately turn<br>off* their zero-conf features.<br><br>I unde=
rstand this wasn&#39;t the intention when designing the opt-in deployment<b=
r>mechanism. Given this new information, do you see a path where we can del=
ay the<br>opt-in deployment and find a safer way to deploy full-RBF?<br><br=
>It&#39;d be great for this deployment to be a success so that we can conti=
nue fixing<br>the remaining relay policy problems, such as package relay an=
d the RBF rules.<br>Maybe we could go straight to an opt-out deployment loc=
ked by code at a certain<br>height in the future to give time to everyone a=
nd, at the same time, avoid a<br>huge mempool divergence event?<br><br>Belo=
w is our analysis of how zero-conf apps break with opt-in full-RBF. I hope<=
br>it helps.<br><br>Cheers,<br>Dario<br><br><br># How do zero-conf apps wor=
k<br><br>While the workings and trade-offs of zero-conf applications might =
be known by<br>many in this list, it&#39;s useful to define precisely how t=
hey work to understand<br>how they break.<br><br>We call zero-conf applicat=
ions to entities that accept on-chain payments from<br>*untrusted parties* =
and will sometimes deliver the paid-for product or service<br>without waiti=
ng for the transaction to be included in a block.<br><br>Some examples of z=
ero-conf apps:<br><br>- Muun&#39;s submarine swaps for outgoing lightning p=
ayments<br>- Bitrefill&#39;s on-chain payments for gift cards and phone top=
-ups<br>- Many bitcoin ATMs&#39; on-chain deposits for selling bitcoin for =
cash (at least<br>=C2=A0 the two biggest bitcoin ATM manufacturers support =
this: Genesis Coin and<br>=C2=A0 General Byte)<br><br>All of these applicat=
ions are receiving incoming on-chain transactions for which<br>they don&#39=
;t control the inputs, and performing a risk analysis to decide whether<br>=
they are ok with accepting the payment without confirmation.<br><br>In prac=
tice, this works because once the bitcoin P2P network has fully<br>propagat=
ed a non-RBF transaction, you need the collaboration of a miner to<br>repla=
ce it, which isn&#39;t easy to get today. Even though many of the biggest<b=
r>miners offer off-band transaction broadcasting services, they currently w=
on&#39;t<br>process conflicting transactions.<br><br>Roughly, the risk anal=
ysis goes like this:<br><br>1. if an incoming transaction is RBF (direct or=
 inherited)<br>=C2=A0 =C2=A0--&gt; too risky, wait for 1 conf (or more) sin=
ce it can be replaced at any time<br>2. if the payment is for an amount gre=
ater than X<br>=C2=A0 =C2=A0--&gt; too risky, wait for 1 conf (or more), si=
nce the amount is worthy of a<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0sophisticated a=
ttacker<br>3. wait for full(ish) propagation of the incoming transaction<br=
>4. if there&#39;s no double-spend attempt<br>=C2=A0 =C2=A0--&gt; accept 0-=
conf<br><br>As with any other risk analysis, there&#39;s always a false-neg=
ative detection rate,<br>leading to an expected loss, which the zero-conf a=
pp should be willing to bear.<br>Notice that the expected loss is tunable v=
ia the amount X in the above analysis.<br><br><br># Why are zero-conf apps =
not protected with an opt-in deployment<br><br>Full-RBF adoption works on t=
hree different layers:<br><br>- The transaction application layer<br>- The =
transaction relaying layer<br>- The transaction mining layer<br><br>If an a=
pplication wants to replace with full-RBF an *outgoing* transaction, it<br>=
will need:<br><br>- An upgraded node that opted into full-RBF, from which i=
t can broadcast the<br>=C2=A0 replacement transaction<br>- A connected comp=
onent of upgraded nodes that opted into full-RBF, that can<br>=C2=A0 relay =
the replacement transaction<br>- A miner in that connected component with a=
n upgraded node that opted into<br>=C2=A0 full-RBF, that can mine the repla=
cement transaction<br><br>However, an application cannot control whether a =
replacement to an *incoming*<br>transaction is relayed via full-RBF. As soo=
n as a single application can<br>generate replacements easily via full-RBF,=
 all other applications have to assume<br>that any incoming transaction fro=
m an untrusted party might be replaced via<br>full-RBF. That is, for the ap=
plication layer this is a forced upgrade.<br><br>As soon as an unsophistica=
ted attacker can use opt-in full-RBF, the risk<br>analysis performed by zer=
o-conf applications stops working because the<br>transactions to analyze ar=
e all incoming transactions from untrusted parties.<br>Since some wallets a=
lready implement cancel functionality for opt-in RBF<br>transactions, enabl=
ing the same functionality for every transaction wouldn&#39;t<br>require mu=
ch work, making canceling any unconfirmed transaction a one-click<br>experi=
ence. After this, the security model of zero-conf applications goes from<br=
>&quot;susceptible to attacks from miners&quot; to &quot;anyone can perform=
 an attack, with an<br>easy-to-use interface&quot;.<br><br>That is, the opt=
-in deployment of full-RBF doesn&#39;t protect zero-conf<br>applications fr=
om having to turn off their zero-conf features very soon after<br>the initi=
al deployment. All mitigations are mostly ineffective against<br>untrusted =
parties.<br><br><br># Other things we have to fix<br><br>While it&#39;s cle=
ar how full-RBF breaks zero-conf applications, other more subtle<br>things =
break in *many* wallets (Muun included). If given the opportunity, we<br>wo=
uld like to fix them before deployment. One could argue that these things<b=
r>were already broken, but they get considerably worse as the network adopt=
s<br>full-RBF (even with an opt-in deployment), so we should fix them.<br><=
br>## Mental model for unconfirmed incoming transactions<br><br>Many wallet=
s with support for on-chain payments (Muun included) show incoming<br>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<br>disappeared (exchanges doing this is the #1 issue we have to deal=
 with in our<br>customer support channels).<br><br>With full-RBF, wallets s=
hould make it extremely clear to users that unconfirmed<br>funds are not th=
eirs (yet). Otherwise, protocol-unaware users that are<br>transacting on-ch=
ain with untrusted parties can be easily scammed if they don&#39;t<br>know =
they have to wait for a confirmation. Eg. in Argentina, it&#39;s pretty com=
mon<br>to meet someone in person to buy bitcoin P2P for cash, even for newc=
omers.<br><br>## Block explorers as payment receipts<br><br>Most wallets wi=
th support for on-chain payments (Muun included) use the<br>transaction vie=
w of a block explorer as a shareable payment receipt. The sender<br>of an o=
n-chain transaction usually shares this link with the receiver to let<br>th=
em know they made a payment. Protocol-unaware receivers sometimes take this=
<br>link as proof of payment.<br><br>Most explorers currently don&#39;t tra=
ck payment replacements and, more importantly,<br>don&#39;t warn users that=
 unconfirmed funds are not theirs (yet). With full-RBF,<br>wallets should e=
ither stop relying on explorers for this functionality or wait<br>for them =
to support it explicitly.<br><br><br># Impact at Muun<br><br>Work to transi=
tion Muun from using zero-conf submarine swaps to using payment<br>channels=
 is ongoing, but we are still several months away from being production<br>=
ready. This means we would have to turn off outgoing lightning payments for=
<br>+100k monthly active users, which is a good chunk of all users making<b=
r>non-custodial lightning payments today.<br><br>Furthermore, the more subt=
le fixes imply non-trivial amounts of product work<br>that we cannot reason=
ably deploy before they start affecting users.<br><br>While I cannot talk f=
or other applications, there are many impacted in one way<br>or another, an=
d none of the ones I checked with were aware of this change, or<br>its impl=
ications.<br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000003a44fe05eb40de6b--