public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
[parent not found: <6342098B-A548-43C9-8F92-AAD9D0BB66AB@coinspaid.com>]
* [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
@ 2022-12-01 12:27 Daniel Lipshitz
  2022-12-01 22:03 ` Erik Aronesty
                   ` (2 more replies)
  0 siblings, 3 replies; 79+ messages in thread
From: Daniel Lipshitz @ 2022-12-01 12:27 UTC (permalink / raw)
  To: bitcoin-dev

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

HI All

I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
crypto  transactions, BTC is a primary part of our business. Our guarantee
enables our customers to recognise zero-conf deposits. We reimburse our
clients value of the trx should we get it wrong and a transaction we
confirmed gets double spent.

Should full RBF become default enabled and significantly adopted this would
have a major impact on the capacity to accept zerof confs on mainnet. With
the end result being this use case will be forced to move to a different
chain, with lightning being just another option.

I wanted to share some statistics about how significant this use case is.
GAP600 clients are primarily payment processors and non custodial
liquidity providers; you can see some of our clients on our site
www.gap600.com. There are also merchants who have developed their own tools
so GAP600 statistics are only a subset of the full use case.

I do not know of any wallet, exchange or custodian who accepts zero conf
without having some sort of solution in place. The market seems to be fully
aware of the risks of zero-conf. The opt-RBF seems to be a solution which
gives a clear free choice for actors.

Statistics for consideration as a sample of the zero conf use case -


   1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
   15M transactions
   2. These transactions have a cumulative value of 2.3B USD value.
   3. We currently are seeing circa 1.5M transactions queired per month.


It's a sizable amount of trxs on mainet and we are by no means the full
market of platforms accepting zero-conf.  I realise there are other
considerations which BTC has,  I would urge you to take into account the
major risk being placed on this significant market share when deciding to
make this feature default enabled and encouraging full adoption.

Thank you for your consideration
Daniel
________________________________

Daniel Lipshitz
GAP600| www.gap600.com

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

^ permalink raw reply	[flat|nested] 79+ messages in thread
[parent not found: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>]
* [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
@ 2022-10-07 16:20 Dario Sneidermanis
  2022-10-07 17:21 ` David A. Harding
                   ` (5 more replies)
  0 siblings, 6 replies; 79+ messages in thread
From: Dario Sneidermanis @ 2022-10-07 16:20 UTC (permalink / raw)
  To: bitcoin-dev

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

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.

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

^ permalink raw reply	[flat|nested] 79+ messages in thread
end of thread, other threads:[~2022-12-05 12:27 UTC | newest]

Thread overview: 79+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
2022-10-14 10:03 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 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] <6342098B-A548-43C9-8F92-AAD9D0BB66AB@coinspaid.com>
2022-12-03 14:06 ` Daniel Lipshitz
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] <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
  -- strict thread matches above, loose matches on Subject: below --
2022-10-07 16:20 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
2022-10-17 22:14 ` Antoine Riard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox