We’ve developed this process to meet a variety of goals, based on everything we’ve learned from the Zcash launch and the Overwinter and Sapling upgrades. The primary goals are to ship safely — with plenty of time for ecosystem partner integration, in collaboration across multiple organizations — in a governance agnostic manner, all while pipelining concurrent upgrades.
Predictability is important if you want other organizations to coordinate with you. We don’t want to break the wallets and exchanges that support Zcash with surprise changes. Those teams have other stuff going on as well, so a long lead time is important.
This is what I mean by to democratic.
Having a good excuse to not take action. (EDIT: from always having to having a good)
Democratic with ZIP’s, with deadlines, with informing when and how: zcash has never messed up.
But wait, the goal to ship safely wasn’t respected, then why respect the NU process at that point?
Everyone is entitled to do an oopsie.
Personally I think asking for forgiveness (to the SO MANY exchanges, developers, etc) would’ve been better than going full COV OP.
Are you speaking on behalf of the foundation?
I agree a long lead time is important, but critical management is critical management, heck critical management is “other stuff going on”.
Just speaking generally, there’s no official Foundation position on the NUP. It’s an ECC thing — we may end up mirroring it with Zebra dev, but AFAIK that hasn’t been ultimately decided. @gtank will provide more info on our tech roadmap soon.
you want an ASIC resistant version of Zcash, there was recently a friendly fork promising just that, and it’s now live. I would go chat up their forums.
Hello everyone … I’m a bit new in the world of crypto, I’ve been slamming my head for only 3 years. according to my point of view the choice to increase ASIC was due to achieve fundamental goals in the future. I believe that those who say that resistance to asics was better, is only talking about the busnes that concerns them. I believe that over time ZCASH will become a great Crypto, not only by looking at the price, but also in terms of technology, privacy, speed and security . It has a strong potential and the people who are working on it know it and I think they will push to improve it even more.
I verified indeed that the overwinter rules were committed March 2 New Release: 1.0.15 - Electric Coin Company
which is another reason why it’s invalid imo to try to connect no asic resistance to the exploit:
If the company was really serious about no asics it would’ve changed equihash params already for overwinter - otherwise you kill the GPUs and need to revive them later, and all of overwinter (except the day before release) was planned/executed without knowledge of the vuln.
sidenote: the fact that the Ycash team managed to change the equihash params with much less engineering resources is another indication to the (perhaps obvious) fact that it’s a simple change.
Well I would argue a network where you know your ASIC will only be good for two months each time would be a great disincentivization.
In the worst case, keeping the GPUs alive for another 4 months would at least have kept much more good will.
More generally, the argument of the company is we need a lot of resources cause we have the best people doing complicated stuff…
that doesn’t go together with: we’ll break previous promises whenever something is a bit harder than trivial.
As a point of reference, I’ve understood Monero’s opt-in donation budget is around 25k per month on average, and they fight ASICs + integrate new crypto (maybe a little less fancy than Zcash, but not much less, with new stuff like bulletproofs) with that budget.
In any case, all of that is in the should Zcash be asic resistant question;
my main point was more: please don’t use the counterfeit bug as the reason/excuse you didn’t do something about ASICs.
That is what crosses a line for me and makes me talk publicly about issues I usually don’t.
Even before launch, we knew that 144,5 would be a much preferable parameter choice. The only reason it launched with 200,9 is that 144,5 solving was feared to be too slow, the choice was already made before the realization that 144,5 instances can in fact be solved within seconds, and launch was on a tight schedule.
The switch to 144,5 was always desirable, both for ASIC resistance and for header space savings (200,9 proofs are well over a KB). I think the switch should have been on the roadmap from launch, and definitely be included in Overwinter.
This is an accurate transcription of what I said. What I should have clarified, though, is that the BCTV14 flaw was not the only reason we did Sapling (which is kind-of obvious).
The point I was trying to make is that the flaw made it necessary to do Sapling on a shorter timescale than several of the ECC engineers, who didn’t know about the flaw, would have wanted. And that completely precluded doing an ASIC-resistance fork. I’m not sure whether or not an ASIC-resistance fork would have happened under other circumstances. I don’t think I’m revealing too much by saying that it was a source of significant controversy within ECC that we weren’t doing one. If you remember, we did try to do a hybrid PoW with an ASIC-resistant component later in Blossom, and that had to be abandoned –unfortunately– due to security concerns about the hybrid aspect.
Overwinter couldn’t possibly ever have included a PoW change. It would have been far too risky. Overwinter was always conceived as a minimal upgrade in order to prove that we could safely do hard-fork upgrades (which was not at all clear!) Remember that the Bitcoin Core community is generally implacably opposed to hard-fork upgrades; Zcash inherited that code base and the assumptions coded into it.
How is the change of equihash params more risky/complicated than the change of signature hash in overwinter? Given @tromp’s comment for example, it seems reinforced that it is a simple not risky change. What is the relevance of bitcoin’s opposition to hardforks when Zcash in any case regularly hard forks?
Also, I don’t think it’s a fair comparison to mention the hybrid PoW which we both agreed was, putting it delicately, much more controversial and risky (especially with the selective timelock feature)
I understood you were saying it’s not the only reason. My opinion that I have tried to convey is that even saying that it was a non-negligible factor (and since that’s the only reason you mention explicitly you’re hinting it’s not just non-negligible but at the very least prominent) is “exploiting the exploit” unfairly to go back on initial promises. And I find it personally offensive, cause it’s using my work to endorse things I disagree with.
One additional reason for this that I haven’t mentioned yet in this thread but @mistfpga mentioned is that there was a mitigation to the vuln that didn’t require sapling.
I agree it had its own disadvatnages (as I explain in zeroknowledgefm podcast if anybody’s interested) but it’s another indication that if it was a priority it could’ve been done.
By the way, also adding privacy is a huge complication to the Zcash protocol, but of course it would be absurd to remove it for simplicity, cause it’s the main feature.
Similarly I (and seems many others) understood asic-resistance as a main feature in the early days.
When someone would ask me “In two sentences what is Zcash?”
I’d say “It’s like bitcoin, with a privacy layer, asic-resistance and 10% dev fund”
Again, I think it’s a misleading use of the word “primarily”.
The signature hash change, included in overwinter, was an order of magnitude more complex than changing equihash params. Do you disagree?
But we included it, cause we cared about users not being able to make large transactions.
Frankly that would be a preposterous amount of technical risk to incur in a single upgrade. There’s a reason we have had so few bugs, and it depends on not doing things like that. Sorry if I sound frustrated, but there’s a lot of armchair engineering and protocol design going on here (as there was in many of the previous PoW discussions).
I don’t really agree. I think they’re incomparable kinds of complexity.
It just barely made it in, not because we cared so much about large transactions, but because it was a serious DoS problem even for 100 KB transactions.
@daira: wasn’t the DoS problem solved way before by restricting transaction size: Make 100KB transaction size limit a consensus rule, rather than a standard rule by ebfull · Pull Request #1501 · zcash/zcash · GitHub
And so given that earlier change, I think it’s more accurate to say the sighash change was about allowing larger tx?
(Your phrasing makes it sound like there was a DoS attack possible until overwinter using large tx,
and that’s the primary reason we did something in overwinter that was beyond a test upgrade, and I think that’s misleading given this attack was mitigated in this earlier restriction)
I can’t comment the technical details discussed in the last posts, but what makes me thinking is that after a One-Man-Show project (Ycash) can fork with ease to a new algo parameter within equihash and obviously, at least it looks like that, without problems after as well.
Sure, there are a bit different circustances as Ycash had not to deal with sapling and overwinter, but than again, they on the other side don’t have a ~50 engineer team at Ycash.
Just out of curiousity, as what is done is done anyway, but would it had been an option to postpone an asic resistance hardfork for some months and meanwhile test things on a test net?