New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guarda Zcash light wallet #16

Open
AndrewGuarda opened this Issue Sep 13, 2017 · 51 comments

Comments

Projects
None yet
@AndrewGuarda

AndrewGuarda commented Sep 13, 2017

Guarda Wallet team application for Zcash foundation grants 2017Q4

Motivation and overview

We are a group of blockchain enthusiasts with background in software development and product management. We have a distributed team from EU, Russia and Ukraine. At the moment we have experts from IT, fintech, blockchain, security, marketing, design, UI/UE.

Recently we have united together to develop a project called Guarda. Mobile cryptocurrency wallet which would make using any cryptocurrency easy, accessible and secure.

Our wallet for the first currency was launched this week in Google Play

Zcash is one of our favourite blockchains thanks to technological supremacy, great development team and clear value proposition. As a team of crypto enthusiasts we believe in anonymity as key feature of decentralized currencies and blockchain technology overall. Zcash already is in our development roadmap. However development of Zcash light wallet is yet an issue due to the lack of open source mobile light wallet implementations.

Technical approach

We are guided by several core principles:

  • Building trustless solutions.
    If customer wants to rely on other cryptocurrency node he\she can type in this information.
  • Multicurrency approach.
    We thoroughly choose best cryptocurrencies and willing to support them all.
  • Respect customers privacy.
    We do not require any KYC or customers data. No registration is required as well.
  • Never touch customers funds.
    The proposed wallet is a light wallet allowing customer manage his\her keys himself
  • Never touch fiat.
    Purchase of cryptocurrencies will be delivered in collaboration with professional payment gateways.

In general the wallet consists of the following parts:

  • Server side node
    Blockchain community developed solution. Open-source and distributed free
  • Lightwallet library
    This allows you to work with the cryptocurrency blockchain, without the additional overhead of having to write your own integration code for the platform. Usually the library interacts with the server side node through JSON RPC. As we are applying for a grant we believe this part of our work should be open sourced and available for public on a royalty free basis.
  • GUI layer
    Customer experience oriented graphic user interface running on mobile operating system of the mobile phone.

High level architecture can be described as follows:
hl arch
Network HL architecture:
net hl arch

We have three basic stages for the wallet implementation.

  • Everything starts from the own blockchain nodes deployment. We have own primary and backup nodes for the wallet support. In addition we offer a range of third party nodes that can be applied by user. We are using sophisticated proxy for the node balancing in order to get up-to-dated blockchain status.

  • The next step is mobile client library implementation. It is used by mobile wallet to manage transactions and abstract blockchain, security, cryptography layer from GUI developers.

  • The last stage is the design implementation of mobile application. We are thriving to use trendy and cozy interfaces in our wallets to provide best customer experience.

We are developing light wallet which means that user private keys are always under the user control. The private keys are always on the customer device and managed only by user. The wallet signing a transaction on the device side and transmit the signed transaction over Internet using ssl to blockchain node.

The Guarda wallet implemented functions are:

  • send coins
  • receive coins
  • exchange cryptocurrencies to zcash,
  • PIN code app protection

To be implemented in following two months (before Zcash wallet to be released):

  • purchase zcash for the fiat .
    Our committed partners for card transactions and SEPA payments are available to be disclosed upon request from Grant Review Committee.
  • other node usage
  • mnemonic phrase
  • password encrypted keyfile

Team background and qualifications

  • Paul S., CEO, has three years experience in blockchain, 10 years in fintech. Certified banking cards security and business expert. Launched over 6 successful projects within last three years. Paul interests are: cryptocurrency exchanges, wallets, smart contracts, oracles.
  • Ondrej H., product manager, has 15+ experience in IT product management. Has in the portfolio projects from mobile ads, SaaS enterprise solutions, high load IT solutions, mobile app development and production.
  • Vlad A., senior Android developer, 7+ years of mobile development
  • Valentin S., senior Android developer, 6+ years of mobile development
  • Alex N., senior iOS developer, 6+ years of mobile development
  • Roman L., senior backend developer, expert in blockchain, has 3+ years of experience for blockchain development, cryptocurrency mining, etc.

Evaluation plan

