We’re hosting an AMA with the Zcash Company team Friday, June 15th at 12:00 PST/15:00 EST/19:00 UTC. The team will be online taking questions for 2 hours.
This will be the thread which we will be taking and responding to your questions - please keep questions focused on technical topics related to Zcash.
What are the technical barriers to being able to conduct straw polls weighted by amount of ZEC holdings?
For example, conducting a straw poll amongst ZEC holders regarding whether to change the Equihash parameters, with the result being, “ZEC users holding a combined X number of coins favor changing the parameters.” The straw poll would have to be fair (no way to vote multiple times with the same coins).
The voter registration part is the catch for most of those propositions
Edit - it could be done assuming you were doing something like gdpr information controller stipulations, idk
Thanks for doing this again. Regarding Sapling activation from an end-user perspective… what will be the process of moving between Sprout and Sapling addresses? Can you also talk a little more about the planned auditing that will occur as a result of moving between circuits?
And another Sapling one Regarding delegated proving and the new “Proof authorizing key” as in the Sapling spec:
In this case privacy will be lost to that party since it needs the proof authorizing key. This allows deriving the ak and nk components of the full viewing key , which are sufficient to recognize spent notes and to recognize and decrypt incoming notes.
What is your expectation of this being used in say a hardware device with regards to maintaining privacy?
Could you speak to the current plans for the deprecation of transparent addresses? Once Sapling is in place, how aggressive will be the push from Zcash Co. to eliminate their use? Thanks in advance.
Clarification: Sprout is zcashd 1.0.x, Overwinter is 1.1.x and Sapling is 2.0.x
The while these network upgrades are technically hard forks, there’s no sign of contention and an expectation for only 1 chain to persist. There is EOS halt functionality, a long testing period before hand for nodes and third-parties to take time with the upgrade and we have an ecosystem team who are diligently working with various third-parties to make sure everyone is on board.
For more info on the network upgrades and their expected outcome, this blog introducing Overwinter (aka Network Upgrade 0) is helpful: Overwinter - Electric Coin Company
Edit: clarifying that EOS halt is “end-of-support halt” meaning, the user will be required to update to continue running.
The release schedule is also a good resource here: Schedule - Zcash
Any movement of funds from Sprout to Sapling, or vice versa, has to go through the transparent value pool. As far as the protocol is concerned it doesn’t necessarily need to go via a transparent address, but the value must be revealed. This is to support the “turnstile” approach to auditing whether there has been any overall inflation of the monetary base due to protocol flaws - #2248. The user interface to this hasn’t been settled yet because we haven’t implemented the necessary RPC call - #3268. It may involve a separate script that performs the transfer over an extended period to improve privacy.
For future upgrades there might be a way to do monetary base auditing without revealing amounts publically - #2373 - but there are some unsolved technical problems there.
Would it be possible for the foundation to hire external resources for a specific chosen idea beside waiting for the right candidate and idea?
I like some of the grant ideas proposals such as Paynent integration in wechat or whatsapp (if I remember well). Why not having these ideas being voted and ask for a quote from external company to do the work? What about freelance platform such as upwork for example ?
Thanks and as a (hopefully) quick follow up to that, will Sprout transactions be supported following Sapling activation or will it be a case of you must move your shielded funds to Sapling before sending? If Sprout transactions will be allowed how and when will these be phased out?
No strategy for deprecation of transparent address, yet. It’s worth discussing now, though. Maybe we should have a new ticket for this (since I can’t seem to find one). Want to make one??
It shouldn’t be too hard, but requires some thought and a hard fork if done on chain. You need some flag to signal that this tx is just a vote and not a real spend, and this flag needs to be baked in deep enough to not allow replays with real zec spending, and ideally, not compromise privacy when the zec used to vote is really spent.
One way seems to have a public random string related to the vote issue, and bake this string into the nullifier computation. #2321 mentioned above is in a different context than stake voting, and doesn’t address the privacy/replay issues I think.
Very special questions.
What is a current status of RnD for zk-smart contracts?
When usersmay expect addition of an execution layerfor Zcash and implementation of zk-executions ?