Cake Technologies Zcash Mobile Wallet Design & Development

Community Grants Applications
22

Hi @cakewallet , just following up here. ZOMG has a meeting next week where we plan to call a vote for this proposal.

A couple more questions,

You mentioned NU5 support but I didn’t see a specific mention of Unified Addresses in the proposal. Do you plan to support all three types of addresses? T, Z & UA? Or just Z & UA? Or just T & Z?

[ Going a bit off-topic here: I may be misunderstanding, perhaps someone from ECC can answer. @str4d @joshs ?] Does it eliminate the need for T support in a wallet if it has UA support? Meaning: any service (exchanges for example) that currently only send to T-addreses will automatically be able to send to UAs after NU5? Or is it still desirable to keep T-support with Auto-Migration enabled for the foreseeable future, at least until most exchanges /services update ? ]

Also, cakewallet, as part of this grant would you be willing to commit support Zcash through at least one more Network Upgrade beyond NU5 (NU6) before possibly applying for further funding?

Thank you

7 Likes
23

UA will contain both Receiver Types of T and Z right? I think supporting more than just a UA would negate the reason of creating UA in the first place. Ideally, wallets will only support UA.

This is a valid concern to still allow users to generate legacy T-address, if they were to receive ZEC from wallets that only support T-address and does not support UA. However, I would encourage wallet to just support UA as a forcing mechanism for others to follow. If, after a few weeks of NU5 activation and I am on exhange that does not support UA, I will move to an exchange that support withdrawal to a UA.

3 Likes
24

There is nothing that forces a wallet provide to include a taddr, but not including them within a UA would be a usability problem.

Users of a service that supports UAs, but not shielded support specifically which will be the case with most major exchanges, will not be able to send Zcash to the wallet.

However, the only way to access the Orchard pool is to through a UA.

Best practice is to support a UA that includes both a taddr and Orchard address, and supports auto shielding of any ZEC received to the taddr.

3 Likes
25

We outlined more specifics for addresses here:

https://cakewallet-my.sharepoint.com/:x:/g/personal/justin_cakewallet_com1/Ee0mjskmJCJMsJGelFdWE2UB4lGHqnPtBcMqBkJy6ilb1Q?e=Wsir0T

We have not considered allowing users to manually “extract” the base t-address from UAs, but we could do this in theory. I prefer that we only do this if no exchanges upgrade to support sending to t-addresses (or other addresses) that are in the UA format.

As currently written, we will support sending to:

  • Standalone t-addresses
  • T-addresses in UAs
  • Orchard addresses in UAs

As currently written, we will support receiving funds in:

  • T-addresses in UAs
  • Orchard addresses in UAs
  • Not currently added but possible with worse UX: Standalone t-addresses (which we would then auto-shield ideally)

We will display transactions sent/received with Sprout/Sapling addresses (eg: if the wallet was restored), but we don’t want to continue supporting these pools fully.

Also, cakewallet, as part of this grant would you be willing to commit support Zcash through at least one more Network Upgrade beyond NU5 (NU6) before possibly applying for further funding?

Is there a sheet out there somewhere with the NU6 changes yet? We fully intend to continue supporting Zcash without needing additional funding, but that will of course depend on how aggressive the changes are in NU6.

8 Likes
26

Not aware of any blog post or forum topics on this. I believe Zcash Developer teams are still focusing on NU5 activation and NU6 is not discussed publicly. However, what will be included in NU6 is likely informed by recent ZF/ZCAP poll, ECC ZEC holders poll, and other data points.

Most likely, the biggest change in the horizon after NU5 is ZSA or Zcash Shielded Assets (think ERC 20 on Ethereum). The ZSA proposal is currently being discussed here.

Thanks @cakewallet
Good luck with the proposal.

Edit:

I believe this feature is unnecessary. If it is, for example due to lots of user request as their favorite exchange only support legacy t-address, then this should be included as an advanced feature.

1 Like
27

Before anything, I’m Pacu, iOS developer and product owner of ECC’s wallet team. But I’m posting this as a community member in a personal fashion. This posts reflects my own opinions and thoughts.

Second preamble: I’m not going to question any cost related things, since I believe that it’s not my business to do so. And also I’m humbly suggesting others to refrain to barter development costs out of thin air. I guess for everything in life there’s someone willing to charge less money for the (supposedly) same amount of work. I don’t think that people quoting lower consultancy prices with the sole objective of plummeting the costs requested by the grant authors are bringing anything of value to the discussion.

Hi @cakewallet ! Thanks for posting this grant application! It’s really exciting! I’m a user of your wallet and also a lurker of your repository. I’ve always been interested in mobile app development and the different approaches one can find in the diverse projects of the open source space. Welcome!

