[Feedback Request] Zcashd node to be deprecated in Q2 2025

[pacu]

As you might already be aware, Zcashd is scheduled to be retired in April 2025 [1]. Zcash Engineers (ECC, Zcash Foundation and ZCG grantees) are working on a new software stack that will be based on the new Zebra [2] consensus node that will replace the existing Zcashd node and wallet functionality [3]. This is a huge overhaul of the existing software that drives the ecosystem and we need to hear your voice!

We want to ensure that the needs of existing zcashd users are met by the new stack, so we're reaching out to you now to get feedback on what zcashd functionality you rely on, so we can incorporate that feedback as we build out the new stack and work towards zcashd deprecation.

Action Items:

• Please tell us which node you are currently running (Zcashd, Zebra or both)
• The main purpose you use the node for (network security, wallet, block explorer backend, etc)
• Operating System you run the node with
• [Important] Survey of the existing RPC Methods you currently use. For each RPC method detail:
  • Name of the RPC
  • A brief sentence with the Purpose, requirement or functionality that you use it for
  • Detail optional parameters that you might be setting for each RPC (if applicable).
• [optional] Feedback on Feature Requests:
  • Is there functionality that Zcashd provides that falls short to meet your requirements? How could it be improved?
  • Is there functionality that you need or that you’d like to have that is not present in Zcashd?

Thank you for your time and for supporting Zcash.

Best regards,

@mpguerra - Zcash Foundation, @decentralistdan - Electric Coin Company, @pacu - Zcash Community Grants Developer Relations.

References:
[1] ​​https://electriccoin.co/blog/ecc-roadmap-july-2024/
[2] https://github.com/zcashfoundation/zebra
[3] https://github.com/zcash/librustzcash/issues/1373#issuecomment-2373552815

[pacu]

Hi Folks! have you been able to take a look at this?

[buck54321]

Please tell us which node you are currently running (Zcashd, Zebra or both)

We use the zcashd JSON-RPC interface.

The main purpose you use the node for (network security, wallet, block explorer backend, etc)

We offer Zcash as a wallet in our multi-wallet GUI. Users can trade Zcash using the built-in DEX functionality. We support shielded pools for Zcash, but trading occurs using transparent atomic swaps.

Our DEX server operators use zcashd as a backend for validating funds and swap txs as part of our trading protocol and reputation system.

Operating System you run the node with

Users have to run a full node (for now), so are presumably using some flavor of Debian. DEX server operators have run zcashd on both Debian and Arch.

[Important] Survey of the existing RPC Methods you currently use. For each RPC method detail:

• Name of the RPC
• A brief sentence with the Purpose, requirement or functionality that you use it for
• Detail optional parameters that you might be setting for each RPC (if applicable).

• getrawtransaction: For retrieving raw tx bytes. We decode them into a Go tx type. We use this primarily for pulling out sigscripts in some critical paths in atomic swap negotiation.
• gettransaction: We use this instead of getrawtransaction primarily when we need to know the block hash of the block that includes the transaction. usually to check transaction confirmations.
• dumpprivkey: Used to sign inputs in our atomic swap redemption and refund transactions.
• signrawtransaction: Used to sign some swap-related transactions.
• sendrawtransaction: Used to send some swap-related transactions.
• lockunspent: Our trading protocol locks funds for standing DEX orders.
• listlockunspent: View locked outputs.
• gettxout: Used when looking at counterparty transaction outputs as part of the atomic swap process. We use the optional includemempool parameter.
• getnetworkinfo: Enforce zcashd minimum version
• getblockchaininfo: Used to check chain sync status and to ensure the network (mainnet/testnet/regtest) is correct.
• getbestblockhash: We hit this endpoint regularly to check for new blocks.
• getblockheader: We use this when we need to know the time or height/confirmations of a transaction's block. We use this in critical atomic swap code to determine the median block time, since the RPC doesn't offer that info (see zcash#6005). We use the optional verbose parameter both true and false.
• gettransaction: We use this to view wallet transactions in many many contexts.
• getbalance: We actually only use this in one place for a very specific purpose. If this value does not match the transparent value returned as part of z_getbalanceforaccount, we know that the user has some funds in the "legacy" account (non-hierarchical/no account number), which is problematic for a number of reasons. We use the optional inZats parameter to get the values in zats.
• getnetworkinfo: Used to check peer count. We won't take certain actions if we have no peers.
• getblock: Used in recovery paths when the swap counterparty fails to communicate their redemption details. Critical function. We set the optional verbosity to false because we deserialize the block ourselves into a Go type.
• getblockhash: Used in some synchronization logic.
• getrawmempool: Used when searching for unreported counterparty redemptions. Could probably live without it.
• listsinceblock: We maintain a parallel database of all wallet txs with metadata for various purposes including UI display.
• getwalletinfo: We use the mnemonic_seedfp field from this result to detect if the remote zcashd node has changed between startups, so we can use the correct tx history/database.
• z_getaddressforaccount: Generate new unified addresses.
• z_listunifiedreceivers: As part of our UI, the user can display the receivers of unified addresses. This is important esp. if the user must have a transparent address.
• z_listaccounts: Used to ensure proper account structure.
• z_getnewaccount: Users can run our wallet against a fresh zcashd node and we'll create the proper account structure.
• z_getbalanceforaccount: Retrieve account balances. We use the optional minconf parameter to sus out "immature" orchard funds, since orchard requires >= 1 confirmation to spend.
• z_sendmany: Used for sending funds to shielded addresses, or to mixed shielded/transparent addresses which we do for "split txs" as part of our swap order funding protocol.
• z_validateaddress: Used to validate addresses in many contexts.
• z_getoperationresult: Get the results of z_sendmany.
• z_getnotescount: We use this in a couple of places in order to try to estimate the maximum fees (we're ZIP-317 compliant) that a tx might incur.
• z_listunspent: We use this in some tx fee estimation logic and some validation logic during sends to shielded addresses.

[optional] Feedback on Feature Requests:

• Is there functionality that Zcashd provides that falls short to meet your requirements? How could it be improved?
• Is there functionality that you need or that you’d like to have that is not present in Zcashd?

I'll take this opportunity to respectfully offer some constructive complaints:

Estimating the number of nActionsOrchard required for ZIP-317 tx fees is seemingly impossible, so we have to use some shaky logic to get fee estimations for the user.

The way the fromaddress parameter works in the z_sendmany RPC is odd and causes us to have to do some dancing. It would be great if we could just specify an account number, since that's almost what it reduces to internally anyway.

As mentioned above, block median time is a critical component of script logic for HTLCs, but the RPC doesn't provide it anywhere, so we have to constantly iterate block headers and calculate it on the fly. I would have loved to see https://github.com/zcash/zcash/pull/6005 or similar implemented, but there's probably no point now.

The RPC is, somewhat understandably, a little discombobulated as a result of its historical development, esp. in regards to the implementation of accounts and ZIP-317. I look forward to seeing some of these oddities ironed out in whatever interface we migrate to.