-
Notifications
You must be signed in to change notification settings - Fork 890
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
fix: channel closer on unilateral to remote #4198
fix: channel closer on unilateral to remote #4198
Conversation
Sounds reasonable. What do you mean by "scratching/recovery script"? Example? |
Nothing that I specifically know of, but its something that I can imagine users will come up to check for unclaimed funds in an old backup or something. |
4ab988d
to
915323c
Compare
Hopefully the test is now stable ... |
Reasonable. If someone's going to all the work to close a channel out-of-band, that definitely counts as remote. For what it's worth, we know definitively who did it in onchaind. |
Incase we have been offline while a channel was force closed on us we now set the 'closer' to 'remote' instead of null because this is by far the most probable reason. Changelog-None
915323c
to
47415ca
Compare
ACK 47415ca |
Currently we set the
lightning-cli listpeers
channelcloser
tonull
if we have been offline and detected a force closed channel on us. This was because in theory it could have been ourself that used some scratching/recovery script for our private keys. Since this is topmost unlikely scenario, especially since someone doing this would certainly not fire up the daemon again and expect it to do something useful, we are better of to set thecloser
toremote
as it should be.