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

Workaround for LND to cause a force-close on our channel #8213

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

adi2011
Copy link
Collaborator

@adi2011 adi2011 commented Apr 5, 2025

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.

adi2011 added 2 commits April 5, 2025 14:48
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
@vincenzopalazzo
Copy link
Collaborator

What will be the right behaviour in this case? wondering if we may report this to LND while keeping the workaround

@adi2011
Copy link
Collaborator Author

adi2011 commented Apr 7, 2025

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.

@vincenzopalazzo
Copy link
Collaborator

vincenzopalazzo commented Apr 7, 2025

The correct behaviour should be LND responding with a unilateral close after receiving the error.

Are we reporting to LND this wrong behaviour?

Copy link
Collaborator

@endothermicdev endothermicdev left a 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

@adi2011
Copy link
Collaborator Author

adi2011 commented Apr 9, 2025

@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.

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

Successfully merging this pull request may close these issues.

3 participants