Skip to content

Instantly share code, notes, and snippets.

@ddustin
Last active June 26, 2023 14:12
Show Gist options
  • Save ddustin/017aeadfbf34d2fcd950f1238614afe2 to your computer and use it in GitHub Desktop.
Save ddustin/017aeadfbf34d2fcd950f1238614afe2 to your computer and use it in GitHub Desktop.
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.
@niftynei
Copy link

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

@t-bast
Copy link

t-bast commented Jan 30, 2023

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.

@ddustin
Copy link
Author

ddustin commented Jan 30, 2023

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.

@t-bast
Copy link

t-bast commented Jan 30, 2023

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?

@ddustin
Copy link
Author

ddustin commented Jan 30, 2023

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.

@t-bast
Copy link

t-bast commented Jan 30, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment