Splice locked ack flow

splice_locked     ->
                   <- splice_locked
(Whichever side has lower funding pubkey starts STFU)
STFU              ->
                   <- STFU (ack)
splice_locked_ack ->
                   <- splice_locked_ack
Receiving splice_locked_ack ends STFU mode and
means we can atomically move to the new channel
confirmed state.

The issue is if there is pending HTLC activity / commits during the lock in phase.

Pre-lock-in our commitments are:
funding_tx commit sig + (tlv) splice_tx commit sig

Post-lock-in our commitments are:
splice_tx commit sig

If a pre-lock-in style is sent just before the moment of splice lock in and arrives just after splice lock in, then it's an invalid message.

This can happen if payment activity is happening a lot during this moment.

So we need an atomic moment to say "before X we're pre-lock-in" and "after X we're post-lock-in" where X is something atomic for both nodes.

The prior splice_lock proposal did not include an atomic moment for X and both nodes arrive to it at slightly different moments.

I think I'm starting to see what you mean. Doesn't that mean we just need to quiesce again to notify of a splice_locked? If we defer splice_locked until we're quiescent again, does that race disappear?

Yup that works but has a downside. If there is a delay between when each node sees the on-chain confirmation, we'll be quiescent for the length of that delay.

Agreed, that's not ideal. We'll need to thoroughly test potential races in the protocol to see whether we can make it right without quiescing again or not...