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:
- Dev fund outputs to shielded addresses are required by the consensus rules to be decryptable (in order to verify the dev fund amounts), and thus the output recipient and value (and memo, if the miner chooses to set it) is visible on-chain. Block explorers that haven’t added support for viewing shielded coinbase outputs wouldn’t show the shielded outputs, but that’s a UI issue, not a data availability issue.
- Dev fund outputs to transparent addresses are required by the consensus rules to be shielded, so no one inspecting the chain directly learns where those funds subsequently go. (They might learn indirectly if the funds are shielded and then unshielded, but they would learn the exact same thing for outputs to shielded dev fund addresses, assuming the same recipient behaviour of eventually unshielding the funds).
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