path: root/8f/4ad5229a5465cbe979ca90b7e4c42f395e4293

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7BC62C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 22:15:04 +0000 (UTC)
Received: by mail-il1-x134.google.com with SMTP id o13so6571926ilc.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <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 18:14:52 -0400
Message-ID: <CALZpt+HXMebcKg1kiN_TP-YHfzw+OTr5Jn0JowmsWkUO2VJstA@mail.gmail.com>
To: "john@synonym.to" <john@synonym.to>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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 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

<div dir=3D"ltr">Hi John,<br><br>I hear your worry about RBF issuing concer=
ns for 0conf acceptance merchants. I don&#39;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.=
<br><br>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&#39;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].<br><br>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.<br><br>Overall, RBF =
is far from being a &quot;black-and-white&quot; thing, dependending of the =
perspective you&#39;re coming from, and thanks to everyone for patience in =
this discussion.<br><br>Best,<br>Antoine<br><br>[0] <a href=3D"https://list=
s.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html">https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html</a><b=
r>[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
21-June/019074.html">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2021-June/019074.html</a><br>[2] <a href=3D"https://github.com/lightning/=
bolts/pull/910">https://github.com/lightning/bolts/pull/910</a><br></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0=
ven. 7 oct. 2022 =C3=A0=C2=A012:43, Dario Sneidermanis via bitcoin-dev &lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hello list,<br><br>I&#39;=
m Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For the p=
ast<br>few days we&#39;ve been reviewing the latest bitcoin core release ca=
ndidate, and we<br>found some troubling facts related to the opt-in full-RB=
F deployment.<br><br>We first learned about the opt-in full-RBF proposal la=
st June when it was<br>announced on the mailing list. Closing the gap betwe=
en the protocol&#39;s relay<br>policies and the miner incentives is inevita=
ble, so it was a welcomed addition.<br>Furthermore, allowing transaction re=
placements that remove the opt-in RBF flag<br>was deeply problematic.<br><b=
r>At the time, we understood we had at least a year from the initial opt-in=
<br>deployment until opt-out was deployed, giving us enough time to adapt M=
uun to<br>the new policies. However, when reviewing the 24.0 release candid=
ate just a few<br>days ago, we realized that zero-conf apps (like Muun) mus=
t *immediately turn<br>off* their zero-conf features.<br><br>I understand t=
his wasn&#39;t the intention when designing the opt-in deployment<br>mechan=
ism. Given this new information, do you see a path where we can delay the<b=
r>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 continue fixi=
ng<br>the remaining relay policy problems, such as package relay and the RB=
F rules.<br>Maybe we could go straight to an opt-out deployment locked by c=
ode at a certain<br>height in the future to give time to everyone and, at t=
he same time, avoid a<br>huge mempool divergence event?<br><br>Below is our=
 analysis of how zero-conf apps break with opt-in full-RBF. I hope<br>it he=
lps.<br><br>Cheers,<br>Dario<br><br><br># How do zero-conf apps work<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 they work=
 to understand<br>how they break.<br><br>We call zero-conf applications to =
entities that accept on-chain payments from<br>*untrusted parties* and will=
 sometimes deliver the paid-for product or service<br>without waiting for t=
he transaction to be included in a block.<br><br>Some examples of zero-conf=
 apps:<br><br>- Muun&#39;s submarine swaps for outgoing lightning payments<=
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: Ge=
nesis Coin and<br>=C2=A0 General Byte)<br><br>All of these applications are=
 receiving incoming on-chain transactions for which<br>they don&#39;t contr=
ol the inputs, and performing a risk analysis to decide whether<br>they are=
 ok with accepting the payment without confirmation.<br><br>In practice, th=
is works because once the bitcoin P2P network has fully<br>propagated a non=
-RBF transaction, you need the collaboration of a miner to<br>replace it, w=
hich isn&#39;t easy to get today. Even though many of the biggest<br>miners=
 offer off-band transaction broadcasting services, they currently won&#39;t=