We have quite tiny and reasonable schedule for the wallet implementation. The distributed team with a variety range of professionals gives us ability to launch in the parallel main project phases: blockchain node deployment, mobile library and wallet GUI development.
We are using agile approach with continuous delivery, so in any time of moment we are ready to present our progress and performance to the Grant Review Committee.

Security considerations

Security is our priority. The light wallet approach itself is our vision for the secured blockchain wallet. The customer private keys are the most important and sensitive aspect.
We store keys in OS secure storage in an encrypted form.
We are using additional product features to increase the product resistance for the attacks. The team has already implemented PIN-code for the wallet access, password keyfile encyption is expected by the middle of October.
At the node side we are using network security tools, like a WAF with ML.

Schedule

We are estimated the whole zcash wallet duration as 11 weeks:

  • 1 week hosting & node setup, UE
  • 2 week node proxy, setup net security tools, mobile library, UI mock ups
  • 3 week mobile library development, UI prototyping
  • 4 week mobile library development, UI design
  • 5 week mobile library development, mobile app implementation, UI design
  • 6 week integration with third parties services, mobile app implementation
  • 7 week mobile app implementation
  • 8 week alfa release, QA, bug fixes, mobile app implementation
  • 9 week QA, bug fixes, beta-release
  • 10-11 week Project Risks worked

Budget and justification

We have estimated preliminary costs estimation for 60K USD for the project that will cover almost all issues.

Facebook
Twitter
email
github

@tromer tromer added wallet UX labels Sep 15, 2017

@tromer

This comment has been minimized.

Collaborator

tromer commented Sep 17, 2017

Congratulations for the launch of your Ethereum wallet!
Is it open-source?
How much of that code will be reused for the Zcash wallet?
What are your thoughts about supporting Zcash shielded transactions and z-addresses?

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Sep 17, 2017

