Open letter to Justin Ehrenhofer et al

#1

Dear Justin:

Regarding https://twitter.com/JEhrenhofer/status/1094037151694630912: “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:

7 Likes
#2

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.

1 Like
#3

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 )

#4

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.

1 Like
#5

Agree

(post must be 20 characters)

#6
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 z.cash 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.

thanks,

steve

#7

@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.

1 Like
#8

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.

#9

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.

1 Like
#10

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.

2 Likes
#11

Hi,

Sorry to necro an old thread but I feel that enough time has passed now that this question will not be so inflammatory.

Did this bug and the reaction to it have any impact on the teams ability to react to a potential proof of work change. Making the ASIC issue a non solvable problem because this had to be fixed not allowing for any changes to the protocol due to time constraints. The dates seem to line up a bit too well.

The blog goes to great length to say how this was hidden from engineers so it would explain a lot about the reaction of zooko (who knew about the bug) and the engineers (who didn’t) on this forum.

idk this is just my thinking. I have been wondering this since the timeline was posted. im not trying to start a conspiracy.

edit: forgot to add

cheers.

1 Like
#12

The harmony mining thread is still open, at the time it could not be resolved to how to go about doing such a thing without it being detrimental to the current security level of the network
Very few people discussing the subject knew about the bug so I doubt it had much effect at all

#13

Thanks for the reply,

iirc that was after the timeline I am talking about. the decision would have been made around march 1st. only a couple of weeks after bitcartels now infamous thread.

Here is the timeline:

So on the first of March 2018 they had to make a decision. From what they have stated they had two options.

Option 1

Option 2 is the one they went with which was the idea that it should be covertly fixed in sapling. (quoted in my post above)

At the time, the engineering staff like daira, str4d, etc did not know about this issue. There was an obvious conflict between the engineers and zooko over the asic issue with them stating on occasion that they did not understand his stance. A lot of people couldn’t work it out either. However it makes a lot more sense to me when the vuln timeline was put out there. especially the “sapling at all costs” rhetoric.

Like I said before tho this is starting to get into conspiracy territory - Im not saying there was any malintent, I am genuinely curious if this vuln had anything to do with zookos stance on not changing the PoW. its not bad if it did, its not bad if it didn’t.

4 people knew about the bug, Nathan, Zooko, Ariel and Sean. Once option two was selected you cannot back track and do option one. you have to pick an option and see it through. I would be very interested to know if they had gone for option one, would they have also changed the parameters to fork off asics after that became a hot button issue a few weeks later when ASICs went from being rumored to being real. Zooko didnt post until April in that ASIC thread so idk.

Obviously Option 1 delays sapling. but I dont remeber “sapling at all costs” until well after 1st of march. At which point it had to be sapling at all costs or we dont fix this vuln.

#14

FWIW - I think thats exactly what happened and I think it was exactly the right decision - the inflation vuln was far more important to fix than the rise of ASICs.

2 Likes
#15

I don’t really follow, if you’re suggesting company resources were allocated to fix the vulnerability that might have worked on a proof of work shift then I think that was probably the better decision (see Chile Bob agrees)

1 Like
#16

That is kind of what I am suggesting.

Although it is more that they decided that the fix would be silently integrated into sapling, on the 1st.

Once they made the decision to fix in sapling they couldn’t react to the asic issue in any other way except to try and make the best of it. To me, if this is the case, it puts the project in a whole new light for me, giving quite a bit of credibility back to zooko and Nathan.

Personally I would have gone with Ariels suggestion but I am not privy to the internal workings so I am speculating on what would have been best. But with hindsight if they had gone with that they could have changed the parameters like they wanted to anyway and they would have forked off asics, as a side effect.

I don’t know if they would have done this, but it could have been done in the same cycle. although this would have delayed sapling, but this might not have been so important because the bug would have been fixed anyway. But then you have the problem of has any zec been faked already, so maybe turnstyling was a needed part of the fix (to catch any counterfeit zec) and that had to have sapling. idk. like I said I saw the timeline months ago and have wondered ever since. :slight_smile:

It just completely changes what happened in my eyes, and I think the war has calmed enough to be able to talk about this again.

#17

I don’t think changing mining parameters is such a big deal like everyone thinks it is. Changing it would take them less than two weeks at max. And we would have much bigger community that supports coin now. But what is done is done.

1 Like
#18

If memory serves they realised Sapling killed the vuln without anything else having to be done, all they had to do was keep the information contained and the team focused on what they were already doing (Sapling).

I would’ve done the same thing - it killed my mining ‘hobby farm’ but some things are more important.

1 Like
#19

This Github thread adds context as I believe it was started after the vulnerability was found https://github.com/zcash/zcash/issues/3071. It was decided to use the new proving system for Sprout notes so this was deliberately done. As per that issue, it was handled really well as clearly noone suspected a thing.

3 Likes