Skip to content

Do not default to storing InMemoryChannelKeys keys on disk #1209

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

Closed
TheBlueMatt opened this issue Dec 7, 2021 · 4 comments · Fixed by #1867
Closed

Do not default to storing InMemoryChannelKeys keys on disk #1209

TheBlueMatt opened this issue Dec 7, 2021 · 4 comments · Fixed by #1867
Milestone

Comments

@TheBlueMatt
Copy link
Collaborator

We can re-derive these on startup, so we should. Using KeysInterface's read method makes this easy, but we probably want to move the write method into KeysInterface as well (if practical) to make things symmetric.

@devrandom
Copy link
Member

This is complicated by the fact that the channel_parameters field is late bound.

@TheBlueMatt
Copy link
Collaborator Author

Yea, I played with it a little bit and found that. It's further complicated by the fact that InMemoryChannelKeys' serialization is a public API and ideally we wouldn't break it by splitting the serialization logic half into KeysInterface's read method (otherwise you just break up the read code into parts). Not quite sure what the forward direction here is, but maybe it's just swapping around the deserialization stuff to do what we want and working on serialization later.

@TheBlueMatt
Copy link
Collaborator Author

Note that this is still an issue for now, but #1867 did the first step of ensuring we can read variants that don't store the keys. Now we just have to wait a few releases and then stop writing backwards-compatibility data.

@TheBlueMatt TheBlueMatt reopened this Dec 6, 2022
@TheBlueMatt TheBlueMatt added this to the 0.2 milestone Dec 6, 2022
@tnull
Copy link
Contributor

tnull commented Sep 23, 2024

Note that this is still an issue for now, but #1867 did the first step of ensuring we can read variants that don't store the keys. Now we just have to wait a few releases and then stop writing backwards-compatibility data.

This was done in 7a951b1.

Closing as completed.

@tnull tnull closed this as completed Sep 23, 2024
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 a pull request may close this issue.

3 participants