Nathan spoke to them at Zcon0 (Zcash to 10 billion - Electric Coin Company) - predominately L1 scalability and cross chain interop. I also believe we need to spend time on consensus mechanisms (POS / Hybrid) and UX improvements to help drive z2z adoption.
2 Likes
@joshs, Nathan indeed spoke at length in the above Zcon1 presentation about scalably goals, and Daira subsequently spoke of possible approaches. That was an excellent initial discussion of ECC’s stance on scalability.
Where can the community find similarly detailed goals, data and plans about
cross chain interop
and
consensus mechanisms (POS / Hybrid)
and
UX improvements to help drive z2z adoption
?
3 Likes
Great question! We haven’t formally published much of that, we should, but perhaps only when we have something to recommend to the community. It’s one of the challenges of fine grained funding mechanisms. Some of this will take the space to research.
Some interop work is active in conjunction with other 3rd parties, ex. Flyclient/MMRs, BLAKE2. Getting our work and engagement documented on interop is in my backlog.
3 Likes
Please do publish this stuff! 
1 Like
Hold on, no one here is looking for “fine grained” funding mechanisms, in the sense of, as you put it:
A fine-grained allocation of funds can be expressed as: “ We will build x function for $y in z weeks
Again, let’s take the aforementioned Scalability discussion by @nathan-at-least and @daira as the example. It made a case that Scalability is important and plausible. That’s very mucn on the “coarse grain” end of the spectrum, but it conveys deep thinking on the subject, and is appropriate for the phase we’re in.
In my opinion, ECC should convey at least that much information to the community, about each of the main directions it intends to pursue using a Dev Fun.
In the case of complex goals like “UX improvements to help drive z2z adoption”, I would also expect this to be unpacked into the many technical + nontechnical components this entails.
3 Likes
Thanks for the clarification. I intended to communicate is that some of these activities are directional but the future gets more blurry the farther out you try to see. From what I understand, more work has been been done on scaling research than on working through consensus mechanisms, for example. L1 scalability is the big ticket item (which actually may necessitate other things which may also require other R&D and market activities, as Daira highlighted iirc). If you have specific mandates like a roadmap or specific items, it’d be nice to have those as a condition within a proposal so that we can respond in one place.
1 Like
@joshs, yes, community members could create a detailed roadmap instructing ECC how to drive fully-shielded adoption. The community can also attempt to cook up algorithmic incentives to encourage ECC to follow such a roadmap in the absence of other accountability mechanisms. Still, ECC has spent a ton of effort thinking about this, and is so probably in the best position to draw a roadmap that’s effective, comprehensive and matches its expertise.
So it’a s shame that ECC has not shared such a roadmap to date, and I don’t think that ECC can meaningfully claim that it will use the Dev Fund to drive shieled adoption, until it does so.
7 Likes
Zooko went through the roadmap here: State of Electric Coin Company - Zooko Wilcox - YouTube
Does this help?
1 Like
That’s a nice motivational slide. It was perfect for Zooko’s brief, high-level Zcon1 talk. It’s not even close to a meaningful roadmap that people can reason about to justify a many-millions-of-dollars Dev Fund.
In particular, shielded adoption is a huge goal that will take many person-years and collaborations to pursue. That slide had 10 words about this:
Wallet Research and Adoption
Global 3rd Party Awareness and Adoption
Where does a programmatic SDK, and a commitment to make that a supported product, fit into those 10 words?
Where is the plan for a robust, supported lightwalletd discussed?
Where is the mention of research on privacy-preserving note detection for improved lightwallet privacy?
Where’s the discussion of engineering work on shielded hardware wallets?
Is there a commitment to supporting Windows? Mac? iOS? Supported packaged binaries for platforms other than Debian?
And I could go on and on.
ECC’s top-notch motivational PR should bolster, not substitute for, a hard-nosed, substantial and transparent goal-setting-and-planning effort.
11 Likes
Thank you for describing everything as it is, here everyone is tired of explaining that what ECC does is not everyone wants it, while shifting adoption work to the community is not an option at all, then apparently, if the community wants to develop a coin and improve the code, it should do it yourself
It is because of this approach, for example, it seems to me that if funding is supported, nothing will change, the next 4 years will be spent on scaling development, and the current promotion work is not needed because there will be a new code and new adoption work, because compatibility with it won’t be old and the agreements also need to be re-formed, but it only seems to me, I don’t know for everyone.
3 Likes
@Anton1, this is a valid concern, but personaly I am not very worried about this aspect of scalability. It’s true that any scalability solution will probably require a network upgrade with major changes. But I think everybody intends this transition to maintain ZEC as a single coin. And everybody wants the transition to happen in a very careful way, to minimize the disruption to the ecosystem. This is in the ethos of ECC. For example, look at how the Sapling upgrade maintained compatibility with Sprout. Also, the network upgrade pipeline is meant to give everyone time to adapt.
The main hurdle to adoption has been to convince people to run the Zcash software and to use the Zcash-specific interface (RPC, SDK, etc.). I hope that it will be possible to update this software to use a new and improved consensus protocol internally, without changing the external interfaces, and thus minimize the disruption to existing users and integrators.
5 Likes
Per this question:
“Is there a commitment to supporting Windows? Mac? iOS? Supported packaged binaries for platforms other than Debian?”
This effort should include a careful analysis of the costs-and-benefits introduced by ubiquitous (desktop) containerization.
I see Linux, Windows & Mac on ZecWallet… is that what you meant?
There’s also wallets & companion apps for mobile - many more & much better than last year.
1 Like
Yes! Unfortunately, the current Windows and Mac ports are (AFAIK) rely on patches that are not yet in upstream zcashd as maintained by ECC. Testing on these platforms is not part of ECC’s continuous integration system, and there are no official binary packages published by ECC.
The barrier to creating new Windows/Mac GUI wallets (or other products) would be lower, and the result more robust, if the requisite zcashd component was provided by ECC.
Anyway this was just an example of a question. ECC can decide whether or not it offers to put this on the roadmap. It’s just that currently we don’t know whether and when to expect it.
2 Likes
To my knowledge, zcashd compiles natively on MacOS, and cross-compiles for Windows. It was certainly working a year ago when I wrote the MacOS and Windows build PRs that both pulled in the community patches, and fixed underlying problems that some of the patches were papering over.
We had MacOS CI testing for a long time, but had to take it down recently due to dev-infra changes, and we haven’t had the resources to set it back up. Meanwhile Windows CI has caused us no end of problems.
I agree these should exist, but they won’t until we have both reliable CI, and reproducible builds in Gitian. And also the resources to set all this up, in addition to everything else we are doing.
2 Likes
@str4d, thanks for the clarification! Great to hear (or be reminded?) that those patches are in. If I understand correctly, native Windows build is still an open problem.
More to the point of the current discussion: it’s clear that additional work and resources are needed, as you’ve described. Inquiring minds want to know whether and where this is on the list of tasks that ECC will use the Dev Fund for.
(And of course this was just one example.)
1 Like
Hi.
Likely not in 2019
We’re not sure about 2020. It would require a fair bit of time and effort to figure out how to make the transition. We’re not opposed to exploring the option if that’s what the community decides is necessary.
It’s possible for the community to mandate scope. It may be technically feasible. If it’s a mandate in the proposal, we’ll explore it together and respond on whether we could agree to work on that, assuming the rest of the proposal is something we could support.
//Aside
Personally (not a company position), I believe near-term forced taddr deprecation is not a good idea and would hinder the mission. Secondly, if Zcash is encumbered by Bitcoin-scale limitations, it won’t be used as a MoE. If it’s not used as a MoE, what’s the point?
I hope that answers your questions.
3 Likes
Can i get ECC position on timeline for t-addr deprecation? or disabling transactions to t-address
Why exactly?
20 chars
t-addr deprecation is gravely wrong idea for near future. exchanges, other fiat on-ramps and their respected regulations ar against full privacy now. anyone wants to lose majority of existing fiat gateways? brilliant. actually, the whole z+t idea is one of main advantages of zcash. seamless experience, reliable, polished and low-tech-end mass user adopted products is a current challenge, imo.
2 Likes