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 certain conditions are met, such as having no funds in a channel and using an old state. It is important for batched splicing mechanisms to have a backout option to prevent disruptions.
📝 Original message:
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
🗒️ Summary of this message: Batched splicing can be risky if certain conditions are met, such as having no funds in a channel and using an old state. It is important for batched splicing mechanisms to have a backout option to prevent disruptions.
📝 Original message:
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