librustzcash APIs for wallet key manipulation#9
Conversation
|
Can you rebase this on top of the latest librustzcash? |
|
Rebased |
77b724f to
b184cc6
Compare
115f152 to
06990af
Compare
There was a problem hiding this comment.
Psst! There's an API for this in sapling-crypto.
There was a problem hiding this comment.
I can see why you might not want to use it though. It looks like you do the right thing here, so meh, it's okay.
There was a problem hiding this comment.
Well, kinda. I think you should do what my code does, interpret it as a scalar (it should always work) and then use a write_fs afterwards, which should be implemented to write out in little endian bit order.
There was a problem hiding this comment.
Using that API requires six additional conversion read/write operations (to convert ak and nk to scalars and back, and to convert ivk to a Point and back). It didn't seem worth the cycles.
There was a problem hiding this comment.
Once this has been rebased, we should test this function against the test vectors.
There was a problem hiding this comment.
We should be doing some kind of write_fs here instead.
There was a problem hiding this comment.
So extract it into a separate function like we did for read_fs?
There was a problem hiding this comment.
I tried this in latest commit
There was a problem hiding this comment.
This will read from bytes into an Fs in little-endian bit order, which is what we want, but the function librustzcash_crh_ivk produces a little-endian byte order result and writes that out. Then, when you call librustzcash_ivk_to_pkd, it's not going to work correctly.
There was a problem hiding this comment.
Does it? I thought the intention was that the output of BLAKE2s was exactly the representation we wanted. More precisely, I think this is fine, because:
- Here we are reading a little-endian byte array in big-endian, and then flipping, which means we need to flip both the u64s and their bits.
- In
ViewingKey.ivk()we flip the little-endian byte array before reading it as big endian, and since the endianness of the bits within each byte doesn't matter for reading, that should mean the result is the same as we get here by flipping the bits above.
I'll try and generate some test vectors to confirm.
There was a problem hiding this comment.
Now that #12 has been merged, this function needs to be updated (to use read_le and not swap bits).
str4d
left a comment
There was a problem hiding this comment.
All new APIs should be tested against the test vectors that are now in master.
There was a problem hiding this comment.
Now that #12 has been merged, this function needs to be updated (to use read_le and not swap bits).
There was a problem hiding this comment.
Now that #12 has been merged, this function needs to be updated (to use read_le and not swap bits).
There was a problem hiding this comment.
Once this has been rebased, we should test this function against the test vectors.
str4d
left a comment
There was a problem hiding this comment.
Also needs tests (calling these functions inside the key component test function, and checking the output, should suffice).
There was a problem hiding this comment.
This needed to be removed as well.
There was a problem hiding this comment.
This needed to be removed as well.
There was a problem hiding this comment.
Should the reverse() on line 80 also be removed?
|
I rebased this PR on master to fix merge conflicts and remove some stray commits that had crept in. |
| ) { | ||
| // Should be okay, because caller is responsible for ensuring | ||
| // the pointer is a valid pointer to 32 bytes, and that is the | ||
| // size of the representation |
There was a problem hiding this comment.
Comment is out-of-date (I think it might be intended to apply to the unsafe conversion of result).
Add Sapling key classes to wallet Leverages new librustzcash APIs added in zcash/librustzcash#9
Various improvements to project structure and implementation This makes wNAF/multiexp more modularized and abstract (for use later in remodeling groth) and starts moving other things around. Also, good chance to start working on buildbot.
…14868de..23f0768ea 23f0768ea Release lightwallet-protocol v0.4.0 41156c767 Merge pull request #11 from zcash/feature/get_mempool_tx_pools 7c130e883 Add `lightwalletProtocolVersion` field to `LightdInfo` struct. edbb726d7 Apply suggestion from code review 38fddd73b Apply suggestions from code review 0250f2720 Add pool type filtering to `GetMempoolTx` argument. 54ccaadd5 Change semantics of pool-based pruning of compact transactions from "may prune" to "must prune". b0667ec99 Merge pull request #9 from zcash/2025-11-doc-TransparentAddressBlockFilter f3fea7bd4 doc: TransparentAddressBlockFilter doesn't include mempool a67dd323a Merge pull request #8 from zcash/2025-11-lightdinfo-upgrade-info 11da4b7e3 add next upgrade info to LightdInfo structure (GetLightdInfo) 42cd8f720 Transparent data docs update (#7) c0cf957ac Merge pull request #5 from zcash/2025-11-comments 912fc3609 Minor clarification in GetBlockRange documentation. 6b03f2cce Documentation (comments) only d978256a2 Merge pull request #1 from zcash/compact_tx_transparent 7eeb82e7c Merge pull request #4 from zcash/add_changelog a95359dc9 Apply suggestions from code review 592b637a8 Add transparent data to the `CompactBlock` format. 9d1fb2c41 Add a CHANGELOG.md that documents the evolution of the light client protocol. 180717dfa Merge pull request #3 from zcash/merge_librustzcash_history 450bd4181 Merge the history of the .proto files from `librustzcash` for complete history preservation. a4859d11d Move protobuf files into place for use in `zcash/lightwallet-protocol` 2e66cdd9e Update zcash_client_backend/proto/service.proto eda012519 fix comment f838d10ad Add gRPC LightdInfo Donation Address db12c0415 Merge pull request #1473 from nuttycom/wallet/enrichment_queue 698feba96 Apply suggestions from code review 20ce57ab3 zcash_client_backend: Add `block_height` argument to `decrypt_and_store_transaction` a6dea1da8 Merge pull request #1482 from zancas/doc_tweak 4d2d45fc9 fix incorrect doc-comment e826f4740 update CompactBlock doc-comment, to cover non-Sapling shielded notes, and addresses e9a6c00bf Various documentation improvements 988bc7214 Merge pull request #872 from nuttycom/feature/pre_dag_sync-suggest_scan_ranges 58d07d469 Implement `suggest_scan_ranges` and `update_chain_tip` a9222b338 Address comments from code review. e20310857 Rename proto::compact::{BlockMetadata => ChainMetadata} ac63418c5 Reorganize Sapling and Orchard note commitment tree sizes in CompactBlock. 0fdca14f1 zcash_client_backend: Add note commitment tree sizes to `CompactBlock` serialization. 2a0c2b8b7 zcash_client_backend: Add gRPC bindings behind feature flag 1342f0480 zcash_client_backend: Address compact_formats.proto comments 68aa4e01b zcash_client_backend: Bring in latest `compact_formats.proto` e712eb1bc Add prevHash field to CompactBlock 440384c3e Build protobufs for compact formats git-subtree-dir: zcash_client_backend/lightwallet-protocol git-subtree-split: 23f0768ea4471b63285f3c0e9b6fbb361674aa2b
feat: Elgamal Cosmos SDK wiring & tests
Align librustzcash in 'ka_agree' branch with current PR branch
Add Sapling key classes to wallet Leverages new librustzcash APIs added in zcash/librustzcash#9
librustzcash_to_scalarlibrustzcash_ask_to_aklibrustzcash_nsk_to_nklibrustzcash_crh_ivklibrustzcash_check_diversifierlibrustzcash_ivk_to_pkd