I frequently (well, sometimes) want to know the size of the nullifier set and commitment tree for a shielded pool. (I've used "spends" and "outputs" in the issue title because that terminology also makes sense for the transparent pool.)
This corresponds to https://github.com/zcash/zcash/issues/6751, which is unlikely to be implemented now that zcashd is being deprecated. It doesn't matter whether this info is made available via the RPC interface or another interface.
Describe the solution you'd like
For each pool in the "valuePools" array of the getblockchaininfo output, include:
"spends" (numeric) the total number of spends from this pool
"outputs" (numeric) the total number of outputs created in this pool
The top-level "commitments" field (I don't know whether zebrad ever had this field) could be deprecated since it will be identical to the "outputs" field for the Sprout pool.
Alternatives you've considered
This information could be given by a separate RPC, but there is an obvious place to put it in the getblockchaininfo output, and I think it is easy to calculate so should not slow down the RPC.
Specifications
No consensus change.
Complex Code or Requirements
No changes to complex code.
Testing
This can be tested relatively straightforwardly against regtest.
Motivation
I frequently (well, sometimes) want to know the size of the nullifier set and commitment tree for a shielded pool. (I've used "spends" and "outputs" in the issue title because that terminology also makes sense for the transparent pool.)
This corresponds to https://github.com/zcash/zcash/issues/6751, which is unlikely to be implemented now that zcashd is being deprecated. It doesn't matter whether this info is made available via the RPC interface or another interface.
Describe the solution you'd like
For each pool in the "valuePools" array of the
getblockchaininfooutput, include:The top-level "commitments" field (I don't know whether zebrad ever had this field) could be deprecated since it will be identical to the "outputs" field for the Sprout pool.
Alternatives you've considered
This information could be given by a separate RPC, but there is an obvious place to put it in the
getblockchaininfooutput, and I think it is easy to calculate so should not slow down the RPC.Specifications
No consensus change.
Complex Code or Requirements
No changes to complex code.
Testing
This can be tested relatively straightforwardly against regtest.
Related Work
https://github.com/zcash/zcash/issues/6751