Announcing Zingo!

Community Grants
1

Hello Zcashers! (Context Note)

I am writing this post to announce “zingo” a next generation zcash application that is being built on top of orchard.

Terminology: “Developer-User”, (abbreviation DevUser, also UserDev):

“A hacker, software or otherwise, that uses the thing that they are building.”

What is zingo? It’s a Developer-Used wallet created by it’s Users.

  • Store your funds in it, like all of its DevUsers do, and you will get the same privacy, security, and viability benefits that we, the people who focus on it full-time do.

Okay, but what else is it? It’s a platform for experimentation with peer-to-peer consensual economics. We’re building the Apps that Orchard has enabled!

  • The Privacy Enhancement Fee:

    • If you transact with zingo, you will be offered the option to send 3 zats to Enhance Your Privacy:

      • 1 to The Zcash Foundation

      • 1 to the Electric Coin Company

      • 1 to Zingolabs.

    This explicit fee will ensure that your service is viable and adaptive in direct proportion to how much you use it. If you opt to not pay the Privacy Enhancement Fee, it is still likely that others will, making zingo the application you should prefer for your consensual (all) transactions.

  • Direct Feature Bids:

    • If you use zingo you will be provided with an interface that allows you to directly (via the memo field) communicate your opinions to zingolabs. In essence, this is an In App, bug-report/feature-request button. It innovates by ranking Zingolabs-Addressed memos according to the amount of ZEC associated.

    For example: Have you ever experienced a moment of frustration because an App failed to provide your need? You thought:

“I’d pay a ZEC, if only the default memo-field setting didn’t non-consensually leak my private information!”

Well zingo has a solution for you, it explicitly binds your interests to the UserDevs working on the App. Not only do we have the same desire to not have our private data leaked, by providing us with resources to Protect Privacy, you have become a DevUser.

There’s much, much more to say, but this post is intended to be brief.

I’ll finish by introducing the DevUsers of Zingolabs:

  • Juanky - TypeScript, FrontEnd, UX/UI, Internationalization

    • You want me to expose Unified Addresses? Give me the spec, I will figure it out.

  • Aloe - Rust, Haskell, etc… probability, crypto, puzzles, games, epiphanies

    • If we drill down to the next layer of abstractions, there’s some really neat stuff! I suppose we could impl this in a purely functional way…

  • Sessha - Rust, TypeScript, systems, fuzzy edges, corners

    • Well the doc says this button causes FOO… I wonder what it really does? Oh that? What if I push it n times from k directions?

  • Zancas - Rust, TypeScript

    • Blatherer-In-Chief

That’s my 3 zats! I am really excited to hear from the bright minds in this community. Let’s take zcash to new places!

–Za

Context Note: This post was directly stimulated by these instructions (in the “Before Submitting Your Application” section) which read:

“”"
Not sure if you’re ready to submit an application? Have questions? Feel free to post your idea to the forums in the Grants category to solicit feedback. You can tag @ZcashGrants in your post to ask the Committee questions.
“”"
(Consider yourselves tagged! :wink: )

15 Likes
2

Haskell and functional programming? Yes! :raised_hands: :mechanical_arm:

3 Likes
3

@AloeareV keeps dropping HRTBs into my code-review buffer… to be fair, I did opine that functional approaches were preferred… so I have no-one to blame…

4

I am not sure I understand what this is supposed to do…

1 Like
5

If you can ask a more specific question, I’ll try to respond in an interesting way!
Here’s my best attempt at responding to your open-ended question:

Do you have a z-cash wallet?

How is its development and operation financed?

zingo aims to solve the problems of supporting zcash development-and-support by directly integrating User-and-Developer interests.

1 Like
6

Gotcha, This could be interesting…

1 Like
7

There’s much more!

Technically:

Our core effort is to produce and expose an expressive SDK that provides App developers with an easy interface to Orchard and librustzcash. We’re well on our way!

We are the implementors of the V5 transaction parsing that enables zecwallet to function post NU5.

Our SDK, is opinionated and idiomatic Rust it:

  • constructs UAs
  • decrypts Orchard notes
  • Is evolving to be ever-more-functional and expressive.
  • Is being re-architected as a set of modular acyclic crates.
  • Will compile to WASM (once it’s encapsulated in its own crate).
  • Is all Safe code.
  • Is audited with: checkmate and dependabot
  • will be audited with cargo-crev
  • will be fuzzed with property-based testing (proptest)
  • Is acquiring expanded (tarpaulin reported coverage)

Our App Exists (as an internal test app in Android) with:

  • privacy respecting memo-download configs
    • This is per @kowalabearhugs request, and reflects our deep commitment to all UserDev eXperience
  • internationalization
  • automated jest-test-and-coverage
  • active development in privacy-respecting price discovery

Our development environments include:

  • a prototype zingo-cli regtest mode that conveniently connects zingo DevUsers to regtest-mode zcashd’s
  • reduced dependency sets that remove known vulnerabilities
  • test-framework abstractions that ease test production

Socially:
The ecosystem lacks a reliable external third party, that can expand our economy away from the ZF and the ECC. We are positioning ourselves to become this Missing Link. This is an urgent issue, and we are the solution.

The urgency stems from several systemic issues:

(1) The ECC’s entrance into the App field is toxic to the wider economy.

  • This is not a moralistic argument, it’s an economic one. If the ECC enters the App arena, it’s incentivized to work against external App developers.

(2) The ECC’s unique capabilities will be diluted by app development, when it is urgently needed to upgrade the Consencsus Protocol to Proof of Stake

(3) ECC entrance into App development centralizes and constricts economic activity into a Single (or Almost Single) Point of Failure

I believe that the ECCs declaration of intent to enter the App environment is motivated by the lack of a viable partner in that field.

We are that viable partner.

8 Likes
8

Just you wait until they stabilize GATs! :smiley:

1 Like
9

This sounds like a very cool project/initiative. Im excited to see more applications being built on top of zcash and I think the donation funding option is neat. I remember the windows wallet a few years ago had a similar donation model in its UX. How is input from users being collected?

10

The zecwallet project which provides a desktop app seems to be a re-actived project here:

Our project aims to handle all DevUser interactions via the encrypted memo-field on-chain.

Because we are providing mobile apps through the Google and Apple centralized failure-points, DevUser’s will still have to pay the privacy price demanded by those authorities (we haven’t solved that yet), to use those apps/platforms.

Does that answer your question? I don’t recall the details of how the bug-report/donation systems were implemented in the old desktop app.

11

Very thought provoking. There are definitely major issues with the size and capabilities of the Zcash ecosystem. I also agree we are better to start working towards a solution today.

Id also encourage the Zcash protocol developers to continuously reflect on the importance of supporting different business models outside the “dev fund” model when making protocol decisions.

Very very interested to see a grant application on this :blush:.

2 Likes
12

I think this is a great idea, I think financial support for developers is important.

(I work for the Zcash Foundation as a developer, so I have an interest here. But sustainable funding is a well-known problem in open-source development.)

I have a few questions about the implementation details:

1. How do you send these 3 Zats in a privacy-preserving way?

Here are some ways I could discover and track shielded Zingo transactions:

  • Each transaction has 5 shielded outputs (or 2 shielded, and 3 times 1 transparent Zat)
  • The public value balance fields of shielded transactions end in …00003 Zat, if the original number of Zat was a multiple of 10

It would be unfortunate if the “privacy enhancement fee” actually ended up reducing privacy in practice. Can I see the privacy analysis for this design?

2. Have you asked ECC and ZF if they want to receive hundreds or thousands of 1 Zat contributions?

There is a well-known attack called the dust attack, which sends large numbers of very small amounts of cryptocurrency.

Sending extra Zats for each transaction isn’t quite the same, but it could have an impact on the ECC, ZF, and ZingoLabs wallets, if Zingo becomes popular.

ECC and ZF already receive thousands of transparent inputs per day from Funding Streams. But they might not be prepared for thousands of shielded inputs. And it could cost them extra staff time to roll up those small amounts.

3. Does sending those 3 Zat cost the Zcash network more than the value sent?

Creating and spending each shielded transfer uses some CPU. The create and spend also take CPU to verify, and disk space to store, on every active node. (There are about 200 public nodes right now.)

It seems like the extra CPU would cost more than 1 Zat.

But I think there’s a solution that makes all these problems better!

You could send an amount that’s significantly greater than the staff, CPU, and disk cost. Maybe that means increasing the contribution, or storing the contribution amounts locally, until they get large enough.

9 Likes
13

My thoughts exactly @teor, especially regarding your points #2 and #3. It would require quite the massive volume of transaction AND profound appreciation in ZEC in order to make 1 Zat fees into a sustainable funding mechanism. Maybe that 1 Zat is meant to be a placeholder for some other value, which should be given real consideration to balance the need for low-friction/low-cost transactions with a self-funding project. I’d be very interested to hear a roadmap for transitioning from being ZCG dependent to be able to continue development independently.

I think this is a fantastic vision (though I’m not sure I’d agree with the characterization of ECC’s entry into the wallet space as “toxic”, but I see your point).

Great name (Zingo!), great vibe, great team. Would love to see a wallet that’s also a platform for further development and is independently sustainable. Thanks for putting this together and I look forward to seeing Zingo move forward as a formal grant proposal!

3 Likes
14

Hi @teor I am really grateful for your feedback!

To your questions, superficial responses first!

(1) We don’t claim to have solved this.
(2) No, but of course, their consent is required! After all we can’t send funds without a Payment Address! :wink: Consider this post us opening a conversation around all the possible parameters here:
* who get’s paid
* how do they get paid
* how much
(3) Possibly! Three zats is almost certainly not the real right answer, but it serves as a nice starting point.

To your suggested solution (my paraphrase):

  • “Tune the amount to something that’s actually fits in the constraint space.”

Hear, hear! We agree.

Tip of the brain, building on your solution with a small hack…

We’re trusting the User to contribute. After all, it’s opt-in.

So the app could escrow an amount that accumulates over an amount of time, or number of transactions, then when some jittery (randomized) threshold is reached it could send the Bundled Privacy Fee Payment, as a single transaction, somewhat decoupled from the realworld uses, both in the delay (to accumulate a sufficient amount) and due the jitteriness of the threshold.

The threshold itself could be selected using the criteria you mention.

Per the broader context:

  • Have we had a privacy/security analysis of our design?
  • Do we have a published protocol that we’re implementing?
  • Do we have an economic analysis that we can use to tune the PEFs?
  • Have we reached out to the ZF or the ECC for pre-approval of this plan?

The answers to all of the questions are “No”.

With respect to the first 3, these are processes that are better engaged in the open with community involvement. This because we all have some expertise and insight to contribute.

Per the last, it’s also the case that it should be addressed publicly, but in addition to the benefits of leveraging more insight, it’s also critical that we don’t elevate sectors of the community to undue authority.

We aim to diverge from ZF and the ECC so it’s in all our best interests to engage through this medium first, such that we can all be heard.

5 Likes
15

Yep the 3 zats is just a thought experiment… a place holder to bounce ever-more-real ideas off of.

Perhaps “toxic” is poorly chosen language… perhaps “misaligned” or “problematic” or “crowded” would be better. The metaphor of space is probably useful here. We hope to push outward to open more space for all the diverse projects in the community.

Per our relationship to ZCG, we view it as critical both because we need the funding, and because we hope to secure expert insight and feedback that will help us design achievable, valuable milestones.

A more formal framework for understanding our own state and progress is an explicit goal we have for our collaboration with the ZCG.

3 Likes
16

I was just PM’d by a community member who was contacted by… someone else, who let them know (the community member), that I, Zancas, am related to Zooko.

This is a true fact. Zooko is my brother. This has come up elsewhere on this forum. It seems unlikely that Zooko will cease to be my brother any time soon. It’s as true now as it was then.

I am happy to acknowledge that he’s my brother! He’s great guy! And an absolutely inspiring champion of privacy.

On the other hand, I’d like my contributions to be evaluated for their own sake. For the things I do, I prefer to accept responsibility. I am confident that Zooko can get along without taking credit-or-blame for my work. And zancas-brother-of-zooko just doesn’t work for me as an identity, I prefer zancas. If Self-Identification is an important value to you, then perhaps you’ll respect my choice.

Per our professional relationship, there is no current collaboration on any zcash project. I worked for Zooko on Tahoe-LAFS at Least Authority Enterprises from 2012-2014.

As @teor noted above no-one at the Zcash Foundation had heard anything about a proposed app that would attempt to provide sustainable funding for their efforts. The same is true at the ECC. No-one there had heard of the idea, because we didn’t share it with them beforehand.

This was the right decision, it is not the place of the ECC or the Foundation to grant permission for innovation in this space. Those entities exist to support permissionless innovation.

Our intention is to innovate without their permission, but hopefully with the support of the ZCG committee.

It is our explicit intention to devolve central authority away from the ECC… or to put it another way, to expand the space of possibilities so that the different collaborators in the zcash-space can realize their potentials more fully, without stepping on each others’ toes.

For future reference perhaps this post can serve as a Single Source of Truth: Zancas and Zooko are brothers.

Interested parties can bookmark it.

10 Likes
17

@zancas when DAO?

18

If your question is: When will zingolabs be a DAO?

Then

The DevUsers of zingo will be paid by the two mechanisms proposed here the:

Privacy Enhancement Fee

and the

Direct Feature Bids

The recipient of these funds will be a wallet shared among the DevUsers.

We intend to implement a multi-sig threshold payment similar to Solana Squads, but that’s not necessary for our operations to be DAO-ist. Since our income will be derived directly from our users, and our expenses will be paid out from our shared zcash wallet, we can be considered a DAO as soon as we begin receiving funds derived from those mechanisms.

If your question is: When will zingolabs provide functionality that allows others to build DAOs?

Then an answer is:

Once there are sufficient Direct Feature Bids to enable us to implement multi-sig payments.

2 Likes
19

Amazing. DAO-ist sounds fine by me :+1:.

20

We think that multi-sig will take longer to implement than PEFs and DFBs.