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

fix: generate_spaced_private_keys doesn't generate even keyspace #1664

Closed
wants to merge 1 commit into from

Conversation

KolbyML
Copy link
Member

@KolbyML KolbyML commented Feb 3, 2025

What was wrong?

If you set the count to 128, only half the key range is covered. Milos found the issue

image

How was it fixed?

Use this first 16 bits instead of first 8 bits, this makes the script slower, but it is more then fast enough. I was able to generate 128 private keys in 10 minutes, we don't generate spaced keys often so I think this accuracy increase is a good trade off

@KolbyML KolbyML force-pushed the fix-generate-spaced-enr branch from 40daa0f to 4891d5b Compare February 3, 2025 21:52
@morph-dev
Copy link
Collaborator

I'm not sure I like this approach. It probably works the best when number of nodes is not power of two, but I think it has wrong properties when it is.

For example, let's say that we want to generate 4 NodeIds. To me, that means that NodeIds should have unique highest 2 bits, and all remaining bits are fully random.

In this case, we will get unique 2 bits (and even this is not 100% guaranteed with current implementation), and next 6 bits will be close to each other. On the first thought, one might think that having other 6 bits the same (or close to each other) is desired property (they seem equally distributed), but I believe that's not desired because we are dealing with XOR distance (I can go into details on this if needed).

@KolbyML
Copy link
Member Author

KolbyML commented Feb 3, 2025

I'm not sure I like this approach. It probably works the best when number of nodes is not power of two, but I think it has wrong properties when it is.

For example, let's say that we want to generate 4 NodeIds. To me, that means that NodeIds should have unique highest 2 bits, and all remaining bits are fully random.

In this case, we will get unique 2 bits (and even this is not 100% guaranteed with current implementation), and next 6 bits will be close to each other. On the first thought, one might think that having other 6 bits the same (or close to each other) is desired property (they seem equally distributed), but I believe that's not desired because we are dealing with XOR distance (I can go into details on this if needed).

I am not too committed to this so I am going to close the PR. Next time I need to generate node_id's I just want the code to work well enough, if you want to make a PR to fix this it would be much appreciated

@KolbyML KolbyML closed this Feb 3, 2025
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