ZIP 32 APIs #29
ZIP 32 APIs #29
Conversation
63 chunks per pedersen hash segment
| source = "registry+https://github.com/rust-lang/crates.io-index" | ||
| dependencies = [ | ||
| "aes-soft 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", | ||
| "aesni 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", |
There was a problem hiding this comment.
I haven't reviewed these; I'm just assuming they correctly implement AES.
| @@ -270,6 +270,35 @@ extern "C" { | |||
| uint64_t vpub_old, | |||
| uint64_t vpub_new | |||
| ); | |||
|
|
|||
| /// Derive the master ExtendedSpendingKey from a seed. | |||
| void librustzcash_zip32_xsk_master( | |||
There was a problem hiding this comment.
Huh? I thought we decided on xsk and xfvk for the ZIP 32 constructs (as used in ZIP 32 itself), and expsk / fvk for the corresponding Sapling key structs?
src/rustzcash.rs
Outdated
| pub extern "system" fn librustzcash_zip32_xsk_master( | ||
| seed: *const c_uchar, | ||
| seedlen: size_t, | ||
| xsk_m: *mut [c_uchar; 169], |
src/rustzcash.rs
Outdated
|
|
||
| #[no_mangle] | ||
| pub extern "system" fn librustzcash_zip32_xsk_derive( | ||
| xsk_p: *const [c_uchar; 169], |
src/rustzcash.rs
Outdated
|
|
||
| let xfvk = match xfvk_p.derive_child(i) { | ||
| Ok(xfvk) => xfvk, | ||
| Err(_) => return false, |
There was a problem hiding this comment.
This doesn't (say) zero the output array in case of error. libsodium does that and I think it's a good idea. Does not block.
There was a problem hiding this comment.
If we want to do that, we should do so consistently in all of the FFI APIs. Opened #34.
|
Rebased on master to fix merge conflicts, and address @daira's comments. |
| .expect("valid ExtendedFullViewingKey"); | ||
| let i = zip32::ChildIndex::from_index(i); | ||
|
|
||
| let xfvk = match xfvk_parent.derive_child(i) { |
There was a problem hiding this comment.
Add somewhere descriptive error message for hardened child index?
The one in derive_child just returns an error without a message.
There was a problem hiding this comment.
That should happen in the librustzcash repo now, where we should have a better overall error story instead of arbitrary strings. As for here, we don't get to easily send error states across the FFI :(
There was a problem hiding this comment.
Where should that happen exactly? Isn't this librustzcash?
There was a problem hiding this comment.
Sorry, I meant in the refactor work happening in the master branch. This PR is merging into a 2.0.1-specific branch, which will later be merged into master.
| unsigned char *xfvk_i | ||
| ); | ||
|
|
||
| /// Derive a PaymentAddress from an ExtendedFullViewingKey. |
There was a problem hiding this comment.
I'm wondering how this will be designed to work without repeating addresses. E.g. if j_ret=j+1 we should store j_ret somewhere to know we should start from j+2 for the next address.
There was a problem hiding this comment.
Correct; you are given back the "index" of the address being returned, and should store it so that you know to try index + 1 the next time you want an address.
There was a problem hiding this comment.
Wondering if the following interface is better: You give as input the index j of a valid diversifier - the method return an error if j is not a valid index; and if it is, returns the next valid diversifier
There was a problem hiding this comment.
It might be; we can explore that in a follow-up PR when we have more users of the API.
Use ZIP 32 for all Sapling spending keys The wallet now only stores Sapling extended spending keys, and thus can only be used with keys generated from an HDSeed via ZIP 32. This means that all Sapling keys and addresses generated by users can be recovered as long as they have a backup that includes the seed. Depends on zcash/librustzcash#29 Closes #3380.
Use ZIP 32 for all Sapling spending keys The wallet now only stores Sapling extended spending keys, and thus can only be used with keys generated from an HDSeed via ZIP 32. This means that all Sapling keys and addresses generated by users can be recovered as long as they have a backup that includes the seed. Depends on zcash/librustzcash#29 Closes #3380.
Use ZIP 32 for all Sapling spending keys The wallet now only stores Sapling extended spending keys, and thus can only be used with keys generated from an HDSeed via ZIP 32. This means that all Sapling keys and addresses generated by users can be recovered as long as they have a backup that includes the seed. Depends on zcash/librustzcash#29 Closes #3380.
No description provided.