Overall, If I were to be ask for a Yay or Nay on this grant. I go for Yay! just by reading the title.

I’ve been taking a look at the milestones and the spreadsheet you folks shared. It looks reasonable and straight forward.
I do have some things I would like to bring up. I’d split them into three topics: clarification questions, implementation risks and concerns, and some rhetoric insights

clarification questions

  1. Besides the Application, how would the Zcash community as a whole (users and developers) benefit from your work? Will your team contribute and build on existing tools?
  2. Are you planning to build your own SDKs or work with the existing ones? (zecwallet-cli or the Swift and Kotlin Zcash SDKs)
  3. Will other Flutter developers be able to benefit from your development? Will there be a Zcash Plugin similar to the Monero plugin? Will that be embedded on your app’s repo or live on a separate one instead?
  4. if the answer of question two is positive. Why is so? Are there any blockers that lead you to spin off yet another Zcash SDK? What are they? Would you be willing to collaborate on enhancing and expanding the existing tools so they help you achieve your goal if those concerns/blockers could be worked out?
  5. What is the rationale behind initially supporting Orchard only and sapling for the second milestone? Is it a time/resource constraint or a product decision?

implementation risks and concerns

How will you manage the fact that Monero and Zcash use different seed phrases? If I recall correctly Monero uses 25 words and Zcash wallets use 24 words BIP-39 compliant phrases. Will the user have to create a new set of words to use Zcash? (I’m not a cryptography expert at all, and maybe this is a dumb question)

UAs were created with the purpose of gradually moving away from the concepts of “addresses” and “pools” altogether. Basically, a group of people were brainstorming and one said “What if there was no such thing as an address, wouldn’t all this be much easier?” (pretty ‘Imagine’ vibes, huh? :sweat_smile:). The nature of UAs is abstracting the fact that there are pools and receivers to the users, to prioritize transacting ability and adding flexibility and future proving. So that regardless of your wallet’s capabilities there’s always a way of getting your Zcash from point A to point B. Concepts mentioned on this thread like Orchard only or T only UAs break UAs essence and bring back the original problem UAs are meant to be solving but with different string encodings. Even though it can sound operationally convenient in terms of development process, deploying such opinionated UAs could add needless friction to your user experience and lower the users’s perceived value from this feature. Would you reconsider this and maybe reprioritize work Items so that your app supports sapling receivers from day 1?

Rhetoric Questions Section
ZOMG grants are funded with a portion of the block rewards, meaning that the funds originate from within the Zcash community and their investment should be analyzed from the perspective of “what will this investment bring back to the Zcash ecosystem?”

I don’t mean to play devil’s advocate or pitch a dodgeball. I believe there’s value in elaborating and rethinking these proposals from different perspectives.

CakeWallet is a well known and reputable wallet product in the Anonymity Enhancing Cryptocurrency space, specifically for XMR. By visiting the Monero website, it’s easy to appreciate that CakeWallet is a flagship wallet of that cryptocurrency with several thousand users (that may or may not use Zcash) and a good reputation on both platform stores.

That being said. If the ultimate goal of this endeavor is to put a wallet that does both coins ZEC and XMR on people’s hands, why shouldn’t ZOMG instead issue a similar grant to Zwallet, Nighthawk or Unstoppable to bring Monero into their already Zcash capable wallets?

Could you tell us a little bit more about your product approach and let us know about how your approach is more beneficial than the one I just hypothesized about?

Again! thanks @cakewallet for requesting this grant! Best of Luck!

10 Likes
28

Hi folks!

I just read Pacu’s note here that he posted about his personal perspective (without Pacu asking ECC as a company to agree or disagree). Without me expressing agreement or disagreement with most of it, I wanted to respond to this one bit:

I really agree that the goal of UAs is compatibility, so that users who are considering using any wallet or any service (like a centralized exchange or a DEX) can know that it’ll “Just Work” without them having to learn about different address types or learn about which products are compatible with which other products.

And, UA’s are just one part of a larger goal — Shielded By Default! The goal of Shielded By Default is privacy with compatibility. The users should know both that it’ll “Just Work” and that their funds will be shielded.

The current definition of Shielded By Default is this:

  • Auto-shielding: UX feature in ECC Wallet SDKs that moves funds from a transparent address to a shielded address
  • Unified Addresses: Protocol feature that creates a single address encoding with multiple address types (ex – Transparent, Sapling, Orchard)
  • Support for the latest shielded pool: Orchard will be released with NU5. It is the latest, most secure ZEC pool and uses the Halo 2 proving system, removing the need for the trusted setup and upgrading the protocol’s underlying cryptography.

