We’re hosting an end of the year AMA with the core developers this Thursday, December 22nd at 12:00 PST/15:00 EST/20:00 UTC. Devs will be online taking questions for 2 hours.
This will be the thread which the developers will be taking and responding to your questions - please keep questions focused on technical topics. If there is enough demand, we can do another AMA at a later date with a broader scope.
This thread will stay closed until 30 minutes or so before AMA starts at which point y’all can start posting questions.
We hope you can join us!
Edit: This AMA is now over. Thanks to all who participated! We hope to do this again in the coming months so keep an eye out for that announcement. If you want to continue discussion on any of the questions raised by the community or answers given by the team, please use the discourse function to reply as a linked topic ← click on link icon in particular post and select “New Topic”.
Not so much about Zcash, but for anon tech in general. What do you think about Navtech from nav coin, the double blockchain anon system? Have you, or will you review the source code?
It’s great to have different players in the anon crypto world and I hope they can together make financial privacy available for everyone.
There has been some evidence that CPU botnets are mining Zcash (Zooko posted a response to allegations to that effect on Twitter).
Is there any sense that moving forward with planned changes to the Equihash parameters may discourage the use of CPU botnets? And, has a change to the Equihash parameters been planned?
Are there plans to move to use CMake? I saw https://github.com/scipr-lab/libsnark/tree/cmake, but it looks like gone a bit stale. CMake would help having a Windows port and facilitate contributions from mainly Windows platform programmers.
Zcash joinsplit verification, while much faster than joinsplit creation, is relatively slow. Are you concerned that an attacker may prepare a large number of joinsplits and begin spamming the network with them to cause problems? Has the feasibility (or lack thereof) of such an attack been investigated?
I am not familiar with Navtech / nav coin, and we have no plans to review it currently. For this AMA our intent is to focus on Zcash or the technology behind it rather than other cryptocurrencies. Bitcoin is one obvious exception because we based much of our design on Bitcoin’s design.
As almost any number can function as a private key, is it reasonable to think there would be an (almost?) equal number of public keys for a particular key size?
If the number of possible public keys is as great as or at least approaches that of private keys, and, in light of how undesirable it is for the signing ceremony private key data to still exist, couldn’t a random number be used as a public key instead of having to first derive it from a private key?
If you’re given a number that is supposed to be treated as a public key, are there any provable ways to test that assertion?
I do believe we’ll switch to using CMake with libsnark, but I’m not sure when. Howard Wu has done a great job with that branch and most of the future libsnark work will be built on it.
Do ztransactions work now? Also, I have some questions about them:
They require the ZCash params, but how much memory do they require besides that?
Is there a link to the code that happens to be the most resource-intensive?
I’m just starting with blockchains and read about https://github.com/scipr-lab/libsnark/tree/cmake, which is very a very interesting one. That’s something I’ve been actually thinking myself and then if it were possible (that blog post answered my question), but is there a code sample somewhere?
Say someone is contemplating a startup, is there an established or preferred mechanism to validate ideas or poke minds with ideas or is it more or less asking around in the chat and forums?
I’m going to do my best to articulate the question I want to ask, terminology slips my tongue from time to time, newer to mining cryptocurrencies altogether.
I have seen discussions on several forums that concerned me, so I wanted to hear directly from you guys.
Question: Are there discussions on changing the ZEC algorithm in the near future that would adversely affect GPU mining? I am currently considering investing a lot of money into GPU rigs.
As almost any number can function as a private key, is it reasonable to think there would be an (almost?) equal number of public keys for a particular key size?
The public parameters for zk-SNARKs (which I believe you’re referring to) consist of millions of numbers with various unnatural algebraic relationships. The only known way to sample parameters of this form is to construct them manually.
It isn’t botnet, it’s a trojan. Kaspersky reported that they found a few (about 1000) instances of a Zcash miner running on their users’ computers, named after some other unrelated software, i.e. it was named minecraft.exe or whatever. I think they speculated that it was uploaded to a Torrent site in order to trick people into downloading it. So, that’s not a botnet.
Now, we have already been thinking of doing a backward-incompatible (“hard fork”) upgrade to (among other improvements) change the Equihash parameters from 200,9 to 144,5. Or we could possibly choose other parameters that would be better in light of what we’ve learned about Equihash implementation in the past couple of months. 200,9 takes about 140 MB of RAM, and 144,5 would take at least 500 MB of RAM.
What effect, if any, that would have on possible future botnets, I’m not sure. Since there aren’t any botnet implementations of Zcash mining yet, we can’t learn anything from studying them.
Switching to the 144,5 params would also reduce the size of Equihash solutions from 1344 bytes to 100 bytes, which has several benefits, including making it faster and cheaper to verify the Zcash blockchain inside the Ethereum virtual machine (for “Project Alchemy”).
We have been concerned about verification cost and considered it during security reviews, and did various calculations about DOS vulnerability given the current block size parameters. It’s worth noting that Bitcoin txn verification (at least without segwit) is superlinear in the number of inputs when SIGHASH_ALL is used, whereas JoinSplit verification is always (a large) constant. So in some respect JoinSplits verification scales well as block size increases.
We have several options to improve verification costs directly which others can describe.
