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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
