Where we're going, we don't need roads! ECC Weekly Update

General
1

Hi Zeeps,

Is anyone else a fan of Formula 1? If not, that’s okay; this post is for you, too.

F1 is my jam or at least one of them. I like just about anything that makes my heart beat - that makes me feel. Yeah, the sport is a little elitist. Sue me. It’s fast, dangerous and fun. Verstappen has been a force these last couple of years - untouchable. That is until my boy Lando pulled out his first win last week in Miami.

1000×666 871 KB

I spoke with an F1 ad broker once in my early days at the then-Zcash Company. They approached me about putting the Zcash logo on a Ferrari or Mercedes for the truly affordable price of several million. For a logo. Oof. I guess someone’s got to pay for those cars.

Many have been talking about the importance of focusing on the rails, the powerful engine that will propel us all into the world of financial freedom through the private permissionless chain called Zcash. This project is blessed with some of the world’s best engine designers and builders. Bar none.

But if you follow F1, you know that the engine is but one element. Each team is a “Constructor,” pulling together the tightly tuned engine and chassis, deciding which tires to run on and for how long based on things like the track and weather conditions.

The engine is only one, albeit important element. Every little detail matters. Do you see where I’m going? To construct a winner, you have to be able to pull it all together. It’s a beautiful thing to watch in F1. In Zcash, to be real, all the other disciplines are only now starting to catch up. Experts in building awareness and driving adoption are emerging, but primarily, we’re focused on building a more powerful engine, one that is, at best, underused.

But more importantly, we cannot build Zcash to be an F1 car, or worse, just an engine, if we expect it to be a globally useful tool for financial freedom.

F1 cars are built for one thing: to go fast on tight tracks, free of debris, for a few hours at a time. There are only 20 drivers in a race from 10 teams. You must have come up through the sport, strong financial backing, and super fast reflexes to race one of these bad boys. Lots of people watch, but few can drive.

If not an F1 machine, what should we build?

Well, I ask, who are we trying to empower, and what do they need?

If you want to build a car for mechanics, it will only be useful to mechanics.

If you want to build for the wealthy elite, build a Ferrari. A friend of mine bought one. I think it cost as much as his house. He only drove it once a week on smooth roads and spent $15k a year in upkeep. It mostly sat in his garage. High fun, low utility.

What then, a Tesla? A Jeep? I admittedly swap cars more than I swap toothbrushes, and I like a clean toothbrush. I’ve owned 4 Jeeps. They’re amazing in the snow and mountains where I live. They are built for purpose. I currently own a Tesla. Super fun, terrible in the snow with my sporty tires.

Here’s my point. If we want adoption, we must go to where the users are and build for purpose. Who needs financial freedom? Where do they live? What tools do they need? It’s not a one size fits all. We need a good engine, but also an adjustable stack on top. And to know how to do that, we go to where the people are, and then we build for those people. We already know we aren’t building for the wealthy elite. We’re building for the common man around the world, who needs utility, censorship resistance, and security.

Plenty of cars have been built with cool features that designers thought people wanted, but that totally flopped. They were likely all designed by someone sitting in an ivory tower somewhere, totally disconnected from the people they hoped would throw money their way.

Build for no one, and no one will come. Bet everything on a hunch that “someday,” people will come, and chances are that you will sit miserably in your poverty, pissed off at all these “dumb ass people that just don’t get it.”

This is why I applaud @peacemonger’s efforts in her user research with ZURE, and @zancas and the Zingo! team, who are actively engaging with the LATAM community. They are out there, listening, so that we can build for purpose. We need more of this. It’s also what we’re trying to do with Zashi to inform our work on the engine. To build a world-class user experience for ZEC, we need to understand the users we’re building for.

And then, when we are able to really get to know our users, our people, we can build the complete vehicle that delivers them from antiquated and often nefarious financial constraints. Then, we build a new system that truly sets people free. If we do this right, what we build might surprise you.

Because where we’re going, we don’t need roads!

fc1ef908-f5a9-41e4-923c-f6b3674430eb_text

Here’s what ECC has been driving this week:

Zashi / and wallet related

Zashi iOS:

  • re-wrote app navigation to fix an iOS 15 issue
  • worked on biometric security
  • implemented authentication for Send, Delete and Export Private Data
  • built a custom Changelog implementation with an editable .json file
  • updated About screen UI and built a new Changelog screen
  • implemented handling multiple memos and displaying them in the app UI
  • implemented a fix for a shielding crash
  • Analytics Update:
    • Unique Installs: 1.41k
    • Total Downloads: 1.6k

Zashi Android:

  • implementing authentication requirements
  • splash screen added to every app launch

Analytics Update:

  • Production Installs: 935
  • Total Downloads: 2.02k (incl. Beta)

@nuttycom found a note commitment tree bug that has been difficult to diagnose

A feature flag was added for Sapling so Brave won’t have to import the Sapling crate.

Binance threw us a curveball this week, both in that it started to reject funds coming from shielded addresses and in an RPC requirement. Kris jumped on it and got it implemented.

@str4d spent some time with Zingo! on seed phrase storage

Zcash

Strad further refactored the zcash_primitives Transaction type to introduce a Bundles trait and include Sprout

Work was done in support of ZIP 320.

@daira and Strad spent time on ZSA naming conventions

Daira-Emma and @ebfull also started mapping scaling design goals that use a lot of prior work to increase the block capacity for Orchard proofs.

We agreed to provide a circuit audit for Penumbra and have begun working on that. Daira posted the details here.

We also supported a grant review for another Zcash ecosystem partner.

Other

I met with Jack to discuss our decision to terminate the ECC/ZF trademark agreement and its ramifications. We’ll provide an update as the conversation progresses.

I published an FAQ for a possible path to a new type of dev fund

We began Z|ECC summit planning

We opened up a new role for a Zashi product designer and are actively interviewing some amazing candidates for our Director of Finance and Operations position.

Relatedly, Margaret is “retiring” to focus on creative pursuits. She has been the operational glue holding ECC together since the beginning. She’s a fantastic person, and we’ll miss her.

Janie is back with us full-time and is our new Business Operations Manager! She’s a star, and I hope many of you can meet her!

We also completed our first survey of ZAC members. As of now (one new one was completed today), we have 29 respondents.

  • Overall Reaction to ECC’s Zcash Dev Fund Position:

    • Strongly disagree: 6.9%
    • Neutral: 17.2%
    • Agree: 41.4%
    • Strongly agree: 34.5%

  • Preferred Option for Dev Fund:

    • Allow the Dev Fund to expire: 11.5%
    • Direct Dev Funds to a decentralized grants pool: 88.5%

  • We had a lot of great written thoughts and feedback as well. Thank you all!

  • Tatyana wrote a great post on good survey construction, and we’ll follow these recommendations as we move forward!

That’s the scoop for this week, Zeeps.

Got your seatbelt buckled? Good!

Onward.

20 Likes
2

Josh, thanks for the update, as always!

I have one topic in mind.
I’m currently busy with a big Russian-language review for Zashi.
It’s current and future functionality, but with a focus on what a person is just learning about Zcash.

I have already rewritten the draft of this review many times based on my experience using it and the conclusions I come to in the conclusion.
I tried to find a target audience for the current state of the wallet without taking into account that in the future Zashi in my mind becomes the center of the ecosystem, like Keplr for Cosmos. I’ll talk about that in the review as well. Because this idea is perfectly traceable from the goalposts you’ve outlined. And everything around it kind of hints at it, including the fact that you’re hiring an interface designer.

And btw I can see why we’re now focusing on this app as a final product rather than a protocol. We can have a roadmap for Zashi, but not the project as a whole. This is where it’s obvious, hello Gary Gensler.

But the conclusion I’m coming to now is that the target audience for Zashi today is exclusively new users. Simple functionality, concise design, the best UX of all variants. That’s hardly enough for an ex-user. Not for me, because my current benchmark for functionality is YWallet. I specify again that we are talking about a specific moment in time.

But you know what’s most discouraging? Zashi is most likely positioned as a convenient app for everyday payments, but it has an artificial limit of 10 confirmations sewn into it. It doesn’t affect the sender of the funds. But morally it is very stressful when you are the recipient. Especially if you’re a new user. Why 10 confirmations? 15 minutes spoils the whole experience for this target audience. I’m just trying to understand, has Zcash had such massive blockchain rebuilding? I haven’t heard anything about it. Can you explain why this is necessary?

Let’s just imagine ourselves in the shoes of a new user.
And I know there is a special line in the Balance tab. And the transaction history also shows the incoming transaction. But this feeling that a transaction takes such a long time to arrive goes against my understanding that it is convenient to pay for goods in a store. Because I’m a new user, I just downloaded the wallet and topped it up and now I’m starting from my first experience with Zcash. And it seems to me that it’s slow as hell.

5 Likes
3

I really appreciate your thoughtful feedback and perspective! It’s valuable.

I agree! It’s too long and a UX killer. There has been a lot of discussion among our team about this internally and I shared your comments with the team. The concern is risk with rollbacks. 10 confirmations was anchored in prior guidance for exchanges to ensure probabilistic finality given we are a PoW chain. There are different levels of risks for different types of transactions and sizes, but its currently a one-size-fits-all solution. We need a better answer and working on it is a priority.

4 Likes
4

Josh, thank you! I assumed it was a moot point. I’ll say in my video that it’s another reason to change the consensus algorithm.

2 Likes
5

I love reading your updates, Josh!

Thanks for your great way to engage… There’s always -from my point of view- an open invitation to read, which is impossible to decline or ignore.

This one about formula 1 Is just perfect. It reminded me of my father, who was a devoted fan of Enzo Ferrari’s squadra rossanera.

Also, your words make me think of Zcash and Il Cavallino Rampante.

I won’t say much, 'cause I’ve just got an idea for my next article for @ZcashEsp :shield:

This was really inspiring for me.

Hugs! :hugs:

4 Likes
6

Thanks for the inspiring update. I like “Turismo” and “Rally” because they take “street cars” to their limits. The lowest categories of Rally use mid and small size working class cars to race on tough roads. See article on WRC

I guess that our challenge is to build a street car for the working people that can also win a Turismo or WRC race when tweaked accordingly and with the proper driver behind the wheel. (Note: This doesn’t mean that the car will let any driver be a racer and win a race on its own)

The magic of these car racing categories are that you see the car you, your neighbor or “uncle joe” can afford and own competing for the pole position on a sunday morning and that’s exciting and builds rapport and communion.

Send my :heart: to Margaret, she will be missed indeed! Congratulations to @janie on her new role.

2 Likes
7

Thank you for the kind words. The encouragement is fuel! I love the F1 post connected with you. Someone else mentioned something similar to me. :slight_smile:

Please shoot me the article when you are done.

2 Likes
8

Recently, various chains have a third-party developer reward program. But with 21 million limit caps, it seems difficult to make a third-party developer reward pool. Any good ways to do this?

1 Like
9

I appreciate your interest :heart:
Sure, I’ll let you know ASAP it’s done and posted.

10

Hey @joshs @paulbrigner, seems like according to FIT21, Zcash should plan expiring the dev fund, otherwise risks being considered a security.

FIT21 seems to be introducing the “howey test of crypto”>

  1. power rule

tl;dr must be permissionless to use

  1. ownership and voting

tl;dr no insider / affiliated person with more than 20% of supply

  1. no changes without consensus (PoW/PoS) or agreement of DAO

  2. no marketing as investment

  3. 100% of last 12-month inflation must go to end-users!

What’s your take? I’m posting here just to make sure this doesn’t get unnoticed. I’d have created a new thread on FIT21 discussion, unfortunately, I’m unable to do so.

1 Like
11

point 5 seems to be critical why to expire the dev fund

1 Like
12

Astute.

FIT21 is what prompted this comment:

While the bill did get through the house yesterday with bipartisan support, it has been expected to be killed in the Senate until major changes are made. That said, with the winds shifting so quickly in DC, and so much industry support (even tho not really wanting to be passed as-is), I have concern and its something the community should watch closely - both as it relates to funding and governance.

I’ll share back what we learn in our conversations with legal.

5 Likes
13

@joshs

Josh, I have a request about Zashi. I discovered this when I tried to post to ZecPages. There is a practice of adding various additive prefixes to the address. It’s a very handy thing to have. But Zashi doesn’t seem to want to work with it. I’ll explain what I mean with examples.

A QR code containing information like:

zcash:<address>

lets the phone know that the QR code being read by the camera is intended to be opened by the “Zcash” app

zcash:<address>?amount=0.001

allows you to open the QR application on the sending page, enter not only the address, but also the amount

zcash:<address>?amount=0.001&memo=SGVsbG8sIEpvc2gh

In addition to the address and amount, it will also write "Hello, Josh!"

This is super handy functionality that, for example, Zingo! understands!

I don’t remember what kind of ZIP it is, the developers know better. Perhaps @pacu or @zancas will help with it.

btw, I’ve finished my honest review https://youtu.be/LpDSIX796AQ

4 Likes
14

Yeah, that’s called PAYMENT URI. Devs should definitely implement this in Zashi, it’s supposed to be a standard thing (not sure if there’s a ZIP for it). Good catch! I think the best way is to send feedback to Zashi devs directly, but hopefully it arrives to them anyway even from here.

3 Likes
15

This is ZIP 321: Payment Request URIs. The ability to encode a payment request into a string that can be scanned by a wallet app is Very Useful :slightly_smiling_face:

This is Horrendously Unsafe :slightly_smiling_face:

Why it is unsafe is non-obvious to regular users! So I’ll try and expand on the problem.

This general approach has a few names:

  • RFC 3986 calls it a Uniform Resource Identifier.
    • The “resource” in our case is a Zcash payment request, which is self-identifying (change any part of the payment request, and you get a different payment request), and short enough that we can embed it directly in the URI instead of embedding a short identifier for it (vs how e.g. a transaction ID is a short identifier for a transaction).
    • A “URL” refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism.
  • Android calls it a Deep Link.
  • Apple calls it a Custom URL scheme.

The “scheme” is what denotes how to parse the rest of the URI. For website URLs, the scheme is either http or https. For ZIP 321 payment requests, the scheme is zcash.

The “Uniform” in URI is there because uniformity in encoding (namely scheme ":" hier-part [ "?" query ] [ "#" fragment ]) enables anyone to parse a URI even if they don’t understand a given scheme. However, what do you do once you’ve parsed a URI to determine its scheme?

  • If the scheme is http or https, the phone knows what to do: open the user’s configured default web browser.
  • If the scheme is tel, the phone opens the call window.
  • If the scheme is myfunsurprise, the phone… does what?

What Android and iOS both chose to do is allow apps to register themselves as handlers for non-standard schemes (see the above links). And herein lies the problem: any app can register itself for a scheme, including apps that you do not trust (or that you trusted at some earlier point in time as e.g. a flashlight app, but were later updated to include Additional Fun Features). This creates a privacy problem: if you scan a QR code containing a ZIP 321 payment request, and the wrong app is registered to handle it, then that app learns everything that the payment request contains (recipients, amounts, private information in memo fields).

On Apple, users have zero control over this:

If multiple apps register the same scheme, the app the system targets is undefined. There’s no mechanism to change the app or to change the order apps appear in a Share sheet.

What that means is if multiple Zcash wallets handling these URIs are installed, only one of them can receive these payment requests (which is a separate UX problem with scanning payment requests with the OS camera entirely). And if a malicious app registers itself as a handler and gets lucky, none of the user’s wallet apps will receive these payment requests.

On Android, there’s an even worse problem: apps can detect what other apps have registered themselves as handlers for a scheme. This leads to two attacks:

  • Wallet enumeration: a malicious app can determine what Zcash wallets (that support zcash: Deep Links) you have installed on your phone.
  • MitM attack: a malicious app can advertise itself as a zcash: handler (pretending to look like a real Zcash wallet), and if the user accidentally selects it, the app can take the payment request, edit it to contain its own recipient address, and then use an explicit Intent to open the user’s real wallet app (that it detected) with the edited payment request.

What this means is that it is insecure to scan zcash: payment requests outside of your already-trusted Zcash wallet app. Instead, you need to first open the Zcash wallet app, and then use its QR code scanner to scan the payment request.

Unfortunately, scanning QR codes at the OS level is something many users are used to doing:

  • Android users have installed QR code scanning apps forever, and modern Android versions usually have a helper button inside the camera app to switch to QR code scanning mode.
  • Very recent iOS versions have added a direct QR code scanning button to the pull-down menu.

Training Zcash wallet users to not do this will be tricky, but is necessary if we are going to popularise zcash:-style ZIP 321 payment URIs. One idea we’ve been considering for Zashi is to register a zcash: handler, but have the app ignore the data it receives and pop up a modal that tells the user “Here’s why we don’t support this, use the camera inside Zashi instead” (and then only actually trust zcash: URIs from the Zashi camera). That still suffers from the wallet-enumeration problem on Android, but it at least means that users get some kind of education about the privacy and loss-of-funds problem, and it eliminates the risk.

The way that Android and iOS fix this security problem for modern apps is by not using custom URIs at all; instead they use https URIs with domains that self-authenticate (the domain hosts a file that contains specific app IDs that are approved for use). See Android App Links and iOS associated domains. But that then means whoever controls the domain controls what apps can be used with it (which is the point, but is also a bit of a problem in fully decentralised settings).

6 Likes
16

Jack, thanks for such a detailed response. That side of it wasn’t obvious to me, but I get the point. I hope you find a better way.

2 Likes
18

Zcash wallets can support URI parsing without publicly posting it to the OS to avoid wallet enumeration as @str4d said.

Although Apple limits the “can open url?” Calls. I’m not sure how much of a danger it is to implement URI schemes in the OS level given that a malicious app would be already capable of claiming the uri, if legit apps cease to claim it they end up maximizing the attack surface instead of reducing it. Least Authority might know best.

About ZIP 321 URIs, I developed native libraries to understand these URIs on Android and iOS, but I haven’t had the bandwidth to integrate them to all wallets and to be fair it puts me on a difficult spot to favor a wallet before another one, so I try to be even with the time I spend with every team because I’m an advocate for the wallet ecosystem.

Any zcash wallet can use those libraries. And contributions are welcome :smiling_face_with_three_hearts:

2 Likes