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

Questions about ETH2 BLS key derivation #2968

Closed
kristieguo opened this issue Sep 11, 2020 · 3 comments
Closed

Questions about ETH2 BLS key derivation #2968

kristieguo opened this issue Sep 11, 2020 · 3 comments

Comments

@kristieguo
Copy link

Hello,

I'm doing some research and preparing to support ETH2 staking in our custody product. However, I read the EIP proposals and have questions about BLS key derivation implementation.

The EIP2333 proposal states:

"Based on the order of the private key subgroup of BLS12-381 and the size of the entropy utilised, more than 54% of keys generated by BIP32 would be invalid."

I did some tests and the result matches the statement. However, currently our custody system is using BIP44 to derive keys and we want to keep it that way. By reading the entire proposal, we understand that a new key derivation method involving intermediate Lamport algorithm is recommended but we could not find a Javascript SDK for the entire derivation process. We don't want to take the risk of writing the derivation by ourselves and leads to possible token assets loss. So I was wondering what exact reason is leading to the percentage of 54% invalid key generation and how we could solve this problem without abandoning BIP. By referring to the BLS Javascript SDK as in https://github.com/herumi/bls-eth-wasm, I came up with the solution as below and demo code in attachment:

  1. derive from seed by BIP
  2. set derived key in step1 to little endian, make it as the BLS private key
  3. get BLS public key by the private key

Although I see at least one problem in this solution. Keys generated in step 2 may be the same after being set to little endian even if the original keys generated in step 1 are different. Despite this problem, Could this solution 100% solve the BIP key generation problem mentioned in the EIP proposal? Or does anyone have better solutions for us to continue to use BIP44 for key generation without implementing another derivation algorithm?

I really appreciate it if anyone could help us. Thank you.

@github-actions
Copy link

Since this is your first issue, we kindly remind you to check out EIP-1 for guidance.

@axic
Copy link
Member

axic commented Sep 11, 2020

I suggest to leave this comment on #2337 which is the discussion URL for EIP-2333. The authors of it are likely not monitoring every issue made to the EIP repository.

@kristieguo
Copy link
Author

I suggest to leave this comment on #2337 which is the discussion URL for EIP-2333. The authors of it are likely not monitoring every issue made to the EIP repository.

OK. Thank you.

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

2 participants