The term `recipient` is commonly used to refer to the address to which a
note is sent; however, a bundle may include multiple outputs to the same
recipient. This change is intended to clarify this usage.
Co-authored-by: Daira Emma Hopwood <daira@jacaranda.org>
This also removes the `bridgetree` transitive dependency when building
using the `test-dependencies` feature flag, as the only use of it can be
satisfied just with `incrementalmerkletree`.
`NoteValue - NoteValue` is always guaranteed to produce a valid
`ValueSum`, so we make that infallible and introduce a new helper method
`ValueSum::magnitude_sign` that we use for circuit synthesis.
The initial Action circuit specification indicated that only the byte
encodings of `g_d_new` and `pk_d_new` would be witnessed, but we ended
up witnessing the points directly instead. This commit removes the
leftover (and now redundant) encoding-decoding round trip.
The `Bundle` struct is variable in size and requires allocations, but
`Action` is not. This split will make it cleaner to disable the bundle
logic for no-std support.
All relevant types have `Debug` impls, but some of the trait and method
impls were lacking `Debug` bounds on their generic types. This prevented
`Debug` impls being used on the overall partially-constructed `Bundle`
types.
Use derived equality and ordering (which delegate to constant-time
versions) for note::nullifier::Nullifier and tree::MerkleHashOrchard
so that these types can be used as map keys in wallets.
This enables `InProgress<Unproven, Unauthorized>: Clone`, which allows
the bundle returned by `Builder::build` to be cloned. In pure-Rust
wallets this should not be necessary, but it is required for `zcashd`
due to FFI-crossing.
Callers cannot assume that any specific output corresponds to a specific
Orchard recipient, and must trial-decrypt all outputs to find the ones
belonging to them. This is consistent with higher-layer semantics like
having Unified Addresses as recipients (where the mapping from recipient
to a specific output would become much more complex).
Closeszcash/orchard#203.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>