Date: Tue, 17 Oct 2023 17:04:06 +0000
To: Bastien TEINTURIER <bastien@acinq.fr>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Ckp3N2cHGyyFyTp8IkjqYwnXsef1KxzhFs9vHQvFCpdWKUCrCfpxLBAgIXsKEtTNQqvfdyywt7weJd2pVz8UKn6egfRy46-xd17pnltcQyU=@protonmail.com>
In-Reply-To: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com>
References: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com>
Feedback-ID: 2872618: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>,
 "lightning-dev\\\\\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Batch exchange withdrawal to lightning requires
	covenants
Precedence: list

Good morning Bastien,

I have not gotten around to posting it yet, but I have a write-up in my com=
puter with the title:

> Batched Splicing Considered Risky

The core of the risk is that if:

* I have no funds right now in a channel (e.g. the LSP allowed me to have 0=
 reserve, or this is a newly-singlefunded channel from the LSP to me).
* I have an old state (e.g. for a newly-singlefunded channel, it could have=
 been `update_fee`d, so that the initial transaction is old state).

Then if I participate in a batched splice, I can disrupt the batched splice=
 by broadcasting the old state and somehow convincing miners to confirm it =
before the batched splice.

Thus, it is important for *any* batched splicing mechanism to have a backou=
t, where if the batched splice transaction can no longer be confirmed due t=
o some participant disrupting it by posting an old commitment transaction, =
either a subset of the splice is re-created or the channels revert back to =
pre-splice state (with knowledge that the post-splice state can no longer b=
e confirmed).

I know that current splicing tech is to run both the pre-splice and post-sp=
lice state simultaneously until the splicing transaction is confirmed.
However we need to *also* check if the splicing transaction *cannot* be con=
firmed --- by checking if the other inputs to the splice transaction were a=
lready consumed by transactions that have deeply confirmed, and in that cas=
e, to drop the post-splice state and revert to the pre-splice state.
I do not know if existing splice implementations actually perform such a ch=
eck.
Unless all splice implementations do this, then any kind of batched splicin=
g is risky.

Regards,
ZmnSCPxj