Without `AllowRevealedRecipients`, we can’t send transparent change, but previously we asserted if
we couldn’t get a transparent change address. Now it returns a new `TransparentChangeNotAllowed`
failure, which is just a more specific `TransparentRecipientNotAllowed` to avoid confusion when
there are no explicit unshielded recipients.
- still support explicit fixed fees everywhere – if a caller provides a fee, we
don’t adjust it
- treat negative fees as signifier for use of ZIP 317 fees when a fee needs to
be provided because of additional positional arguments
When deciding whether we can pay Orchard receivers, rather than checking
whether we have “sufficient non-Sprout funds”, we can just check whether the
selector selects Sprout – if it doesn’t then we can select Orchard receivers
regardless, and we’ll catch insufficient funds later.
This is also helpful for ZIP 317, because in that case we don’t even know the
total non-Sprout funds necessary until after we decide which receivers to pay.
In its existing usage, `CppStream` was only used in a context where the
C++ `READWRITE` macro was being called with a `CDataStream`. However, in
other contexts the macro can be called with various other types with a
stream-like interface. Since we can't expose C++ templates across the
`cxx` bridge (or FFI generally), we instead turn `CppStream` into an
enum that covers all of the stream-like types we may want to use.
`std::visit(match {...}, specimen)`, improving code readability.
For ease of review, this commit includes only obviously correct
transformations that all follow the same pattern.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
InsertBlockIndex should take a const reference to a uint256 instead of
just a uint256.
LoadBlockIndexGuts also assume std::function<CBlockIndex*(const uint256&)> insertBlockIndex
as an argument:
2d456afebe/src/txdb.h (L150)
This fixes an RPC test failure that tests specifically for this with
z_shieldcoinbase. This also exposed an issue where an overly-high fee resulted
in a negative Payment causing an exception too deep. Added an assert when
creating a Payment and guarded against it for z_shieldcoinbase.
Fixes#2621 and #5654 (but does not handle Orchard locking, which is tracked in
a separate issue).
Extracted from z_sendmany to be used across multiple transaction
operations. Previously, it also checked a `bool` to decide what “LegacyCompat”
means, but bools are too easy to concoct, so it now expects the sender and
recipients to be checked internally. Also, z_sendmany was generating the bool
only from the sender, illustrating how easy it is to miss something when you try
to precompute.