Merge v4.5.1-1 hotfix branch #5354
Conversation
Addresses managed by the zcashd wallet may be generated using multiple different sources of randomness and/or the wallet's HD seeds. Depending upon how addresses are generated, they may divided into multiple sets, each associated with a separate spend authority and treated as an independent pool of funds. In the future, the root spend authority for a wallet will be a mnemonic seed phrase; the API represented by this PR anticipates that future and attempts to provide functionality that will serve both current and future needs, as well as the transition between them.
Without this change, mainnet and testnet nodes following standard rules will not accept v5 transactions into their mempools, causing them to be ignored.
We switched testnet to follow standard rules in #1604, in order to find bugs such as the one fixed in the previous commit.
Update the tests to reflect the new listaddresses result structure.
Co-authored-by: str4d <jack@electriccoin.co>
Mark v5 transaction format as standard for NU5
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
Add `listaddresses` RPC method.
We aren't going to move to Clang 13 in a hotfix release. The other dependencies passed their postponement re-evaluation date, but also won't be updated just yet.
Dependency bumps for v4.5.1-1
Release v4.5.1-1
| pwalletMain->GetSaplingPaymentAddresses(saplingAddrs); | ||
| BOOST_CHECK(addrs.size() + saplingAddrs.size() == numAddrs); | ||
| // here we also include the watchonly sapling addresses | ||
| BOOST_CHECK(sproutAddrs.size() + saplingAddrs.size() == numAddrs + (n1 / 2)); | ||
|
|
||
| // Ask wallet to list addresses | ||
| BOOST_CHECK_NO_THROW(retValue = CallRPC("z_listaddresses")); |
There was a problem hiding this comment.
In other cases where we have foo and z_foo methods, foo is the legacy one (e.g. sendmany and z_sendmany). Should we add a note to the z_listaddresses method doc pointing to listaddresses as a method that can provide more information?
There was a problem hiding this comment.
Hm - I guess I misunderstood this convention; I thought that the z_<action> methods only existed when they superseded legacy methods, but it makes sense to me now that all the methods added by Zcash should be z_ prefixed. I wish that this comment had been made before it was released!
There was a problem hiding this comment.
Well, we'd have needed to merge it with z_listaddresses, or use a completely different name. Sorry for not spotting this earlier.
No description provided.