>
> I haven't looked at the `announcement_signatures` case yet, but at least
> for the `commit_sig` case this should never be an issue.
>
Yup the issue is the same for `announcement_signatures`. Storing the
last_short_channel_id is key here so you know which announcement
message you can safely igno
Hi Dustin,
I believe this is the scenario I described in [1]?
I haven't looked at the `announcement_signatures` case yet, but at least
for the `commit_sig` case this should never be an issue. It only means
that sometimes, after sending `splice_locked`, you will receive some
`commit_sig` messages
Hey,
In testing the `splice_locked` workflow I discovered a race condition which
is critical we solve correctly. The core problem happens if any channel
activity occurs in the time after `splice_locked` is sent and before
`splice_locked` is received.
`splice_locked` is defined as being locked onc
