From: Anthony Towns <aj@erisian•com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
Date: Sun, 16 Oct 2022 18:08:49 +1000 [thread overview]
Message-ID: <Y0u8Ee2Ao375z8UD@erisian.com.au> (raw)
In-Reply-To: <Y0d/e2sEoNRgD7KP@erisian.com.au>
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
next prev parent reply other threads:[~2022-10-16 8:08 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
[not found] <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
2022-10-14 10:03 ` 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] <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
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] <6342098B-A548-43C9-8F92-AAD9D0BB66AB@coinspaid.com>
2022-12-03 14:06 ` Daniel Lipshitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y0u8Ee2Ao375z8UD@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox