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.

iiuc this proposal adds a second STFU mode until/during splice_locked is exchanged + ack'd

I don't understand what issue you're having, can you describe that in more details?

It feels to me that we don't need a splice_locked_at, as long as splice_locked has a way of referencing a commitment (through a splice_number or something similar). You would move the commitment to the main commitment once you've sent and received splice_locked for that number.

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...