[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

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)
• I haven't tested edge cases around announcement_signatures because of the 1-conf splice_locked behavior, but the "normal" case works correctly

@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?)?