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

keytree: serialization for xpub, xprv #179

Closed
oleganza opened this issue Mar 1, 2019 · 4 comments
Closed

keytree: serialization for xpub, xprv #179

oleganza opened this issue Mar 1, 2019 · 4 comments

Comments

@oleganza
Copy link
Contributor

oleganza commented Mar 1, 2019

For both Xprv and Xpub types:

  • ::to_bytes(&self) -> [u8; 64]
  • ::from_bytes(&[u8]) -> Option<Self> (checking that slice is exactly 64-byte-long)

For later: implement Serde on top of these (example)

Note: the from_bytes won't benefit from using fixed-length array ([u8; 64]) because at least Xprv would still have to check if scalar is canonically encoded. So we might as well make decoding of all of these failable and take byteslices to let user not to make extra 64-byte copies.

@tessr
Copy link
Contributor

tessr commented Mar 11, 2019

What should be serialized/deserialized here? For the private key, is the deserialized form composed of the deserialized scalar (a u8 of length 32) followed by the deserialized derivation key (also a u8 of length 32)? For the pub key, is it the same thing but the deserialized point instead of the scalar?

@oleganza
Copy link
Contributor Author

Yes:

xprv = <scalar 32 bytes> <dk 32 bytes>
xpub = <point 32 bytes> <dk 32 bytes>

Now that Xpub holds a decompressed point, the Option<Xpub> returned by decoding &[u8] can also fail because decompress() fails (not only on len()!=64).

@oleganza oleganza reopened this Mar 11, 2019
@oleganza
Copy link
Contributor Author

(clicked wrong button)

@tessr
Copy link
Contributor

tessr commented Mar 19, 2019

Resolved by #228

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