-
Notifications
You must be signed in to change notification settings - Fork 974
Splice Interop #8817
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
base: master
Are you sure you want to change the base?
Splice Interop #8817
Conversation
12654e5 to
5275215
Compare
Update log message to match the behavior of the check its logging about. Changelog-None
In some situations Eclair sends CHANNEL_READY before resuming the splice in reestablish. This update allows one of these messages to be processed if it comes in during the splice resume process. Changelog-None
Splice commands can fail because of external reasons, for example our peer rejecting the splice. These external reasons eat the active `splice_command` so we need to stop storing the `splice_command` in callbacks and instead pull it from the `splice_commands` list which automatically removes the object when its consumed. This corrects a lightningd crash under certain RPC circumstances. Changelog-None
A new TLV in `channel_reestablish` lets our peer request announcement signatures. This updates CLN to (re)send them when requested. As per splice spec PR https://github.com/lightning/bolts/pull/1160/changes#diff-ed04ca2c673fd6aabde69389511fa9ee60cb44d6b2ef6c88b549ffaa753d6afeR3303-R3308 Changelog-None
5275215 to
8e56bc7
Compare
I believe you've introduced a new bug in your fix. I've tested the following flow:
Here is the log of the force-close: If you want to reproduce, you can use this custom eclair branch that ignores splice
This one doesn't seem to be fixed. I still get the following error on reconnection: Steps to reproduce:
|
A collection of fixes for interop with Eclair.
channel_readymessages to occur during splice reestablish flow.reestablishTLVs.