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, `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`.
For consistency, we serialize the `finalState` field in the
same (sparse) encoding as Sapling and Sprout use. In the future
we may want to update this to the dense encoding that
incrementalmerkletree::bridgetree::Frontier uses, but that's not
necessary for the moment.
This replaces the old implementation of asyncrpcoperation_sendmany
with one where all transaction construction is delegated to the
transaction builder. The capabilities of z_sendmany are somewhat
modified in the process:
* z_sendmany now permits sending funds from a Sprout address to
both transparent and Sapling addresses. PRIVACY NOTE: When
user sends a Sprout->Sapling transaction, the amount of the
transaction is publicly revealed.
* z_sendmany no longer supports transactions sending funds into
the Sprout pool, with the exception of change amounts when
sending from a Sprout address.
* When sending transparent coinbase funds to a set of shielded
addresses, the amount sent to recipients must fully consume
the input value and no change is permitted. This is a slightly
weaker constraint than was previously implemented; in the past,
only a single shielded recipient was allowed.
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.
Daira-Emma Hopwood
Jack Grigg
Kris Nuttycombe
Jack Grigg
Greg Pfeil
Larry Ruane
Dimitris Apostolou
MarcoFalke
mdr0id
Simon
arielgabizon