📅 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>;
Greg Sanders [ARCHIVE] /
npub1jd…3gh0m
2023-10-18 13:02:10
in reply to nevent1q…zlfw
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mSeen on
wss://nos.lolPublished at
2023-10-18 13:02:10Event JSON
{
"id": "7ee6f7e1280586450ea5ed37454f4b95b0cb840fd74866461479396d8b112500",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1697634130,
"kind": 1,
"tags": [
[
"e",
"77f2597fa5007d64c39dc7060db6a936c6d10d3e7418dd618d5cc20cd1023237",
"",
"root"
],
[
"e",
"50c09864bec60754f99cb96dbffaf4b890bd5bc81b9dc81e7649fccc6948bd77",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 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",
"sig": "0dae04dd6cf7033ae984c606ee5afbb83dd6a66c15aaf805dd4236c8843137d2d38a9c306d8164767e56f2eb5bfb92edfb038adaba16d56fc5a0c3c9536cfe70"
}