Thanks! It's been a rush :) However a lot to be done in the future.

  1. For the moment not. However, we will be open sourcing all the libraries we develop for the SVP wallets (if there's none existent at the moment). The best example of such a library is web3j. The library will be available for Android and iOS.
  2. The GUI code will be reused (Business layer and UI layer on HL scheme). Most of the work is carried out in the SVP library.
  3. If we develop the wallet we will support these. That's core functionality of the Zcash blockchain. Without the support of shielded transactions, the wallet would make no sense.
@tromer

This comment has been minimized.

Collaborator

tromer commented Sep 30, 2017

@guardaco, about shielded transactions:
Generating shielded transactions is currently very expensive: about 40sec on a desktop CPU (so minutes on a phone), and 3GB of application RAM (too much for most phones). zcash/zips#104 and https://z.cash/blog/cultivating-sapling-new-crypto-foundations.html will help but are not available yet. So what are your plans for this, short term and long term?

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Sep 30, 2017

@tromer Thanks for the question. You're right, the shielded transaction will occupy the device resources for a long time. We are not willing to become a bleak light wallet. We are looking for the suitable UE solution in order to fulfill the customer’s expectations. In the short time terms, we’re considering to use one of the following approaches:

  1. The shielded transactions are available for all devices. It sounds like a doubtful idea, some devices probably can be stucked, anyway we need to check it. We’re going to perform the test/benchmarking how it will work in order to evaluate this approach.

  2. The shielded transactions will be available for the powerful devices only. We’ll rate the devices based on it’s hardware. The shielded transactions will be available only for the high-rated devices with suitable transaction calculation time.

  3. Spreading the calculations between the customer device and guarda server. We’ll use a secure way to communicate with server to keep the privacy.

We’ll choose one of the mentioned above approaches (or tune it) based on R&D results. It should meet our expectations for reasonable shielded transactions implementation.

We are going to use further/ongoing tools from zcash foundation to improve the UE in the long time terms.

@acityinohio

This comment has been minimized.

Collaborator

acityinohio commented Oct 4, 2017

Every informal proposal has multiple reviews by the review committee. The reviews are being collected and discussed in a private google doc (the 5 reviewers all have edit access to it, no one else can view it). By way of early, informal feedback, the reviewers have made a list of projects that they consider leading candidates for grant funding.

In that vein, your project was selected as one of the leading candidates, and the review committee encourages you to submit a full proposal by October 6th and looks forward to reviewing it.

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Oct 4, 2017

Hey @acityinohio it's really great to hear that community has chose our project as short-listed one. Could you clarify the structure, content for the great full proposal or just give us any tips how to create it.

@tromer

This comment has been minimized.

Collaborator

tromer commented Oct 4, 2017

The full submission should be a single file attached to this Issue, structured as explained in https://github.com/ZcashFoundation/GrantProposals-2017Q4. I see you've already followed this structure, so just double-check it and put a copy as an attachment here (so we can refer to a specific, time-stamped version).

@tromer

This comment has been minimized.

Collaborator

tromer commented Oct 5, 2017

@guardaco The tentative $60k budget is a large fraction of the total funds available for the 2017 Q4 Grants round, and this affects the probability of funding the proposal.

Is it feasible to break the work into two stages, allowing the committee to fund only the first stage in the current Grants round, and hopefully fund the second stage in the next Grants round? If so, please include both stages in your proposal, but demarcate their schedule and budget. The first stage should still be meaningful and useful by itself.

Also, please clarify your position on open-source distribution of the code. Is it accurate to say that the server-side code and client-side library code will be open sourced, but the client-side GUI will be proprietary? In this case, my opinion is that the GUI development costs should be excluded from the budget.

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Oct 5, 2017

Dera @tromer , sure, we can divide the project scope for two stages: Android (most popular) wallet & iOS wallet. Both wallets require SPV library and mobile application development, only the node setup is а common task. So we can use the mobile platform as a demarcation point. We can divide the total budget for two equal parts in this way, 30K each. Hopefully it should work.

Regarding open source policy issue - we agree to make open sources for SPV library and Server. GUI will stay our proprietary solution. We haven't included GUI in the quotation. It will be reused from our ETH project with design changes only.

@acityinohio

This comment has been minimized.

Collaborator

acityinohio commented Oct 6, 2017

Also just a reminder @guardaco that the submission deadline is October 6th! Please endeavor to have a final proposal submitted by then, as an attachment to this issue (and yes, it can be October 6th anywhere in the world).

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Oct 6, 2017

Dear Zcash team, please find attached application for the Q42017 grant.

The application for Zcash foundation grant 2017Q4.pdf

@tromer

This comment has been minimized.

Collaborator

tromer commented Oct 13, 2017

I see that there are quite a few light Zcash SPV wallets: https://www.zcashcommunity.com/wallets/ .
I understand the proposal will have an open-source SPV server and library, which AFAIK none of those provides. Are there other significant differences?

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Oct 13, 2017

Dear @tromer, we believe that following three points will answer your question:

  1. SPV single currency wallet will definitely bring more brand awareness. Existing of Zcash-only light wallet helps blockchain to stand out of the list among other currencies. AFAIK no SPV single currency wallet is available for the moment.

  2. Our proposal includes open source option for the server side and SPV library that will drive the Zcash ecosystem services development. It can be used by the community and 3rd party developers for new exciting product launches on top of Zcash blockchain.

  3. Shielded transactions support is the key to the blockchain anonymity growth. Our proposal fulfillment can help solve the problem of efficient amount of shielded transactions which leads to even more anonymity of Zcash blockchain.

@tromer

This comment has been minimized.

Collaborator

tromer commented Oct 15, 2017

@arielgabizon and @ebfull proposed an improvement to the current Zcash code that will reduce memory consumption of the prover to around 1.4GB: zcash/zcash#2243

That's small enough to fit on a modern Android phone with 3GB or more of RAM. (I think the Android OS will let a process allocate 1.4GB on such a phone.) Though it will still take several minutes of computation, and ~1GB of device storage for the proving key.

And this will probably be available before the other two solutions (delegated proving and Sapling).

So, how difficult would it be to take zcashd's shielded-transaction code and use it in the proposed Android SPV library? Can it be refactored into a stand-alone library? Note that Zcash's shielded-transaction code directory originated from libzerocash, which is a stand-alone library. Should such a library include more than just the shielded-transaction handling?

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Oct 16, 2017

Dear @tromer,
Dear zcash team.

It’s really great to know zcash still working for the performance of shielded transactions. Looks like we have a good chance to process good enough with shielded transaction using mobile light wallet.

It’s hard to make proved estimation regarding SPV library development difficulty level beforehand. The change request for the reducing of memory consumption is pending and it isn’t included in the master branch of zcash. We need to have a look in to the details of the pull request, perform necessary R&D and test it with number of devices. In the theory, it should help to solve only the issue of the optimization calculations for the shielded transaction at the device side.

We’ll release stand-alone library that will support SPV for Android. It’s not library for shielded transactions only. It will use JSON-RPC to communicate with zcash node and will support necessary methods for the light wallet:
- create wallet
- restore wallet
- load wallet balance
- transactions history
- send the transaction
- shielded transaction support
The library will be open sourced and will be available for using by 3rd parties.

@acityinohio

This comment has been minimized.

Collaborator

acityinohio commented Nov 21, 2017

@guardaco : I'm thrilled to inform you that the Grant Review committee—and the Zcash Foundation board—has tentatively approved your proposal! While the recommendations are already posted, we are planning to make a more public post tomorrow morning (November 21st) Pacific Standard Time.

Next steps: please email me josh [at] z.cash.foundation with an email address suitable as a point of contact. Due to our newfound 501(c)3 status there are additional reporting and compliance burdens that may delay or change disbursements, but we are working through them as fast as we can.

Just in case you didn't see it, please find the committee recommendation for your project below, and congratulations again!

Proposes to develop a mobile Zcash wallet for Android. While several mobile wallets are already available, this one will be tailored to Zcash in UX and capabilities, including support for shielded transactions (as soon as this becomes technically feasible via low-memory proving or Sapling). Moreover, the SPV back-end and client-side library will be released as open source, that can be used in other prospective Zcash SPV solutions.

A risk factor is the dependence of the Zcash-specific portions on code that is currently in zcashd, and will need to be refactored into libraries, forked or reimplemented; but the same issue will arise with other efforts to support the full Zcash functionality, so it's important to start tackling it.

We recommend collaboration with IDEO CoLab on the UI design.

The team has prior experience developing mobile wallets, and the budget is reasonable.

@acityinohio acityinohio added the awarded label Nov 21, 2017

@tromer

This comment has been minimized.

Collaborator

tromer commented Nov 21, 2017

The low-memory prover is integrated into the Zcash v1.0.13 release, and with memory use around 1.4GB, in principle can be used to create shielded transactions in a mobile wallet.

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Nov 22, 2017

That's really awesome update. Guarda team is proud to be able to get the support from Zcash foundation. We are looking forward to the project beginning.

@mineZcash

This comment has been minimized.

mineZcash commented Dec 16, 2017

Any progress updates on this @guardaco ? Is there a github repo anywhere with your work?

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Dec 16, 2017

hey @mineZcash we are in progress with UI/UX at the moment. Would you like us to put updates here? It will be great to have like the weekly updates.

@acityinohio

This comment has been minimized.

Collaborator

acityinohio commented Dec 18, 2017

Just to add on @mineZcash's comment, would love to see a GitHub repo, updates here, and/or blog or email updates! The grant program is new and while we don't have a strict reporting/updates requirement (other than the final report six months from now) it would be great to point to progress on grants on a semi-frequent basis.

Additionally, after this point by @mineZcash in Zcash Community chat (https://chat.zcashcommunity.com/channel/the-zcash-foundation?msg=rx822kt6tscW6cAzm) it sounds like others (@hoffmabc from Open Bazaar and @jasondavies) are either working on SPV code or could benefit from it. If you've done any work, or want to contribute to theirs, I thought I would at least mention it to connect you all.

@lindanlee

This comment has been minimized.

lindanlee commented Jan 4, 2018

@guardaco, I'm a UX researcher for zcashco. If it would be beneficial, I am available to collaborate on the UI/UX of the Zcash wallet. I'd be willing to do a current UX evaluation of any prototypes, perform user research, or help design any layouts/elements that you need.

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Jan 4, 2018

@lindanlee Hello Linda,

Nice to meet you, I’m Andrew from Guarda team. I’m expressed Zcash foundation attitude and help for our project.

It would be nice to have your opinion about the wallet UX. You can see the current releases that are available on google play: https://play.google.com/store/apps/developer?id=guarda.co as we announced in our proposal we are going to adopt the existing UX for Zcash solution. So it will be great in case you'll be already familiar with UI/UX about 20th of January. That's approx date when we'll be ready to start the discussion about the wallet GUI.

Also you can check our roadmap at guardaco/zcash-SPV#2

@lindanlee

This comment has been minimized.

lindanlee commented Jan 4, 2018

@guardaco, I'll check out a current release and familiarize myself before the 20th. If applicable, I'll also have any feedback ready before the discussion starts.

Are all of your wallets implemented with the same set of features/similar in layout and UX? I was planning to poke around the Bitcoin one, but let me know if I should look at another one.

Looking at the roadmap, I'd be happy to help out with steps 3. App design (UX/UE/UI) and all substeps, 5.3. GUI implementation/realization, and 6. Quality assurance, specifically with the manual testing of the application. Let me know how I can help facilitate this process (signing up for any email lists, slack channels, etc).

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Jan 4, 2018

@lindanlee I can recommend starting with ETH/ETC as far as it has more options in the menu, like tokens, GAS mode or Fee mode while transaction sending. So we can inherit some functionality from ETH, I guess.

Sure, I have the same opinion, we’ll glad to get your feedback on stages 3 especially. It will be very useful to involve you in UX/UI stage in that terms. I’ll send you the invitation to the design in figma or invision and we can continue a discussion on GitHub, e.g. I can create the separate issue for the design. It will be public and more relevant for the community, I hope.

@lindanlee

This comment has been minimized.

lindanlee commented Jan 4, 2018

@guardaco thanks for the heads up! I'll then start with the ETH/ETC wallet. I'm glad I asked. 👍

Sounds great. Let me know when you decide which platform you'll be using. When it is time, you can include me in the github discussion and send an invite to linda@z.cash on invision and figma.

Looking forward to syncing back later in the month!

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Jan 18, 2018

Hey, @lindanlee I've sent you the invitation to our issue, let's start the UX discussion there, in terms do not block thread here by many UX messages. We can put here just the UX/UI milestones

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Feb 2, 2018

Dear Community members,

Just brief update from Guarda Wallet team. We are moving forward into the accordance with the roadmap almost.

We've finished with Zcash node setup at our side, it's now available at zec.guarda.co

We've started the collaboration with @lindanlee , Z-cash UX expert. Linda's feedback is very helpful for our team. This week we've presented our very first ZEC wallet prototypes that have t-addr and z-addr: https://www.figma.com/file/q6OZOmsg8ot8JTXyIMUhHj/Guarda-Zcash-Wallet-(Android/iOS). UPD: Linda already left her feedback, we are working with it. The next design is in the process of development. The update will be available for comments in figma project.

This week we are planning to have a call regarding ZEC wallet with @techoluwoye from Coincentrix.io, who are got Z-cash Foundation grant for Z-cash Education Outreach. I hope we can help to make some valuable effort for Z-Cash community together.

Next week we are going to start SPV library API public discussion. We are planning to proceed in the same way as for UI issue.

I'll put all valuable updates here.

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Feb 28, 2018

Dear Z-Cash foundation,
Dear Z-Cash Community,
Guarda moved to the next project stage, we're going to implement the SPV library. We've created the discussion regarding SPV library functions and methods at guardaco/zcash-SPV#1 It will be really nice to have feedback or comments on it.
@tromer
@acityinohio
@mineZcash
@amiller
@naconner

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Mar 20, 2018

Dear all,
We've finished beta for Zcash wallet (t-addr only at the moment). Please find the link to the beta release for Zcash community on Google Play market https://play.google.com/store/apps/details?id=com.guarda.zec
Any valuable feedback is very welcome.

@tromer @acityinohio @lindanlee @mineZcash

@lindanlee

This comment has been minimized.

lindanlee commented Mar 20, 2018

Hi all. I've tested out the app, and left some feedback on this comment here: guardaco/zcash-SPV#3 (comment).

In short, the app is great, mostly because the Guarda team is talented and made many great design calls along the way, and also because Zcash and Guarda were able to collaborate well during the design process. They did a great job incorporating any feedback I had for them.

Here's the comment, copy and pasted for your convenience:


@AndrewGuarda, thanks for taking the time to make the product! It is now objectively my favorite Zcash wallet on the market. I'll happily relay this to my team at Zcash.

It looks really great, and has a lot of other functionalities that other wallets do not. My favorite three things of many were: 1) incredibly quick refresh time to show transactions almost instantly, 2) include/exclude fee feature in the send UI, and 3) ability to "repeat" a transaction.

