-
Notifications
You must be signed in to change notification settings - Fork 937
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
Workaround for LND to cause a force-close on our channel #8213
base: master
Are you sure you want to change the base?
Conversation
Unfortunately LND does not force close the channels on receiving an error, they blame us for this behaviour (https://github.com/lightningnetwork/lnd/blob/abb1e3463f3a83bbb843d5c399869dbe930ad94f/htlcswitch/link.go#L2119) To fix this we will send them a Bogus Channel Reestablish with 0 commitment_number and invalid last_per_commit_secret. Key Changes: - In connect_activate_subd, if we detect a stub channel, we serialize and send a bogus channel_reestablish message. Changelog-Fixed: Fixing LND's non responsive behaviour on receiving an error.
Make sure we are sending bogus channel reestablish after recovering from emergency.recover file and peer storage backup. Key Changes: - Add wait_for_log() with appropriate debug statements
What will be the right behaviour in this case? wondering if we may report this to LND while keeping the workaround |
The correct behaviour should be LND responding with a unilateral close after receiving the error. This is a known behaviour, and LDK handles it in a similar manner. |
Are we reporting to LND this wrong behaviour? |
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.
That was an interesting read. Old LND gossip bug leads to old CLN version to be too aggressive in sending an error, so LND treats all errors as soft rather than force-closing the channel, which requires current CLN to botch the channel reestablish to explicitly initiate a force-close. I guess it makes sense, but some of these old bugs were resolved 5 years ago and yet are still reverberating between implementations. It's probably time to revisit this in spec discussion.
In the mean time this is a pragmatic solution.
ACK 92fc59b
@vincenzopalazzo It's a known issue across implementations — I assume someone must've reported it already. I'll check and file an issue if I don't find one in their repository. |
LND does not force close on us when we recover our node using emergency.recover or peer storage backups (https://github.com/lightningnetwork/lnd/blob/abb1e3463f3a83bbb843d5c399869dbe930ad94f/htlcswitch/link.go#L2119).
We will send a channel reestablish with bogus data to make them force close on us.