SplicingReestablishNotes.md

IMMEDIATELY AFTER RECEIVING CHANNEL_REESTABLISH

• Do we have any active inflight splices?
  • Yes:
    • does latest splice inflight have commit and remote sig?
      • Yes: continue
      • No: send next_funding txid of latest inflight candidate, then, continue
    • peer sends next_funding value of:
      • None: Have I sent splice tx signatures?
        • Yes: Have I received splice tx signatures?
          • Yes: send nothing
          • No: unilaterally close
        • No: Delete inflight (send nothing)
      • Same as our next_funding: resume splice negotiation (send commit and splice sig)
      • Same as our channel txid: error; unilaterally close
      • Any other value: error; unilaterally close
  • No: do not send any next_funding txid
    • peer sends next_funding value of:
      • Same as our channel txid
        • resend splice_locked at the completion of reestablish
      • Any other value
        • Ignore, do not resume splice (we have nothing inflight to resume)

does latest splice inflight have commit and remote sig?
No: send next_funding txid of latest inflight candidate, then, continue

Note that the "No" case should trigger as soon as you sent commit_sig, even if you didn't receive the remote commit_sig. Overall, the reestablish works exactly the same as dual funding (which is now on cln's master branch).

No: unilaterally close

Why? They're simply asking you to retransmit your tx_signatures, which is legit?

resend splice_locked at the completion of reestablish

That isn't sufficient, you must re-send tx_signatures if they request the next_funding_txid matching the latest funding transaction.

Ignore, do not resume splice (we have nothing inflight to resume)

That isn't sufficient either, you must let your peer know that they must forget this attempt, so you must send tx_abort.

Overall I think you're trying to re-spec differently what has already been spec-ed for dual funding and works.
Can you have a look at lightning/bolts@36c04c8, I think this should clarify it, as splicing must have exactly the same requirements (and simply add requirements for splice_locked retransmission).

I reviewed lightning/bolts@36c04c8 further and I think we can do it this way. My implementation was structured around "what are the conditions we should resume the splice" and this spec is more piecemeal in what is sent and leaves uncertainty on what is received. Had to do some restructuring but this works. So, happy to do it this way and be consistent with dual-funding.

The thing we do need to add is the resending of splice_locked when you receive next_funding_txid that matches your current channel_txid.