Some minor things to fix:

  • When starting, it took a while between "create a new wallet" to getting to the home screen. A progress message, or "initializing your wallet" placeholder screen may be helpful. I clicked on it many many times, and I accidentally ended up clicking through a bunch of prompts without reading.
  • My balance on the home screen showed as "0.004" when it was actually "0.0039836." I suggest showing the exact balance, even if it's a lot of digits. Similarly, the "send max" button in the send interface filled in "0.004" when I had 0.0039836 ZEC, and I was unable to complete that transaction until I manually altered the amount myself.
  • In the settings, the FIAT currencies available are USD, EUR, RUR, and GBP. But in the purchase menu, the denominations listed are EUR, DKK, NOK, SEK, GBP, and INR. I think that these sets of FIAT currencies should be the same.
  • In transaction details, show the FIAT amount in addition to the sum (i.e. in addition to "0.004," show "$1.33"). Bonus if you show both what the FIAT equivalent was at the time, and currently--so that in 10 months from now, I can look at the transaction and see "0.004, $1.33 at time of transaction, currently $4.60." This helps with accounting/tax purposes.
  • in the google play store, the screenshots show a shield logo with a Z without a circle, but your application shows it with the circle. I don't think this is a big deal, but thought I would let you know.

I don't want to write too much, but I think that I want to emphasize how much I appreciated your hard work and your attention to detail in the UI. There are so many little design decisions that you made, on your own and without my guidance, that really make this app feel intuitive. (I'll just go ahead and list a bunch off the top of my head in appreciation: your brand presence/aesthetic, PIN interface and how it re-prompts after inactivity/being sent to the background, clean transaction listing and subtle green bar to show spendable funds, your use of icons, error messaging, color, immediate feedback for successful actions, etc.) Don't let my feedback discourage you, and I do have many more things I like than I do not. :)


