Orchard proving can require large amounts of memory, so by default
`z_sendmany` will not attempt to create transactions containing more
than 50 Orchard inputs or outputs to reduce the risk of memory
exhaustion. The `-orchardactionlimit` parameter allows users with
larger amounts of memory at their disposal to override this limit.
Fixes#5889
z_mergetoaddress doesn't currently have any mechanism for specifying
the minconf value. We don't want to default back to a minconf of 1,
as before, because we'll be selecting anchors with at least 3
confirmations by default, so the simplest change here is to make
the minconf value default to the number of anchor confirmations, and
add a configurable minconf at some point in the future. It's likely
that `z_mergetoaddress` will end up being deprecated in any case,
so this works for now.
Also, ensure that anywhere that we're attempting to obtain the Orchard
anchor that we don't attempt to get an anchor from a height below NU5
activation.
This modifies the release script to take as its first argument
the hash of the git commit to be released. It also improves the
verification of the previous commit tag by ensuring that the tag
exists in the history of the specified commit.
This changes anchor selection and Orchard authentication path generation
to default to select anchors at a the depth specified by the
`-orchardanchorconfirmations` CLI argument, with a default anchor
selection depth of 10 blocks.
If the value of `minconf` used for a particular call to `z_sendmany` is
less than the the set number of Orchard anchor confirmations, `minconf`
will be used instead for the Orchard anchor confirmations depth,
so that the selected anchor will be certain to contain any notes
selected to be spent.
Fixes#5644
We've decided to remove the option to allow all deprecated features,
because this has the effect that, if a user enables this flag, they
won't get the warning (and hence may forget to take action) at the time
that a feature is moved from the default-allowed set to the
default-denied set.
Co-authored-by: str4d <thestr4d@gmail.com>
The -reindex option causes the node to first read the block files,
adding each block to the block index, then reset the reindexing flag,
then build the best chain (the "UpdateTip: new best" logging messages).
Before the wallet notification thread begins to actually do
notifications, it should wait until we're no longer in initial block
download, rather than waiting until the reindexing flag is reset (which
is too early).