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

Channel not auto closing (other node SCB'ed) #5818

Closed
svewa opened this issue Dec 13, 2022 · 4 comments
Closed

Channel not auto closing (other node SCB'ed) #5818

svewa opened this issue Dec 13, 2022 · 4 comments

Comments

@svewa
Copy link

svewa commented Dec 13, 2022

running v22.11rc3, ~230 channels

So this other node broke, and the owner used the SCB to recover his funds. My node noticed this, but didn't close the channel. Closing it manually seems to have worked now.

Partial listnodes output:

"state_changes": [
                  {
                     "timestamp": "2022-02-18T12:37:04.689Z",
                     "old_state": "CHANNELD_AWAITING_LOCKIN",
                     "new_state": "CHANNELD_NORMAL",
                     "cause": "user",
                     "message": "Lockin complete"
                  }
               ],
               "status": [
                  "CHANNELD_NORMAL:bad reestablish revocation_number: 0 vs 41393",
                  "CHANNELD_NORMAL:Sent reestablish, waiting for theirs"
               ],
@devastgh
Copy link

Same issue here with v22.11.

@btweenthebars
Copy link

see here: #5876

@whitslack
Copy link
Collaborator

This is the correct behavior. Your node should not force-close merely because of receiving an outdated channel_reestablish. It is the responsibility of the other node (the one that restored the SCB) to send an error message if it wants your node to force-close.

@rustyrussell
Copy link
Contributor

rustyrussell commented Mar 23, 2023

Um, sure. Meanwhile, he should be able to force it!

Try lightning-cli close <channelid> 1 to give them one second before closing. The default is 48 hours!

rustyrussell added a commit to rustyrussell/lightning that referenced this issue Oct 16, 2023
…ning.

This gives the peer a chance to send an error, which will make us drop
to chain.

Signed-off-by: Rusty Russell <[email protected]>
Fixes: ElementsProject#5818
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Oct 17, 2023
…ning.

This gives the peer a chance to send an error, which will make us drop
to chain.

Signed-off-by: Rusty Russell <[email protected]>
Fixes: ElementsProject#5818
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Oct 19, 2023
…ning.

This gives the peer a chance to send an error, which will make us drop
to chain.

Signed-off-by: Rusty Russell <[email protected]>
Fixes: ElementsProject#5818
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Oct 19, 2023
…ning.

This gives the peer a chance to send an error, which will make us drop
to chain.

Signed-off-by: Rusty Russell <[email protected]>
Fixes: ElementsProject#5818
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Oct 19, 2023
…ning.

This gives the peer a chance to send an error, which will make us drop
to chain.

Signed-off-by: Rusty Russell <[email protected]>
Fixes: ElementsProject#5818
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Oct 20, 2023
…ning.

This gives the peer a chance to send an error, which will make us drop
to chain.

Signed-off-by: Rusty Russell <[email protected]>
Fixes: ElementsProject#5818
rustyrussell added a commit to rustyrussell/lightning that referenced this issue Oct 22, 2023
…ning.

This gives the peer a chance to send an error, which will make us drop
to chain.

Signed-off-by: Rusty Russell <[email protected]>
Fixes: ElementsProject#5818
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

5 participants