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.
Daira Hopwood
Kris Nuttycombe
Greg Pfeil
Greg Pfeil
Jack Grigg
Jack Grigg
Nathan Wilcox
Sean Bowe
Wladimir J. van der Laan
Pieter Wuille
sasha