Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

151 views
Skip to first unread message

Anthony Towns

unread,
May 2, 2025, 1:33:26 PMMay 2
to Sergej Kotliar, Bitcoin Development Mailing List
On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <[email protected]> wrote:
> > On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
> > wrote:
> > > Currently Lightning is somewhere around 15% of our total bitcoin
> > > payments.
> > So, based on last year's numbers, presumably that makes your bitcoin
> > payments break down as something like:
> >
> > 5% txs are on-chain and seem shady and are excluded from zeroconf
> > 15% txs are lightning
> > 20% txs are on-chain but signal rbf and are excluded from zeroconf
> > 60% txs are on-chain and seem fine for zeroconf
> Numbers are right. Shady is too strong a word, it's mostly transactions
> with very low fee, or high purchase amount, or many dependent unconfirmed
> transactions, stuff like that. In some cases we do a human assessment of
> the support ticket and often just pass them through.

> > > This is very much not nothing, and all of us here want Lightning to grow,
> > > but I think it warrants a serious discussion on whether we want Lightning
> > > adoption to go to 100% by means of disabling on-chain commerce.
> > If the numbers above were accurate, this would just mean you'd go from 60%
> > zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
> Point is that RBF transactions are unsafe even when waiting for a
> confirmation, which Peter Todd trivially proved in the reply next to this.
> The reliable solution is to reject all RBF payments and direct those users
> to custodial accounts. There are other variants to solve this with varying
> degree of convolutedness. RBF is a strictly worse UX as proven by anyone
> accepting bitcoin payments at scale.

So the mempoolfullrbf default changed from false to true in 28.0 released
in October last year, which is advertised as being run by maybe 30%-40%
of the network now, and fullrbf transactions have been reportedly been mined
reliably since well before that.

Any chance of an update on how that change has affected bitcoin/lightning
payment volume for you guys, or customer satisfaction (if payment
acceptance is delayed more often), or how much engineering/support time
was needed to adapt, or any other impact?

Cheers,
aj

Anthony Towns

unread,
May 6, 2025, 9:03:33 AMMay 6
to Sergej Kotliar, Bitcoin Development Mailing List
On Fri, May 02, 2025 at 08:06:18PM +1000, Anthony Towns wrote:
> So the mempoolfullrbf default changed from false to true in 28.0 released
> in October last year, which is advertised as being run by maybe 30%-40%
> of the network now, and fullrbf transactions have been reportedly been mined
> reliably since well before that.
>
> Any chance of an update on how that change has affected bitcoin/lightning
> payment volume for you guys, or customer satisfaction (if payment
> acceptance is delayed more often), or how much engineering/support time
> was needed to adapt, or any other impact?

There was a related thread on X late last year that offers some relevant
information for these questions:

https://x.com/MattAhlborg/status/1828436316930912364

Some key points from that thread, IMO:

* The "relative volume" metric shows a drop in bitcoin/lightning volume
from 30%-40% in 2022 to 25%-30% in late 2024

* The "monthly active users" metric shows a drop in bitcoin/lightning
volume from about 50% to about 40% in a similar timeframe, as well as
a large switch from on-chain to lightning

* The "average payment size" metric shows distinctly different behaviours
between on-chain bitcoin users and lightning users -- individual
on-chain payments are about 4x greater in value than individual
lightning payments

* Bitrefill stopped accepting zeroconf transactions in Aug/Sep 2023; they
didn't indicate if this was due to seeing a rise in (attempted?) fraud,
or a purely preventative measure.

* The charts show definite correlations between the decrease in on-chain
activity with fee spikes

* The charts don't show obvious correlations between on-chain activity
and when bitrefill stopped accepting zeroconf transactions. At best
you could argue this shows up as volume not returning to on-chain
bitcoin after the fee spikes eased.

* This may also be due to a rise in use of bitrefill accounts -- ie,
you send a bunch of money to top up your bitrefill account, and
then later spend small amounts from that. Doing that provides some
insulation from the impact of both on-chain fees and confirmation
delays. The thread doesn't give details on how that has changed over
time, so there's no indication if there's any correlation with either
dropping support for zeroconf or with fee spikes.

* Much of the lightning monthly active users (>50%) is due to a business
partnership, where the users don't end up using lightning directly. The
author speculates that as little as 12.5% (or as much as 25%) of the
lightning payments they see are from users who control their own keys.

That's not super positive for bitcoin (as a payments system) overall --
lightning growth seems to be almost entirely in the B2B zone, rather
than the P2P zone, in particular.

It doesn't seem to indicate huge problems resulting from how
mempoolfullrbf was handled; though if "just custody funds with bitrefill"
was a significant mitigating factor, perhaps that's not terribly positive
either from a P2P, be-your-own-bank perspective.

IMO, anyway. Thanks to John Carvalho for the pointer to the thread.

Cheers,
aj

Reply all
Reply to author
Forward
0 new messages