From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C9D3BC002D for ; Fri, 7 Oct 2022 16:21:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id B255383EC0 for ; Fri, 7 Oct 2022 16:21:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B255383EC0 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=muun-com.20210112.gappssmtp.com header.i=@muun-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=n5G2YoGZ X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ojoR0Hu3DXMi for ; Fri, 7 Oct 2022 16:21:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1C14B83EBB Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by smtp1.osuosl.org (Postfix) with ESMTPS id 1C14B83EBB for ; Fri, 7 Oct 2022 16:21:03 +0000 (UTC) Received: by mail-wr1-x431.google.com with SMTP id u10so8036435wrq.2 for ; Fri, 07 Oct 2022 09:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muun-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=3zT09/SwnKPoxAYNl+BVDYD2tXqb/fAw+dIdFIvaJdI=; b=n5G2YoGZ/XGhS9G2V6H+rVph91IHCLSwUIQYnN0txfS8HaR3iHuS2TmUqwtFtC8sKq QiQ7OcDuba5y8r3h2llIKI2PfSo+/6XCwTQz6zUSREKmwsN0h//h9iEC/fxUV4s4ddeo zCC5Pp+v6IXdjW2awwre2knaXqlqjDTzhSakCntdlsU6pBSrZ+DBY+ODPCRXUrYZEMe4 vC4+qsxnqXYON3kwcJa9Eje5zji/9nZEJUvUTxtNB2IInXv9gp96y3/nbY7bzmw6jxn+ Iozz2kC3dZ+TyS8kdFiLJIG9zbbqUQklGYA2+sDDhNKd4OnvBe9F5RgcOyYUNCeAMsu+ T2Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3zT09/SwnKPoxAYNl+BVDYD2tXqb/fAw+dIdFIvaJdI=; b=T8xo81wRZqSiQQMMa/zIbp2RXy6H9J+R1La/tUl7wmNVUysbwGjHtEG44efNa2uFZ7 025KIwJF3aBxGpY4rHBwIo6B/q2Iqapy2dWXoA7yLizsgO1DAPEtGJCd6tyCMCPa6ysq HeD2FHkNP76xsOoaoH9D60FEQy39FqDPxKfUNZJvL6aN9Td0CcQPFSedmbWfk55l7cts fhjnH6fE23lvBCGaOr5UE7PPvFo4X9jw9/SiXGePY6cj4oz3pa+v1IWqMfXhPtv7HSGQ fthw7pQOypxzZjyCFz+Jdtpe2tVWZBfSO4RtavD57AoDNUPvncs/K3TeXg9FPvZEWLQR l+GQ== X-Gm-Message-State: ACrzQf1zoP/mhOOE9iM828NyyBKmyvG2E6UDAorAwO0J+tpes86GMgqT JwN3ZeIrbHECeTh9ASYNUngczAGD4wx1IoigngYW+jfNXyCkpg== X-Google-Smtp-Source: AMsMyM62B78wLr6rVWB4wQKMnbdSPpwqTKADJNSi9f+Zgl2lN2+YY0Clf2ReHcTRYLSBxnOWde3oz4SsfW9oJdTHmrs= X-Received: by 2002:adf:f407:0:b0:22e:5848:f6b with SMTP id g7-20020adff407000000b0022e58480f6bmr3797137wro.46.1665159660802; Fri, 07 Oct 2022 09:21:00 -0700 (PDT) MIME-Version: 1.0 From: Dario Sneidermanis Date: Fri, 7 Oct 2022 13:20:49 -0300 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="00000000000013b0cf05ea743226" X-Mailman-Approved-At: Fri, 07 Oct 2022 16:43:29 +0000 Subject: [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: Fri, 07 Oct 2022 16:21:05 -0000 --00000000000013b0cf05ea743226 Content-Type: text/plain; charset="UTF-8" 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 relay 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 Muun 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 deployment 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, avoid 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 known by many in this list, it's useful to define precisely how they work to understand how they break. We call zero-conf applications to entities that accept on-chain payments from *untrusted parties* and will sometimes deliver the paid-for product or service without waiting for 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 and General Byte) All of these applications 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 practice, this works because once the bitcoin P2P network has fully propagated a non-RBF transaction, you need the collaboration of a miner to replace it, which isn't easy to get today. Even though many of the biggest miners offer off-band transaction broadcasting services, they currently won't process conflicting transactions. Roughly, the risk analysis 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 of 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 detection 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 into 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 via 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-click 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 things were already broken, but they get considerably worse as the network adopts 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. This 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 for +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 one way or another, and none of the ones I checked with were aware of this change, or its implications. --00000000000013b0cf05ea743226 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello list,

I'm Dario, from Muun wallet, a mobi= le non-custodial bitcoin wallet. For the past
few days we've been re= viewing the latest bitcoin core release candidate, and we
found some tro= ubling facts related to the opt-in full-RBF deployment.

We first lea= rned about the opt-in full-RBF proposal last June when it was
announced = on the mailing list. Closing the gap between the protocol's relay
po= licies and the miner incentives is inevitable, so it was a welcomed additio= n.
Furthermore, allowing transaction replacements that remove the opt-in= RBF flag
was deeply problematic.

At the time, we understood we h= ad at least a year from the initial opt-in
deployment until opt-out was = deployed, giving us enough time to adapt Muun to
the new policies. Howev= er, when reviewing the 24.0 release candidate just a few
days ago, we re= alized 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 deployment
mechanism. Given this new information, = do you see a path where we can delay the
opt-in deployment and find a sa= fer 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 str= aight 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, avoid a
huge mem= pool divergence event?

Below is our analysis of how zero-conf apps b= reak with opt-in full-RBF. I hope
it helps.

Cheers,
Dario
<= br>
# How do zero-conf apps work

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

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

Some examples of zero-conf apps:

- Muun's submar= ine swaps for outgoing lightning payments
- Bitrefill's on-chain pay= ments 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 applications are receiving incoming on-chain tran= sactions for which
they don't control the inputs, and performing a r= isk analysis to decide whether
they are ok with accepting the payment wi= thout confirmation.

In practice, this works because once the bitcoin= P2P network has fully
propagated a non-RBF transaction, you need the co= llaboration of a miner to
replace it, which isn't easy to get today.= Even though many of the biggest
miners offer off-band transaction broad= casting services, they currently won't
process conflicting transacti= ons.

Roughly, the risk analysis goes like this:

1. if an inco= ming transaction is RBF (direct or inherited)
=C2=A0 =C2=A0--> too ri= sky, wait for 1 conf (or more) since it can be replaced at any time
2. i= f the payment is for an amount greater than X
=C2=A0 =C2=A0--> too ri= sky, wait for 1 conf (or more), since the amount is worthy of a
=C2=A0 = =C2=A0 =C2=A0 =C2=A0sophisticated attacker
3. wait for full(ish) propaga= tion of the incoming transaction
4. if there's no double-spend attem= pt
=C2=A0 =C2=A0--> accept 0-conf

As with any other risk analy= sis, there's always a false-negative detection rate,
leading to an e= xpected 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<= br>
Full-RBF adoption works on three different layers:

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

If an application wants to replace with full-RB= F an *outgoing* transaction, it
will need:

- An upgraded node tha= t opted into full-RBF, from which it can broadcast the
=C2=A0 replacemen= t transaction
- A connected component of upgraded nodes that opted into = full-RBF, that can
=C2=A0 relay the replacement transaction
- A miner= in that connected component with an upgraded node that opted into
=C2= =A0 full-RBF, that can mine the replacement transaction

However, an = application cannot control whether a replacement to an *incoming*
transa= ction is relayed via full-RBF. As soon as a single application can
gener= ate replacements easily via full-RBF, all other applications have to assume=
that any incoming transaction from an untrusted party might be replaced= via
full-RBF. That is, for the application layer this is a forced upgra= de.

As soon as an unsophisticated attacker can use opt-in full-RBF, = the risk
analysis performed by zero-conf applications stops working beca= use the
transactions to analyze are all incoming transactions from untru= sted parties.
Since some wallets already implement cancel functionality = for opt-in RBF
transactions, enabling the same functionality for every t= ransaction wouldn't
require much work, making canceling any unconfir= med transaction a one-click
experience. After this, the security model o= f zero-conf applications goes from
"susceptible to attacks from min= ers" to "anyone can perform an attack, with an
easy-to-use int= erface".

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 mos= tly ineffective against
untrusted parties.


# Other things we = have to fix

While it's clear how full-RBF breaks zero-conf appli= cations, other more subtle
things break in *many* wallets (Muun included= ). If given the opportunity, we
would like to fix them before deployment= . One could argue that these things
were already broken, but they get co= nsiderably worse as the network adopts
full-RBF (even with an opt-in dep= loyment), so we should fix them.

## Mental model for unconfirmed inc= oming transactions

Many wallets with support for on-chain payments (= Muun included) show incoming
external transactions in some way to their = users before they confirm. This 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 chann= els).

With full-RBF, wallets should make it extremely clear to users= that unconfirmed
funds are not theirs (yet). Otherwise, protocol-unawar= e users that are
transacting on-chain with untrusted parties can be easi= ly 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 bu= y bitcoin P2P for cash, even for newcomers.

## Block explorers as pa= yment receipts

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

M= ost explorers currently don't track payment replacements and, more impo= rtantly,
don't warn users that unconfirmed funds are not theirs (yet= ). With full-RBF,
wallets should either stop relying on explorers for th= is functionality or wait
for them to support it explicitly.


#= Impact at Muun

Work to transition Muun from using zero-conf submari= ne swaps to using payment
channels is ongoing, but we are still several = months away from being production
ready. This means we would have to tur= n off outgoing lightning payments for
+100k monthly active users, which = is a good chunk of all users making
non-custodial lightning payments tod= ay.

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

While I cannot talk for other applications, there are many = impacted in one way
or another, and none of the ones I checked with were= aware of this change, or
its implications.
--00000000000013b0cf05ea743226--