Open letter to Justin Ehrenhofer et al


Dear Justin:

Regarding “zooko, I respectfully think its misleading to say Zcash users’ funds are safe and no action is needed without further explanation. If users hold Sprout right now, their funds may be at risk. They should move their money ASAP using turnstile tool guide.”

Thank you so much for working on this! You, James Prestwich, Greg Slepak, and others have raised a lot of good objections or criticisms about this.

I wrote in this tweet “Q: Is my money safe? A: Here are two facts…”. This is being quite reasonably interpreted as “Q: Is my money safe? A: Yes! Here are two facts…” but I meant it more like “Q: Is my money safe? A: We don’t know! Nothing in life is safe. Zcash isn’t safe. Bitcoin isn’t safe. Dollars in your bank account are not safe. But here are two facts: we have seen no evidence that the issue was exploited before it was fixed. However, even if it was—or in case of any other such problem in the Sprout pool—this will not inflate the monetary base because of turnstiling.”.

Now beyond the facts there are also recommendations. Our expert recommendation is that no action is needed by users to mitigate this issue. Other experts could make different recommendations.

Of course, we could turn out to be wrong! We’re not omniscient—we’re just experts. If people want to move their money out of the Sprout pool out of an abundance of caution, that’s fine. The only reasons not to are the ever-present risk that you’ll get your money stolen or accidentally deleted when trying to move it (so be careful and don’t rush), and the fact that moving money out of the Sprout pool exposes the exact amount, which could compromise your privacy, depending on your situation.

I’d like to emphasize that it is a super valuable public service to all Zcashers for people like you to scrutinize these issues and provide your own recommendations. It’s wonderful that Zcashers are not solely dependent on the Zerocoin Electric Coin Company for analysis and recommendations. This is an important part of protecting and extending the larger Zcash community.

Thank you so much! :heart:


I appreciate the response, but the statement from your company says (in bold):

"The counterfeiting vulnerability has been fully remediated in Zcash and no action is required by Zcash users."

I argue this is still misleading without sharing the important context that funds may be locked. While this is documented elsewhere, I feel the takeaways from the post would have changed significantly if this context were included in the disclosure blog post. Furthermore, while the company’s opinion may be that the vulnerability is remediated, the sentence seemingly makes an unprovable factual statement.

I argue that the Zcash Company’s concern for users is too limited. Sure, most users care about preventing inflation. However, I feel there are some users in the Sprout pool that the company has mostly omitted from its expert opinion. The blog post did not clearly indicate the freeze risk to users of the Sprout pool; it merely touched on the possible inflation issue.

Finally, I argue that since the Zcash Company would make the decision on the frozen funds issue, that it clarifies exactly what sort of actions would be taken. The community would benefit from further clarification on the conditions and consequences of a pool freeze. I believe that if this is more clearly communicated in context of the vulnerability at hand, then users will have a much better understanding of the best decisions they should make.


I believe that as with all software releases from Zcash Company, if they did decide to release a core update freezing the funds in a pool it would still be up to the Community (ie: nodes and miners) to adopt the change since it would require a hard fork? (correct me if I’m wrong on this @daira or @str4d )


This is correct. The Zcash Company may make a decision, and some other faction may decide to ignore this decision and fork away. Nevertheless, it would be useful to have a clearer “if… then” process.



(post must be 20 characters)

To exploit the counterfeiting vulnerability, an attacker would have needed to possess information found in the large MPC protocol transcript that was made available shortly after the launch of Zcash. This transcript had not been widely downloaded and was removed from public availability immediately upon discovery of the vulnerability to make it more difficult to exploit. The Zcash Company adopted and maintained a cover story that the transcript was missing due to accidental deletion. The transcript was later reconstructed from DVDs collected from the participants of the original ceremony and posted following the Sapling activation.

wtf? how do you know those dvd’s are the originals? and I thought you were all meant to destroy them.

So the ceremony can be recreated. So it was just a fine piece of performance art and “security theatre”

please tell and explain how I am wrong? I really want to be wrong.

As a side incidental, I haven’t looked into the full technical details, or recreated the exploit yet. the blog post is my only source I have used for info.

Okay so the bug might have been exceptionally esoteric (so what? that sounds like sloping shoulders). Just because of that it doesn’t stop your handling of it and your “critital vuln system” to be backward. For example why has it taken a year to disclose? you say it was fixed in sapling. why wasn’t it documented then? It is shit like this that makes me want regulation of crypto.

Please could you direct me to your bug bounty program and legal requirements.




@mistfpga You are mixing up a few things here.

  1. The transcripts (dvd’s) are a record of the ceremony for verification that it was performed correctly. It can’t be used to recreate the “randomness” that the participants added to the ceremony and destroyed. And alone can’t be used to forge currency.

  2. The ceremony had nothing to do with this bug. The bug was in one of the underlying parameters that zkSNARKs are built on. They took down the transcripts because having the transcript + knowledge of the zkSNARK discrepancy would have created and opportunity for an attacker to create false zkSNARK proofs.

Everything along with a detailed timeline of what happened is in the blog post, I suggest reading it closely before jumping to further conclusions.


Hi Shawn,

thank you for that further explanation. I have read the blog post it is all I had read at that time (and still is, I haven’t followed all the links yet. Also I was very tired when I posted. (no excuse

Im glad I was wrong, for some reason I thought it was part of the “toxic waste”. It was certainly the reading it closely I was having issues with. heh

I need to look into this further, but the action and goal are not related.

to me this is worrying.

Those were the parts I was trying to draw attention too. anyway I am not making any judgements and I apologise for coming across wrong and a bit stupid. Again thanks for the clarification.


A parameter that was picked at part of the ceremony. A parameter which should actually have been considered part of the toxic waste. But which due to a design bug was considered a protocol parameter.


Yes, it was generated during the ceremony. But that was due to the ceremony implementation closely following the ZKP protocol from the paper, not due to anything about the ceremony itself. Even in systems with no ceremony (like Bulletproofs), this kind of bug is possible.