Date: Sun, 16 Oct 2022 18:08:49 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y0u8Ee2Ao375z8UD@erisian.com.au>
References: <Y0ZTtlRSBihNN9+v@erisian.com.au>
 <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
 <Y0d/e2sEoNRgD7KP@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y0d/e2sEoNRgD7KP@erisian.com.au>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
 danger
Precedence: list

On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev wrote:
> On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev wrote:
> > In my view, it is just what I said: a step towards getting full RBF
> > on the network, by allowing experimentation and socializing the notion
> > that developers believe it is time.
> We "believe it is time" for what exactly, though? (a) To start
> deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
> 18 months; or (b) to start switching mainnet mining and relay nodes over
> to full RBF?

For what it's worth, that was a serious question: I don't feel like I
know what other people's answer to it is.

Seems to me like there's fundamentally maybe three approaches:

 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
    payments indefinitely

 2) Draw a line in the sand now, but give people who are currently
    accepting unconfirmed txs time to update their software and business
    model

 3) Encourage mainnet miners and relay nodes to support unconditional
    RBF immediately, no matter how much that increases the risk to
    existing businesses that are still accepting unconfirmed txs

I think Antoine gave a pretty decent rationale for why we shouldn't
indefinitely continue with conditional RBF in [0] [1] -- it makes it
easy to disrupt decentralised pooling protocols, whether that be for
establishing lightning channels or coinjoins or anything else.

[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

It's also an unstable equilibrium -- if everyone does first-seen-is-final
at the mempool level, everything is fine; but it only takes a few
defectors to start relaying and mining full RBF txs to spoil zeroconf
for everyone -- so even if it were desirable to maintain it forever,
it's probably not actually possible to maintain it indefinitely.

If so, that leaves the choice between (2) and (3). You might argue
that there's a 4th option: ignore the problem and think about it later;
but to me that seems like it will just eventually result in outcome (3).


At least a few people are already running full RBF relay nodes [2] [3]
[4], and there's a report that non-signalling RBF txs are now getting
mined [5] when they weren't a few months ago [6]. I wasn't able to
confirm the latter to my satisfaction: looking at mempool.observer, the
non-RBF signalling conflicting txs don't seem to have been consistently
paying a higher feerate, so I couldn't rule out the possibility that
the difference might just be due to inconsistent relaying.

[2] https://twitter.com/murchandamus/status/1552488955328831492
[3] https://twitter.com/LukeDashjr/status/977211607947317254
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
[5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
[6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html

It seems to me that the best approach for implementing (3) would be
to change the default for -mempoolfullrbf to true immediately, which
is both what Knots has been doing for years, and what #26305 proposes
[7].  So from seeing what people are actually *doing*, I could easily
be convinced that (3) is the goal people are actually working towards.

[7] https://github.com/bitcoin/bitcoin/pull/26305

But if (3) *is* what we're really trying to do, I think it's a bit
disingenuous to assume that that effort will fail, and tell people that
nothing's going to change on mainnet in the near future [8] [9] [10]
[11]. If pools are starting to allow replacements of txs that didn't
signal according to BIP 125 and mine blocks including those replacements,
then it's true that zero-conf apps are in much more immediate danger
than they were a month ago, and as far as I can see, we shouldn't be
pretending otherwise.

[8] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204
[9] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1276682043
[10] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020981.html
[11] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021006.html

Personally, I prefer an approach like (2) -- commit to doing something
first, give people time to prepare for it, and then do it, and outside
of Knots, I don't think there's been any clear commitment to deprecating
zeroconf txs up until now. But what we're currently doing is suboptimal
for that in two ways:

 - there's no real commitment that the change will actually happen
 - even if it does, there's no indication when that will be
 - it's not easy to test your apps against the new world order, because
   it's not well supported on either testnet or signet, being disabled
   by default on both those networks

Dario suggested an approach [12] that seems like it would resolve all
these issues:

] This could be one such proposal:
] 1. We activate [..] full-RBF on testnet now.
] 2. We commit now (in the code) to a block height in the future at
]    which [..] full-RBF will activate on mainnet.

(I've delted the words "opt-in" and "opt-out" from the quote above,
because they didn't make sense to me)

[12] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021007.html

I've made up a patch along these lines [13]; it's easy to use a timestamp
rather than a block height, so I've arbitrarily picked 1st May (slightly
over 6 months away) as the changeover time. If people are willing to
give zeroconf businesses some time to adapt, including something along
those lines in 24.0 seems a better approach to me:

 * it gives a clear deadline for businesses to adapt, so that they don't
   defer it and suddenly complain "oh no, we didn't think you were
   serious, please give us more time" later

 * it gives plenty(?) of time to update your code and test it, as well
   as teach customers and customer support about the new behaviour

 * when the deadline hits, presumably plenty of nodes and miners will
   immediately start supporting the new behaviour on mainnet, so that
   protocols can quickly start relying on that method of tx pinning no
   longer being applicable

 * nodes on signet and testnet will quickly adopt the new behaviour,
   well before it's available on mainnet, making testing easier

[13] https://github.com/bitcoin/bitcoin/pull/26323

To me, this seems like a good way of achieving what I said previously:

> If we're trying to socialise the idea that zeroconf deprecation is
> happening and that your business now has a real deadline for migrating
> away from accepting unconfirmed txs if the risk of being defrauded
> concerns you, then enabling experimentation on test nets and not touching
> mainnet until a later release seems fairly fine to me -- similar to
> activating soft forks on test nets prior to activating it on mainnet.

Cheers,
aj