Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-18 📝 Original message:On Mon, Oct 17, 2022 at ...
📅 Original date posted:2022-10-18
📝 Original message:On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> > 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.
Full RBF doesn't need a majority or unanimity to have an impact; it needs
adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
a 10MvB mempool can be replaced before being mined naturally), and some
way of finding a working path to relay txs to that hashrate.
Having a majority of nodes/hashrate support it makes the upsides better,
but doesn't change the downsides to the people who are relying on it
not being available.
> 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.
Removing responsibility from core developers seems like it's very much
optimising for the wrong thing to me.
I mean, I guess I can understand wanting to reduce that responsibility
for maintainers of the github repo, even if for no other reason than to
avoid frivolous lawsuits, but where do you expect people to find better
advice about what things are a good/bad idea if core devs as a whole
are avoiding that responsibility?
Core devs are supposedly top technical experts at bitcoin -- which means
they're the ones that should have the best understanding of all the
implications of policy changes like this. Is opt-in RBF only fine? If
you look at the network today, it sure seems like it; it takes a pretty
good technical understanding to figure out what problems it has, and
an even better one to figure out whether those problems can be solved
while keeping an opt-in RBF regime, or if full RBF is needed.
At that point, the technical experts *should* be coming up with a
specific recommendation, and, personally, I think that's exactly what
happened with [0] [1] and [2].
[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[1] https://github.com/bitcoin/bitcoin/pull/25353
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
That did draw hard line in the sand: it said "hey, opt-in RBF had a good
run, but it's time to switch over to full RBF, for these reasons".
It's a bit disappointing that the people that's a problem for didn't
engage earlier -- though looking back, I guess there wasn't all that
much effort made to reach out, either. There were two mentions in the
optech newsletter [3] [4] but it wasn't called out as an "action item"
(maybe those aren't a thing anymore), so it may have been pretty missable,
especially given RBF has been discussed on and off for so long. And the
impression I got from the PR review club discussion more seemed like
devs making assumptions about businesses rather than having talked to
them (eg "[I] think there are fewer and fewer businesses who absolutely
cannot survive without relying on zeroconf. Or at least hope so").
[3] https://bitcoinops.org/en/newsletters/2022/06/22/
[4] https://bitcoinops.org/en/newsletters/2022/07/13/
If we're happy to not get feedback until we start doing rcs, that's fine;
but if we want to say "oops, we're into release candidates, you should
have something earlier, it's too late now", that's a pretty closed-off
way of doing things.
And I mean: all this is only about drawing a line in *sand*; if people
think core devs are wrong, they can still let that line blow away in
the wind, by running different software, configuring core differently,
patching core, or whatever else.
> Moreover, relying on node operators turning on the setting
> provides a smoother approach offering time to zero-conf services to react
> in consequence.
I don't think that's remotely true: take a look at taproot activation:
it took two months between releasing code that supported signalling and
having 98% of hashrate signalling; with 40% of blocks signalling within
the first two weeks.
> So the current path definitely belongs more to a 3) approach.
> > 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
Yes, that's how it appears to me, too. It's not my preference (giving
people clear warning of changes seems much better to me), but I can
certainly live with it.
But if the line in the sand is "we're doing this, no matter how much that
increases the risk to existing businesses that weren't expecting it" then
it seems *very* disingenuous not to make those risks very clear so that
people who weren't expecting it actually take action to avoid those risks.
That is, it seems to me that Dario was exactly right in titling this
thread "Zero-conf apps in immediate danger", and our co-developers who
are dismissing the risk by saying things along the lines of "probably
nothing will change anytime soon" are exactly wrong.
(More generally, that's similar to one of the things I've hated
watching in mainstream economics over the past few years: "doing this
will cause massive inflation" "no it won't, there's no inflation risk"
"oops, inflation magically appeared, how did that happen? oh well, too
bad, we have to live with it now". This looks pretty similar to me: "do
something risky, deny the risk, make sure nobody can hold us accountable
when the risk eventuates later" so it makes me really uncomfortable)
> 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.
Sure; that's a fine reason to draw the line in the sand. But it's not
a good reason to have it happen immediately, rather than giving people
time to react, and it's not a good reason to understate the risk of
it happening now. Maybe there are good reasons for either or both of
those, though?
> 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.
Using the passive voice there doesn't seem helpful. Who learnt these
things? You, I and Dario all seem to agree with (a), but John Carvalho
certainly appears not to, for instance. I'm not sure who agrees with
(b) -- I know I do, and I think Dario does; but multiple people seem
opposed to the clear timeline offered in #26323, and your #26305 seems
more likely to encourage a "pollination" approach rather than discourage
it ("oh, this will be the default option for 25.0, might as well enable
it now like all the cool kids are").
For what it's worth, my guess is that releasing core with full rbf
support and having you and Murch and others advocating for people to
try it out, will mean that full RBF is usable on mainnet within two
or three months, supported by perhaps 5%-20% hashpower, but probably
still requiring special effort to actually find a peer that can relay
full rbf txs to that hashpower (probably doing an addnode, despite the
privacy implications). Even if that happens, I'm not super confident
that it would mean people would actively steal from zeroconf businesses
in any volume, though. It's not something I'd risk happening to me,
but accepting zeroconf from strangers isn't something I'd risk anyway.
Slowing that down from January-ish to May seems like it ought to be a
big win for anyone who has been doing zeroconf, and having it be easy
to find a path to miners when it is supported seems like a big win even
given a cost of a few months delay.
OTOH, if we're really not expecting full rbf to be available for many
months, then I would have expected the "disable this for mainnet,
reconsider after the release" PR (#26287) to have gone ahead already.
> 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,
Doing something like #26323 only after 24.0 is out does nothing to
mitigate whatever immediate risk there is to bitcoin businesses/users...
And if the choice is between "bikeshedding" and "merge a PR, then ignore
feedback that it's harmful", I'd much rather the bikeshedding. What's
the point of having rcs if you're going to ignore negative feedback?
I mean, if you think the feedback is wrong, that's different: maybe we
shouldn't care that zeroconf apps are in immediate danger, and maybe
bitcoin would be better if any that don't adapt immediately all die
horribly as a lesson to others not to make similarly bad assumptions.
But saying "we don't want them to be in danger" and also refusing to do
anything to avoid it?
Cheers,
aj
📝 Original message:On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> > 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.
Full RBF doesn't need a majority or unanimity to have an impact; it needs
adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
a 10MvB mempool can be replaced before being mined naturally), and some
way of finding a working path to relay txs to that hashrate.
Having a majority of nodes/hashrate support it makes the upsides better,
but doesn't change the downsides to the people who are relying on it
not being available.
> 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.
Removing responsibility from core developers seems like it's very much
optimising for the wrong thing to me.
I mean, I guess I can understand wanting to reduce that responsibility
for maintainers of the github repo, even if for no other reason than to
avoid frivolous lawsuits, but where do you expect people to find better
advice about what things are a good/bad idea if core devs as a whole
are avoiding that responsibility?
Core devs are supposedly top technical experts at bitcoin -- which means
they're the ones that should have the best understanding of all the
implications of policy changes like this. Is opt-in RBF only fine? If
you look at the network today, it sure seems like it; it takes a pretty
good technical understanding to figure out what problems it has, and
an even better one to figure out whether those problems can be solved
while keeping an opt-in RBF regime, or if full RBF is needed.
At that point, the technical experts *should* be coming up with a
specific recommendation, and, personally, I think that's exactly what
happened with [0] [1] and [2].
[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[1] https://github.com/bitcoin/bitcoin/pull/25353
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
That did draw hard line in the sand: it said "hey, opt-in RBF had a good
run, but it's time to switch over to full RBF, for these reasons".
It's a bit disappointing that the people that's a problem for didn't
engage earlier -- though looking back, I guess there wasn't all that
much effort made to reach out, either. There were two mentions in the
optech newsletter [3] [4] but it wasn't called out as an "action item"
(maybe those aren't a thing anymore), so it may have been pretty missable,
especially given RBF has been discussed on and off for so long. And the
impression I got from the PR review club discussion more seemed like
devs making assumptions about businesses rather than having talked to
them (eg "[I] think there are fewer and fewer businesses who absolutely
cannot survive without relying on zeroconf. Or at least hope so").
[3] https://bitcoinops.org/en/newsletters/2022/06/22/
[4] https://bitcoinops.org/en/newsletters/2022/07/13/
If we're happy to not get feedback until we start doing rcs, that's fine;
but if we want to say "oops, we're into release candidates, you should
have something earlier, it's too late now", that's a pretty closed-off
way of doing things.
And I mean: all this is only about drawing a line in *sand*; if people
think core devs are wrong, they can still let that line blow away in
the wind, by running different software, configuring core differently,
patching core, or whatever else.
> Moreover, relying on node operators turning on the setting
> provides a smoother approach offering time to zero-conf services to react
> in consequence.
I don't think that's remotely true: take a look at taproot activation:
it took two months between releasing code that supported signalling and
having 98% of hashrate signalling; with 40% of blocks signalling within
the first two weeks.
> So the current path definitely belongs more to a 3) approach.
> > 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
Yes, that's how it appears to me, too. It's not my preference (giving
people clear warning of changes seems much better to me), but I can
certainly live with it.
But if the line in the sand is "we're doing this, no matter how much that
increases the risk to existing businesses that weren't expecting it" then
it seems *very* disingenuous not to make those risks very clear so that
people who weren't expecting it actually take action to avoid those risks.
That is, it seems to me that Dario was exactly right in titling this
thread "Zero-conf apps in immediate danger", and our co-developers who
are dismissing the risk by saying things along the lines of "probably
nothing will change anytime soon" are exactly wrong.
(More generally, that's similar to one of the things I've hated
watching in mainstream economics over the past few years: "doing this
will cause massive inflation" "no it won't, there's no inflation risk"
"oops, inflation magically appeared, how did that happen? oh well, too
bad, we have to live with it now". This looks pretty similar to me: "do
something risky, deny the risk, make sure nobody can hold us accountable
when the risk eventuates later" so it makes me really uncomfortable)
> 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.
Sure; that's a fine reason to draw the line in the sand. But it's not
a good reason to have it happen immediately, rather than giving people
time to react, and it's not a good reason to understate the risk of
it happening now. Maybe there are good reasons for either or both of
those, though?
> 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.
Using the passive voice there doesn't seem helpful. Who learnt these
things? You, I and Dario all seem to agree with (a), but John Carvalho
certainly appears not to, for instance. I'm not sure who agrees with
(b) -- I know I do, and I think Dario does; but multiple people seem
opposed to the clear timeline offered in #26323, and your #26305 seems
more likely to encourage a "pollination" approach rather than discourage
it ("oh, this will be the default option for 25.0, might as well enable
it now like all the cool kids are").
For what it's worth, my guess is that releasing core with full rbf
support and having you and Murch and others advocating for people to
try it out, will mean that full RBF is usable on mainnet within two
or three months, supported by perhaps 5%-20% hashpower, but probably
still requiring special effort to actually find a peer that can relay
full rbf txs to that hashpower (probably doing an addnode, despite the
privacy implications). Even if that happens, I'm not super confident
that it would mean people would actively steal from zeroconf businesses
in any volume, though. It's not something I'd risk happening to me,
but accepting zeroconf from strangers isn't something I'd risk anyway.
Slowing that down from January-ish to May seems like it ought to be a
big win for anyone who has been doing zeroconf, and having it be easy
to find a path to miners when it is supported seems like a big win even
given a cost of a few months delay.
OTOH, if we're really not expecting full rbf to be available for many
months, then I would have expected the "disable this for mainnet,
reconsider after the release" PR (#26287) to have gone ahead already.
> 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,
Doing something like #26323 only after 24.0 is out does nothing to
mitigate whatever immediate risk there is to bitcoin businesses/users...
And if the choice is between "bikeshedding" and "merge a PR, then ignore
feedback that it's harmful", I'd much rather the bikeshedding. What's
the point of having rcs if you're going to ignore negative feedback?
I mean, if you think the feedback is wrong, that's different: maybe we
shouldn't care that zeroconf apps are in immediate danger, and maybe
bitcoin would be better if any that don't adapt immediately all die
horribly as a lesson to others not to make similarly bad assumptions.
But saying "we don't want them to be in danger" and also refusing to do
anything to avoid it?
Cheers,
aj