Comments (3)
Some of the missing information can be reconstructed from contextual information:
- ✅
depth
is always 3, asAccountPrivKey
is derived using the pathm/44'/coin_type'/account'
. - ❌ We cannot determine the parent key fingerprint correctly without re-deriving the parent from the seed.
- ❓
child number
isaccount'
(I believe including the hardening flag), which we "know" in the places we currently use the USK encoding (specifically for derived accounts inzcash_client_*
), but don't necessarily have at the spot we are doing the decoding (in particular for imported UFVKs, support for which was recently added tozcash_client_*
).
I also notice that AccountPubKey::{serialize, deserialize}
is used in the UFVK encoding and has the same problem (for bip32
compatibility): it only encodes the chain code and pubkey. This uses the ordering chain code || pubkey
and is therefore a suffix of the bytes used in the xpub
encoding, rather than an entirely separate encoding. This encoding was intentional and is specified in ZIP 316; IIRC we decided that we didn't need any of this data and preferred the shorter UFVK encoding.
So in both cases we need to decide how to handle the unknown data. I think the "correct" way to handle this is to define AccountPrivKey
and AccountPubKey
as solely being wrappers around the chain code and pubkey / privkey, and then ensure there are no public APIs that expose the internal hdwallet
(or soon-to-be bip32
) types. Then when we migrate to bip32
we can just stick obviously-garbage data into the unknown fields.
The difference in encoding between AccountPrivKey
(privkey || chaincode
) and AccountPubKey
(suffix of xpub
) is annoying, and we may also want to fix this for AccountPrivKey
.
from librustzcash.
I think it's fine to fix the USK encoding; the encoding methods are still under the unstable
feature flag. Also, in order to stabilize this encoding, ZIP 316 would need to be updated to specify it, which hasn't yet been done.
The AccountPubKey
encoding can stay as it is, I think; that choice was intentional.
from librustzcash.
I think it's fine to fix the USK encoding; the encoding methods are still under the
unstable
feature flag.
Agreed. The Android SDK already tells its users that they need to be prepared to regenerate the USK:
https://github.com/Electric-Coin-Company/zcash-android-wallet-sdk/blob/159de09b2bf1cc1c752260c76d444c11dfabebc9/sdk-lib/src/main/java/cash/z/ecc/android/sdk/model/UnifiedSpendingKey.kt#L64-L74
The iOS SDK doesn't, but it also has a regeneration API like the Android SDK. And if we want this to be a joint we keep oiled, we need to exercise it.
from librustzcash.
Related Issues (20)
- Add a test for correct calculation of ZIP 317 total output size for mixtures of P2PKH and P2SH outputs
- shardtree panic HOT 5
- Ensure symmetry of transparent output handling between `put_blocks`, `store_decrypted_tx` and `store_sent_tx` HOT 2
- Don't create new `WalletDb` wrappers outside `WalletDb::transactionally`: take `&mut WalletDb<SqlTransaction<'_>, P>` as argument instead HOT 1
- Adding a second account with an older birthday height effectively changes height for existing account HOT 2
- zcash_address::kind::unified::address::Address::can_receive_memo does not account for whether Orchard is disabled HOT 1
- Handling of change memos imposes artificial constraints HOT 1
- `tokio 0.12` migration causes `UnknownIssuer` errors with `lightwallet` servers using Let's Encrypt HOT 4
- zcash_primitives 0.17.0, zcash_proofs 0.17.0
- `create_proposed_transactions` can incorrectly produce transactions HOT 4
- librustzcash fails to sync account with birthday set to sapling activation height HOT 4
- zcash_client_backend: Add gRPC-over-Tor support
- Precisely document same-UFVK errors on account creation and ensure they are per-component HOT 2
- Create `unstable-frost` feature
- Allow Orchard-only UFVK be created from an Orchard FVK
- Figure out what to do in librustzcash about the broken `GetTransaction` method of lightwalletd HOT 1
- [zcash_client_sqlite] Replace the `put_tx_meta` workaround in the test `send_multi_step_proposed_transfer`
- zcash_client_sqlite always enables the "orchard" feature of zcash_keys HOT 4
- Cache incoming viewing keys and detect IVK collisions when adding accounts
- zcash_client_backend: Faster failure detection for invalid sent transactions
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from librustzcash.