-
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
Invalid signature on reconnection eclair/c-lightning #2661
Comments
We had new occurences of this. Happened 0 time in august and 2 times in september so far. Probably not high priority but would still be nice to get fixed. Last reported one:
|
I experienced another occurrence of this failure mode. My inexperienced reading of the log:
What I observe immediately is that the log records nothing that would reveal whether the peer received my Shouldn't sending an |
@darosior: This is still an issue even after the fix in #3215. I am running the 0.7.3 release, and I just got bitten again by the "Bad commit_sig signature" error.
|
@whitslack |
I think this is a synchro problem, from your log:
It looks like we send an |
@darosior: No. I only know what is shown on 1ML, which isn't much for that node.
That's how I read it as well. Repeating my question:
(Stating the obvious) It's not correct to assume that all messages received after having enqueued an |
(Stating the Now, we should not get upset in that specific case : we are the funder, we update the fees, we commit, we receive a commitment with old fees just after having committed. Will work on a repro test .. (edit: it's quite hard to reproduce..) |
Our feerate logic is overly simplistic (ha!) and we seem to get confused on back-to-back feerate updates. Fixing it seems to require much more complex feerate logic which I am deeply reluctant to implement, as it's terribly fragile and will be discarded eventually once we have simplified commitments. Fixes: ElementsProject#2661 Signed-off-by: Rusty Russell <[email protected]> Changelog-Fixed: Occasional 'Bad commit_sig signature' channel failures with fee updates (ElementsProject#2661)
OK, I have written a protocol test which reproduces this; it doesn't even need the reconnection to trigger. For the moment, I've implemented a workaround which simply means we never send consecutive update_fee until the previous one is settled. I don't think that catches all the possible cases, though, so will continue working on it (but now it shouldn't hold up release!). |
Awesome! One less cause of force-closing of channels 🎉 |
Our feerate logic is overly simplistic (ha!) and we seem to get confused on back-to-back feerate updates. Fixing it seems to require much more complex feerate logic which I am deeply reluctant to implement, as it's terribly fragile and will be discarded eventually once we have simplified commitments. Fixes: ElementsProject#2661 Signed-off-by: Rusty Russell <[email protected]> Changelog-Fixed: Occasional 'Bad commit_sig signature' channel failures with fee updates (ElementsProject#2661)
Issue and Steps to Reproduce
Following an unrelated memory issue with eclair causing it to grind to a halt, I had to forcekill the node, and on restart I saw a few
Bad commit_sig
from several c-lightning nodes. After investigating I think this may have revealed a corner case problem on c-lightning's side related toupdate_fee
.Here is what happened (taken from the logs below):
I think eclair is right to have been using feerate=fee2 after reconnection.
The text was updated successfully, but these errors were encountered: