My cont thoughts on today's chat - Related to real world usability goals

In my opinion we need a zcash stablecoin to work alongside zcash. needs to be Ultra fast. One way to speed up payments may be a AMP like collateral mechanism built into zcash (is this possible)?. if the community funds the collateral pool, the transaction cost may be close to 0 and we could get instant clearing. Back the stablecoins with short term treasury bonds, where interest received flows directly to owners after small transaction fee which helps support collateral pool and where transaction fees also go to buy zcash for the ECC/foundation treasury to fund future development and/or pay out to zcash holders so zcash and zstablecoin becomes yield bearing.

  1. privacy - seems like this is fairly solid technology
  2. stability - it’s hard to see z cash ever being stable enough to get people to use it for everyday transactions. bitcoin other positive attributes are outweighing privacy
  3. speed - need instant clearing. we don’t have this.
  4. yield. zcash would benefit from being yield bearing in some way. either by transaction fees; burn mechanism or stablecoin with backing by yield bearing government securities with flow through mechanism and zcash benefits by more transaction fees on network
  5. network/reliability - useability. not great. seems reliable but very complex UIUX and not user friendly.

There is a saying “cash is trash”. There needs to be some incentive (yield) to own zcash, privacy alone won’t be enough. and it just wont work for everyday transactions because who wants to hold something like zcash to pay rent when it might go down by 10% or more. most people live paycheck to paycheck. the average person is not the ideal zcash owner because they need their money to be stable first and private second. people with money need stability and yield in my view. otherwise it’s safer in a bank.

  1. is something I’ve been asking for weeks. Thank you no one up until now would tell me why we can’t have services running in the background.

However, it does seem odd to me that the people who can solve zk proofs can’t get services to run on mobile platforms. Another example is why I think hiring an app developer 3rd party who does this already is a better option than trying to learn it in-house and be an app expert.

I once was a cannabis grower and ran a very large LEGAL cannabis greenhouse in Colorado. 6k plants at a time.

I learned some very very critical lessons that apply here. We were selling to be blunt, drugs, the easiest thing to sell on the planet right? everyone wants it…

A) We grow only the best, organic cannabis. I mean the best soil, sun, microbial life… We have a biologist on staff. We had a custom 3 million dollar state-of-the-art greenhouse with full automation for the ecosystem… It cost 40%-60% more per gram to produce organic than non…

(Problem) Only 1% (if that) of Colorado consumers care at all about organic cannabis. 60% don’t even know the difference or risks.

(Just fix it…) No amount of education, no amount of marketing, no amount of passion was going to change whether consumers in Colorado cared about it at that point. I feel privacy is the same way right now. You can’t educate or perfect a product to solve this issue.

Our solution was to wrap the organic cannabis in blunts and pretty packaging to help sell them to the consumers who were looking for blunts and it worked for a while we sold millions of them. Sadly the move was too late and the company after 5-8 million spent collapsed. They sold millions of blunts and had countless happy customers… but over all it didn’t matter because the focus the entire time was on the tech “organic” and not on the custom. The best “products/tech” are still useless if there are no customers.

Many many developers think that if I build it, and build it really well they will come. This is 100% bullshit. I blame Field of Dreams. Among us took 4 years on the market failing before a youtube influencer did a video on them, only 6-8% of games on steam make over $10k ever doesn’t matter how good they are. Today Among us is a household name because of that 1 video. Most likely if that person didn’t do that video you would have never heard of them. No matter how good the game was.

I learned very very clearly you can’t change consumers quickly regardless of how much you try. You must pivot and find a way to meet them where they are. (IE Make a product they want to use on top of zec)

They will not come to you in any short period unless you are investing Mr Beast money, who has launched credit cards/apps, when he does it he gives each person who signs up a $1 if they connected a bank, to get them to adopt, and a chance to win 100k or something. Regardless of how scummy something might seem, those apps are getting used. If you build it they will not show up. They don’t know about it, they don’t want it because it doesn’t help them or meet them where they are.

There should be a directed focus IMO to make a product that users want to use in the large demographics you want to target outside the fanboys.

  1. You must own the custom and the customer relationship. As a grower we had to go through other stores to access the customer. When times got hard they survived because they owned the customer relationship. We did not. Having Binance or exchanges own and be the main interaction point for your customers is a major issue in my mind.

You cannot run a service in the background that does synchronization because the Android and iOS operating systems stop it. It has nothing to do with the skills of the mobile devs.


I agree that implementing anonymous messaging by mining every single message into a blockchain doesn’t really make sense, given alternative p2p methods for communication and data storage with equivalent privacy properties. The key challenge is giving those p2p alternatives the same kinds of privacy properties we’d expect for Zcash transactions.

A crucial factor of my argument is that scaling anonymous messaging and scaling anonymous transactions are really the same theoretical problem, because of the following argument. (This will sound ridiculous to anyone who isn’t familiar with the computer-science concept of a reduction.)

