Date: Wed, 19 Oct 2022 03:17:51 +0000
To: Anthony Towns <aj@erisian.com.au>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <PC-7ALULc67cy0mTKzk_uj-pbCcwDoMuJQmmevzLPexK32B11vuzCusGSrx1wNCQ5YtMqfQeI1N5AmdemvfHEJNJ5VmZxAeaWS6E3tNZxIs=@protonmail.com>
In-Reply-To: <Y05PHYtrNmA0vg7U@erisian.com.au>
References: <Y0ZTtlRSBihNN9+v@erisian.com.au>
 <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
 <Y0d/e2sEoNRgD7KP@erisian.com.au> <Y0u8Ee2Ao375z8UD@erisian.com.au>
 <CALZpt+GSYBFxajSyZS19sQi4_6zHjkA5sP00V-pR=_NEVVUnkg@mail.gmail.com>
 <Y05PHYtrNmA0vg7U@erisian.com.au>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
Precedence: list

Hi aj,

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

Bitcoin Core contributors and maintainers should provide the options, recom=
mendations etc. about mempool policies. If these policies are kept for user=
s to change based on their needs, why force anything or change defaults ign=
oring feedback?

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

Why even provide options for users to change RBF policy in that case? Optio=
n to disable was already [removed][1] ignoring NACKs and MarcoFalke prefers=
 users try the [workaround][2] if there is ever a need to disable it. Are w=
e going to remove all the options to switch RBF policies in future because =
fullrbf has been suggested by leading technical experts? Is there a possibi=
lity of experts going wrong and has it ever happened in past?

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

To be fair, John Carvalho did [comment][3] about this in a pull request alt=
hough it was wrong PR and never going to be merged.

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

I think this is the best option for users at this point. Keep running older=
 versions of Core and use Knots or other implementations until technical ex=
perts in core repository, other bitcoin projects and users are on the same =
page.

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

Even I noticed this since I don't recall the developers of the 3 main coinj=
oin implementations that are claimed to be impacted by opt-in RBF making an=
y remarks.

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

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, October 18th, 2022 at 12:30 PM, Anthony Towns via bitcoin-dev <=
bitcoin-dev@lists.linuxfoundation.org> wrote:


> On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev w=
rote:
>=20
> > > 1) Continue supporting and encouraging accepting unconfirmed "on-chai=
n"
> > > 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 throu=
gh
> > > #25353 + #25600 wasn't making the assumption the enablement itself wo=
uld
> > > reach agreement of the economic majority or unanimity.
>=20
>=20
> 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.
>=20
> 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.
>=20
> > Without denying that such equilibrium would be unstable, it was designe=
d to
> > remove the responsibility of the Core project itself to "draw a hard li=
ne"
> > on the subject.
>=20
>=20
> Removing responsibility from core developers seems like it's very much
> optimising for the wrong thing to me.
>=20
> 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?
>=20
> 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.
>=20
> 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].
>=20
> [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00=
3033.html
> [1] https://github.com/bitcoin/bitcoin/pull/25353
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020=
557.html
>=20
> 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".
>=20
> 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").
>=20
> [3] https://bitcoinops.org/en/newsletters/2022/06/22/
> [4] https://bitcoinops.org/en/newsletters/2022/07/13/
>=20
> 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.
>=20
> 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.
>=20
> > Moreover, relying on node operators turning on the setting
> > provides a smoother approach offering time to zero-conf services to rea=
ct
> > in consequence.
>=20
>=20
> 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.
>=20
> > So the current path definitely belongs more to a 3) approach.
>=20
> > > 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
>=20
>=20
> 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.
>=20
> 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=
.
>=20
> 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.
>=20
> (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)
>=20
> > While this
> > way cannot be denied to be a zero-risk deployment for business acceptin=
g
> > unconfirmed transactions, it should be weighed in face of multi-party
> > contracting protocols encumbering an annoying pinning vector.
>=20
>=20
> 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?
>=20
> > Since Dario's mail, I think we have learnt new data points, a) on the l=
ong
> > 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.
>=20
>=20
> 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").
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> > 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 proce=
ss,
>=20
>=20
> Doing something like #26323 only after 24.0 is out does nothing to
> mitigate whatever immediate risk there is to bitcoin businesses/users...
>=20
> 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?
>=20
> 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.
>=20
> But saying "we don't want them to be in danger" and also refusing to do
> anything to avoid it?
>=20
> Cheers,
> aj
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev