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

[ArmchairCryptologist <ArmchairCryptologist@protonmail.com>]

------- Original Message -------
On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev <bitcoin-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 solution outside of "leave lightning vulnerable to pinning by non-RBF translations" and "kill zeroconf by introducing full-RBF" - specifically, adding a form of simple recursive covenant that "all descendant transactions of this 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.

Based on my admittedly not all-encompassing understanding of the bitcoin transaction format, there are several unused bits in nSequence, which is already 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 that 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 type of covenant, but I'll leave that to the people who actually live and breathe the bitcoin transaction format.

--
Regards,
ArmchairCryptologist