change(rpc): Ensure mining pools will accept responses to `getblocksubsidy`

[upbqdn]

The response of getblocksubsidy contains an array, named fundingstreams, where each object contains a pair named address. If the community chooses the lockbox as a funding stream, there will be no real address to use in that field. We can either:

1. skip the serialization of that pair,
2. set its value to the empty string, or
3. use a dummy address.

In any case, we should make sure mining pools will accept the responses.

[daira]

I propose the following:

• Omit lockbox funding streams from the "fundingstreams" array.
• Add a "fundinglockboxes" array, in which each entry has the same fields as a "fundingstreams" entry except for "address".
• Add a top-level "total_required_outputs" field that is the sum of all consensus-required non-miner outputs. This is by definition equal to the block subsidy minus the allowed miner subsidy, and as of NU6 should be the sum of the values in "founders", "fundingstreams[i].value", and "fundinglockboxes[i].value".

Rationale:

• There is no possibility that a client crashes when trying to read an "address" field that is not there or that it cannot decode, or misinterprets a funding lockbox as though it were actually sending to the dummy address.
• The output contains all necessary information about the block subsidy for clients that can understand it.
• The "total_required_outputs" field provides clients of this API with useful information that they could only otherwise calculate by knowing about all funding mechanisms and how they are represented in the JSON output. This improves forward compatibility of the API.

[nuttycom]

@daira I named the array lockboxstreams in https://github.com/zcash/zcash/pull/6912/files#diff-ccc24453c13307f815879738d3bf00eec351417537fbf10dde1468180cacd2f1. The suggestion of the top-level total is a good one.

[nuttycom]

I don't think that total_required_outputs is a good name though, because the lockbox value explicitly doesn't correspond to a transaction output, which could be confusing. It's more like total_non_miner_block_subsidy or something.

[oxarbitrage]

I like the proposal. we need to decide if we should keep returning the fundingstreams array after Nu6 and if we do, with what inside (empty or some sort of dummy addresses with 0 as value)

[oxarbitrage]

For reference, here are a few samples we have of getblocksubsidy outputs we did in the past for zebrad at different heights (which should be the same as zcashd):

• https://github.com/ZcashFoundation/zebra/blob/main/zebra-rpc/src/methods/tests/snapshot/snapshots/get_block_subsidy_excessive_height%40mainnet_10.snap (this is what will happen if we do nothing after the block subsidy expires).
• https://github.com/ZcashFoundation/zebra/blob/main/zebra-rpc/src/methods/tests/snapshot/snapshots/get_block_subsidy_future_height%40mainnet_10.snap (this is happening until the dev fund is over)
• https://github.com/ZcashFoundation/zebra/blob/main/zebra-rpc/src/methods/tests/snapshot/snapshots/get_block_subsidy_tip_height%40mainnet_10.snap (this is what happens at a fake tip, which is actually for that output nu5 tip)

The work in progress proposal for the format after Nu6 is the following (feel free to edit):

{
  "fundingstreams": [],
  "lockboxstreams": [
    {
      "recipient": "Funding LockBox 1",
      "specification": "https://zips.z.cash/draft-nuttycom-funding-allocation",
      "value": 0.21875,
      "valueZat": 21875000,
    }
  ],
  "miner": 2.5,
  "founders": 0.0,
  "lockboxtotal":0.0,
  "fundingstreamstotal": 0.0,
  "totalblocksubsidy": 0.0,
}

[upbqdn]

One thing I didn't mention in the PR description is that the consumers of the RPC might have hardcoded expectations regarding the response content.

I noticed this with https://github.com/nighthawk-apps/zcash-explorer, which was expecting both result and error in RPC responses because zcashd returns such responses. Zebra returns either result or error, which corresponds to the JSON-RPC spec (https://github.com/ZcashFoundation/zebra/issues/8672#issuecomment-2229018550), and the block explorer couldn't parse Zebra's responses. It occurred to me that a similar issue might happen here with mining pools if we changed the response format.

[nuttycom]

I think that instead of total_required_outputs, we should have a totalblocksubsidy (no underscores, for consistency with the rest of the API) such that totalblocksubsidy = miner + founders + Σ fundingstreams.value + Σ lockboxstreams.value

[oxarbitrage]

I think that instead of total_required_outputs, we should have a totalblocksubsidy (no underscores, for consistency with the rest of the API) such that totalblocksubsidy = miner + founders + Σ fundingstreams.value + Σ lockboxstreams.value

Ok, i changed that in the proposed output in https://github.com/ZcashFoundation/zebra/issues/8702#issuecomment-2248773668

[nuttycom]

A couple more additions, for completeness:

+            "  \"fundingstreamstotal\" : x.xxx, (numeric) The total value of direct funding streams in " + CURRENCY_UNIT + ".\n"
+            "  \"lockboxtotal\" : x.xxx,        (numeric) The total value sent to development funding lockboxes in " + CURRENCY_UNIT + ".\n"
+            "  \"totalblocksubsidy\" : x.xxx,   (numeric) The total value of the block subsidy in " + CURRENCY_UNIT + ".\n"

[daira]

"totalblocksubsidy" makes sense to me in place of "total_required_outputs" (which I agree is badly named), because you can always compute totalblocksubsidy - miner if you want the total amount directed to other places by consensus.