Skip to content

Instantly share code, notes, and snippets.

@ddustin
Last active April 4, 2023 19:44
Show Gist options
  • Save ddustin/7ee222eb31c3eac5b141c991c0937fae to your computer and use it in GitHub Desktop.
Save ddustin/7ee222eb31c3eac5b141c991c0937fae to your computer and use it in GitHub Desktop.
Legend:
Item -> means sent
Item <- means received
Chan X (implies a channel at block height X)
(Since these happen at different times)
Splice locked race condition example
Node A. Node B.
* Channel starts at block height 100
splice_locked ->
<- splice_locked
<- commitments_signed (Chan 100)
-> splice_locked
Node B now considers splice locked (Chan 106)
<- commitments_signed (Chan 106)
splice_locked <-
Node A now considers splice locked (Chan 106)
commitments_signed <- (Chan 100)
commitments_signed <- (Chan 106)
Node A considers the commitments_signed for Chan 100 invalid.
The commitments_signed for Chan 106 is, however, valid.
This example uses commitments_signed but remains a problem for any message
that depends on channel state.
@niftynei
Copy link

Order of events:

  1. A sends splice_locked
  2. B sends splice_locked back at the same moment (also 6 block depth)
  3. B sends commitment_signed for pre-splice tx (chan 100)
  4. B rcv splice_locked from A (sent at 0)
  5. B sends commitment_signed for splice tx (chan 106)

what should A do when it gets chan 100 commitment_signed??

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