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

From: Antoine Riard <antoine.riard@gmail•com>
To: Anthony Towns <aj@erisian•com.au>,
	 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 17:41:48 -0400	[thread overview]
Message-ID: <CALZpt+GSYBFxajSyZS19sQi4_6zHjkA5sP00V-pR=_NEVVUnkg@mail.gmail.com> (raw)
In-Reply-To: <Y0u8Ee2Ao375z8UD@erisian.com.au>

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

Hi AJ,

>  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

To give more context, the initial approach of enabling full RBF through
#25353 + #25600 wasn't making the assumption the enablement itself would
reach agreement of the economic majority or unanimity. Rather, it would
give the tools to node operators to build full-rbf relay paths and as such
to fulfill their applications requirements (e.g lightning dual-funding).
Without denying that such equilibrium would be unstable, it was designed to
remove the responsibility of the Core project itself to "draw a hard line"
on the subject. Moreover, relying on node operators turning on the setting
provides a smoother approach offering time to zero-conf services to react
in consequence.

So the current path definitely belongs more to a 3) approach. While this
way cannot be denied to be a zero-risk deployment for business accepting
unconfirmed transactions, it should be weighed in face of multi-party
contracting protocols encumbering an annoying pinning vector. It sounds to
me that an adequate way to resolve such a "split-risk" situation has been
to adopt a "micro" release practice rather than a "macro" one, namely offer
the options to node operators and let them vote with their respective
economic traffics.

Since Dario's mail, I think we have learnt new data points, a) on the long
term full RBF to align miner incentives is acknowledged and b) a clear
timeline based on e.g a block height is favored over the pollination
deployment.

As such, I think it makes sense to revise the full RBF deployment approach,
concentrating the discussion on the reasonable time buffer we should adopt
before activating full RBF on mainet. A time buffer realistic with respect
to the engineering,
operational and vendoring needs of the zero-conf businesses/applications. I
hope both #26305 and #26323 answer those criterias. Tie-breaking between
both, I believe I would favor something like #26323 though only post 24.0
to avoid introducing a bikeshedding precedent in terms of release process,
and with a longer timeline to be sure we ship 25.0 before the activation
day. Though listening to more feedback and decision factors, if we have
more things to consider.

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

Concerning my statement only, it should be re-contextualize with the other
statements calling the zero-conf operators to adapt their services, or
raise concerns, or be proactive at least [0]. On the other hand, from my
perspective, a status quo situation is also unsafe, as we left things like
multi-party coinjoins being DoSed by deanonymizing attackers. So in case of
risk arbitrage situation, as developers, best we can do is be vocal about
it and if possible find a common ground among all stakeholders. And I think
this is what this current thread aims to achieve, which I would say is a
healthy release process.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

Le dim. 16 oct. 2022 à 04:09, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> a écrit :

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

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