@tromer, I personally think that this is a great result of the foundation's funds, and I'm happy that we will be able to get a good Zcash SPV wallet on the market with the foundation's support. (Also, Zcash specifically asked them not to do zaddr support until after sapling, so there wasn't a 'failure' in deliverables on that end.)

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Mar 21, 2018

@lindanlee thank you so much for your feedback. It's really awesome to get such great product feedback from the foundation. Our team will definitely fix all issues, and make the wallet even better. Then we can release it in Play Market as the great result of cooperation with Zcash Foundation.

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Mar 21, 2018

@tromer, I personally think that this is a great result of the foundation's funds, and I'm happy that we will be able to get a good Zcash SPV wallet on the market with the foundation's support. (Also, Zcash specifically asked them not to do zaddr support until after sapling, so there wasn't a 'failure' in deliverables on that end.)

@tromer @lindanlee as far as t-addr is pretty close to the delivery, we are moving to z-addr. What do you think: maybe we should wait for Sapling before implementing zaddr? how will Sapling affect?

@mineZcash

This comment has been minimized.

mineZcash commented Mar 21, 2018

(Also, Zcash specifically asked them not to do zaddr support until after sapling, so there wasn't a 'failure' in deliverables on that end.)

@lindanlee I'm a little disappointed that Zcash Co has asked not to have z-address support yet.

I think as long as it is carefully restricted to devices that are of the correct configuration it could be good for z-address adoption. But it will certainly require testing; perhaps the app could simply limit all devices to t-addresses only unless the phone has been "whitelisted" to be compatible?

The Google app store fully supports this approach: https://support.google.com/googleplay/android-developer/answer/7353455?hl=en with options for specific device performance restrictions (ie:RAM requirements)

@lindanlee

This comment has been minimized.

lindanlee commented Mar 21, 2018

@mineZcash. I'm also not quite happy about the fact that zaddrs are not more widely supported. I think one of the really terrible things right now are that when people think they use ZEC, they assume that they're using a zaddr and getting the security properties, when they're not! Also, not having support for the distinguishing factor of your coin is a special case of "hair on fire," and I want to fix it as soon as I can.

That being said, I don't make the strategic calls. I believe that @nathan-at-least, CTO of ZEC and product owner, has explicitly said to discourage any technical work to support zaddrs until after sapling is complete. (@nathan-at-least, please confirm.)

That being said, I would be more than happy to collaborate on user interface design or user interaction norms that supports both taddrs and zaddrs. And if supporting zaddrs is as easy as "adding an if statement somewhere in the code and calling z_sendmany instead of send_many" or something along those lines, I would personally not see the harm in going ahead with that. At the time of discussion, there was a lot of talk of optimization that would need to be required for zaddrs to be feasible on mobile devices in addition to special design considerations (i.e. a popup that says, 'shielded transactions may take up to 20 minutes').

@AndrewGuarda, how many weeks of work would supporting zaddrs take for your team?
@mineZcash, I like the whitelisting approach. Or, a better approach is to have the features related to zaddrs 'hidden' by default and only turned on for whitelisted compatible devices. After sapling, it'll be available by default to all.
@tromer, any thoughts?

@amiller

This comment has been minimized.

Contributor

amiller commented Mar 21, 2018

I wouldn't want Guarda to "waste" work by putting in a lot of effort to support Sprout zaddrs when Sapling is so close. On the other hand, if it could be available sooner than Sapling, it may still be worthwhile. Also, we can disagree with Zcash Co's strategic descions if we want to. :P

@lindanlee

This comment has been minimized.

lindanlee commented Mar 21, 2018

@amiller Good point. This is foundation stuff! :)

