No way to list all t-addresses in wallet (zcashd)

[adityapk00]

Describe the issue

Since deprecating getaddressessbyaccount RPC in v4.5.0, there now seems to be no way to get the list of all t-addresses belonging to the wallet.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Call getnewaddress RPC to generate a new T-address. The generated t-address is returned in the response
2. No other RPC now returns this address again

Expected behaviour

There should be a way to list all the wallet's t-addresses that have been generated, similar to what z_listaddresses does.

Note: There is a listaddressgroupings RPC, but that only returns the first t-address.

The version of Zcash you were using:

v4.5.1

Any extra information that might be useful in the debugging process.

This is needed for full node wallets like Zecwallet Fullnode, which need a list of all the wallet's t-addresses.

ZcashFoundation/zecwallet#327

[str4d]

Gah, this is annoying.

Tracking and listing individual transparent addresses is not something that the wallet inside zcashd (or Bitcoin Core for that matter, which we inherit our transparent behaviour from) is designed for; the transparent spending keys (and thus addresses) are all treated as a single "bucket" of funds. The only time you are supposed to care about an individual transparent address is when you have an unspent coin in it; once the coin is spent, the address is not meant to be used again. This is intended to prevent address reuse, but that doesn't actually provide the privacy claimed by upstream (because address clustering is a well-understood wallet tracking mechanism).

I much prefer our shielded behaviour where we treat each spending key as a separate bucket (because address reuse doesn't matter, due to addresses not appearing on chain), but there's a continual mismatch between that and the transparent RPCs.

How are you using / presenting this information in ZecWallet? If we need to introduce a replacement API, we should try and get the semantics right.

[POLANOS]

There must be a way (RPC command) to list all generated wallet t-addresses. Moreover, for the Zecwallet Fullnode wallet, a mechanism should also be implemented to show the balance of funds on the balances of these addresses and the total balance.

[POLANOS]

Could you implement the RCP command - importprivkey "zcashprivkey" ("label" rescan) - using load balancing across all cores and CPU threads?

[laakie]

We really need to list out t addresses as well.
listaddressgroupings takes forever as it returns back every change address ever used as well.

Please fix this.

[wbaby]

Pls fix this annoying problem.

[adityapk00]

From a wishlist perspective, what Zecwallet would like is:

1. An RPC called listaddresses
2. Return a JSON array, with a list of Objects
3. Each Object is {address: <taddress>, path: <bip32 derivation path for this t-address>}

This way, Zecwallet can differentiate generated addresses and change addresses, and display them appropriately.

[str4d]

@adityapk00 that sounds pretty close to what we proposed last week: #5328. Let's discuss the requirements over there.

[str4d]

(Also, note that t-addrs do not currently have BIP 32 derivation paths. This is something we will be changing as part of introducing Unified Addresses though.)

[str4d]

As far as this issue goes: t-address information is still accessible, but not currently as easily (it's visible via e.g. listreceivedbyaddress and listaddressgroupings). If you were using getaddressessbyaccount specifically, please add a comment to this issue letting us know how you were using it, and what you were using it for. And if you need it in the short term, I recommend running zcashd v4.4.1 by compiling it yourself with an altered deprecation height (in src/deprecation.h). (There were no changes in v4.5.0 or v4.5.1 that are required for mainnet).

@adityapk00 could you answer my question from above?

How are you using / presenting this information in ZecWallet?

[adityapk00]

How are you using / presenting this information in ZecWallet?

Zecwallet doesn't store any wallet data (i.e., it gets all data needed to render the UI from zcashd).
At startup, Zecwallet will query the list of addresses (z-addresses and t-addresses) and list them on the "Receive" screen.
When users create new addresses, Zecwallet assumes the newly created addresses are query-able, so when the UI is refreshed, it fetches the list of t-addresses, expecting the newly created T-address to be present in the list.

With v4.5.0, the new address is not present in the list of t-addresses fetched from zcashd, so it doesn't show the new t-address. Users think they cannot create new t-addresses, which is what causes the "bug".

Note that the workarounds don't work for Zecwallet, because this is a new T-address, so it won't show up in listreceivedbyaddress (No transactions to this t-address yet) or listaddressgroupings.

[POLANOS]

Hello. Zecwallet Fullnode wallet does not display known t-addresses in the "Receive" section. At the same time, z-addresses are displayed correctly. Please fix.

[fireice-uk]

@str4d @steven-ecc Please note that we have multiple support requests per day about this in Zcash social channels. A bugfix patch and release would be useful.

[r3ld3v]

We've prioritized #5343 and are looking at producing a hotfix release in the next couple of days once we've gotten feedback on the replacement API.