(Note: in the future as the technology and the marketplace evolves, we at ECC will upgrade our definition of what a wallet needs to do to protect their users in order for us to consider it to be a “Shielded By Default” wallet.)

So if Cake Wallet wants to support the Shielded By Default initiative, or if ZOMG wants to fund wallets that are Shielded By Default wallets, I’d suggest using these requirements.

This means that Sapling support is not a requirement for Shielded By Default! (Assuming the wallet ships after Orchard activates, currently planned for January 17, 2022:

Screenshot 2021-11-24 13.56.10
Screenshot 2021-11-24 13.56.101205×526 47.5 KB

Because the Shielded By Default requirement is “support for the latest shielded pool”, and after Orchard activates, that will no longer be Sapling.

9 Likes
29

Welp, we definitely need to come to consensus on what color our pills are!

9 Likes
30

Thanks for bringing this up. I focused on the receiver types and left shielded by default out of the analysis.

There’s then the question (for all wallets, not specifically to this proposal) on how wallets choosing not to support sapling will communicate this to existing users adopting them in the case they restore keys that actually may have sapling funds.

3 Likes
31

ZOMG can only fund projects that add value to Zcash as opposed to ZF which can fund projects that adds value to privacy (not 100% certain).

32

Congratulations, @cakewallet! The ZOMG met last week and approved your grant. We are excited for Zcash to be available for your existing community of users.

Thanks for engaging with our community in the above thread. We hope you will take their input into consideration, and work closely with the ZF and ECC teams in order for your wallet to be best presented and maintained for your users over the longer term (e.g. using ZF/ECC SDKs, creating architecture that best support future upgrades, etc).

Please provide your progress updates here so that the community can stay updated. For private updates, feel free to reach out to the ZOMG through a direct message on the forum, or through your ZF contact.

Good luck!

16 Likes
33

didn’t ZOMG fund some Tor project? I’m not sure that what you said is accurate.

edit: yep I mean Tor.

34

I think you mean Tor. Zcash Community Grants | The Zcash Community Grants program funds independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of the Zcash ecosystem.

4 Likes
35

Thank you for the excellent news! We consider this the first step of a long-term, mutually-beneficial partnership! We will absolutely keep these helpful comments from the ECC, ZF, ZOMG, and Zcash community members in mind, and we will provide updates on our development progress here.

13 Likes
36

I believe what he has said is accurate, and I think the Tor grant was granted on the basis that the team would prioritize Zcash compatibility during their work.

Some relevant quotes from ZIP 1014 (ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants):

“This slice of the Dev Fund is intended to fund independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of the Zcash ecosystem”

“Major Grants SHOULD be restricted to furthering the Zcash cryptocurrency and its ecosystem (which is more specific than furthering financial privacy in general)”

Now whether this is what has ended up happening or not is debatable, but I think it has generally held up, although we have been slow to attract “major” development teams so far (this seems to be improving though).

5 Likes
37

Congrats on the grant, really looking forward to seeing how this one progresses.

5 Likes
38

This is indeed possible, and an intended compatibility use case for UAs. By using the same t-address inside the UA as you give out to legacy services, you can just implement auto-shielding logic once for the UA, and payments sent to the t-address will automatically be included. I completely agree with you that this should only actually be done if your userbase demands it; having UAs that contain transparent receivers is the better interoperability approach, as currently-transparent exchanges only need to implement the new encoding format in order to be compatible.

Incidentally this is also part of why ZIP 316 specifies that transparent-only UAs are invalid: there’s no justification for the cognitive complexity of having another transparent-only address format, when t-addresses are already well-supported in the ecosystem. As a bonus, UAs are always guaranteed to contain at least one shielded receiver, which means that an exchange that adds UA support can start collecting metrics on how many of their users would withdraw to a shielded address if the exchange supported it (which is a great way to justify shielded integration).

6 Likes
39

What does this mean in plain english? I thought UA is an encoding of all address formats.

40

UA can contain multiple receiver types (i.e. current address formats). So a UA for example can contain a Sapling receiver/address, Orchard receiver, and Transparent receiver.

As explained previously, a UA cannot contain just Transparent receiver. A UA must have at least one shielded receiver. A wallet might decide to only support Orchard but not Sapling, such as the Trezor Model T app currently in development.

So, a UA can encode all address formats but individual wallet/app can choose what pools they support.

3 Likes
41

so if somebody is sending ZEC to UA address that has Sapling & Orchard receiver, where does the funds go?

1 Like