You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
derive from seed by BIP
set derived key in step1 to little endian, make it as the BLS private key
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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:
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.
The text was updated successfully, but these errors were encountered: