Skip to content

Compute channel keys only once on startup#3296

Open
sstone wants to merge 2 commits intomasterfrom
compute-channelkeys-once
Open

Compute channel keys only once on startup#3296
sstone wants to merge 2 commits intomasterfrom
compute-channelkeys-once

Conversation

@sstone
Copy link
Copy Markdown
Member

@sstone sstone commented Apr 30, 2026

We currently compute channel keys when we load channels from our database and discard them, so we'll compute them a second time (and potentially a 3rd time for some of them when we "clean" HTLCs).
Here we keep the keys generated when channels were loaded and pass them along as needed.

This can reduce startup time on nodes with many channels (on a local test on a dev machine with a node with 10 000 channels startup time went from 19s down to 12s).

We compute channel keys when we load and verify channels from our database, and pass them along instead of re-computing them later (which is expensive).
@sstone sstone requested review from pm47 and t-bast April 30, 2026 14:36
@t-bast
Copy link
Copy Markdown
Member

t-bast commented Apr 30, 2026

Is this really worth the additional complexity? This is 100% CPU-bound, so it's not a very expensive code-path on restart (the restart issues are rather IO-bound or memory-related, we never have a CPU bottleneck, even on restart).

Maybe I'm turned off by the InitWithoutKeys new messages, do we really need them if they're just for tests? If we can make this PR more trivial, then I think it's definitely worth integrating, but in its current state it creates some messiness so I'm not convinced :/

@sstone
Copy link
Copy Markdown
Member Author

sstone commented Apr 30, 2026

Is this really worth the additional complexity? This is 100% CPU-bound, so it's not a very expensive code-path on restart (the restart issues are rather IO-bound or memory-related, we never have a CPU bottleneck, even on restart).

There's also a consistency issue: we create channel keys and use them to validate the channel seed, and discard them immediately
=> we could have a bug and create different, invalid keys later (even though it's unlikely), it is safer to keep the ones we know are valid.

Maybe I'm turned off by the InitWithoutKeys new messages, do we really need them if they're just for tests? If we can make this PR more trivial, then I think it's definitely worth integrating, but in its current state it creates some messiness so I'm not convinced :/

Yes it's not very nice so far attempts to avoid such a message created even more complexity, I'll try and find something better.

@sstone
Copy link
Copy Markdown
Member Author

sstone commented May 4, 2026

I went for a simpler approach in 7b17a4f where channel keys are stored as a transient, optional property of PersistentChannelData and initialized on startup when we load channels.

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.

2 participants