@nathan-at-least

This comment has been minimized.

nathan-at-least commented Mar 21, 2018

Hello! I think we got some wires crossed, and I want to clarify some things:

  • Zcash Company has tabled an earlier plan to implement "delegated proving" for Sprout, see: zcash/zcash#2322 (comment) . However, there's already a fully functional prototype of a Sprout delegated proving server and client, so if you wanted to use that, we'd definitely help answer any questions and help dust off the code.
  • Sapling Z Addresses will be a different format than Sprout addresses. We call Sprout addresses "Z1 addresses" and Sapling addresses "Z2 Addresses".
  • Once Sprout Z2 addresses are adopted, we intend to discourage use of Z1 addresses, but this won't start until 2019 most-likely. Discouraging includes a bunch of things, but one example is to ensure wallets default to creating Z2 addresses for shielded addresses, maybe hiding Z1 address creation behind expert-mode settings, and having an "upgrade my address" button that creates a new Z2 address for each existing Z1 addresses and transfers funds to the new system. These proposals are highly UX dependent, and have privacy impacts, so I recommend getting a lot of review for UX design around this.
  • Zcash Company itself is focusing our attention on Sapling Z2 Address support, and our company engineering team isn't prioritizing improving support for Sprout Z1 addresses, outside of basic bug fixes or improvements to zcashd.
  • Sapling Z2 addresses won't be supported on mainnet until at least September 2018, so Z1 address support could still be very useful if it is released in the next few months.

