1000 blocks was selected as a balance between limiting the likely
maximum memory usage of the batch scanner, and avoiding
artificially restricting scanning throughput of small/fast blocks
due to the second-boundary lock synchronization point.
This also removes the `zcashd.wallet.batchscanner.usage.bytes` gague
value that was previously made available when `-prometheusport` was
specified.
Co-authored-by: Jack Grigg <jack@z.cash>
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.
The RPC method handler is left in as a tombstone, to redirect callers to
the replacement method (as this is an upstream Bitcoin Core RPC method
that users may expect to be present).
Have updatecheck look in $XDG_DATA_HOME/zcash/updatecheck/token for the GH
token. Having one in the repo will still take precedence (for pre-existing
users, as well as if you want to override the token used in a particular
case). The new location is standardized, exists at the user level (as the token
logically does), and means that you don't need to copy files around if you get a
new clone or worktree to do a release.
- make the token optional (just will hit a rate limit after a few runs of the
script)
- only load the token once, rather than once per request (this is necessary
after the above change, so you don't get the warning printed repeatedly)
- switch from BasicAuth to an Authorization header (this means we no longer need
the GitHub username, just the token)
- support a token file that doesn't contain a username (it will still parse old
versions of the file properly)
Previously, `finalorchardroot` and `orchard.anchor` were serialized differently
in the RPC API, which made it difficult to correlate them. This changes the
serialization for `finalorchardroot` to match `orchard.anchor`.
Previously we were sending an `Option<DecryptedNote>` from each `Batch`
back to its parent `BatchRunner`. However, this requires allocating
sufficient space in the channel to handle the case where every output
can be decrypted. In general this will not be the case, and we can
instead signal "nothing decrypted" by just dropping the channel sender.
This reduces the post-batch-scanning memory usage of `BatchRunner` from
being linear in the number of on-chain outputs, to being linear in the
number of outputs for the wallet.
Assume that when a wallet transaction has a valid block hash and transaction position
in it, the transaction is actually there. We're already trusting wallet data in a
much more fundamental way anyway.
To prevent backward compatibility issues, a new record is used for storing the
block locator in the wallet. Old wallets will see a wallet file synchronized up
to the genesis block, and rescan automatically.
(cherry picked from commit bitcoin/bitcoin@391dff16fe)
The only source of transactions for `CreateNewBlock` is the mempool, and
every transaction added to the mempool goes through `AcceptToMemoryPool`
which checks proofs and signatures.
We maintain the ability to enable these checks in `TestBlockValidity`
because it is also used in an (undocumented) `getblocktemplate` mode to
check a proposed block (minus PoW), where we cannot assume the
transactions are valid.
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
Since the wallet ecosystem may not be fully updated to handle
v5 transaction parsing at the point of NU5 activation, some
nodes may prefer to construct V4 transactions when not including
Orchard transaction components.
This change adds a CLI flag that allows node users to specify
that preference.
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
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