Are you sure? Active adresses at the Monero chart doesn’t backup your claim:
(have in mind i’am everything else but NOT a monero fan!)
2 Likes
I agree that active adresses is not the best indicator but it’s still one that tells a story. Even more if compared to competition coins.
I agree that someone never should take just 1 indicator, so here your suggested # of Tx chart for ZEC:
2 Likes
carefully boxalex, you are just step away from being transfered from “respect” to “ignore” zone.
1 Like
^lol @ this 
Lets ignore the people posting any kind of critique and surround ourselves with people who only praise us - policy.
actually as none of my current concerns/questions/arguments gets any attention/answer in all the other threads i ask i allready have the impression i’am on the ignore list by now…
2 Likes
Actually it’s not exactly like this for several reasons.
- the active adresses chart means active per day used adresses. It doesn’t matter if it’s a new or the same adress as it would be counted the same way. Actually thinking more about it, IF every transaction on ZEC would use a new adress the persons behind each adress would be even less than. Explaination: 1 Person doing 5 transactions the last 24 hours would have 5 adresses in the chart accumulated but it would be actually only 1 wallet/person used. This said, your changed by transaction adress is more an argument in favour of declining wallets.
- fully shielded transactions are a vast minority so far. From the Zcash explorer we see that fully shielded tx the last 24h have been just 48 tx. For just shielded transactions we are good to take just a 20% (again taken from Zcash blockexplorer data). But than again, we had these shielded transactions 6 months ago as well. There is just a decline. I’am just describing what happens, not why it happens not to derail this topic!).
1 Like
This confuses me, because the first I knew (and to my knowledge, the first anyone in ZcashCo apart from Zooko and possibly Nathan Wilcox knew) of the time-locking proposal was Zooko’s GitHub comment 26 days ago.
4 Likes
I guess you are no longer in the circle of trust
No, I just haven’t had time to reply. You asked a whole lot of questions, a lot of which were rather open-ended.
1 Like
Being too conservative in making consensus changes is not a problem that Zcash has.
Zcash is probably the most complex cryptographic protocol that has ever had widespread deployment.
We’ve had a well-executed launch and two ambitious network upgrades, which have:
- established robust safeguards including replay and rollback protection for subsequent upgrades;
- addressed denial of service problems such as quadratic hashing;
- improved performance of the main bottleneck –shielded spends– by a factor of almost 20 (!);
- switched to more conservative curve and pairing parameters; and
- added functionality such as protocol support for shielded hardware wallets.
Throughout the Sprout, Overwinter, and Sapling design processes, I cannot think of a single feature that we added without having broad consensus among the protocol design team that it was a good idea to include it. We never added features just because a single person thought they were a good idea. (The nearest we got were two features each driven mainly by two people: hierarchical shielded addresses by me and @str4d, and diversified addresses by me and @ebfull. Both of those had sign-off from the rest of the team.)
We have also never decided to add features without being pretty damn sure that we knew how to make them secure. That doesn’t mean that all of the details were nailed down; obviously, you don’t do that before you’ve decided to include a feature, in order to avoid unnecessary work. But we have made sure that features didn’t get included without protocol engineers being confident that they could be designed securely and robustly.
As a result, despite the complexity of the protocol, our attack surface is in great shape. We’ve never had a serious cryptographic or operational security failure (touch wood). We have had a couple of potentially exploitable memory safety and DoS issues that required security bugfix releases, but our code is gradually being migrated to Rust which is a useful step toward mitigating that attack surface. The nearest we’ve got to a known cryptographic design error in the deployed protocol is the minor failure of defence-in-depth described in issue #3719.
I attribute this success in avoiding security issues largely to having a design culture that systematically rejected potential features that could have introduced weaknesses. As a result, we managed to contain the protocol complexity against pressures toward bloat; unnecessary, risky, or insufficiently well-motivated changes; or “creeping featurism”.
The suggestion that anyone, including Zooko, might push particular consensus changes through over the objections of other protocol team members is quite new. The rule that we have always followed is that changes need rough consensus among the protocol team in order to be included. We’ve never before had management setting “requirements” over serious objections from any protocol engineers or cryptographers. And we shouldn’t now, or ever.
Sincerely,
Daira
17 Likes
Daira, it wasn’t your job to evaluate potential future consensus protocol improvements. You were asked to execute on Sapling last year, which you did, very well.
I talked to Nathan (the Company’s CTO) extensively, to the Electric Coin Company’s Technical Advisory Board, and to maybe hundreds of the people whose cooperation would be necessary to make this go through without a chainfork: other companies, investors/hodlers, traders, random users, scientists and engineers who specialize in economics and consensus protocols and mining, miners, etc.
Once I was satisfied that it would have good results that would protect and strengthen the network for all users, and improve the incentive alignment between the new incoming class of alg-B miners and the users/holders, and that the opposition to it probably wouldn’t be enough to cause a chainfork, then I brought it to the engineering team as a candidate Goal for Network Upgrade 2.
The Zcash engineering team is not tasked with helping me evaluate the social, economic, PR, or strategic consequences of different possible consensus protocol features or other strategic decisions. They’re tasked with helping evaluate the technical implications and interactions between different features, and then they’re tasked with execution.
Heh heh heh. I just posted a note in parallel with your note giving a quite different account of our internal company engineering process. Perhaps we should take it off-line?
Note that on the Network Upgrade Pipeline there will be internal and external specification security audits and implementation audits. Of course, we also want to construct the original specification so that it is easy to audit, and as secure as possible.
… oh, and also, we have a corporate policy that employees are not forbidden from acting in the role of independent community member and writing contributions or voicing opinions in public, as long as they don’t misrepresent their opinions as being representative of the Electric Coin Company’s position.
3 Likes
Is it possible you could write these down and document them, such that we could follow up and make it a public record?
3 Likes
Technically it wasn’t, but in practice I’ve been doing it anyway since before launch (as have other protocol engineers), and no-one has complained about my doing that before.
6 Likes
These charts don’t start in 2017 like the other one, which makes them misleading.
I just want to make a note here that I feel like some of the dialogue has been poorly worded in the back-and-forth. That has caused people to feel like they have been attacked intentionally, which is usually followed with a like-kind response that escalates conflicts.
Just a reminder that we’re all on the same team. 
7 Likes
I cant believe you said something like this. If someone sees a problem, should they not come out and say something and raise attention to the issue that will effect Zcash? All I keep hearing from you Zooko is “Dont look at it too much, you might find problems, get back to YOUR job and dont worry about it”.
[Moderation edit by @daira: deleted an off-topic hypothetical.]
Seems like you are going about this backwards. Why would you start proposing changes to the end users when it hasnt even been talked about with the engineers to see if it would even be feasible?
1 Like