Finally, the Zcash Company has no authority over the Foundation or Guarda, and it's an open source permissionless protocol. ;-)

(I personally would love a mobile wallet with Sprout support, but that's my own opinion.)

@nathan-at-least

This comment has been minimized.

nathan-at-least commented Mar 21, 2018

Oh, another detail about Z2 addresses is that they will be smaller, and that might make them more convenient for UX design.

@lindanlee

This comment has been minimized.

lindanlee commented Mar 21, 2018

@nathan-at-least, thanks for the clarification. I learned some things I didn't know.

Now I'm personally on board with supporting z1 sprout addresses. 🏆

Now someone like @amiller, @tromer, or @AndrewGuarda needs to decide they want to do the thing. Keep me posted! I'm available as a resource and would love to keep co-designing.

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Mar 22, 2018

Thanks for your explanation, @nathan-at-least Just to give you a brief update on how our z-addr wallet development is going: Following our initial plan, we've done a lot of testing for possible implementation approach. Based on our results there is no impactful way to implement z-addr SPV solution based on JSON-RPC communication with ZEC daemon only.

In order to deliver reliable/fast/scalable implementation of z-addr for the mobile application users, we have to develop a customized server-side solution (backend) that will provide necessary resources.

The general architecture will stay the same; the only difference is a new instance of the backend. The mobile application will be integrated with ZEC blockchain node using both: RPC and server-side using the specific/custom protocol. This solution will let us make the wallet app stable and reliable for the community users. As per we can see now, Sapling can partially solve the problem, making it easier to create z-transactions. That will significantly improve the user experience. So we’ll probably consider the possibility of waiting for Sapling release if it will help us provide a better solution.

@arielgabizon

This comment has been minimized.

arielgabizon commented Mar 23, 2018

@AndrewGuarda what is the main problem with using the zcashd daemon? time? space?

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Mar 24, 2018

@arielgabizon the main problem we've discovered is in the restoring zk wallets (history mostly). It requires scanning the whole blockchain and parses it with the wallet viewing key. So we'll have the problems with all of you mentioned: time, space, performance, the battery in the terms of the mobile application. So the issue is not in the insufficient zcash daemon interfaces, it's mostly about the mobile device performance.

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Mar 26, 2018

Dear all, please find z-cash t-addr SPV library repository https://github.com/guardaco/zcash-SPV

@AndrewGuarda

This comment has been minimized.

AndrewGuarda commented Mar 30, 2018

Dear Zcash foundation, community.

I want to thank everybody for the valuable feedback and comments on our z-addr issue. Finally, we've got the architecture solution that allows implementing z-addr using Wallet Service (WS) backend.

The workflow app-WS looks as follows:

  1. app gets the latest known block
  2. Private view key registration in WS
  3. app gets the wallet outputs from the blocks range
  4. Check the nullifier's availability
    This will let us do both: restore wallets and create new wallets using the WS.

The next z-addr issue is to sign the transaction on the device. We've done the performance tests for z-addr transaction signing operation (we've used data center hosted server):

  • 862Mb RAM for key storage
  • processor time:
    • one output transaction takes 23sec
    • 9 outputs and 1 input takes 212 sec
    • 16 inputs and 1 output takes 189 sec
  • During the transaction generation, 12 proc threads periodically loaded up to 100%, one thread is loaded always to 100%, 3GB RAM is used by all server procs. We'll get the chance to get heated high-end phones within the mobile application.

