-
Notifications
You must be signed in to change notification settings - Fork 912
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
splicing: Adds the features needed to enable collaborative splicing & resizing of active channels. #6253
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I haven't reviewed all the fixups, but I got through the actual main commits!
ad722c3
to
0de8092
Compare
6e40fec
to
7101be9
Compare
e46cd6a
to
a4ab946
Compare
112fc41
to
f63bc51
Compare
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:
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) |
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... |
da669d3
to
4119195
Compare
Rebased against trivial conflict.... |
Using the -n flag on echo is non-standard for zsh. printf ‘%s’ accomplishes the equivilent thing. Changelog-Added: Small fix for Mac OS building # Conflicts: # plugins/Makefile
Changelog-None
Changelog-None
Changelog-None
Update gossip routiens and various other hecks on the channel state to consider AWAITING_SPLICE to be routable and treated similar to CHANNELD_NORMAL. Small updates to psbt interface Changelog-None
Some fields weren’t intitialized causing complex crashes elsewhere. Changelog-None
Changelog-None
New daemon process means we don’t have to deal with gossip, so that gets removed along with error cleanup and a refactoring of how we calculating PDBT diffs.
Update the lightningd <-> channeld interface with lots of new commands to needed to facilitate spicing. Implement the channeld splicing protocol leveraging the interactivetx protocol. Implement lightningd’s channel_control to support channeld in its splicing efforts. Changelog-Added: Added the features to enable splicing & resizing of active channels.
Also convert everything to an array thingy
integer was missing from the list of type conversions causing CI to fall over ChangeLog-None
It's being killed with signal 143, which means docker isn't happy; too much memory consumption? Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
4119195
to
c8bf63a
Compare
... and again for CI breakage fix. |
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
channeld
splice_finalized
committed_splice_count
check fails inhandle_peer_commitsig
check_balances