the warning before test 4r is generated by the check_z_mergetoaddress
at line 459, which moves all the sapling funds into taddr_2 and thus
expects (sapling_balance - DEFAULT_FEE) to show up into taddr_2.
However, the check_z_mergetoaddress_parallel at line 418 had already
funded taddr_2 (with the sum of taddr_1 and taddr_3), and so we need to
add that to the amount of money that check_z_mergetoaddress at line 459
expects to find.
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.
This adds tests to wallet_z_sendmany that demonstrates conditions
where pool-crossing transfers were not being caught by the privacy
policy checks, which were validating only against the transfer
request rather than the actual transfer selected. This missed
cases where sending funds between unified addresses would reveal
amounts via the turnstile.
Making all privacy policy checks after note selection guards against
this error.
If a new Orchard wallet is created after the first Orchard spend
post NU5 activation, it causes an assertion failure because the root
of the wallet's empty note commitment tree does not match the global
note commitment tree root.
The test fails during the final `z_sendmany`, because it is selecting a
note that was detected before restarting the node. Because we force the
wallet to call `SetBestChain` on every block, the wallet doesn't need to
rescan on restart, and thus doesn't repopulate the `position` field of
the in-memory note.
This issue went unnoticed in existing tests that exercise node restarts,
because the RPC tests are fast enough that they never pass the 10-minute
timeout for writing the wallet state. This commit adds a regtest-only
config option that disables the lazy writing.
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>
Orchard output ordering is no longer deterministic, as we now shuffle
spends and outputs during bundle building. But we _can_ still check that
the action index of a note being spent is correct.
Also fixes a bug in the `nuparams` helper, which would have caused MSB
zeroes in consensus branch IDs to not be rendered in the `-nuparams`
option. This hadn't been encountered because we haven't yet generated a
consensus branch ID with a zero MSB.
Kris Nuttycombe
sasha
sasha
Jack Grigg
therealyingtong
Steven
str4d
Kris Nuttycombe
Daira Hopwood
Marshall Gaucher
Steven Smith