Zsa1 upsteram merge #63

Neither of these should have been feature flags, as they gate breaking changes to the Zcash consensus rules (and in some ways are incompatible with each other), while feature flags should be additive.

CI: Rework the test states

Various fixes to Orchard tests

…der a common single-pool test

zcash_client_sqlite: More Orchard tests

… tree

…lated views.

zcash_client_sqlite: Add database tables for Orchard

… `put_block`

…ions.

…ransactions.

Co-authored-by: Daira-Emma Hopwood <[email protected]>

zcash_client_sqlite: Implement Orchard scanning

…ights for the anchor.

…om selection.

…apling and Orchard.

…uture Sapling flagging.

…re_sent_tx`

…ngeStrategy`

Also update sqlite to utilize the new struct

Co-authored-by: Kris Nuttycombe <[email protected]>

…et_account_for_ufvk`

…t_account_by_ufvk.

Co-authored-by: str4d <[email protected]>

… note commitment tree.

Co-authored-by: str4d <[email protected]>

…port `zcash_client_sqlite`: Add Orchard wallet support

…atching Return partial matches when using `WalletRead::get_account_for_ufvk`.

…ccount_index) pairs.

…count Add `WalletRead::get_seed_account`

zcash_client_sqlite: Update to make use of `orchard::note::Rho`

…anned range. In order to support constructing the anchor for multiple pools with a common anchor height, we must be able to checkpoint each note commitment tree (and consequently compute the root) at that height. Since we may not have the information in the tree needed to do so, we require that it be provided. As a bonus, this change makes it possible to improve the UX around spendability, because we will no longer require subtree ranges below received notes to be fully scanned; the inserted frontier provides sufficient information to make them spendable.

…ork behind the `orchard` flag.

…n errors.

…ool_checkpointing zcash_client_sqlite: Ensure that Orchard and Sapling checkpoints are always available for the same block heights.

APIs for mobile SDKs

…ount`

Account APIs needed for the mobile SDKs

…note_selection zcash_client_backend: Fix note selection & add more multi-pool tests.

…rait.

…parsing.

…selection_refactor zcash_client_backend: Pure refactoring for note selection ergonomics.

…nstruction.

…rint::SeedFingerprint`

zcash_keys: Remove HdSeedFingerprint as it duplicates `zip32::fingerprint::SeedFingerprint`'

…lt<Option<Transaction>, _>` This should never have had the behavior of returning an error on a missing txid in the first place; doing so conflates database corruption or connectivity errors with the ordinary case where data may not be available.

zcash_client_backend: Make `WalletRead::get_transaction` return `Result<Option<Transaction>, _>`

The transport-specific code is moved behind a new `lightwalletd-tonic-transport` feature flag.

Co-authored-by: Kris Nuttycombe <[email protected]>

zcash_client_sqlite: Fix ambiguities in transaction views

Add `UnifiedIncomingViewingKey` struct

zcash_client_backend: Rename `AccountKind` to `AccountSource`

The blanket `impl Account<A> for (A, Option<UnifiedFullViewingKey>)` is removed because we cannot know the UIVK for `(A, None)`. We instead provide a blanket impl for `(A, UnifiedIncomingViewingKey)`. We also move both of them behind `test-dependencies` because they are only intended for testing purposes.

The previous implementation was mixing the caller-provided seed with the wallet-provided ZIP 32 account index, and throwing an error if the USK derivation failed. We instead need to count that as a mismatch, because the wallet account's actual seed would derive a USK fine (because wallet accounts are required to have a known UIVK).

Closes zcash#1283.

…vance zcash_client_sqlite: Always check for seed relevance in `init_wallet_db`

During wallet migration in particular, the absence of _any_ accounts is expected, and all seeds should be treated as relevant (because accounts cannot be added before a wallet is initialized).

…ce-with-no-accounts Distinguish seed relevance when no derived accounts are present

Remove `orchard` feature flag from behind `zcash_unstable` cfg flag

…hain_test_fixes zcash_client_sqlite: Fix `scan_complete` tests.

Fixes zcash#1280

…ation zcash_client_backend: Treat protobuf default as the empty `CommitmentTree`.

…ccounts

…chain state.

zcash_client_sqlite: Include Orchard receiver in default UA for new accounts

…hain_test_fixes Fix update_chain_tip_unstable_max_scanned tests.

…d UA receivers.

…ests zcash_client_sqlite: Fix tests that broke with the addition of Orchard UA receivers.

Fixes zcash#1292 Fixes zcash#1299

… conflict bug (not failing.)

…ckpoints.

…_conflict zcash_client_sqlite: Fix a problem related to checkpoint pruning.

This fixes an error wherein a note commitment in the last note commitment position in a block was not being correctly marked as a checkpoint. This would occur when a block contained both Sapling and Orchard note commitments, but the final transaction in the block contained only either Sapling or Orchard note commitments, but not both. Fixes zcash#1302

…ckpoints

Fixes zcash#1292 Fixes zcash#1299

This also fixes the `update_chain_tip_stable_max_scanned` tests.

zcash_protocol release version 0.1.1

…nsaction_value

…le_max_scanned zcash_client_sqlite: Use account birthday subtree sizes for progress

…n output is recorded as sent.

…actions. Previously, if the funding account for a received transaction output was determined to be an account known to the wallet, the output was recorded as though it were sent to an internal (change) address of the wallet.

zcash_primitives release version 0.15.0

…ed_tx`

Release zcash_proofs version 0.15.0

Release zcash_keys version 0.2.0

…sent_output`.

