splicing: Adds the features needed to enable collaborative splicing & resizing of active channels.

[ddustin]

Note: Github force-closed my previous PR #5675, so I had to open a new one here.

This PR is meant to add splicing to CoreLightning. Splicing enables the resizing of multiple channels in a single on-chain transaction, without any channels being "down" or closed during any part of the process. While enabling the resizing of multiple of your own channels -- splicing also gives your peers (and their peers, and their peers' peers, etc.) an opportunity to dynamically add channels as well.

Not only can participants add their own resizes, due to compatibility with @niftynei's dual funding feature, they can also add channel opens into the same batch. Eventually dual closing will allow all onchain lightning events to be batched into a single bitcoin transaction.

This will also, in time, enable wallets to implement "one balance" apps that allow users to send lightning & on-chain payments without needing to manage two "bitcoin balances" -- with the lowest fees possible.

The code implements splicing spec located here: lightning/bolts#863

My endless gratitude to @niftynei 🙏 who has helped an insane amount with planning, disagnosing, and literally writing parts of the code -- not sure I could have gotten this far without her. Thanks as well to @cdecker, @rustyrussell and everyone who helped me while working on this.

Here are the things I believe need to be done before the PR can be considered ready for a developer-only release

• Refactor splice_init RPC to take a user's initial PSBT
• Do byte ownership fee calculations
• Enable signature ordering logic
• Add splice commit sigs to inflight
• Redo inflight process to cache a copy in channeld
• Add BOLT messages with corresponding commit hashes
• Change splice RPC to use channel_id instead of peer_id
• Finish Collaborative transaction building #5287
• Refactor this code to use Collaborative transaction building #5287
• Refactor RPC to remove splice_finalized
• Move wire updates to experimental patches
• Add #if EXPERIMENTAL && DEVELOPER flags around code
• Diagnose why the committed_splice_count check fails in handle_peer_commitsig
• Update channel balance on splice_locked & save to DB
• Load correct channel balance post splice_lock after restart
• Test splicing a post-spliced channel
• Check for TODO items in code
• Correct balance checks for the l2 code path lisa gist. See check_balances
• Reconnect logic

[rustyrussell]

OK, I haven't reviewed all the fixups, but I got through the actual main commits!

[litch]

I'm testing this in a mixed-nodes environment and it looks like a post-spliced channel is un-detectable by LND. I'm not 100% sure why at this point, and have some logs I can provide on request.

Workflow:

• Lnd1 is connected to cln1
• Open a channel between cln1 and cln2
• Verify that Lnd1 can see the channel between cln1 and cln2 in its describegraph
• Splice the channel
• the channel between cln1 and cln2 is now not listed in the describegraph
• Open a new channel between cln1 and cln2
• Verify that the new channel between cln1 and cln2 appears in the describegraph, whereas the spliced one does not

Happy to help debug!

EDIT TO ADD:

It looks the newly-created channel eventually does get broadcast. The ChannelAnnounce message wound up getting broadcast an hour after the splice happened. Even with dev-fast-gossip enabled and I restarted the CLN node within that hour window (at about 40 minutes). Unsure if that is related.

In any case: tACK (at least in my cluster of regtest nodes)

[rustyrussell]

You can't advertize a channel less than 6 blocks old, so the "new" channel won't appear for this long. However, implementations are supposed not to discard "closed" channels for 12 blocks, so they old channel id can still be used in the interim...

[rustyrussell]

Rebased against trivial conflict....

[rustyrussell]

... and again for CI breakage fix.