Imagine you have scalable anonymous transactions. Then you automatically have scalable anonymous messaging (up to constant factor overhead) because you can encode your messages into the transaction values. If I want to send “HELLO”, I just send you transactions that encode the ASCII message into the values: 0.0072, 0.0069, 0.0076, 0.0076, 0.0079.

OTOH, if if you have scalable anonymous messaging, then you automatically have scalable anonymous payments (modulo blockchain latencies for confirmation/authentication): just use your anonymous messaging layer to send the note ciphertext to the recipient, and then they only have to wait for the note commitment to appear in the blockchain, no need to scan.

Because of this connection between the two problems, scaling one scales the other, and the privacy properties of one determine the privacy properties of the other. The problem with just sending messages p2p (e.g. over Tor) is that it gives up on the privacy properties that Zcash is known for (e.g. it becomes vulnerable to global passive adversaries).


Well… We don’t have scalable private transactions… I agree that if we had them, the rest would go along.
But to me, it is the same argument as “if we had fusion, we wouldn’t have an energy crisis.”


@hanh already noted the issues with running background services on mobile devices, but also consider, just in terms of usability, the experience of any developer using almost any library that’s out there. A Python developer just runs pip install <package> and then can immediately begin writing code; a quick import <package> at the top of their source code file and immediately they have fast-performing functions for all the functionality they wanted. If you’re a PayPal or Bitcoin dev, you have the same available to you, because transaction data is available through fast requests over the web (but it’s not private).

Consider also the plight of a WordPress extension developer: you can either expose an API whose calls encompass all of the syncing and delay page rendering by hours (or more likely run into request response timeouts) or somehow shoehorn-in background syncing into WP hosts that don’t support full access to the server (e.g. by using crontab).

In a lot of environments—mobile, web, and more generally just in terms of usability—background syncing just isn’t viable.

1 Like

Sure, the dev experience is far from ideal. I am actually considering exposing the ywallet core in nodes but it is complicated. I am afraid zcash is much more complex than BTC though.


Edit to add this tl/dr: A scalable private payments design derived from Zcash may enable new high-bandwidth applications including micro or mini-payments; but while I’ve brainstormed and am excited about the possibility, I don’t know if what I imagine is possible.

I still believe there’s an important under-explored design space at the intersection of L1 scalability, private messaging, and data availability.

For scalability, as much as we can restrict data to only being stored or transmitted between the parties that directly need it, the better. A counterexample is note contents and memos in current shielded Zcash: only the sender and recipient need to ever see those, but all nodes store them and they are transmitted to every current and future node (lots of duplicate bandwidth).

Meanwhile, for privacy, as much as we can restrict data to only being stored or transmitted between the parties that directly need it, the better. As a cryptography-happy crowd we’re often fine with ignoring this and just relying on cryptography to protect confidentiality, but another way to protect confidentiality is to just avoid sending the data to the wrong people in the first place.

So it really seems like there’s a deep connection between scalability and privacy to me, since achieving both involves limiting where data is sent to only necessary parties.

This is the kind of thing I have occasionally brainstormed about as a side-hobby. The last time around (a while ago) I had written up thoughts with the name Modular Scalable Payments Architecture. (I haven’t updated that since I last pinged you about it @earthrise .)

The key idea is “can we shift around data availability concerns safely so that data that only needs to be seen between specific parties only needs to be stored/transmitted between them and no one else”. It’s not an easy trade-off, because currently wallets rely on the network to store all their private baggage, which is great for restoring from a seed or storing-and-forwarding new incoming transfers to wallets that have been offline an arbitrary amount of time.

So the two big UX challenges with that approach are: (a) how can we ensure offline wallets can still receive transfers, and (b) how can wallets restore safely from backups?

-plus all the privacy and consensus challenges. :wink:

However, if there were a good solution, then presumably it would work well for higher bandwidth p2p usage. If the storage/bandwidth for the overall L1 did not grow linearly with what users send to each other, and/or if the latency of those messages weren’t bottlenecked by consensus, then generic messages, media, API calls, etc… could be bundled together with transactions within the same (idyllic/unicorn) system.

That’s the dream. :wink:

ps: One other reason the idea excites me: a lot of the scalability research across the crypto industry is focused on general programmable systems without privacy. This is way harder!

General programmability means it’s not clear up front which parties need access, and a lack of privacy means there’s not even precision or clarity on who that is. For example, DEX last-trade-prices may be consumed by many completely off-chain actors!

By contrast, if we have private transfers from senders to recipients, the number of parties is relatively small and completely explicitly defined by the privacy constraints. So maybe the design space is much easier than the rest of the industry’s scalability goals.

So it may be that no one is looking at this particular niche of design space, and Zcash could lead in this niche. I would guess that layer 2 payment protocols, especially lightning are the closest in the use case and adoption here. (The idyllic/unicorn MSPA would not have the liquidity constraints that lightning has, which seems like a major advantage if a real unicorn MSPA could be found.)


There is also an anti-connection between privacy and scalability: whenever an adversary can be sure that Alice did not receive a particular message, they can be sure that Alice wasn’t the intended recipient of that message (or the messaging system is lossy). This is one of the key reasons network-level anonymity is so hard: learning that a bunch of people didn’t receive a message gives you information about who did receive the message. This is ultimately why decoy-based systems don’t work, and the engineering challenge is to make it look like anyone could have been the recipient of the message as efficiently as possible.


Couple of quick points:

  1. adding anonymous messaging to zcash is an interesting idea who’s time might be now (in the past I’ve thought it wasn’t worth focusing on)
  2. you’re going to need to do it at the mempool/ p2p layer.
  3. There’s no deep link between anonymous payments and anonymous messaging.
    Payments require consensus on who pays who. Messages do not. You can’t build payments out of messaging, there’s no double spend prevention.

There is a link between anonymous payment notification and anonymous messaging.
And in fact, it’s pretty trivially clear that for zcash to scale, at some point we have to move beyond nodes scanning the blockchain and decrypting every ciphertext. Zcash payment URLs were intended to address this by using existing messaging systems, but could be used in a purpose built one.

TLDR: you need a separate anonymous messaging layer. Development/ dependence wise, its mostly seperate from Zcash. They can be tighlty integrated (e.g., have a mixnet where the nodes are PoS nodes, though thats a security nightmare), but the designs are distinct.


I agree that theoretically, scalable anonymous messaging ⇏ scalable anonymous transactions (but it does ⇒ modulo the cost of syncing the note commitment and nullifier sets and checking PoW, which I don’t see how we can avoid). The reverse direction of the implication, that scalable anonymous transactions ⇒ scalable anonymous messaging, does hold, which I think we both agree on, and that’s what’s really the key here. I think that fact should guide our protocol development strategy going forward.

1 Like

My point is precisely you can avoid that cost for anonymous messaging and you are going to need to for any practical design. In fact, since payment notification itself is a scaling limitation, you are going to have to even just for Zcash without general purpose messaging.

Design an independent anonymous messaging system and then integrate it with zcash. Don’t try and design from scratch some blockchain specific thing, you will get stuck.


Afaik, all zk based scalability work use the account model, not the merkle tree utxo approach. It seems that even if the problem seems to be of a smaller scope for zcash, the large anonymity set presents a real challenge.


My overall point was there needs to be a use case we can be selling and evangelize to grow the user base right now. I thought private messaging would be an easy win. If it’s not, what would be?

Here is a different way of asking the question. In the current stage, zcash is at what app on the market could it replace that your parents and/or kids might want to use. Or would use it with some soft encouragement.

1 Like

This is an interesting opinion to bring, as the ZCG has had the memo-field approach as an open RFP for the past few months:

Its now on hold because of market conditions - but I wonder if the plans are to re-evaluate the whole approach then? Would love to know if that is the case as we have already made plans on how to build an approach just with the memo field.


Emphasizing This Point.

Perhaps its time to rebrand Zcash to remove cash
How about Zgold?

Yes, and this also explains the phenomena why mousetraps and toilets have rarely been innovated upon. New technologies or designs are not certain to be adopted… social behavior is not the same as the physics of gravity or heat

For the Topic of Scalability. A technical step toward solution is known proof Recursion, but how it can be built into Zcash at the protocol layer is not.

Great thread here everyone, thanks for the contributions

1 Like

I’m very skeptical that people are willing to pay for private messaging…

But I like the idea of have a messaging system using the Zcash network, but not using the blockchain. It would make a lot of things easier. I’m thinking about how to deploy FROST in practice and the hardest part is how to make the participants communicate which each other.

IMO another big hurdle is actually buying Zcash. It should be somehow integrated with wallets, which I appreciate is a big effort that would involve cooperation from exchanges from multiple countries. Here in Brazil I basically have to buy BTC and convert to ZEC.


The problem is that mobile phones are walled gardens. You can’t do whatever you want when it comes to develop apps.

Manufacturers put their own restrictions and background processing capping is one of them.

You can only have a quota of background processing and you get what the operating system provides, it could be zero, 10 seconds, minute or an hour. You don’t know when you are going to get the quota if any.

Also there are not reliable tools to test these bg tasks and it comes to wallet applications to request the background processing time.


FYI, this web site tracks how well/poorly manufacturers let apps run in the background.


Yes! buying/accessing/swapping to ZEC within wallets, and using it right away for sending money/messages, without any oppression is what we are aiming for in Nighthawk Wallet.

@secparam @earthrise The updated DAGSync mechanism needs to be evaluated on the efficiency and speed of message retrieval, but we could totally start with async messaging, something like the old-school BitMessage.