We still depend on it indirectly, but we don't use it directly anymore
since we upstreamed our patch to `metrics-exporter-prometheus`.
`thiserror` is also only used by the wallet tool, so has been reordered
accordingly.
`hyper 0.14.18` stops building the C libraries by default (after opt-in
support was added via a new flag in nightly Cargo), which means we no
longer have the problem of the `cdylib` build requiring a linker to be
hooked up to the Rust build when all we want is a `staticlib`.
For consistency, we serialize the `finalState` field in the
same (sparse) encoding as Sapling and Sprout use. In the future
we may want to update this to the dense encoding that
incrementalmerkletree::bridgetree::Frontier uses, but that's not
necessary for the moment.
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.