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

[Antoine Riard <antoine.riard@gmail.com>]

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

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

Yes, this has been the crux of the conceptual discussion in #25600.

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

In the present case, I don't think there is a real concern of a frivolous
or half-baked lawsuit. My concern is rather the pretension to omniscience
that we would adopt as Core devs w.r.t policy changes, as far from being a
more closed, hermetic system like the p2p stack, it's interfacing with the
operations of a number of Bitcoin applications and second-layer contracting
protocols. As of today, I think this is still a relatively short process to
analyze the implications of any policy changes on the major Bitcoin
applications
flows and L2s of the day (i.e mainly Lightning and coinjoins). I'm not sure
this statement will stay true in a future with a growing fauna of L2s (i.e
vaults, DLC-over-channel, peerswaps, etc), each presenting unique
characteristics.

How do we minimize the odds of policy-based disruptions for current Bitcoin
softwares and users ? I don't have strong ideas, though I wish for the Core
project to adopt a more open-ended and smooth approach to release
context-rich policy changes. I aimed with #25353 and #25600 to experiment
with such a smoother approach advocated for (rather than the last year
proposal of turning on by default full-rbf, that was a wrong and missing
context). I hope at least one good outcome of this gradual process has been
to give time to Dario to publish a thoughtful standpoint for 0conf
operators, of which at least I learnt a few interesting elements on the UX
of such applications.

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

Yeah, I'm still valuing the mailing list as a kind of "broadcast-all"
communication channel towards all the community stakeholders, though this
is the perspective of a developer and I'm not sure business/services
operators have the same communication habits. There is definitely a
reflection to hold, if we, as Core devs, we should follow a better
communication standard when we propose significant policy changes. And go
the full-tour of Reddit AMA, podcasts and newsletters as suggested in my
reply to Dario. It's hard to know if lack of vocal reactions on the mailing
list or to the publication of optech newsletter signifies a lack of
opposition, a lack of negatively impacted users or lack of interest from
the wider community. Maybe we should have a formalized, bulletpoints -based
for future policy changes, with clear time buffers and actions items, I
don't know.

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

In the present case, it's more a lack of feedback showing up until we start
doing rcs, rather than a pretty closed-off way of doing things. That we
should amend expected and already-merged changes in the function of
feedback, I'm all for it in principle. The hard question is the set of
decision heuristics to converge on to qualify such feedback as worthy to
react on. Again in this case, we're doing some risk arbitrage (which I
really dislike as a situation) between 0conf applications and multi-party
funding flows of contracting protocols. Correcting our release process
isn't free of implications as we're removing the risk burden on some class
of use-case to pour it on a second class, in my opinion. Moreover, assuming
we have to bind to reasonable communication standards which is an open
question, I'm also worried we would also normalize the publication of very
late feedback from community stakeholders.

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

First, without more visibility brought back on the 0confs operations
necessary to adapt their operations, two months might be considered as
enough. 8 weeks is sensibly the release schedule followed by few
open-source projects in the ecosystem. Second, the communication machine
behind softforks activation sounds to be far more fine-tuned, or at least
gather spontaneously community self-coordination than policy changes, and
it would be reasonable to expect things to be slower with policy changes.
However, I would agree you can have a quick adoption a day from another
with one single well-crafted meme buzzing on Twitter. Social phenomenas
don't offer the same degree of predictability than system engineering. How
we cope up with that, as core devs, I don't know.

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

I'm not sure if it has been established clearly, though as I announced on
IRC two weeks ago, Dario reached out to me offline before publishing his
mail. My recommendation to him have been immediately to adjoin 0confs
services examples impacted, if possible with numbers on users affected and
evaluation of engineering and operational effort if would request to adapt
their use-cases, and inviting to publish on this venue, as business
operators might not be used to with open-source process (I can disclose the
correspondence if requested and with Dario approval).

Goal was to collect the maximum of data points in our community
decision-making process about full-rbf. Now this doesn't relieve us of
finding a common ground on what should be a minimal bar to accept those
points, how to value those data
points, if we should take operators on their raw numbers or request the
publication of "light" proofs like on-chain transactions, lightning
invoices (everyone in business would take the happy measure showing the
most active users possible). The question of what signals we should
collect, and how we process them is a hard question in a decentralized and
trust-minimized process like the Bitcoin development one, from my
perspective. I don't have strong ideas there.

Though speaking for myself, and not for other contributors, I've raised the
warnings about potential impacts of full-rbfs in both my June 2021 [0] and
June 2022 [1] mails, so I find the qualification of disingenuous is a bit
ungrounded. Overall, I would remind all that it's better to keep patience
in face of complex changes in Core, rather than to fall quickly in a blame
ascription position.

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

(I don't deny "blame-and-reward" assignments can be worthy a posteriori,
once we're out of the "hot" discussion phase, especially to introspect on
how we can improve our engineering process, though in the middle of a
discussion... I don't know, it sounds premature and noisy).

> (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)

I can share the sentiment about mainstream economics and the way
risk-management impacts large-range of human beings is completely shrug
on... Though again in the present case, I think it would be more productive
to describe what engineering
needs or standards expectations of you are not fulfilled rather than to
fallback on the pure expression of an uncomfortableness and how as a
community of contributors we could improve on that. Though to object,
speaking of risk appreciation, not hardening the funding phase of
multi-party funding protocols also lets the door open to DoS attacks by
deanonymizing attackers targeting things like coinjoin.

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

I agree. I would like to observe that "reasonable time to react" and
"adequate risk statement" is more an art than a science.

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

About John Carvalho disagreeing about full-rbf, I think he voiced a concern
during the summer on one of the PR introducing a full-rbf setting and I did
invite to voice his concerns on the ML, invitation stayed without follow-up
until the recent days [2] [3]. I would have loved to spend time back then
arguing on the full-rbf and miners incentives compatibility.

[2] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654
[3] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163815017

I know we all have busy agendas and a short timeline to react to all the
changes happening in the Bitcoin ecosystem... I think I replied to John
Carvalho answer on this thread, inviting him to develop his argumentation
further and I'm staying available to discuss with any full-rbf opponents,
in a calm and respectful fashion [4].

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

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

Yeah I mean this could have been a forward process before Dario published
his thoughts. Achieving 5%-20% hashpower and full-rbf relay paths would
have assumed landing #25600 _and_ actually reach out to few mining pools to
inform them about the potential economic benefits. Now, I think the best
process is to keep listening to more feedback from the community, lay out
all the deployment options in code we have done and think more before
committing to something.

> 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 think this might be the point where I could say we're diverging. In
principle, I agree we should listen to negative feedback raising harmful
disruptions risks for users and services. The more open, practical question
to me is more how we collect, qualify and sanitize such negative feedback
in a way which is acceptable for the community at large. Giving concrete
bounds to the immediate dangers in a consensual way, and asserting this
danger results from a lack of communication of the Core project, I'm still
wondering on those subjects. And note again, I didn't deny the option 3)
approach as you laid out was zero-risk for 0conf operators.

All that said, if we think as a project we should offer a "zero-risk"
process towards 0conf operators w.r.t full-rbf, at the detriment of the
risk encumbered by contracting protocols, I think it can be wise to
resurrect #26287.

Best,
Antoine

Le mar. 18 oct. 2022 à 03:00, Anthony Towns <aj@erisian.com.au> a écrit :

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

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