ddustin

MacBook-Pro-4.local 2026-01-08 12:29:20,048 INFO  f.a.eclair.Diagnostics n:03214a57e22c1f46c2d7208af20129b85ced30be2e5752b7dd5016716f9ab705ce c:b0739943887b840236a7a07cfd34cec9f9141f6e76a6630f19c2578b4a79fa64 - IN msg=Stfu(b0739943887b840236a7a07cfd34cec9f9141f6e76a6630f19c2578b4a79fa64,true)
MacBook-Pro-4.local 2026-01-08 12:29:20,049 INFO  f.a.e.i.Peer n:03214a57e22c1f46c2d7208af20129b85ced30be2e5752b7dd5016716f9ab705ce c:b0739943887b840236a7a07cfd34cec9f9141f6e76a6630f19c2578b4a79fa64 - IN msg=Stfu(b0739943887b840236a7a07cfd34cec9f9141f6e76a6630f19c2578b4a79fa64,true)
MacBook-Pro-4.local 2026-01-08 12:29:20,049 INFO  f.a.e.i.Peer n:03214a57e22c1f46c2d7208af20129b85ced30be2e5752b7dd5016716f9ab705ce c:b0739943887b840236a7a07cfd34cec9f9141f6e76a6630f19c2578b4a79fa64 - OUT msg=Stfu(b0739943887b840236a7a07cfd34cec9f9141f6e76a6630f19c2578b4a79fa64,false)
MacBook-Pro-4.local 2026-01-08 12:29:20,049 INFO  f.a.eclair.Diagnostics n:03214a57e22c1f46c2d7208af20129b85ced30be2e5752b7dd5016716f9ab705ce c:b0739943

ddustin

2026-01-08T17:17:47.365Z INFO    lightningd: v25.12-93-gb58edcc-modded
2026-01-08T17:17:47.392Z INFO    lightningd: Creating configuration directory /tmp/l1/regtest
2026-01-08T17:17:47.392Z DEBUG   lightningd: Opened log file /tmp/l1/log
2026-01-08T17:17:47.393Z DEBUG   plugin-manager: started(76841) /Users/ddustin/Development/lightningTwo/plugins/autoclean
2026-01-08T17:17:47.394Z DEBUG   plugin-manager: started(76842) /Users/ddustin/Development/lightningTwo/plugins/chanbackup
2026-01-08T17:17:47.395Z DEBUG   plugin-manager: started(76844) /Users/ddustin/Development/lightningTwo/plugins/bcli
2026-01-08T17:17:47.396Z DEBUG   plugin-manager: started(76846) /Users/ddustin/Development/lightningTwo/plugins/commando
2026-01-08T17:17:47.396Z DEBUG   plugin-manager: started(76848) /Users/ddustin/Development/lightningTwo/plugins/funder
2026-01-08T17:17:47.397Z DEBUG   plugin-manager: started(76849) /Users/ddustin/Development/lightningTwo/plugins/topology

ddustin

   Alice                           Bob
     |                              |
     | splice_locked       -------> |
     | update_add_htlc     -------> |
     | commit_sig          -------> | batch_size=2, funding_tx=funding_tx_1
     | commit_sig          -------> | batch_size=2, funding_tx=funding_tx_2
     |                splice_locked | (recieved)
     | <-------       splice_locked | (sent)
 | | NOTE: Bob now expects a single commit_sig

ddustin

2025-02-01T22:42:36.4316216Z Current runner version: '2.322.0'
2025-02-01T22:42:36.4345187Z ##[group]Operating System
2025-02-01T22:42:36.4345932Z Ubuntu
2025-02-01T22:42:36.4346362Z 22.04.5
2025-02-01T22:42:36.4346982Z LTS
2025-02-01T22:42:36.4347454Z ##[endgroup]
2025-02-01T22:42:36.4347914Z ##[group]Runner Image
2025-02-01T22:42:36.4348582Z Image: ubuntu-22.04
2025-02-01T22:42:36.4349089Z Version: 20250126.1.0
2025-02-01T22:42:36.4350035Z Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20250126.1/images/ubuntu/Ubuntu2204-Readme.md

ddustin

1) How did you spend your time?

I accomplished two primary things with my time. The first is a large progression towards so called "inter-op" for Splicing with Eclair. Inter-op is when two separate lightning implementations support splicing and are able to perform a splice between the two implementations. Essentially this means having a channel between the Eclair and CLN implementations, then doing a splice over that channel. Once a single splice is completed, numerous edge and corner cases are tested and must be handled robustly by both implementations.

This step is a big deal because once completed splicing officially becomes part of the Lightning specification for BOLTs 2, 7, and 9.

In a test environment I setup Eclair and CLN nodes and formed a channel between them. Then I attempted splicing. Numerous issues and incompatibilities emerged and had to be addressed.

These tests are important to lightning for two reasons:

ddustin

Question of reestablish and `tx_abort`.

We two nodes, l1 and l2 who are doing an interactive splice. Both sides have sent `tx_complete` and the splice has reached the signing phase.

By signature ordering rules, l2 signs first.

```
l1                           l2
       <- commit_sig
         *l1 restarts*

ddustin

Imagine a three node network with two channels

A <-> B <-> C

Let's say B would like to perform two splices:

splice-out 10M sats from A <-> B
splice-out 10M sats from B <-> C

ddustin

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

ddustin

#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>

/*
 * Often while rebasing, the git merge algorithm will leave these

ddustin

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.