From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Greg Sanders <gsanders87@gmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
"lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants
Date: Tue, 17 Oct 2023 17:17:04 +0000 [thread overview]
Message-ID: <xq5SXj5Qx2uuhwui_Xoc0K0WBxoJj98cYBCoumHLi101ofbMCET_-4athmHvDvDl0H9GKHlsRo73j9iUuSx9OmHbfQNjDDYAx-JzFNLMNtI=@protonmail.com> (raw)
In-Reply-To: <CAB3F3Dtb2s7gCjV6ok3=XjOx174DEuRksij4GOoFD20atwJfig@mail.gmail.com>
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
next prev parent reply other threads:[~2023-10-17 17:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 13:03 Bastien TEINTURIER
2023-10-17 17:04 ` ZmnSCPxj
2023-10-17 17:10 ` Greg Sanders
2023-10-17 17:17 ` ZmnSCPxj [this message]
2023-10-17 19:10 ` [bitcoin-dev] [Lightning-dev] " Antoine Riard
2023-10-18 14:35 ` Bastien TEINTURIER
2023-10-18 18:03 ` Antoine Riard
2023-10-19 7:35 ` Bastien TEINTURIER
2023-10-19 17:09 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='xq5SXj5Qx2uuhwui_Xoc0K0WBxoJj98cYBCoumHLi101ofbMCET_-4athmHvDvDl0H9GKHlsRo73j9iUuSx9OmHbfQNjDDYAx-JzFNLMNtI=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gsanders87@gmail$(echo .)com \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox