becgabri
commented
2 months ago We expect to have SLP10 compatibility. While we will not use seed phrases - and thus also cannot generate keys for multiple curves from a single seed phrase - we will ensure that all keys are generated from a master key in compliance with SLP10. This means if generation of a particular child node fails for a specific counter, we will re-try until there is a success.
The following changes should be made to the threshold signing protocol to accommodate HD wallets:
- Modify the key generation protocol to also output a chain code in addition to the ECDSA key shares. This means key generation will produce a master secret key and master public key. This chain code can be generated by having parties generate sharings of a random value by committing to a random 256 bit value at the end of the first round and then combining all those shares in the third round after all parties see the decommitments.
- Change the sign protocol so that it can take as input a shift parameter, which will end up being equal to the $\ell$ value in SLIP10 (where $\ell$ is the SHA512 hash of the parent key, chain code, and a counter). Given party $i$ holds $k_i , \chi_i, r$, the message $m$, and $\ell$, output $k_i \cdot m + r(\chi_i + k_i \cdot \ell)$. Note that because the child key only needs to be taken account at the end, this means presign records for a master key are valid for any child key.
emmorais
Hierarchical Deterministic (HD) wallets provide a structured and secure way to generate a tree of cryptographic keys from a single seed. Extending this technique to threshold-ecdsa enhances both security and flexibility of the keys generated by the library for many use cases. In addition, BIP32 or SLIP10 compatibility ensures that the library adheres to established standards, facilitating interoperability and broad usability.