How to hire ECC

I like the algorithmic policy enforcement, a (maybe obvious?) benefit is that by removing human judgement uncertainty is reduced.

  • What happens after 100% of transactions are shielded? Well earned flexibility, until year 4?
  • What if a “whale” is run over by a train, before they can shield?
  • Is it worth reiterating that it disincentivises transferring into the transparent pool?

If The ECC were to have the option of focusing its capital on either:
(a) restructuring to conform to a definition of not-for-profit/nonprofit

OR

(b) increasing shielded usability+adoption

I think I would be happier if they chose “b”.

1 Like

Great questions. Let’s see…

Yes. I feel it’s too early to fix goals for more than a couple of years ahead (and also I don’t have many more tricks for algorithmic incentivication that cannot be easily gamed).

Then the corresponding fraction of the Dev Fund is lost (or delayed) as well, until the time (if any) that t-addresses are completely removed from the protocol.

I’m not stressing this feature, because it affects only the Dev Fund recipients (which BTW one would hope are anyway avid adopters of shielded storage…).

1 Like

There’s another issue:

One can claim that it’s fine if the bulk of ZEC are kept in t-address cold-wallets (for simplicity and stability), as long as the bulk of transactions between users are fully shielded, and the deposits/withdrawals to the cold wallets are done in a linkability-conscious way.

That’s incompatible with the above algorithmic incentive.

I don’t know if the claim is tenable privacy-wise, and haven’t seen it properly analyzed. It may be premature to rule it out.

1 Like

Recall that the NU3 ZIP which ECC has committed to implementing is ZIP 213: Shielded Coinbase. This will mean that NU4 dev-fund ZIPs can be written to target Sapling addresses directly, assuming that they are compatible with the available degree of encumbrance (and by NU4, multisig Sapling addresses should ideally be available).

2 Likes

I think Monero is cool and I admire the project’s lively ecosystem. Monero’s ethos and preferred tradeoffs are different, but as long as people are honest about that, I don’t mind. Competition strengthens all of us.

The fact remains that z2z transactions are substantially more private due to the implementation of zk-SNARKs.

4 Likes

@joshs given enough funding, what are the top (dev) goals for ECC for next 4 years? Would like to know ECC perspective and vision for 2020-2024.

3 Likes

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! :slight_smile:

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 :slight_smile:

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