Previously, `AllowRevealedSenders` would permit linking multiple legacy taddrs. This strengthens the
policy to only allow sending from a single taddr, preventing linking of any addresses. To send from
multiple taddrs (legacy or UA) now requires `AllowLinkingAccountAddresses`.
that they have more than `-txunpaidactionlimit` unpaid actions, will now
not be accepted to the mempool or relayed. For the default values of
`-txunpaidactionlimit` and `-blockunpaidactionlimit`, these transactions
would never be mined by the ZIP 317 block construction algorithm. (If the
transaction has been prioritised by `prioritisetransaction`, the modified
fee is used to calculate the number of unpaid actions.)
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
Previously transparent inputs were under-counted because the `CTxIn`s were created without a
signature. This now adds a dummy signatures so sizes are correct.
Fixes#6658.
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.
These features were deprecated at least 3 minor releases ago. I found
one mistake which was that `z_validateaddress` had not been placed
behind the `addrtype` deprecated feature; this has been fixed.
Previously we only required synchronization points where blocks were
sent between nodes; now we need them between action and query operations
on the same node, because wallet notification of mined blocks no longer
occurs in real-time.
The p2p_nu_peer_management and rewind_index RPC tests still start from
Sprout, because they are explicitly (and only) testing network behaviour
across network upgrades.
The mempool_tx_input_limit test is removed because the flag has been
ignored since Sapling activation, and will be removed at some point in
the near future.
Strictly speaking this is not a true deduplication; the test output will be
slightly different (due to inconsistent print statements) but I think this is
close enough.
The mempool was not synced so a block could be generated and not
clear out the mempool. This would then cause subsequent code
which expected the mempool of all nodes to be empty to hang.
The new parameter is to satisfy the principle of least astonishment
by providing a sensible default for the maximum number of transparent
inputs to shield. If users do not configure -mempooltxinputlimit
it is possible for them to create transactions with hundreds of
inputs which suffer from mining delay, due to the current state of
the network where some miners have configured -mempooltxinputlimit
as a way to deal with the problem of quadratic hashing.