<br>process conflicting transactions.<br><br>Roughly, the risk analysis goe=
s like this:<br><br>1. if an incoming transaction is RBF (direct or inherit=
ed)<br>=C2=A0 =C2=A0--&gt; too risky, wait for 1 conf (or more) since it ca=
n be replaced at any time<br>2. if the payment is for an amount greater tha=
n X<br>=C2=A0 =C2=A0--&gt; too risky, wait for 1 conf (or more), since the =
amount is worthy of a<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0sophisticated attacker<=
br>3. wait for full(ish) propagation of the incoming transaction<br>4. if t=
here&#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-negative de=
tection rate,<br>leading to an expected loss, which the zero-conf app shoul=
d be willing to bear.<br>Notice that the expected loss is tunable via the a=
mount X in the above analysis.<br><br><br># Why are zero-conf apps not prot=
ected with an opt-in deployment<br><br>Full-RBF adoption works on three dif=
ferent layers:<br><br>- The transaction application layer<br>- The transact=
ion relaying layer<br>- The transaction mining layer<br><br>If an applicati=
on wants to replace with full-RBF an *outgoing* transaction, it<br>will nee=
d:<br><br>- An upgraded node that opted into full-RBF, from which it can br=
oadcast the<br>=C2=A0 replacement transaction<br>- A connected component of=
 upgraded nodes that opted into full-RBF, that can<br>=C2=A0 relay the repl=
acement transaction<br>- A miner in that connected component with an upgrad=
ed node that opted into<br>=C2=A0 full-RBF, that can mine the replacement t=
ransaction<br><br>However, an application cannot control whether a replacem=
ent to an *incoming*<br>transaction is relayed via full-RBF. As soon as a s=
ingle application can<br>generate replacements easily via full-RBF, all oth=
er applications have to assume<br>that any incoming transaction from an unt=
rusted party might be replaced via<br>full-RBF. That is, for the applicatio=
n layer this is a forced upgrade.<br><br>As soon as an unsophisticated atta=
cker can use opt-in full-RBF, the risk<br>analysis performed by zero-conf a=
pplications stops working because the<br>transactions to analyze are all in=
coming transactions from untrusted parties.<br>Since some wallets already i=
mplement cancel functionality for opt-in RBF<br>transactions, enabling the =
same functionality for every transaction wouldn&#39;t<br>require much work,=
 making canceling any unconfirmed transaction a one-click<br>experience. Af=
ter this, the security model of zero-conf applications goes from<br>&quot;s=
usceptible to attacks from miners&quot; to &quot;anyone can perform an atta=
ck, with an<br>easy-to-use interface&quot;.<br><br>That is, the opt-in depl=
oyment of full-RBF doesn&#39;t protect zero-conf<br>applications from havin=
g to turn off their zero-conf features very soon after<br>the initial deplo=
yment. All mitigations are mostly ineffective against<br>untrusted parties.=
<br><br><br># Other things we have to fix<br><br>While it&#39;s clear how f=
ull-RBF breaks zero-conf applications, other more subtle<br>things break in=
 *many* wallets (Muun included). If given the opportunity, we<br>would like=
 to fix them before deployment. One could argue that these things<br>were a=
lready broken, but they get considerably worse as the network adopts<br>ful=
l-RBF (even with an opt-in deployment), so we should fix them.<br><br>## Me=
ntal model for unconfirmed incoming transactions<br><br>Many wallets with s=
upport for on-chain payments (Muun included) show incoming<br>external tran=
sactions in some way to their users before they confirm. This is a<br>commo=
n practice because not showing them leads users to worry that their money<b=
r>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 should ma=
ke it extremely clear to users that unconfirmed<br>funds are not theirs (ye=
t). Otherwise, protocol-unaware users that are<br>transacting on-chain with=
 untrusted parties can be easily scammed if they don&#39;t<br>know they hav=
e to wait for a confirmation. Eg. in Argentina, it&#39;s pretty common<br>t=
o meet someone in person to buy bitcoin P2P for cash, even for newcomers.<b=
r><br>## Block explorers as payment receipts<br><br>Most wallets with suppo=
rt for on-chain payments (Muun included) use the<br>transaction view of a b=
lock explorer as a shareable payment receipt. The sender<br>of an on-chain =
transaction usually shares this link with the receiver to let<br>them 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 track payme=
nt replacements and, more importantly,<br>don&#39;t warn users that unconfi=
rmed funds are not theirs (yet). With full-RBF,<br>wallets should either st=
op relying on explorers for this functionality or wait<br>for them to suppo=
rt it explicitly.<br><br><br># Impact at Muun<br><br>Work to transition Muu=
n from using zero-conf submarine swaps to using payment<br>channels is ongo=
ing, but we are still several months away from being production<br>ready. T=
his means we would have to turn off outgoing lightning payments for<br>+100=
k monthly active users, which is a good chunk of all users making<br>non-cu=
stodial lightning payments today.<br><br>Furthermore, the more subtle fixes=
 imply non-trivial amounts of product work<br>that we cannot reasonably dep=
loy before they start affecting users.<br><br>While I cannot talk for other=
 applications, there are many impacted in one way<br>or another, and none o=
f the ones I checked with were aware of this change, or<br>its implications=
.<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>

--000000000000a8742d05eb424ee6--