📅 Original date posted:2023-10-17
🗒️ Summary of this message: Batched splicing can be risky if not all splice implementations perform a check to ensure subsequent splices confirm, potentially leading to loss of funds.
📝 Original message:
Good morning Greg,
> > 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.
Do note that there is a risk here that the reason for "not confirming" is because of an unexpected increase in mempool usage.
In particular, if the attack is not being performed, it is possible for the previous splice tx that was not confirming for a while, to be the one that confirms in the end, instead of the subsequent splice.
This is admittedly an edge case, but one that could potentially be specifically attacked and could lead to loss of funds if the implementations naively deleted the signatures for commitment transactions for the previously-not-confirming splice transaction.
Indeed, as I understood it, part of the splice proposal is that while a channel is being spliced, it should not be spliced again, which your proposal seems to violate.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-10-18 13:02:11
in reply to nevent1q…mra6
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lSeen on
wss://nos.lolPublished at
2023-10-18 13:02:11Event JSON
{
"id": "88c10020267adb05d1cc6cd303847d1d1e9a234a1eca6509f63f317c99562ca6",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1697634131,
"kind": 1,
"tags": [
[
"e",
"77f2597fa5007d64c39dc7060db6a936c6d10d3e7418dd618d5cc20cd1023237",
"",
"root"
],
[
"e",
"7ee6f7e1280586450ea5ed37454f4b95b0cb840fd74866461479396d8b112500",
"",
"reply"
],
[
"p",
"937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19"
]
],
"content": "📅 Original date posted:2023-10-17\n🗒️ Summary of this message: Batched splicing can be risky if not all splice implementations perform a check to ensure subsequent splices confirm, potentially leading to loss of funds.\n📝 Original message:\nGood morning Greg,\n\n\n\u003e \u003e I do not know if existing splice implementations actually perform such a check.\n\u003e Unless all splice implementations do this, then any kind of batched splicing is risky.\n\u003e As long as the implementation decides to splice again at some point when a prior\n\u003e splice isn't confirming, it will self-resolve once any subsequent splice is confirmed.\n\nDo note that there is a risk here that the reason for \"not confirming\" is because of an unexpected increase in mempool usage.\n\nIn particular, if the attack is not being performed, it is possible for the previous splice tx that was not confirming for a while, to be the one that confirms in the end, instead of the subsequent splice.\nThis is admittedly an edge case, but one that could potentially be specifically attacked and could lead to loss of funds if the implementations naively deleted the signatures for commitment transactions for the previously-not-confirming splice transaction.\n\nIndeed, as I understood it, part of the splice proposal is that while a channel is being spliced, it should not be spliced again, which your proposal seems to violate.\n\nRegards,\nZmnSCPxj",
"sig": "3b049cc2278ceb7c837c5623a11087019ae2224f05ffac7cb472031f3267bfc9c3fe2824cdfca2dc0eb51dc00f0b432e0dbbf3d7caa5bcc0c9574a055423827a"
}