At present, we don't take builder padding rules into account in the determination of whether or not we can include spends of dust notes in grace actions. It's too complex to attempt a complete fix for Zashi 1.0, but we can have a tolerable workaround for launch by just never selecting dust-valued notes. This is a temporary solution; opened zcash#1316 to track the resolution.

zcash_client_sqlite: Use consistent criteria for detecting what accounts fund a transaction.

zcash_client_sqlite: Disallow selection of dust notes.

remove doc hidden from some keys

Closes zcash#1079

Closes zcash#1126

…0.10.0 Release `zcash_client_sqlite 0.10.0` / `zcash_client_backend 0.12.0`

…ipient account to be null, but not both.

…traint zcash_client_sqlite: Fix sent note recipient constraint

Closes zcash#1326.

zcash_client_sqlite: Fix column name in UTXO query

…0.10.2 zcash_client_sqlite 0.10.2

…ding to transparent. The "avoid pool crossing" conditions in not selection were erroneously not taking into account the need to pay transparent outputs.

zcash_client_sqlite: Fix incorrect input selection filtering when sending to transparent.

… have an Orchard receiver.

…t_ua zcash_client_sqlite: Add a migration to ensure that default addresses…

…parent_output`

zcash_client_sqlite: Use named column accessors for `to_spendable_note`

zcash_client_sqlite: Fix sloppy named-parameter reference.

This implements the necessary state machine for taking a wallet in some arbitrary synchronization status, and fully scanning (the remainder of) the chain. Closes zcash#1169.

zcash_client_backend: Implement async wallet synchronization function

…addresses Prior to this change, the recipient of a sent transaction would always be shown as the protocol-level address, instead of any unified address intended as the recipient. Now, instead of reencoding the recipient address, we use the original `ZcashAddress` value from the payment request.

…thday` query.

zcash_client_sqlite: Fix broken `account_birthday` method.

…0.10.3 Release zcash_client_sqlite version 0.10.3

Bumps [peaceiris/actions-gh-pages](https://github.com/peaceiris/actions-gh-pages) from 3 to 4. - [Release notes](https://github.com/peaceiris/actions-gh-pages/releases) - [Changelog](https://github.com/peaceiris/actions-gh-pages/blob/main/CHANGELOG.md) - [Commits](peaceiris/actions-gh-pages@v3...v4) --- updated-dependencies: - dependency-name: peaceiris/actions-gh-pages dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>

Bumps [supplypike/setup-bin](https://github.com/supplypike/setup-bin) from 3 to 4. - [Release notes](https://github.com/supplypike/setup-bin/releases) - [Commits](supplypike/setup-bin@v3...v4) --- updated-dependencies: - dependency-name: supplypike/setup-bin dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>

…pplypike/setup-bin-4 build(deps): bump supplypike/setup-bin from 3 to 4

…aceiris/actions-gh-pages-4 build(deps): bump peaceiris/actions-gh-pages from 3 to 4

Refactor `equihash` code

Co-authored-by: str4d <[email protected]>

Extract `zip321` crate from `zcash_client_backend`

Trust set imported from `zcash/zcash` where there were common deps.

As with our `cargo-vet` usage in `zcash/zcash`, these are binary crates for interacting with Windows APIs, so both sides are maintained by Microsoft and are not something we can audit ourselves.

Most of the config is copied from `zcash/zcash`, but with a few extra license exceptions due to the `download-params` feature of `zcash_proofs` and the `lightwalletd-tonic-transport` feature of `zcash_client_backend`.

Set up Cargo audit infrastructure

CI: Add workflow to automatically trigger audit aggregation

CI: Add explicit token to GitHub CLI usage

CI: Migrate to `codecov/[email protected]`

Signed-off-by: jimmycathy <[email protected]>

chore: remove repetitive words

…zsa1 # Conflicts: # Cargo.toml # components/zcash_note_encryption/Cargo.toml # components/zcash_note_encryption/src/batch.rs # components/zcash_note_encryption/src/lib.rs # zcash_client_backend/src/proto.rs # zcash_client_backend/src/scan.rs # zcash_primitives/src/sapling/note_encryption.rs # zcash_primitives/src/transaction/components/sapling.rs # zcash_primitives/src/transaction/components/sapling/builder.rs

Zsa1 upsteram merge #63

Zsa1 upsteram merge #63

Commits on Mar 10, 2024

Commits on Mar 11, 2024

Commits on Mar 12, 2024

Commits on Mar 13, 2024

Commits on Mar 14, 2024

Commits on Mar 15, 2024

Commits on Mar 18, 2024

Commits on Mar 19, 2024

Commits on Mar 20, 2024

Commits on Mar 21, 2024

Commits on Mar 22, 2024

Commits on Mar 23, 2024

Commits on Mar 24, 2024

Commits on Mar 25, 2024

Commits on Mar 26, 2024

Commits on Mar 27, 2024

Commits on Mar 29, 2024

Commits on Apr 1, 2024

Commits on Apr 2, 2024

Commits on Apr 3, 2024

Commits on Apr 5, 2024

Commits on Apr 6, 2024

Commits on Apr 8, 2024

Commits on Apr 9, 2024

Commits on Apr 10, 2024

Commits on Apr 12, 2024

Commits on Apr 18, 2024

Commits on Apr 19, 2024

Commits on Apr 22, 2024

Commits on Apr 23, 2024

Commits on Apr 26, 2024

Commits on Apr 27, 2024

Commits on Apr 29, 2024

Commits on May 4, 2024

Commits on May 7, 2024

Commits on May 13, 2024

Commits on Jun 13, 2024

Commits on Jun 18, 2024

Commits on Jun 19, 2024

Commits on Jun 20, 2024

Commits on Jun 26, 2024