Dusty Daemon 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

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

   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

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:

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

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

	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

	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

	#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

	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.