Versioned EIP2333 Key Generation
Rigidity opened this issue · comments
The blst_derive_child_eip2333 function uses a fixed version of keygen. If you need the ability to derive child keys using blst_keygen_v3 for example, you have to manually invoke the parent_SK_to_lamport_PK function.
The issue is that bindings to parent_SK_to_lamport_PK are not present, so doing this from Rust is impossible without reimplementing the code (which would not be performant). This could be fixed by either exporting bindings for parent_SK_to_lamport_PK (simpler) and/or by making a blst_derive_child_eip2333 function for each version, similar to blst_keygen.
The
blst_derive_child_eip2333function uses a fixed version ofkeygen.
And that's how EIP-2333 defines it. I mean if it didn't use the specific version, then it couldn't be called derive_child_eip2333. And there are no versions in the spec. So why the question? I mean the goal of the project is not exactly to meet random requests, there should be justification...
Not everyone is using the most up to date version of the standard. Chia for example, uses v3 keygen, and deriving compatible hardened keys is impossible with v5. blst_derive_child_eip2333 is only a two line function, so it seems rather simple to just export parent_SK_to_lamport_PK so it can be implemented manually in Rust using the desired version.
Not everyone is using the most up to date version of the standard. Chia for example, uses v3 keygen, and deriving compatible hardened keys is impossible with v5.
blst_derive_child_eip2333is only a two line function, so it seems rather simple to just exportparent_SK_to_lamport_PKso it can be implemented manually in Rust using the desired version.
The issue is not being simple to add, it's about support and maintenance for the years to come and also documentation to explain the differences and if changes or deprecation is needed, making sure that stakeholders are informed.
Does Chia have a spec? It would, let's say it's called CIP (Chia Improvement proposal), the resulting proc can be called blst_derive_child_cip1234 leaving no doubt to who it is for.
As @mratsim implied, a reference to a spec is the best way to go about.
As for exposing parent_SK_to_lamport_PK. Formally speaking it's not necessarily off the table, but there should be an indication that it's a sensible thing to do. For example availability of multiple conflicting specs/drafts and versions...