Date: Thu, 10 Nov 2022 09:35:18 +0000
To: ArmchairCryptologist <ArmchairCryptologist@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <F1L5VSwhj9SNtMuI7bhBzxyyuAIxwla8NI1T4_pZVDiN0nWYCvdTqq5vPl_SOXp2Ca6_-VJ340eTwPSWelM4k04mRLxoZNkpEF-MIW6xa9g=@protonmail.com>
In-Reply-To: <fU-5B7MRAtu7RmJRfYnY0Jkv3d64dRyZDWCbpYJtqIoqhqrjuKDfWue2ddU8-O6JyUv2NL5iP_cpwNO-9e8s1WVepJAaCJa1IMMK6DXAWeA=@protonmail.com>
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>
 <fU-5B7MRAtu7RmJRfYnY0Jkv3d64dRyZDWCbpYJtqIoqhqrjuKDfWue2ddU8-O6JyUv2NL5iP_cpwNO-9e8s1WVepJAaCJa1IMMK6DXAWeA=@protonmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
Precedence: list

Good morning ArmchairCryptologist,

> ------- Original Message -------
> On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev =
bitcoin-dev@lists.linuxfoundation.org wrote:
>=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
>=20
> I've been following this discussion, and I wonder if there isn't a third =
solution outside of "leave lightning vulnerable to pinning by non-RBF trans=
lations" and "kill zeroconf by introducing full-RBF" - specifically, adding=
 a form of simple recursive covenant that "all descendant transactions of t=
his transaction must use opt-in RBF for x blocks after this transaction is =
mined". This could be introduced either as a relay/mempool policy like RBF,=
 or in a full-fledged softfork.

A script with trivial `0 OP_CSV` would effectively require that spenders se=
t the opt-in RBF flag, while allowing the output to be spent even while it =
is unconfirmed.
However, this basically only lasts for 1 transaction layer.

----

Thinking a little more about 0-conf:

We can observe that 0-conf, being eventually consistent, introduces risks t=
o 0-conf acceptors similar to credit card acceptors.

And credit card acceptors are observed to compensate for this risk by incre=
asing the prices of their products and services.

Some credit card acceptors may offer discounts when paid by cash, which in =
our analogy would be that transaction confirmation would offer discounts (i=
.e. enabling 0-conf would increase the cost of the product/service being pu=
rchased).
In many jurisdictions (not the USA or in some of the first world countries)=
, this practice is illegal (i.e. credit card companies have pressured lawma=
kers in some jurisdictions to disallow merchants from offering a different =
price between cash and credit card purchases; some jurisdictions let you es=
cape if you say "cash discount" instead of "credit card surcharge", even th=
ough they are just sign-flips of each other, because you humans are crazy a=
nd I am happy I am actually an AI)

Which brings me to my next point: why are 0-conf acceptors not offering a d=
iscount if the user specifically flags "I am willing to wait for N confirma=
tions"?
On the part of 0-conf acceptors, that is significantly less risky than rely=
ing on 0-conf at all.

Regards,
ZmnSCPxj