diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2022-10-17 18:14:52 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-10-17 22:15:07 +0000 |
| commit | c03c3ecab44d4a796224c2d1e944133ddfc6075f (patch) | |
| tree | 4baed002243d748af5847f71cbb2944e7d60f500 | |
| parent | 1fc3d672882b3eab7741b4a986c2ef78bba6aecb (diff) | |
| download | pi-bitcoindev-c03c3ecab44d4a796224c2d1e944133ddfc6075f.tar.gz pi-bitcoindev-c03c3ecab44d4a796224c2d1e944133ddfc6075f.zip | |
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
| -rw-r--r-- | 8f/4ad5229a5465cbe979ca90b7e4c42f395e4293 | 571 |
1 files changed, 571 insertions, 0 deletions
diff --git a/8f/4ad5229a5465cbe979ca90b7e4c42f395e4293 b/8f/4ad5229a5465cbe979ca90b7e4c42f395e4293 new file mode 100644 index 000000000..5c8f04967 --- /dev/null +++ b/8f/4ad5229a5465cbe979ca90b7e4c42f395e4293 @@ -0,0 +1,571 @@ +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'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'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 "black-and-white" thing, dependending of the = +perspective you'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 <= +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +linuxfoundation.org</a>> 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'= +m Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For the p= +ast<br>few days we'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'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'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'= +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'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's submarine swaps for outgoing lightning payments<= +br>- Bitrefill's on-chain payments for gift cards and phone top-ups<br>= +- Many bitcoin ATMs' 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'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't easy to get today. Even though many of the biggest<br>miners= + offer off-band transaction broadcasting services, they currently won'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--> 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--> 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's no double-spend attempt<br>=C2=A0 =C2=A0--> accept 0-conf<br>= +<br>As with any other risk analysis, there'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'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>"s= +usceptible to attacks from miners" to "anyone can perform an atta= +ck, with an<br>easy-to-use interface".<br><br>That is, the opt-in depl= +oyment of full-RBF doesn'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'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't<br>know they hav= +e to wait for a confirmation. Eg. in Argentina, it'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't track payme= +nt replacements and, more importantly,<br>don'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-- + |