{"type":"rich","version":"1.0","title":"Greg Sanders [ARCHIVE] wrote","author_name":"Greg Sanders [ARCHIVE] (npub1jd…3gh0m)","author_url":"https://yabu.me/npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-10-17\n🗒️ 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.\n📝 Original message:\n\u003e I do not know if existing splice implementations actually perform such a\ncheck.\nUnless all splice implementations do this, then any kind of batched\nsplicing is risky.\n\nAs long as the implementation decides to splice again at some point when a\nprior\nsplice isn't confirming, it will self-resolve once any subsequent splice is\nconfirmed.\n\nCheers,\nGreg\n\nOn Tue, Oct 17, 2023 at 1:04 PM ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Bastien,\n\u003e\n\u003e I have not gotten around to posting it yet, but I have a write-up in my\n\u003e computer with the title:\n\u003e\n\u003e \u003e Batched Splicing Considered Risky\n\u003e\n\u003e The core of the risk is that if:\n\u003e\n\u003e * I have no funds right now in a channel (e.g. the LSP allowed me to have\n\u003e 0 reserve, or this is a newly-singlefunded channel from the LSP to me).\n\u003e * I have an old state (e.g. for a newly-singlefunded channel, it could\n\u003e have been `update_fee`d, so that the initial transaction is old state).\n\u003e\n\u003e Then if I participate in a batched splice, I can disrupt the batched\n\u003e splice by broadcasting the old state and somehow convincing miners to\n\u003e confirm it before the batched splice.\n\u003e\n\u003e Thus, it is important for *any* batched splicing mechanism to have a\n\u003e backout, where if the batched splice transaction can no longer be confirmed\n\u003e due to some participant disrupting it by posting an old commitment\n\u003e transaction, either a subset of the splice is re-created or the channels\n\u003e revert back to pre-splice state (with knowledge that the post-splice state\n\u003e can no longer be confirmed).\n\u003e\n\u003e I know that current splicing tech is to run both the pre-splice and\n\u003e post-splice state simultaneously until the splicing transaction is\n\u003e confirmed.\n\u003e However we need to *also* check if the splicing transaction *cannot* be\n\u003e confirmed --- by checking if the other inputs to the splice transaction\n\u003e were already consumed by transactions that have deeply confirmed, and in\n\u003e that case, to drop the post-splice state and revert to the pre-splice state.\n\u003e I do not know if existing splice implementations actually perform such a\n\u003e check.\n\u003e Unless all splice implementations do this, then any kind of batched\n\u003e splicing is risky.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/831a1dfc/attachment-0001.html\u003e"}