This removes a btest case (can’t mix Sprout and Sapling inputs in
z_mergetoaddress) that is no longer testable outside the RPC interface (and
there is an rpc-test for it already).
It also adds a new failure case in `WalletTxBuilder::PrepareTransaction` – we
now check that the fee is in `MoneyRange`. This is generally protected by
`AmountFromValue` in RPC calls, but we have tests that check it at this level,
and better safe than sorry.
This change takes `const SpendableInputs&` instead of copying it. It does an explicit copy later in
more limited scope, avoiding an extra copy in the conventional fee side.
However, this means both the reference and mutable copy are in scope at the same time, making it
easy to use the wrong one by mistake.
The previous code did not mine enough blocks to have sufficient matured
funds for the tests it needed to perform, taking into account the slow
start. So, we now mine 200 instead of 110 blocks.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
I don’t think it’s possible for this error condition to be tested for `z_shieldcoinbase` any more
1. to hit this failure, we need a fee higher than the amount available in coinbase UTXOs;
2. if there are no UTXOs to shield, we fail before reaching an “insufficient funds” check;
3. coinbase UTXOs are >1 ZEC, which is the highest we can set `-maxtxfee` to without emitting a
warning;
4. emitting a warning causes the test to fail.
Previously, `WalletTxBuilder` expected a vector of payments with known amounts.
This meant that operations like `z_shieldcoinbase` and `z_mergetoaddress` needed
to pre-calculate the amount to be sent to the target address.
With ZIP 317 fees, this became harder to do. Now `WalletTxBuilder` accepts
either a vector of payments or a single address (and optional memo) for the net
amount to be paid to.
This also converts `z_shieldcoinbase` to use this approach. `z_mergetoaddress`
conversion is blocked by #6569.
This avoids a race condition where node 1 attempts to fetch the block
while it is considered invalid by node 0, which eventually leads to the
nodes becoming disconnected, preventing the test from advancing.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
There was a race condition here between the block generated by node 0
being broadcast to node 1, and being invalidated by node 0. Due to the
changes we made to the difficulty adjustment algorithm, the invalidated
block and the block replacing it generated by node 0 would have the same
chain work; thus if node 1 observed the invalidated block, it would
never reorg to the replacement block.
We fix this by having node 0 reconsider the invalidated block before
generating its next block. This avoids the chain fork, and also clears
the mempool to provide better separation between test stages.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
str4d
Kris Nuttycombe
Jack Grigg
Greg Pfeil
Daira Emma Hopwood
Greg Pfeil