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).
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 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>
This adds an `-allowdeprecated` CLI parameter whose value is a flag
indicating a deprecated feature that should be explicitly enabled.
Multiple instances of this argument may be provided. In the case that
this parameter is not provided, all currently deprecated RPC methods
that are not slated for removal in the next release remain available.
A user may disable all deprecated features entirely by providing the
string "none" as the argument to this parameter, or enable all
deprecated features, including those slated for removal, by providing
the string "all" as the argument to this parameter. In the case that
"all" or "none" is specified, multiple invocations of `-allowdeprecated`
are not permitted.
To explicitly enable only a specific set of deprecated features, use
`-allowdeprecated=<flag1> -allowdeprecated=<flagN> ...` when starting
zcashd. The following flags are recognized:
- "all" - enables all deprecated features.
- "none" - disables all deprecated features.
- "legacy_privacy" - enables the use of the deprecated "legacy" privacy
policy for z_sendmany. This causes the default behavior to conform to
the `FullPrivacy` directive in all cases instead of just for
transactions involving unified addresses.
- "getnewaddress" - enables the `getnewaddress` RPC method.
- "z_getnewaddress" - enables the `z_getnewaddress` RPC method.
- "zcrawreceive" - enables the `zcrawreceive` RPC method.
- "zcrawjoinsplit" - enables the `zcrawjoinsplit` RPC method.
- "zcrawkeygen" - enables the `zcrawkeygen` RPC method.
- "addrtype" - when this option is set, the deprecated `type` attribute
is returned in addition to `pool` or `address_type` (which contain the
same information) in the results of RPC methods that return address metadata.
That is, without having to launch with test_runner.py. There are
several places where the BITCOIND environment variable determines the
executable, but the default is "bitcoind"; change the default to
"src/zcashd". This does require running the test from the top-level
directory.
Also change the environment variable from BITCOIND to ZCASHD. This could
conceivable break someone, but it just makes too much sense not to do.
Daira Hopwood
Jack Grigg
Greg Pfeil
Sean Bowe
Kris Nuttycombe
Pieter Wuille
Jack Grigg
Kris Nuttycombe
Larry Ruane