I just noticed the addresses included in the Canopy upgrade for the testnet funding in ZIP 214 and included in Zcash 3.1.0 are going to a transparent address.
Is the plan for this to be the case come mainnet launch? What’s the rationale here and why not send them to a shielded address, as given they need to be updated, now seems a good a time as any?
I think transparent distribution lends itself positively to the radical funding model (meaning little to no precedence), even if its not required all of this funding is for the public and I think it reflects that stipulation better, The final recipients can then pass into the shielded pool like anyone else (thats my 2¢ anyways)
Right, but there are other ways of achieving this goal without incorporating transparent addresses.
On a related note it does say in ZIP 213:
Sapling outputs in coinbase transactions are by design publicly viewable
How/where can these be viewed as I can’t see this information from the coinbase transaction itself e.g. https://gist.github.com/garethtdavies/9c46dce5c142acdacc9497c48790c98e (from testnet)
Edit: found the answer, it is via a viewing key so this could be applied to the other funding streams:
Full Sapling note decryption MUST succeed using the all-zero outgoing viewing key. More precisely, all Sapling outputs in coinbase transactions MUST have valid note commitments when recovered using a sequence of 32 zero bytes as the outgoing viewing key.
I think its the gesture thats important here, were funding models like this a more common type of thing I don’t think that gesture would be so heavy idk (again, imho)
The mainnet addresses are probably going to be transparent. The reason is that the ECC ones need to be multisig addresses (as the Founders’ Reward addresses were), and shielded multisig isn’t implemented or audited yet. Note that it will be possible to update the addresses in a future (post-Canopy) network upgrade.
Thanks for the clarification. Also, do you know how to import that all-zero viewing key to zcashd as I assume it is encoded in some way?
The forcing function here is, like Daira said, that the Dev Fund addresses may need to be multisig, and shielded multisig isn’t mature enough. In addition to that, though, it seems more appropriate for Dev Fund coins to go to transparent addresses, since they are donations from the community to specific recipients. Of course, the recipients can always shield them later, like Autotunafish said, but by default I think it makes sense for them to be transparent.
This argument makes no sense to me. The community learns no more information about the dev fund outputs in either case:
The only additional information that is gained by using a transparent dev fund address is that anyone can see on-chain if the address is involved in non-dev-fund transactions. But given the aforementioned security requirements, I think it is highly unlikely that the dev fund addresses would be used for anything other than receiving dev fund outputs and shielding them. And revealing viewing keys for any shielded dev fund addresses would eliminate this difference.
I can see the concern about shielded multisig, its new cryptography. Assuming the software meets your needs, what are the criteria for when ECC would use Frost (ZFND’s shielded multisig)? Is it:
Publication + peer review for the protocol
Audit for an implementation.
Or is there more?
Oh! I hadn’t realized, or had forgotten, about this. This does indeed undermine the example use case I was imagining, which is that a Dev Fund recipient could publicly commit to a policy that they won’t shield their Dev Funds, except in certain cases, such as for example if they are transferring some of the Dev Funds to someone who needs privacy.
But as you say, if a Dev Fund recipient wanted to commit to such a policy, they could work around this “Dev Fund outputs must then be shielded” consensus rule by shielding and then deshielding, and publicly pointing to the newly taddr’ed coins as their Dev Funds.
Isn’t this what viewing keys are designed for? I don’t understand why t-addrs need to be involved in any way (other than the unmet shielded multisig requirement).
Yes, good idea. The same use case goals could be met with view keys. It would require a few improvements, though. One necessary improvement would be integrating view keys into block explorers, so that the same user flow that currently works for taddress would also work for view-keys-into-zaddresses.
That user flow is that you can post a link to a block explorer:
And everyone who clicks the link can see the public data:
To effect the same results with view keys, I think you’d need block explorers to accept and use view keys encoded into the URL itself.
Hm… and then, what if the recipient of this transfer wanted to publicly disclose the next hop, i.e. to be transparent about what they did with the money. With the current taddress-based user flow, you can click on that link on the explorer, and it takes you to here:
Which shows that they have not moved their 100 ZEC. How could the recipient achieve a similar kind of transparency using view keys? I’m sure it is possible, but I wonder if it requires extending the consensus protocol to let users post their view keys to the public on the blockchain, or something.
This recent discussion is a beautiful example of how eating our own dogfood brings up important use-cases and their requirements (in protocol, educational and ecosystem support). Maturity of shielded multisig using FROST, explorers’ viewing key support, semantics of viewing keys, hallelujah!
Perhaps this is the strongest argument in favor of shielded funding. 
Policy making should strive to be as transparent as possible and as close to open source data and not open source information as possible
To resolve this thread, v4.0.0 has been released, all funding addresses (ECC, ZF and MG) are to multisig transparent addresses zcash/chainparams.cpp at master · zcash/zcash · GitHub 
As a reminder, the output addresses for future funding periods (which are approximately monthly; there are 48 periods in the ZIP 214 dev fund streams) can be altered (with confirmation of the new addresses by the intended recipient) in any subsequent network upgrade. This is both necessary to support recovery from key compromise (e.g. if spend authority for either ZF or MGRC’s single address were compromised), and enables a funding stream recipient to choose to switch to shielded addresses later on (once the above shielded multisig issue is resolved), or split their funding stream into smaller substreams (e.g. direct recipients of MGRC grants).
In addition to technical requirements there may be operational and organizational requirements that apply to Dev Fund recipients which they may not have control over. I think the simplest success criteria is if licensed custodians provide commercial support.
I would define a “shielded Dev Fund product” success as follows:
I would definitely like to get Zcash there, because the benefit extends well beyond only DF recipients, although that’s a crucial dogfood case.
