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

Handle closed channels better. #8162

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

Conversation

rustyrussell
Copy link
Contributor

This does several nice things:

  1. Cleans up our closed channel handling.
  2. Loosens the timeout of 2016 blocks on unopened channels: we allow 100 channels to go over that before we start timing them out (requested by @michael1011 )

@rustyrussell rustyrussell added this to the v25.05 milestone Mar 14, 2025
@rustyrussell rustyrussell force-pushed the guilt/closed-channels-handle-better branch from a5a3170 to 0c17cbe Compare April 1, 2025 03:28
We are supposed to allocate of the ctx we're passed, not tmpctx.

Doesn't matter for now, because we don't use this result with anything which outlives tmpctx,
but we're going to:

```
==47574==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040005a8f38 at pc 0x55d3c584d252 bp 0x7ffddfb1b090 sp 0x7ffddfb1b088
READ of size 8 at 0x6040005a8f38 thread T0
    #0 0x55d3c584d251 in json_add_closed_channel /home/runner/work/lightning/lightning/lightningd/closed_channel.c:27:3
    #1 0x55d3c584ca5a in json_listclosedchannels /home/runner/work/lightning/lightning/lightningd/closed_channel.c:118:3
    #2 0x55d3c58c0cbe in command_exec /home/runner/work/lightning/lightning/lightningd/jsonrpc.c:808:8
```

Signed-off-by: Rusty Russell <[email protected]>
@rustyrussell rustyrussell force-pushed the guilt/closed-channels-handle-better branch from 0c17cbe to d54cd31 Compare April 2, 2025 03:52
We're going to start loading them into memory for nicer responses if
people try to reestablish closed channels, but we don't care about ones
which were never actually opened.  We could add a new state, but easier
to simply remove them.

Signed-off-by: Rusty Russell <[email protected]>
Use convenience variables.

Signed-off-by: Rusty Russell <[email protected]>
Michael of Boltz told me this long ago, that when fees spiked some of their clients'
opens got stuck.  After two weeks their node forgot them, and when fees came back down
the opens still failed.  Unfortunately, I can't see an issue for this!

We can give some grace: we don't want to waste too many resources, but 100 channels
is nothing.

The test needs to be adjusted to have *two* slow open channels, now.

Changelog-Changed: Protocol: we won't forget still-opening channels after 2016 blocks, unless there are more than 100.
Signed-off-by: Rusty Russell <[email protected]>
They're small, and this will allow us to efficiently respond to reestablish on them.

Signed-off-by: Rusty Russell <[email protected]>
This was always false.  peer_start_channeld was called in various places
with the argument "NULL" instead of "false", which unfortunately compilers
didn't complain about :(

Signed-off-by: Rusty Russell <[email protected]>
We'll need this to send reestablish, and it is only small (max 47 sha256 per channel).

Signed-off-by: Rusty Russell <[email protected]>
…closed channels.

This may be useful for their recovery, though they should see the spend onchain.

Signed-off-by: Rusty Russell <[email protected]>
Changelog-Added: Protocol: We now reply to `channel_reestablish` even on long-closed channels.
@rustyrussell rustyrussell force-pushed the guilt/closed-channels-handle-better branch from d54cd31 to 3afc03c Compare April 2, 2025 23:46
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.

1 participant