Skip to content
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

Closing negotiations too restrictive #435

Closed
jb55 opened this issue Dec 12, 2017 · 7 comments
Closed

Closing negotiations too restrictive #435

jb55 opened this issue Dec 12, 2017 · 7 comments

Comments

@jb55
Copy link
Collaborator

jb55 commented Dec 12, 2017

I have been attempting to open and successfully close a testnet transaction between two of my computers. So far I got to the point where both computers successfully open a channel and are in the CHANNELD_NORMAL state. As a test, I tried a mutual close of the channels with lightning-cli close peer-b-id from peer-a. This put both peers in the CLOSINGD_SIGEXCHANGE state. I've done this twice and I've never been able to get it out of this state.

After restarting both nodes, I tried to reconnect to peer-b from peer-a (02058ea66978d2e5c346642c45f3cec5a4c733897b59244fc29c3107e844f62608), I get this on peer-b:


lightningd(29128): peer 02058ea66978d2e5c346642c45f3cec5a4c733897b59244fc29c3107e844f62608: Peer has reconnected, state CLOSINGD_SIGEXCHANGE
lightning_gossipd(29137): TRACE: Forgetting remote peer 02058ea66978d2e5c346642c45f3cec5a4c733897b59244fc29c3107e844f62608
lightning_gossipd(29137): TRACE: req: type WIRE_GOSSIPCTL_HANDLE_PEER len 279
lightning_gossipd(29137): TRACE: handle_peer 02058ea66978d2e5c346642c45f3cec5a4c733897b59244fc29c3107e844f62608: new peer
lightning_gossipd(29137): TRACE: 02058ea66978d2e5c346642c45f3cec5a4c733897b59244fc29c3107e844f62608: we sent them a fatal error, closing

Error is : Final fee 362 vs 329 at limits 363-535

and then peer-a just hangs. also, "we sent them a fatal error" doesn't seem to be true, since a fatal error is not reported to peer-a. possibly related: #405

@jb55
Copy link
Collaborator Author

jb55 commented Dec 12, 2017

I'm on #413 + #414 but I've also replicated this on 0610f66 (current master)

@jb55
Copy link
Collaborator Author

jb55 commented Dec 12, 2017

A new development! I now get

channel ALL: bad reestablish msg: WIRE_ERROR 00110000000000000000000000000000000000000000000000000000000000000000002646696e616c206665652033363220767320333239206174206c696d697473203336332d353335

on attempted reconnect from peer-a to peer-b

@jb55
Copy link
Collaborator Author

jb55 commented Dec 12, 2017

after restarting again, I get a new error when attempting a reconnect:

channel ALL: Expected closing_signed: 0011b779498925872861a0f91a390acbd1dcf294b2353f5aeb29b2e002e7c8282c57002746696e616c206665652033363220767320333239206174206c696d697473203336332d35333500

@jb55
Copy link
Collaborator Author

jb55 commented Dec 13, 2017

Ok so peer-a is failing in fromwire_channel_reestablish, it's getting back WIRE_ERROR instead of WIRE_CHANNEL_REESTABLISH @ fromwire_u16(&cursor, plen) != WIRE_CHANNEL_REESTABLISH

This isn't helpful, I'll do some debugging on peer-b

jb55 added a commit to jb55/lightning that referenced this issue Dec 13, 2017
This handles the case where peer->error is sometimes an empty string

Fixes ElementsProject#435
jb55 added a commit to jb55/lightning that referenced this issue Dec 13, 2017
This handles the case where peer->error is sometimes an empty string

Fixes ElementsProject#435
jb55 added a commit to jb55/lightning that referenced this issue Dec 13, 2017
This handles the case where peer->error is sometimes an empty string

Fixes ElementsProject#435
@rustyrussell
Copy link
Contributor

OK, so, the error in these cases is "Final fee 362 vs 329 at limits 363-535".

@Roasbeef previously reported that we're far too restrictive in our closing negotiations. But even if we are, we should be dropping to chain in this case, and closing that way. Plus a nicer error report when this happens...

@jb55 jb55 changed the title Stuck on CLOSINGD_SIGEXCHANGE Closing negotiations too restrictive Jan 4, 2018
@ZmnSCPxj
Copy link
Collaborator

ZmnSCPxj commented Feb 3, 2018

#847 should have fixed this issue I think? Or are there more things attached to this issue?

@jb55
Copy link
Collaborator Author

jb55 commented Feb 3, 2018

I'll close this for now until it pops up again

@jb55 jb55 closed this as completed Feb 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants