Date: Wed, 09 Nov 2022 13:19:28 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ArmchairCryptologist <ArmchairCryptologist@protonmail.com>
Message-ID: <fU-5B7MRAtu7RmJRfYnY0Jkv3d64dRyZDWCbpYJtqIoqhqrjuKDfWue2ddU8-O6JyUv2NL5iP_cpwNO-9e8s1WVepJAaCJa1IMMK6DXAWeA=@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: 24244585: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

------- Original Message -------
On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev <b=
itcoin-dev@lists.linuxfoundation.org> wrote:

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

I've been following this discussion, and I wonder if there isn't a third so=
lution outside of "leave lightning vulnerable to pinning by non-RBF transla=
tions" and "kill zeroconf by introducing full-RBF" - specifically, adding a=
 form of simple recursive covenant that "all descendant transactions of thi=
s transaction must use opt-in RBF for x blocks after this transaction is mi=
ned". This could be introduced either as a relay/mempool policy like RBF, o=
r in a full-fledged softfork.

Based on my admittedly not all-encompassing understanding of the bitcoin tr=
ansaction format, there are several unused bits in nSequence, which is alre=
ady used to flag RBF, that might be repurposed to flag the duration of this=
 lock. Say if two bits were used for this, that would be enough to flag tha=
t the restriction is not used, or active for 100, 1000 and 10000 blocks.

I'm sure there may be other and potentially better ways of enabling this ty=
pe of covenant, but I'll leave that to the people who actually live and bre=
athe the bitcoin transaction format.

--
Regards,
ArmchairCryptologist