When initializing a new Orchard wallet after NU5 activation, it is
not valid to start from the empty note commitment tree; instead,
the note commitment tree needs to be initialized from the state of
the global Orchard Merkle frontier.
In addition, this change necessitates a change to how rewinds work,
such that in a rollback scenario with a newly initialized wallet
that does not have sufficient checkpoints to fully satisfy a requested
rewind, the rewind is allowed to proceed so long as it does not
invalidate any persisted witness data.
This includes:
- `orchard =0.1.0-beta.3` which includes the final circuit changes.
- The new NU5 consensus branch ID.
- Updated ZIP 244 test vectors (which use the NU5 consensus branch ID).
This method detects and returns metadata for any notes belonging to the
wallet that are spent in the transaction. It also trial-decrypts the
Orchard outputs of a transaction using the wallet's incoming viewing
keys along a set of OVKs provided by the caller, and returns metadata
about the notes that were successfully decrypted.
This also alters `TransactionBuilder::SendChangeTo` to take a
`libzcash::ChangeAddress` value and thus avoids the invalid
t-addr case of CTxDestination.
Adds HD seed derivation from ZIP-339 mnemonic phrases.
This replaces random generation of transparent spending keys with BIP-44-compatible derivation from a mnemonic seed phrase, and replaces the random HD seed previously used for Sapling HD key derivation
with the same mnemonic seed. After this change, all new transparent and Sapling addresses
will be derived from a new randomly generated mnemonic seed, which is produced in such a way that
it is guaranteed to produce valid unified spending keys at account 0 for all address types.
Closes#5176.
Closes#2673.
In order to support generation of unified addresses, it needs
to be possible for the code generating a unified address to search
the space of Sapling diversifiers to obtain a valid diversifier.
Historically, invalid diviersifiers were simply skipped, so we retain
this behavior when obtaining a Sapling address from the legacy HD seed.
The orchard crate was pinning a specific rev of zcash_note_encryption
which prevented CI from vendoring the crate dependencies. Now orchard
uses a patch, which enables us to similarly patch here to get the
correct crate versions throughout our tree (while the crates are still
in flux).
- Currently, only RedPallas signatures are batch-validated. We can extend
this validator to cover Halo 2 proofs in the future.
- Signatures in a batch are not retried individually if the batch fails:
- For per-transaction batching (when adding to the mempool), we don't
care which signature within the transaction failed.
- For per-block batching, we currently don't care which transaction
failed. We might do so in future, at which point this behaviour can
be easily changed.
The majority of the parser is in C++, but Orchard bundles are parsed
exclusively by Rust.
The ZIP 244 test vectors are brought in here so we can start by testing
round-trip serialization.
In addition to the specified consensus rules, we unconditionally enable
ZIP 216 in the following situations:
- Wallet code
- Transaction building
- Nullifiers for wallet notes
- Tests
- Benchmarks
Closeszcash/zcash#5201.
hyper 0.14.3 added an unstable C API, but the changes to enable it
require us to configure cargo with a linker for cross-compilation.
We'll need to figure this out eventually, but for now let's just
pin hyper to a version that doesn't require it.
The tracing crate is initialized with an optional log path, and will
either start a background thread for non-blocking log writing, or write
directly to standard output with ANSI encoding.
C preprocessor macros are used to emulate the Rust macros natively
provided by the tracing crate. They handle the creation of static
tracing callsites, and ensure that the correct file and line number
information is used for each logging site.
Kris Nuttycombe
therealyingtong
Jack Grigg
Daira Hopwood
Kris Nuttycombe
Kris Nuttycombe
Sean Bowe