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