Antoine,
In the direction of removing the current option from Bitcoin Core, I think the prerequisite to address are the qualification of enough economic flows at risk and the presence of a sizable loss in miners income.
Are such prerequisites for feature removal published somewhere? I don't see any reason why removing a controversial change should be harder than adding one. Generally, it is impossible to definitively attribute any change in network condition to one thing in such a complex system, and also difficult to know how much time is required to express negative effects. The whole argument here is to prevent disruption of the status quo that has lasted the whole history of Bitcoin, to avoid taking a speculative risk that full-RBF, at the expense of zero-conf, is maybe better for miners... or something.
Further, I feel the mempoolfullrbf feature was rushed through while this controversy was growing, specifically to attempt to achieve this imaginary protection of "sorry, that ship has sailed" which indicates an agenda that is counter to greater social consensus and status quo. We should not incentivize such behavior further by allowing this sort of feature sainthood.
Beyond that, I think there is still the open question if we (we, as the Bitcoin protocol development community, with all its stakeholders) should restrain user choice in policy settings in the name of preserving mining income and established use-case stability.
Removing the mempoolfullrbf feature is the opposite of restraining user choice.
First, any incentivized user can still create and distribute patches for any given mempool policy, regardless of whether we remove the feature from Core, but it is important to note that extremely few have felt the need to do so in the past.
Second, the very debate here is about how it is mempoolfullrbf that removes the user choice of zero-conf services. With a first-seen policy in place, users have *more* options, and Bitcoin is thus more useful, and thus more valuable to everyone. This is evident in that the feature of full-rbf is that it overrides any ability for users to signal intent of how they wish their transaction to be handled by nodes and miners. This is useful info to miners, as they make more money by facilitating use cases than by fee-minimizers painting everything as RBF. User-signaling is a useful feature for the mempool, full-RBF removes that feature.
Third, when Bitcoin Core adds special support for specific policies, it positions itself as a political authority and influencer. It is not Core's place to support one subjective policy more than another, particularly when it conflicts with years of status quo and breaks the current user space, and likely resulting in more doublespent user experiences.
To recall, the original technical motivation of this option, and the wider smoother deployment was to address a DoS vector affecting another class of use-case: multi-party transactions like coinjoin and contracting protocols like Lightning [2] [3]. All of them expect to generate economic flows and corresponding mining income. Since then, alternative paths to solve this DoS vector have been devised, all with their own trade-offs and conceptual issues [4] [5].
I am particularly skeptical that users sending Bitcoin to themselves (coinjoin) could ever be more incentive-compatible than fast-paced commerce & priority competition. I am also skeptical that mempoolfullrbf actually solves LN risks any better than opt-in RBF by default by LN implementations and wallets.
Further, zero-conf support reduces friction for LN adoption by allowing us to make instant, seamless UX within wallets when onboarding, rebalancing, and splicing.
Date: Fri, 2 Dec 2022 17:35:39 -0500
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in
immediate danger
Message-ID:
<CALZpt+HFFwY4XECNZj3XLqnaumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Daniel,
>From my understanding of GAP600, you're operating a zero-conf risk analysis
business, which is integrated and leveraged by payment processors/liquidity
providers and merchants. A deployment of fullrbf by enough full-node
operators and a subset of the mining hashrate would lower the cost of
double-spend attack by lamda users, therefore increasing the risk exposure
of your users. This increased risk exposure could lead you to alter the
acceptance of incoming zero-conf transactions, AFAICT in a similar
reasoning as exposed by Bitrefill earlier this year [0].
About the statistics you're asking for considerations, few further
questions, on those 1.5M transactions per month, a) how many are
Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many
are excluded from zeroconf due to factors like RBF, long-chain of
unconfirmed ancestors or too high-value and c) what has been the average
feerate (assuming a standard size of 200 bytes) ?
My personal position on fullrbf is still the same as expressed in #26525
[1]. As a community, I think we still don't have conceptual consensus on
deploying full-rbf, nor to remove it. In the direction of removing the
current option from Bitcoin Core, I think the prerequisite to address are
the qualification of enough economic flows at risk and the presence of a
sizable loss in miners income. Beyond that, I think there is still the open
question if we (we, as the Bitcoin protocol development community, with all
its stakeholders) should restrain user choice in policy settings in the
name of preserving mining income and established use-case stability.
To recall, the original technical motivation of this option, and the wider
smoother deployment was to address a DoS vector affecting another class of
use-case: multi-party transactions like coinjoin and contracting protocols
like Lightning [2] [3]. All of them expect to generate economic flows and
corresponding mining income. Since then, alternative paths to solve this
DoS vector have been devised, all with their own trade-offs and conceptual
issues [4] [5].
Best,
Antoine