rich1.0Greg Sanders [ARCHIVE] (npub1jd…3gh0m)https://yabu.me/npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mnjumphttps://yabu.me📅 Original date posted:2023-10-17 🗒️ Summary of this message: Batched splicing is risky because if an old state is broadcasted and confirmed before the splice, it can disrupt the process. It is important for batched splicing mechanisms to have a backout option. 📝 Original message: > 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. As long as the implementation decides to splice again at some point when a prior splice isn't confirming, it will self-resolve once any subsequent splice is confirmed. Cheers, Greg On Tue, Oct 17, 2023 at 1:04 PM ZmnSCPxj via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/831a1dfc/attachment-0001.html>