Guarda Zcash light wallet #16
Comments
|
Congratulations for the launch of your Ethereum wallet! |
|
Thanks! It's been a rush :) However a lot to be done in the future.
|
|
@guardaco, about shielded transactions: |
|
@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:
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. |
|
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. |
|
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. |
|
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). |
|
@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. |
|
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. |
|
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). |
|
Dear Zcash team, please find attached application for the Q42017 grant. |
|
I see that there are quite a few light Zcash SPV wallets: https://www.zcashcommunity.com/wallets/ . |
|
Dear @tromer, we believe that following three points will answer your question:
|
|
@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? |
|
Dear @tromer, 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: |
|
@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 Just in case you didn't see it, please find the committee recommendation for your project below, and congratulations again!
|
|
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. |
|
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. |
|
Any progress updates on this @guardaco ? Is there a github repo anywhere with your work? |
|
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. |
|
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. |
|
@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. |
|
@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 |
|
@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). |
|
Dear Z-Cash foundation, |
|
Dear all, |
|
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:
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.) |
|
@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. |
@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? |
@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) |
|
@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 @AndrewGuarda, how many weeks of work would supporting zaddrs take for your team? |
|
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 |
|
@amiller Good point. This is foundation stuff! :) |
|
Hello! I think we got some wires crossed, and I want to clarify some things:
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.) |
|
Oh, another detail about Z2 addresses is that they will be smaller, and that might make them more convenient for UX design. |
|
@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. |
|
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. |
|
@AndrewGuarda what is the main problem with using the zcashd daemon? time? space? |
|
@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. |
|
Dear all, please find z-cash t-addr SPV library repository https://github.com/guardaco/zcash-SPV |
|
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:
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):
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. We need to research Overwinter/Sapling specs to estimate how the situation will be changed in Summer/Autumn. @mineZcash @lindanlee @nathan-at-least @arielgabizon @amiller |
|
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! |
|
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! |
|
@AndrewGuarda has left Guarda. He contacted his collaborators with the news a while ago. |
|
Ah, okay. Can someone else update, then? |
|
How professional. Leaving without even informing. Clap clap |
|
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:)
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. |
|
Now it's May 2019 and still, there is no light Zcash wallet with support of Z-addresses. |
|
@AlekseiSmirnov , they are working on it: https://twitter.com/GuardaWallet/status/1122944035877003265?s=19 |
|
@mineZcash I'm not saying about Guarda. I mean in general. I'm a tech guy and couldn't perform shielded transaction within 1.5 hour. There are no light wallets that work. |
|
From the tweet looks like good progress of Guarda. Hopefully, the state of affairs of easily using z-addrs will change soon. Though Guarda don't mention it in the tweet, I'm guessing they only refer to sapling z-addrs. |
|
I wonder though, how they deal with scanning the whole blockchain with the viewing key that @AndrewGuarda mentioned above was the hardest part. This specific part is not easier for Sapling compared to Sprout. |
|
Is there any issue with the fee calculation? I have funds available on the Android app on BTCH, but I can't transfer those to any wallet because the calculation fee always fails, I can't even make an exchange because the wallets view is always empty. Is there any place where I can submit the logcats, or keep track of those bugs? |
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:
If customer wants to rely on other cryptocurrency node he\she can type in this information.
We thoroughly choose best cryptocurrencies and willing to support them all.
We do not require any KYC or customers data. No registration is required as well.
The proposed wallet is a light wallet allowing customer manage his\her keys himself
Purchase of cryptocurrencies will be delivered in collaboration with professional payment gateways.
In general the wallet consists of the following parts:
Blockchain community developed solution. Open-source and distributed free
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.
Customer experience oriented graphic user interface running on mobile operating system of the mobile phone.
High level architecture can be described as follows:
Network HL architecture:
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:
To be implemented in following two months (before Zcash wallet to be released):
Our committed partners for card transactions and SEPA payments are available to be disclosed upon request from Grant Review Committee.
Team background and qualifications
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:
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
The text was updated successfully, but these errors were encountered: