I design websites and apps for one of the big tech companies in this world (clue; starts with Micro and ends with $oft) and was wondering if anyone wants to collaborate with me to build out a Zcash wallet?
In my mind, there is a rough idea of what this could look like; some of the main goals of the wallet, an outline of stage-by-stage functionality, a method or two of making money from it, etc.
If there is a person / are people interested in collaborating, then let me know. It would be super interesting to start working on something together.
Skills I have: Branding, marketing, UI/UX design, basic front-end development Skills I lack / need: Everything else to make a progressive web app / electron app
Do you mean “Doesn’t Microsoft contractually own everything you do, even if that’s taking a poop on a Saturday?”, then yes.
However, so long as I’m not making a competing product to Microsoft Office, I can have my management sign a piece of paper to say that I own what I do on said project… or rather, that they don’t.
That would be one if the main goals; to make everything easy to use and understand. I’d like my technically inept dad to be able to pick it up and understand it.
A stretch goal, maybe one to chalk up on the roadmap for the longer term plan, would be to make an easier way to get from fiat to ZEC.
I was thinking that if someone is interested in helping, I’d draw up my list of ideas and some sketches and we can build out a roadmap together for a V1 and beyond.
It must be eeeeeasy! The tough part is converting fiat to zec and back again…KYA/AML regs are a big hurdle to that. A simple wallet where the user holds their private keys is what is needed. Make it well supported and super easy to perform backup and restore functions for private keys so stupid users don’t lose their money (think multiple, redundant backups, always on duty).
Perhaps the ZCash Foundation can issue a grant for your project. I understand they are looking for new ideas. Since a wallet for smart phones is something they’d want to see given the upgrades planned for later this year, you may have a chance.
first off: big up @i-am-a-crab
What I would suggest is to wait till sapling update comes out(Q3), it will be the only reasonable time to start implementing shielded transactions for mobile (resources and time is highly decimated [>90% less]).
I wouldn’t consider this a strecth goal but a main milestone for launching.
I’d suggest start collecting the IP for the project, like the domain name, trademarks, MS permissions, then once Sapling rolls out you’d be ready to “work with someone” to build a mobile wallet that can do z-transactions.
Has anyone researched the requirements for z-addr support in a light/thin client? Obviously the requirements for generating proofs will be dramatically reduced in Sapling but are there currently other unknowns when creating a thin client for working with z-addrs?
Thanks for the links. Those proving times do indeed look awesome.
I’m curious why we haven’t seen a light client for PC/Mac/Linux (even for the myriad of Zcash forks) as there with low memory proving 1.7GB isn’t really a massive issue and I’m sure most people would prefer to use an SPV client than have to download the entire chain. That kind of made me think either it’s a tricky issue to solve or perhaps there is something about Sapling that makes it possible?
My knowledge is intermittent as best, but I’m not sure how “thin” a Zcash wallet can really be. Sure, with Sapling you’ll have reduced computation requirements, but you’ll still need the proving key to make a JoinSplit. That alone is ~800 MB, a big thing to download and store. Or will the new MPC key (Powers of Tau) be smaller? I also read about delegating the computation (not sure though if that would remove the need for a local copy of the proving key), but that may be even further off.
Hey, we’ve decided to not move forward with developing “Delegated Proving - Transparent” protocol for these reasons:
This protocol allows a light wallet which holds funds in a T address to send to a Z address without a custodial risk of theft. But what would be much more valuable is for light wallets to hold funds in Z addresses, to increase Z address adoption globally. So the benefit of this DP-T protocol is fairly modest.
The protocol requires a “proving service” and deploying such an architecture is not trivial for many products/services.
Sapling has “built-in” support for delegated proving which will allow a light wallet, so with the same kind of proving service architecture light wallets can hold funds in a Z address, which is highly preferable for systemic privacy and user privacy.
Sapling may allow direct proving on light wallets which would be even better since there’d be no need for a proving service and the associated architectural changes.
Sapling will activate soon enough, that effort we put into DP-T seems better spent on Sapling or Sapling delegated proving (DP-Z).
Thus, I’m closing this. But anyone here should note that we have a fully functional Delegated Proving Service and Client implemented for DP-T! If you’re interested in that, definitely get in touch with us.