We fully understand how important it is for Zcash Foundation to get z-addr implementation on the mobile and our team is ready to continue this work. But it looks we'll get the negative user experience in the current conditions for the temporary solution.
However upcoming Overwinter and Sapling hard forks will partially solve the problem of energy consumption. So we decided to wait for the forks before launching z-addr wallet in order to provide a better user experience, increase the wallet adoption among community members and avoid negative feedback.

We need to research Overwinter/Sapling specs to estimate how the situation will be changed in Summer/Autumn.
As usual, I'll appreciate your thoughts and comments.

@mineZcash @lindanlee @nathan-at-least @arielgabizon @amiller

@flame05

This comment has been minimized.

flame05 commented Apr 17, 2018

Hey @AndrewGuarda, waiting till Sapling release (sept 2018) will be the smart move, memory requirment and processor time will decrease dramatically for shielded txs!

Great job BTW, really slick developement: reactive and crystal clean!

@sonyamann

This comment has been minimized.

sonyamann commented Jun 20, 2018

Hi @AndrewGuarda! I'm pinging all of the 2017 grant recipients for updates on their projects. Can you either write a paragraph or two here, or alternately email me? sonya@z.cash.foundation

Thank you!

@lindanlee

This comment has been minimized.

lindanlee commented Jun 20, 2018

@AndrewGuarda has left Guarda. He contacted his collaborators with the news a while ago.

@sonyamann

This comment has been minimized.

sonyamann commented Jun 21, 2018

Ah, okay. Can someone else update, then?

@flame05

This comment has been minimized.

flame05 commented Jun 28, 2018

How professional. Leaving without even informing. Clap clap

@anna-spada

This comment has been minimized.

anna-spada commented Jul 2, 2018

Hy everyone! It seems that a part of the communication has been lost somewhere in the middle. We've synced up with Sonya last week but I'll also post a brief update here just to make sure that we're all on the same page:)

  1. Zcash android app for T-addr is up and running. However, after the fork we experience some difficulties with sending transactions in the Android app. We're fixing it now and hopefully, we'll upload the updates here soon.
  2. We’ve also added Zcash support on our web-wallet and on desktop wallet app.
    Web and desktop versions are working fine (including transactions) and we see the growing number of users, which is good:)

As per the Z-addr support: the status has not changed much since April: after a discussion with the community and foundation members we decided to wait with Z-addr implementation till Sapling is released. Thus we can make Z-addr app more suitable for usage on mobile devices with limited capacities. We'll keep you updated on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment