From ZmnSCPxj at protonmail.com Tue Oct 17 17:04:06 2023 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Tue, 17 Oct 2023 17:04:06 +0000 Subject: [Lightning-dev] [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants In-Reply-To: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com> References: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com> Message-ID: <Ckp3N2cHGyyFyTp8IkjqYwnXsef1KxzhFs9vHQvFCpdWKUCrCfpxLBAgIXsKEtTNQqvfdyywt7weJd2pVz8UKn6egfRy46-xd17pnltcQyU=@protonmail.com> Good morning Bastien, I have not gotten around to posting it yet, but I have a write-up in my computer 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 backout, where if the batched splice transaction can no longer be confirmed due to 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 be confirmed). I know that current splicing tech is to run both the pre-splice and post-splice state simultaneously until the splicing transaction is confirmed. However we need to *also* check if the splicing transaction *cannot* be confirmed --- by checking if the other inputs to the splice transaction were already consumed by transactions that have deeply confirmed, and in that case, 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 check. Unless all splice implementations do this, then any kind of batched splicing is risky. Regards, ZmnSCPxj