Nostr Web Client

🔖 Title: Batch exchange withdrawal to lightning requires covenants

🏷️ Categories: Lightning-dev, bitcoin-dev

nostr:naddr1qqjrwcmz8yekvc3k95unydty956rzve395un2dpe95crvetyvc6rxc3svsensqg5waehxw309aex2mrp0yhxgctdw4eju6t0qy2hwumn8ghj7etyv4hzumn0wd68ytnvv9hxgqguwaehxw309ahx7um5wghx6at5d9h8jampd3kx2apwvdhk6q3q2llycjh8gg2lhy4aph9c5au8ch5s0km5axrlxrc6e24dnsaqyu0sxpqqqp65wh3aapn

⚠️ Heads up! We've now started linking to replaceable long-form events (NIP-23), which allow for dynamic display of thread details like summaries, authors, and more. If you're unable to see this, your client may not support this feature yet.

Reply to this note

Please Login to reply.

Discussion

45050727... 2y ago

📅 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

937f10fc... 2y ago

📅 Original date posted:2023-10-17

🗒️ Summary of this message: Batched splicing is risky because if an old state is broadcasted and confirmed before the splice, it can disrupt the process. It is important for batched splicing mechanisms to have a backout option.

📝 Original message:

> 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 at 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 at lists.linuxfoundation.org

> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/831a1dfc/attachment-0001.html>

45050727... 2y ago

📅 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