Date: Wed, 12 Oct 2022 16:11:05 +0000
To: Anthony Towns <aj@erisian.com.au>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
In-Reply-To: <Y0ZTtlRSBihNN9+v@erisian.com.au>
References: <Y0ZTtlRSBihNN9+v@erisian.com.au>
Feedback-ID: 19463299: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

On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns <aj@erisian.com.=
au> wrote:

> On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev w=
rote:
>=20
> > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin=
-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> >=20
> > > Thanks for the fast answer! It seems I missed the link to the PR, sor=
ry for the
> > > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > > (https://github.com/bitcoin/bitcoin/pull/25353).
> > > It is not clear to me why you believe the merging of this particular =
pull request poses an immediate risk to you.
>=20
>=20
> Did you see the rest of Dario's reply, bottom-posted after the quoted
> text? Namely:

Oh, my mail client for some reason chose to hide all that. Dario, I'm sorry=
 for missing this; I see now that you were certainly aware of what the PR u=
nder consideration did.

Further comments inline.

> On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via

> > The question then is whether an opt-in flag for full-RBF will have enou=
gh
> > adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> > objective of allowing nodes participating in multi-party funding protoc=
ols
> > to assume that they can rely on full-RBF. If it is, then zero-conf appl=
ications
> > will be at severe risk (per the logic in the initial email).

>=20
>=20
> That logic seems reasonably sound to me:
>=20
> - if adding the option does nothing, then there's no point adding it,
> and no harm in restricting it to test nets only
>=20
> - if adding the option does do something, then businesses using zero-conf
> need to react immediately, or will go from approximately zero risk of
> losing funds, to substantial risk
>=20
> (I guess having the option today may allow you to manually switch your
> node over to supporting fullrbf in future when the majority of the networ=
k
> supports it, without needing to do an additional upgrade in the meantime;
> but that seems like a pretty weak benefit)

I certainly recognize that adding the flag is a likely step towards, over t=
ime, the full RBF policy becoming more widely adopted on the network. That =
is presumably the reason why people are in favor of having the flag, even d=
efault off - including me. I believe that policy's adoption is inevitable e=
ventually, but the speed at which that is achieved is certainly a function =
of availability and adopted of software which provides the option.

That said, I think it's a bit of a jump to conclude that the only two optio=
ns are that either the existence of the flag either has no effect at all, o=
r poses an immediate threat to those relying on its absence. In my view, it=
 is just what I said: a step towards getting full RBF on the network, by al=
lowing experimentation and socializing the notion that developers believe i=
t is time. So I have a hard time imagining how it would change anything *im=
mediately* on the network at large (without things like default on and/or p=
referential peering, ...), but I still believe it's an important step.

Cheers,

--=20
Pieter