[Splicing] Cross-compatibility test results

[t-bast]

Hey! I've done a bunch of splicing cross-compatibility tests with eclair, using cln's master branch, and here are the results. Things are mostly working well, but there are a few important bugs so this isn't safe to ship yet.

Let's start with the bugs/missing features:

• if I initiate a splice-in (and I think splice-out will be the same) from cln, the tx_signatures sent by cln is incorrect and cln crashes: I'm wondering if this is related to funding key rotation? I think the bug is on the cln side, since I've had no issue doing that with ldk
• aborting a splice on reconnection doesn't work: if we disconnect before receiving each other's commit_sig, and eclair actually wanted to cancel the splice, cln will keep sending a warning and disconnecting instead of aborting that splice. It means that this test case isn't implemented in cln: https://github.com/t-bast/bolts/blob/splicing/bolt02/splicing-test.md#disconnection-with-one-side-sending-commit_sig
• cln sends splice_locked after only 1 confirmation: that's very dangerous, you should wait for at least 3 confirmations (eclair waits for 8 confirmations by default). I wasn't able to fully test splice_locked behavior because of this limitation
• cln doesn't retransmit announcement_signatures on reconnection when requested in my_current_funding_locked (by setting the announcement_signatures bit in the retransmit_flags bitfield)

And here is what I tested that worked:

• quiescence seems to work correctly (I couldn't test all cases easily from the outside, but what I tested worked well)
• splicing works correctly even when the local and remote commitment_numbers are different
• retransmission of commit_sig on reconnection works
• retransmission of tx_signatures on reconnection works
• splice_locked behavior looks correct, but I couldn't test the case where eclair sends splice_locked earlier than cln, since cln sends it after only 1 confirmation (see my previous point above)
• RBF works correctly, including commit_sig and tx_signatures retransmission on reconnect (but probably not tx_abort on reconnect, since https://github.com/t-bast/bolts/blob/splicing/bolt02/splicing-test.md#disconnection-with-one-side-sending-commit_sig isn't implemented)

@ddustin I'll let you work on those remaining issues, I feel like we're pretty close! You can use this branch of eclair for your tests: https://github.com/ACINQ/eclair/tree/splicing-official-cross-compat

[ddustin]

• if I initiate a splice-in (and I think splice-out will be the same) from cln, the tx_signatures sent by cln is incorrect and cln crashes: I'm wondering if this is related to funding key rotation? I think the bug is on the cln side, since I've had no issue doing that with ldk

Do you have a log for this?

• aborting a splice on reconnection doesn't work: if we disconnect before receiving each other's commit_sig, and eclair actually wanted to cancel the splice, cln will keep sending a warning and disconnecting instead of aborting that splice. It means that this test case isn't implemented in cln: https://github.com/t-bast/bolts/blob/splicing/bolt02/splicing-test.md#disconnection-with-one-side-sending-commit_sig

What's the warning message for this? Can you post the logs.

• cln sends splice_locked after only 1 confirmation: that's very dangerous, you should wait for at least 3 confirmations (eclair waits for 8 confirmations by default). I wasn't able to fully test splice_locked behavior because of this limitation

CLN uses 1 conf when in regtest. If you set minconf when funding the channel to something higher, splicing will use that same value. You could set it to 9 confirmations for instance if you wanted to test cln seeing it later.

[t-bast]

Do you have a log for this?

No, I've done a lot of tests so I haven't kept every log file. It's trivial to repro though, just grab my eclair branch and you should see it!

What's the warning message for this? Can you post the logs.

Same, I don't have the logs, but the message says that cln expects a commitment_signed. But I sent tx_abort, so if you follow the test vector I linked, cln should just abort and forget that splice.

CLN uses 1 conf when in regtest. If you set minconf when funding the channel to something higher, splicing will use that same value. You could set it to 9 confirmations for instance if you wanted to test cln seeing it later.

Interesting, so you accept whatever minconf your remote chooses (if it's the remote that opens the channel)? That's very dangerous if that's the case? Or is it only when you are the initiator (in that case, what value do you use when you're not the initiator, and how can I configure it?)?

[t-bast]

@ddustin any update on that? I have time for more cross-compat tests in the next couple of weeks if you want me to test some of your changes. This is the only thing blocking us from merging the splice spec PR 🎉

[t-bast]

Do you have a log for this?

Here is a crash log if that can help (it's a 100% repro).

crash.log

[ddustin]

Thanks! I’ve been away on a trip and I’m going to hopefully knock this out in the next couple days

…

On Mon, Dec 22, 2025 at 9:40 AM Bastien Teinturier ***@***.***> wrote: *t-bast* left a comment (ElementsProject/lightning#8705) <#8705 (comment)> Do you have a log for this? Here is a crash log if that can help (it's a 100% repro). crash.log <https://github.com/user-attachments/files/24293492/crash.log> — Reply to this email directly, view it on GitHub <#8705 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQ5FZ7RJA47RWMA27FDFL4C77HDAVCNFSM6AAAAACMWPMS2WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMOBSGM2TQMZWHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[t-bast]

Gotcha. Another bug that I found is that cln does NOT retransmit its announcement_signatures on reconnection, even when asked. Eclair sends in its channel_reestablish the my_current_funding_locked TLV with the announcement_signatures bit set in the retransmit_flags, but cln completely ignores it and doesn't re-send its announcement_signatures.

This should be trivial to fix, you just need to re-create the announcement_signatures messages on reconnection when receiving this TLV.

[ddustin]

I am working on it. Unfortunately announcement_signatures are handled in a totally separate daemon for CLN so this change requires some complex interdaemon communication that it wasn't designed for.

Maybe I could just jam in a new announcement_signatures from the channel daemon but I suspect it would get rejected in PR review 😰

[ddustin]

• if I initiate a splice-in (and I think splice-out will be the same) from cln, the tx_signatures sent by cln is incorrect and cln crashes: I'm wondering if this is related to funding key rotation? I think the bug is on the cln side, since I've had no issue doing that with ldk

Still looking into this one.

• aborting a splice on reconnection doesn't work: if we disconnect before receiving each other's commit_sig, and eclair actually wanted to cancel the splice, cln will keep sending a warning and disconnecting instead of aborting that splice. It means that this test case isn't implemented in cln: https://github.com/t-bast/bolts/blob/splicing/bolt02/splicing-test.md#disconnection-with-one-side-sending-commit_sig

This one is hard to recreate. CLN handles tx_abort in all the cases we test for. Do you have any tips on what stage this could be happening where tx_abort results in a warning or a copy of what warning it outputted?

The two ways processing tx_abort can fail are:

• "tx_abort is not allowed after I have sent my signature. msg: %s txid: %s" (channel error)
• "bad tx_abort %s" (channel warning)

I am guessing from your description the tx_abort is not being processed as an abort and is getting misdirected.

Would appreciate any help recreating your issue 🙏

• cln sends splice_locked after only 1 confirmation: that's very dangerous, you should wait for at least 3 confirmations (eclair waits for 8 confirmations by default). I wasn't able to fully test splice_locked behavior because of this limitation

This is just automatic when in regtest mode 👍

• cln doesn't retransmit announcement_signatures on reconnection when requested in my_current_funding_locked (by setting the announcement_signatures bit in the retransmit_flags bitfield)

This is implemented and being polished off into a PR right now

[ddustin]

Do you have a log for this?

Here is a crash log if that can help (it's a 100% repro).

crash.log

In this log, after sending TX_SIGNATURES to Eclair. We get a WIRE_ERROR in response:

received ERROR channel f81a3fa6048e4328075f4ae0b48b05e818e0192b450bef37ba630426022de508: invalid funding signature: txId=35f92d21481c7622c5ca758469ddf1e9850c76c183916bf2afecb9c2a6cb4e2c (reason=protocol)

It looks like Eclair rejected our signature on the splice. Do you have the logs from the Eclair side? Would be great to get the tx bytes from both sides and see if there is a mismatch.

It looks like your building the PSBT from CLN's command line manually -- this could be the PSBT you're managing on the command line. I'm hopeful this was just an issue with the user signature being don't incorrectly since we previously tested this so thoroughly.

You can check that by just doing a splice-out (no user signatures) or using the dev-splice command which handles all the RPC steps automatically:

Splice out:

lightning-cli dev-splice "8338aef0 -> 10000sat"

Splice In:

lightning-cli dev-splice "wallet -> 10000sat; 100% -> 8338aef0"

Docs for dev-splice: https://docs.corelightning.org/reference/dev-splice

[ddustin]

I'm doing an audit of all the flows where we expect tx_abort

Is it possible you're sending tx_abort before channel_reestablish? It looks like we don't expect that.

It looks like one of our log messages (that might be what you saw) had an incorrect warning message.

"Got incorrect message from peer: %s (should be WIRE_COMMITMENT_SIGNED) [%s]"

When the log message should have read:

"Got incorrect message from peer: %s (should be WIRE_COMMITMENT_SIGNED or WIRE_TX_SIGNATURES or WIRE_TX_ABORT) [%s]"

The messages allowed at this point are commitment, sigs, or abort. Another possibility is Eclair was sending something other than tx_abort. Perhaps Eclair is sending some other message before sending tx_abort?

Still working on recreating what you're seeing locally.

This PR checks for tx_abort before channel_reestablish and cleans up the log message to be more clear about what it's actually checking: #8818

[ddustin]

This PR #8817 should respond to announcement sig requests

[t-bast]

It looks like your building the PSBT from CLN's command line manually -- this could be the PSBT you're managing on the command line. I'm hopeful this was just an issue with the user signature being don't incorrectly since we previously tested this so thoroughly.

You're right, I hadn't found the dev-splice command and was painfully using the low-level RPCs, so I may have messed it up! I just tested using the dev-splice command and splice-out worked fine. However, I couldn't make splice-in work:

• if I do bob-cln-cli dev-splice "wallet -> 100000sat; 100% -> b33f93d8" I get the following error: "Putting change back into same wallet outpoint not yet supported"
• if I do bob-cln-cli dev-splice "wallet -> 100000sat+fee; 100000sat -> b33f93d8" I get the following error: "Don't support wallet funding being used for fee"
• if I do bob-cln-cli dev-splice "wallet -> 100000sat; 95% -> b33f93d8" then the splice completes, but cln sends an invalid tx_signatures and I'm back to the crash I saw earlier (the signed transaction is indeed rejected by bitcoind with OP_EQUALVERIFY failed: elements are different)

I'm probably just not using the script elements correctly: can you explain how I would do a basic splice-in where funds are taken from the on-chain wallet and splice fees are correctly paid? This way I'll run that test, and if I'm still seeing a crash I'll share the logs.

This one is hard to recreate. CLN handles tx_abort in all the cases we test for. Do you have any tips on what stage this could be happening where tx_abort results in a warning or a copy of what warning it outputted?

I don't understand, did you look at the spec test vector I linked: https://github.com/t-bast/bolts/blob/splicing/bolt02/splicing-test.md#disconnection-with-one-side-sending-commit_sig ? This is exactly the scenario I'm testing which fails.

So cln is sending tx_complete and commit_sig, but a disconnection happens before eclair receives either of those two messages, so on reconnection the splice must be aborted. Another similar scenario is that cln sends tx_complete and commit_sig, but when eclair receives tx_complete, it finds that the resulting transaction is invalid (e.g. not paying enough fees) and sends tx_abort instead of commit_sig. In those cases, cln must support aborting that splice, even though it has sent commit_sig, this is important otherwise channels will get stuck. It is safe to abort at that point because cln has not sent tx_signatures, and hasn't received the remote commit_sig.

Let me know if you're confident that cln already supports this and I'll test again, but I suspect that this isn't implemented on your side (LDK had the same issue in our first round of cross-compat tests, they forgot to implement support for this case).

Is it possible you're sending tx_abort before channel_reestablish? It looks like we don't expect that.

No, I'm not sending tx_abort before channel_reestablish. I'm just following the flow of messages from the spec test vector I linked.

[ddustin]

I'm probably just not using the script elements correctly: can you explain how I would do a basic splice-in where funds are taken from the on-chain wallet and splice fees are correctly paid? This way I'll run that test, and if I'm still seeing a crash I'll share the logs.

Not everything works with the splice script yet -- particularly complex feerate things. It's still in earlyish development.

The splice-in test does this:

"wallet -> 200000; 100000 -> b33f93d8"

What you did should work just fine though

"wallet -> 100000sat; 95% -> b33f93d8"

Just leaving extra sats around usually works.

I don't understand, did you look at the spec test vector I linked: https://github.com/t-bast/bolts/blob/splicing/bolt02/splicing-test.md#disconnection-with-one-side-sending-commit_sig ? This is exactly the scenario I'm testing which fails.

Yes I did 👍. tx_abort is definitely implemented and supported but that's not to say there isn't some bug with how it's handled that interop testing is revealing.

If we assume in this example below CLN wants to continue but Eclair is trying to abort, this is what should happen as the code is written:

   Eclair                          CLN
     |             stfu             |
     |----------------------------->|
     |             stfu             |
     |<-----------------------------|
     |          splice_init         |
     |----------------------------->|
     |          splice_ack          |
     |<-----------------------------|
     |                              |
     |       <interactive-tx>       |
     |<---------------------------->|
     |                              |
     |         tx_complete          |
     |----------------------------->|
     |         tx_complete          |
     |       X----------------------|
     |         commit_sig           |
     |       X----------------------|
     |                              | Active commitments for Alice:
     |                              | 
     |                              |    commitment_number = 10
     |                              |    +------------+
     |                              |    | FundingTx1 |
     |                              |    +------------+
     |                              | 
     |                              | Active commitments for Bob:
     |                              | 
     |                              |    commitment_number = 10
     |                              |    +------------+        +------------+
     |                              |    | FundingTx1 |------->| FundingTx2 |
     |                              |    +------------+        +------------+
     |                              |
     |      channel_reestablish     | next_funding_txid = null, next_commitment_number = 11, next_revocation_number = 10
     |----------------------------->|
     |      channel_reestablish     | next_funding_txid = FundingTx2, next_commitment_number = 10, next_revocation_number = 10
     |<-----------------------------|
     |         commit_sig           |
     |<-----------------------------| (If I sign first by signing order rules, otherwise nothing is sent)
     |           tx_abort           |
     |----------------------------->| (Here I expect one of three messages: WIRE_COMMITMENT_SIGNED or WIRE_TX_SIGNATURES or WIRE_TX_ABORT. Any other message and I reset the connection with a warning)
     |           tx_abort           |
     |<-----------------------------|
     |                              | Bob can safely forget the splice attempt because he hasn't sent tx_signatures.
     |                              | Active commitments for Alice and Bob:
     |                              | 
     |                              |    commitment_number = 10
     |                              |    +------------+
     |                              |    | FundingTx1 |
     |                              |    +------------+

An important caveat is that we will send commit_sig if the signing order rules require it before receiving Eclair's tx_abort. Shouldn't be a problem but might be helpful for diagnosing.

There are strict rules in place about only allowing tx_abort on the right txid and possibly there's some bug where it's being too strict. If that were the case I would expect the nodes to reconnect over and over trying to abort and failing to.

There's a test that purposely aborts in:

• test_splicing.py
  • test_invalid_splice

seeing a crash

The CLN channel daemon actually restarts as part of the normal process of tx_abort but the connection is maintained (the connection is maintained in a different daemon).

• if I do bob-cln-cli dev-splice "wallet -> 100000sat; 95% -> b33f93d8" then the splice completes, but cln sends an invalid tx_signatures and I'm back to the crash I saw earlier (the signed transaction is indeed rejected by bitcoind with OP_EQUALVERIFY failed: elements are different)

Okay that sounds likely that there's a problem with CLN's signature. What's odd is that it works correctly CLN <-> CLN. The tests that include a splice-in are:

• test_splice.py
  • test_script_splice_in
• test_splicing.py
  • test_splice
  • test_two_chan_splice_in
  • test_splice_rbf
  • test_splice_gossip
  • test_splice_listnodes
  • test_splice_stuck_htlc
  • test_route_by_old_scid
  • test_splice_unannounced

So there's something about interoping with Eclair that's making splice-in not work. What's odd is splice-in was working great in the big interop testing sessions I did with your colleague. So something has changed.

It would be great to see the tx bytes being signed from both sides and if we could somehow figure out which input is being signed incorrectly.

We did switch the onchain wallet over to taproot, so maybe there's some clue there 🤔.