ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-10-17 🗒️ Summary of this message: Batched ...
📅 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
🗒️ 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