It is possible for an address to be generated for a UFVK that
contains an Orchard FVK, but where the address does not contain
an Orchard receiver. Cache restoration was failing on startup
because we failed to allow for this case.
The test was creating a fake shielding transaction, but by using a
single null `COutPoint` it was accidentally trying to create a coinbase
transaction, which was then rejected by the consistency checks on the
Rust side (which require that no inputs be provided for a coinbase
transaction, which by definition has no real inputs).
This makes it easier to figure out test failures caused by errors on the
Rust side, for which we generally log the error and then return a simple
failure condition (`false` or `nullptr`) which obscures the error on the
C++ side.
We add similar logic to the Boost test framework, but commented out by
default because it results in very verbose test output.
Make consistent use of "pool", "address type" and "receiver type",
in RPC documentaion, and deprecate bare uses of "type" in RPC APIs.
Fixes#5534
Co-authored-by: str4d <thestr4d@gmail.com>
Prior to zcash/zcash@90e59c3be0 Sapling
default payment addresses were added to the in-memory keystore whenever
a full viewing key was added, or loaded from disk. After that change,
the Sapling address was no longer being restored to the in-memory
keystore on wallet load; instead, z_getnewaddress and
z_getnewaddressforaccount both persist the address to the keystore
directly. This commit adds handling to `LoadCaches` to correctly persist
the default address to the wallet database, and add it to the in-memory
keystore, when this condition is detected.
We need to bump the `zcashd` protocol version because the new rules are
not compatible with existing rules followed by 170015 nodes, but we
_also_ need to ensure we can still bump it again once we set the testnet
reactivation height (changing node network behaviour again). This commit
also enables RPC tests to run (because previously the nodes considered
each other to be too old for NU5 to be active, and were disconnecting).
Before merging 4.7.0-rc1 into the nu5-consensus branch, we were in a
split state:
- 4.7.0-rc1 included Orchard support in the transaction builder, which
required special handling of Orchard bundles when computing sighashes.
The `PrecomputedTransactionData` structure could be shared, because
its digests were only relevant to transparent signatures (as shielded
signatures signed the txid directly even in shielding transactions).
- nu5-consensus included the changes to ZIP 244, which required passing
around a `PrecomputedTransactionData` that contained the set of all
transparent inputs being spent, because shielding transactions now also
need to commit to transparent inputs.
In the merge commit, we incorrectly handled the resolution: we correctly
derived a fresh `PrecomputedTransactionData` when signing the Orchard
bundle, but we reused the `PrecomputedTransactionData` that was
previously derived before checking whether or not we even had an Orchard
bundle, for transparent inputs. This meant that its commitments didn't
commit to the Orchard bundle, and so transparent signatures on
transactions with Orchard bundles would fail to verify.
Incidentally, this is the exact inverse of a bug we encounted while
implementing the ZIP 244 changes on the nu5-consensus branch: we were
correctly computing the transparent sighash, but we were relying on the
initial `TxDigests` derived within `PrecomputedTransactionData` for the
Orchard sighash, even though we were actively rewriting the transaction
to include the Orchard bundle. The fix there was similarly to re-compute
the `TxDigests` before computing the sighash.
The merge commit includes changes to address direct merge conflicts.
This commit makes the remaining changes necessary to integrate the
Orchard wallet changes with the NU5 consensus changes.
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).
`CWallet::FindUnifiedAddressByReceiver` is a wrapper around the visitor
`UnifiedAddressForReceiver`, which looks up the Unified Address (if any)
corresponding to the given receiver. However, this only returns external
UAs, and returns `std::nullopt` both if the receiver does not correspond
to a UFVK, and if it does but is derived from an internal FVK. By using
this method as a filter, `listaddresses` was not filtering out internal
Sapling receivers, and thus was leaking Sapling change addresses for
accounts (which we do not want revealed in the UI anywhere).
Instead, we now check for UFVK metadata directly, which verifies that
the Sapling receiver is derived from a UFVK without any extra filtering.
- Legacy transparent addresses derived from the mnemonic seed are no
longer duplicated in the `legacy_random` source.
- Legacy transparent change addresses derived from the mnemonic seed are
now shown under that source.
- Sapling addresses that aren't part of a UA are now identified
correctly when derived from the mnemonic seed, rather than being
assumed to be derived from the legacy HD seed.
Kris Nuttycombe
Jack Grigg
Kris Nuttycombe
Steven Smith
str4d
sasha
sasha
Kris Nuttycombe
Marshall Gaucher
ying tong
Daira Hopwood
Jack Grigg
Dimitris Apostolou
Charlie O'Keefe
Larry Ruane