I have just watched the live stream,
Was I the only one that saw the ECC saying that they didn’t do asic resistance because of the print free zec bug?
This is huge. Why didn’t the ECC come forward long ago and say this 
- This severely broke the good faith the users had in the ECC. - just admitting this and doing a proper full disclosure on the subject might bring the miners back.
Going forward is ASIC resistance a goal anymore?
at Zcon0 it was established with crystal clear transparency that ASIC resistance was not feasible due to the fact that private asics would be developed within 4 months of any algo change.
The facts remain that the ECC has a 6 month update cycle, and it would completely consume the resources of the core team to commit to ASIC resistance.
This was not second actually it was not even being worked on what so ever after the discovery of private asics being readily available on private markets within 4 months of any algo modifications.
Both Bitmain and Innosilicon agreed 4 months was more than enough time to get new asics online, and if the team showed asics resistance they would not announce anything publicly because they have a bottom line to meet and can develop asics faster than the developers could design a resistant algo to the last asic.
Did you watch the live stream?
And in my professional and personal opinion you are wrong about asic development.
I attended Zcon0 in personal and was in person at the mining seminar workshop in Montreal Canada. I had a deep discussion with the operators and administrators at the GPU One facility in Montreal as well after the conference.
I actually opted out on the last mining hardware upgrade, the A++ and Z11 are both worthless if I can buy Zcash at the current price.
I never got involved with them. but irrespective. Daira said “We lost a lot of good faith with the GPU mining community because of the print free zec bug meant we had to do sapling rather than asic resistance”
I am severely paraphrasing, but I will grab the timecodes. It doesn’t matter what else was said, that is the bottom line. no matter how it is dressed. I actually left ZEC over the disclosure policy around that vuln. I only came back when I was pretty certain it was due to the print free zec bug and not zcash wanting asics.
Being the person that discovered the bug, and someone who viewed not doing anything about asics as a great violation of community trust; it really bugs me when one is used as an excuse for the other.
Especially when to this day I don’t understand why the simple code change of equihash parameters was not at least a decent short/midterm solution
I am sorry if you feel I am using you as a cudgel. I am not. I am saying this is a massive chance for the ECC to repair some damage that was seen to be done at that time.
for what it is worth, I think they should have followed your advice and forked with new parameters.
But I do not have the inside knowledge that you do. I am simply going off a statement made by Daira. To be clear, the bug was found 2 - 3 weeks before asics. The decision not to fork was made on the 2nd of march - at this time ASIC;s were not proven. but once they committed to the sapling fix, they couldn’t turn back.
Sorry if you feel I am representing your work/knowledge.
Ohh I understood you were just quoting (perhaps misquoting not sure exactly what Daira said) if you wanna reraise the ASIC subject that’s fine np
Well, im currently integrating RandomX and ProgPow into zcash… if ASIC resistance is no longer a thing, I will do what Nathan and Zooko advised and go find another project to be a part of.
cool!
20 characterss
Transacribing what @daira said:
ECC lost a lot of goodwill from a section of the community as a result of the ASIC mining issue. We lost a lot of miners who had been invested in GPUs. And as it turns out, part of the reason that we couldn’t just keep the protocol GPU-friendly was that we needed to do Sapling, and we needed to do Sapling because of the BCTV14 flaw. And so our hand was forced, basically, but there’s still a perception that we kind of fluffed that from a technical point-of-view, which I don’t think is actually the case. And maybe we wouldn’t— maybe there would be more trust in ECC if things had gone differently.
This doesn’t mean that if the flaw had not existed then ASIC resistance would definitely have been implemented by ECC. There were robust arguments for and against at the time, as was also discussed at Zcon0; we can only speculate as to what might have happened had Sapling not been a required deployment. However, ECC (more precisely, the leadership aware of the flaw) was clearly at the time unwilling to disrupt the deployment of Sapling, for now-obvious reasons.
Pivoting to work on ASIC resistance would most definitely have affected the deployment of Sapling, even for what on its face might look like a very simple code change in the zcashd codebase (but would in fact have required sudden allocation of significant engineering resources across the Zcash ecosystem to address the plethora of stacks, particularly in slow-moving enterprise settings). Neither @daira nor myself were aware of the BCTV14 flaw at the time of the emergence of ASICs, and IIRC both of us agreed on this point.
This would pair well with a ZIP draft! I’ve been trying to encourage protocol-related ZIP drafts to have a reference implementation available at the same time (as well as doing so with ZIPs I write myself). It makes it significantly easier to both find inconsistencies in the specification, and review/consider the change as a whole.
I understand. And for those who were not around at the time, there was significant confusion between the engineers at zcash and the management. It was only found out once they disclosed that this came to light that the engineers (str4d, daira, etc, were not informed of this information)
Here is the timestamp so people can judge for themselves.
btw @daira you are amazing in my eyes, you too @str4d. This is not a reflection on you.
Are you serious? If you are please PM me. Im off on holiday tomorrow for a but PM’s should show up in my in my email inbox.
Check out my RandomX thread in mining to see whats happened so far. Its just I am not going to put any more effort into this (also we are removing taddrs) if ASIC resistance is never going to get approval by the ECC. im just wasting what few hours/days/whatever I have left on this planet.
As I recall, we were discussing a harmony mining scenario, not just here and I know theres limited resources with commiting to the upgrade but that discussion is still relevant (Im pretty sure I posted last on the pertinent thread on this forum so)
Just to clarify: I am not saying that I would personally support (or oppose) a new ZIP proposing an ASIC resistance change in a future NU (and I am definitely not speaking on behalf of ECC). I am saying that having at least initial implementation work done before a ZIP draft is proposed significantly improves the quality of the ZIP draft compared to something that hasn’t actually been tested out.
There are other possible ways to keep asic resistance actually, of course it’s always a trade off, but a project that doesn’t want asics at all price can succed in doing so.
You realise you are shouting at the guy who not only found the vuln but also is one of the best cryptographers in the world right?
I think you should listen to his words, rather than screeching at him. We are talk about a past events, events he was involved in.
in fact have required sudden allocation of significant engineering resources across the Zcash ecosystem to address the plethora of stacks, particularly in slow-moving enterprise settings)
I don’t understand this…what plethora of stacks and enterprise settings would the company need to address to change equihash parameters? You do agree that for zcashd it’s a simple change (The only thing I can think you mean is that we would be responsible for updating mining pool software or something?).
If it’s about the ecosystem needing to align itself with the change that’s true in any case when regularly doing hardforks/network upgrades
Tone it down a bit. No yelling. I’m not saying that y’all can never use capitals for emphasis, but you need to be courteous to each other. Even if — in fact, especially when! — you’re arguing about something.
ASIC resistance would’ve been the perfect reason to hard fork fixing both issues (BCTV14 and kicking off asic from the network).
As right now and as it was back then, the real issue here is respecting meticulously the timing and practices for NU.
Zcash has proven to be too democratic and far from being a community driven project.