Re: [Lightning-dev] [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants
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 [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants
> 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 < [email protected]> 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 > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants
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 ___ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
