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.