public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail.com>
To: Dario Sneidermanis <dario@muun.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
Date: Mon, 17 Oct 2022 16:31:50 -0400	[thread overview]
Message-ID: <CALZpt+H6sS75KWvHTxjhgRnCWM8rTbyUD+um6rUk4W1ev4DHLg@mail.gmail.com> (raw)
In-Reply-To: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 12365 bytes --]

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.html

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.html

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 à 12:43, Dario Sneidermanis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 13290 bytes --]

  parent reply	other threads:[~2022-10-17 20:32 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 16:20 [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Dario Sneidermanis
2022-10-07 17:21 ` David A. Harding
2022-10-07 17:28   ` Greg Sanders
2022-10-07 21:37   ` Dario Sneidermanis
2022-10-11 16:18     ` Pieter Wuille
2022-10-12  5:42     ` Anthony Towns
2022-10-12 16:11       ` Pieter Wuille
2022-10-12 21:44         ` Dario Sneidermanis
2022-10-13  4:35         ` Anthony Towns
2022-10-16  8:08           ` Anthony Towns
2022-10-17 14:25             ` Greg Sanders
2022-10-17 21:41             ` Antoine Riard
2022-10-18  7:00               ` Anthony Towns
2022-10-19  3:01                 ` Antoine Riard
2022-10-19  3:17                 ` alicexbt
2022-10-20 22:08                   ` Peter Todd
2022-11-02 15:04                     ` AdamISZ
2022-10-20 23:18                 ` Peter Todd
2022-11-09 13:19                 ` ArmchairCryptologist
2022-11-10  9:35                   ` ZmnSCPxj
2022-10-07 20:56 ` Luke Dashjr
2022-10-08 20:47 ` alicexbt
2022-10-13 16:07 ` linuxfoundation.cndm1
2022-10-14  2:44   ` alicexbt
2022-10-14 15:02     ` Peter Todd
2022-10-17 20:31 ` Antoine Riard [this message]
2022-10-17 22:14 ` Antoine Riard
     [not found] <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
2022-10-14 10:03 ` John Carvalho
2022-10-14 15:04   ` Peter Todd
2022-10-14 16:28     ` Erik Aronesty
2022-10-15  4:08       ` John Carvalho
2022-10-15  4:20     ` John Carvalho
     [not found] <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
2022-10-19 14:29 ` Sergej Kotliar
2022-10-19 14:45   ` Erik Aronesty
2022-10-19 15:43   ` Jeremy Rubin
2022-10-19 15:51     ` Greg Sanders
2022-10-19 16:04     ` Sergej Kotliar
2022-10-19 16:08       ` Greg Sanders
2022-10-20  1:37   ` Antoine Riard
2022-10-20 14:11     ` Sergej Kotliar
2022-10-21  1:04       ` Antoine Riard
2022-10-20  4:05   ` Peter Todd
2022-10-21 19:35     ` Peter Todd
2022-10-20  7:22   ` Anthony Towns
2022-10-20 12:37     ` Sergej Kotliar
2022-10-20 14:14       ` Ruben Somsen
2022-10-20 14:17         ` Sergej Kotliar
2022-10-20 19:58       ` Anthony Towns
2022-10-20 21:05         ` David A. Harding
2022-10-20 21:07         ` Greg Sanders
2022-10-20 22:02           ` Eloy
2022-10-21 12:02           ` Sergej Kotliar
2022-10-21 14:01             ` Greg Sanders
2022-10-21 14:19               ` Sergej Kotliar
2022-10-21 14:47                 ` Greg Sanders
2022-10-21 19:43             ` Peter Todd
2022-10-24  7:55               ` Sergej Kotliar
2022-10-20 22:13         ` Peter Todd
2022-10-21  9:34           ` Sergej Kotliar
2022-10-21 19:33             ` Peter Todd
2022-10-24  7:45               ` Sergej Kotliar
2022-10-21 11:56         ` Sergej Kotliar
2022-10-23 19:20   ` David A. Harding
2022-10-23 20:51     ` alicexbt
2022-12-01 12:27 Daniel Lipshitz
2022-12-01 22:03 ` Erik Aronesty
2022-12-02  6:34   ` Daniel Lipshitz
2022-12-02  1:52 ` Antoine Riard
2022-12-02  6:59   ` Daniel Lipshitz
2022-12-02  4:30 ` Peter Todd
2022-12-02  7:06   ` Daniel Lipshitz
2022-12-03  8:50     ` Peter Todd
2022-12-03 11:01       ` Daniel Lipshitz
2022-12-03 11:51         ` Daniel Lipshitz
2022-12-03 12:12         ` Peter Todd
2022-12-03 13:17           ` Daniel Lipshitz
2022-12-03 14:03             ` Daniel Lipshitz
2022-12-05 12:21               ` angus
     [not found] <6342098B-A548-43C9-8F92-AAD9D0BB66AB@coinspaid.com>
2022-12-03 14:06 ` Daniel Lipshitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALZpt+H6sS75KWvHTxjhgRnCWM8rTbyUD+um6rUk4W1ev4DHLg@mail.gmail.com \
    --to=antoine.riard@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dario@muun.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox