Hi there,
it’s a long time I’m interested in ZCash and I still mine them with my limited resources (even though it’s going to be not profitable for me very soon). I really wish that the ZEC project could have a great future, as I think that it’s a great technology.
However, as we know, lately price is declining and not all news (if any!) are good.
Recently I saw a lot of debates on the future of this project, but together with these debates I also saw less and less news about improvements of the client itself or about the ecosystem.
What I’d like to see before the CURRENT funding expires is the support for z-addresses in the major HW wallets: I think this is a critical topic for widespread adoption.
If we consider an advanced user, which holds a non-trivial amount of ZECs, we should assume that he/she wants to keep their funds safe, so that a hw wallet is probably the easiest/most common solution to adopt.
However, as of today, I do not know of any hw wallet that supports z-addresses, so that in order to have the funds safe on a hw wallet, t-addresses must be used.
This, IMO, downgrades the great technology of ZCash to the older Bitcoin technology, with no privacy features. OK, you could keep the great part of the funds on a t-address and then send them to a sw wallet, etc.etc. but it’s cumbersome and time-consuming, and not going to be used by many people.
I already asked several months ago on the forum, then I tried make some pressure to have z-addresses implemented on the Ledger HW wallet (which I own, but any other wallet would do, and I’d probably buy it just for that purpose), but to no avail.
Now I really think that z-addresses should be implemented ASAP, and for sure before the current funding scheme expires. This would be great news for the community and probably it would be good news after such a long time with no positive news about ZEC.
Hi @mantoz the short answer is yes, the Zcash developers have been working on shielded support for Lite wallets and Hardware wallets. The Zcash developers are building the SDKs and libraries but it is up to the wallet makers to add the functionality.
In my talk at Zcon1 I demonstrated the necessary primitives for z-addrs on a hardware wallet, specifically the RedJubjub signature scheme running on a Ledger Nano S. The main problem is that the hardware wallets have very constrained environments, and it needs an efficient implementation that fits the available stack space in addition to all the other logic that needs to be there. My demo was only the core signature primitive, because I was unable to fit RedJubjub signatures using our Rust implementation of Jubjub on top of the existing Bitcoin Ledger app. There’s also a separate issue where the ZIP 32 derivation process would not work in a Ledger without Ledger themselves adding support for Jubjub and ZIP 32 into their closed-source firmware, because (understandably) the raw seed is never exposed directly to an app.
Thanks both for the insight.
To be sincere, I think that we are in a critical moment for ZEC, with a great need of some positive news in order to broaden adoption and to reach more people.
Keep in mind that the reference, command-line client is not easy to use for the average user. For sure ZecWallet and the mobile client are easier to use.
Having a hw wallet, with a “standard” interface (i.e. similar/equal to the one used for others cryptos) and able to handle z-addresses would be a great plus.
I don’t know how things work from a commercial POV, but I think that even funding somehow Ledger, in order to have a quick implementation of private transactions in Ledger Live/Nano S, would greatly improve the ZEC ecosystem and make ZEC different (better) from all other coins.
Unfortunately this forum community is small compared to all NanoS users, but if we can do something with Ledger in order to make them act quicker, just let us know.
Should we bite the bullet, recognize that BIP 32 from the master seed is the only thing that’s guaranteed to already exist in hardware wallets, and extend ZIP 32 with a kludgy hybrid mode to make that sufficient?
Namely: do BIP 32 derivation from a master seed to get a private key of the wrong form and then hash that get the seed for z-address derivation.
I thought I saw your talk. I completely missed this. Would you please link me the talk and any slides/code you have released.
Is backward compatibility a requirement? would a new “secure” device that supports z2z and the other coins be a better route? It is pretty easy to remove the constraints in the environment when you are not limited to the two chips the nano uses.
More bad news.
Can anyone from ECC and/or ZCash Foundation reach out to Ledger / Ledger CTO and suggest some support?
Having z-transactions on Ledger (a de-facto standard) is absolutely critical for adoption.
I have heard that “some” wallet companies want significant amounts of money to add Z-address support. The backend infrastructure needed for Z-addresses is much different than what they are currently running so requires more effort/manpower to maintain.
But ZEC is money, and the Founder’s reward purpose is having enough funds for development…
Personally I believe that a complete ecosystem is worth spending a part of that money to get all the features available on a hw wallet (possibly in a reasonably short time).
ECC, don’t be tightfisted, please!
A little bit off-topic and not directly related but as it’s about HW wallets i think it could fit anyway.
Wouldn’t something like this be not a good solution for Zcash HW wallets too?
…In response to this problem, an Israeli startup called GK8 promises to offer a way for crypto exchanges, hedge funds, and other institutions a record of digital currency transactions without an Internet connection. … K8 was launched in 2018 by two members of a special defense unit that guards Israel’s digital assets. The startup also counts Eran Trofer, a noted cryptography expert and the founder of the digital currency ZCash, as a board member. …Lamesh says G8K can record transactions to a blockchain—public online ledgers used to memorialize transactions—while offline by using a “unidirectional connection.” That means data can be uploaded without exposing the crypto owner to the broader Internet…
Indeed! If someone submits a grant proposal to do this integration (perhaps starting with @str4d’s work and offering a plausible path to resolving the remaining issues), I expect it will see wide support.
@Josh, would “add shielded ZEC support to a hardware wallet (device firmware + mobile/PC app)” be a good candidate for a Call for Proposals for the grant program?
And in that case, @str4d, could you help write a more explicit checklist of open issues and missing parts, to make sure proposers don’t miss crucial pieces?
Can I get in on this? does it have to have an on “an off device” (phone/pc) app? is it a bare minimum device hw wallet or a proper hardware wallet?
hopefully I can help more. Id even be up for helping write the requirements. (or that might be the cough syrup talking)
Havent looked at the link sorry, but the foundation has already got most of the code it needs. It now is just a matter of device design. (I think, I haven’t had a chance to formally review the FPGA aws instance code you released, but it looks to have all the the bits you need.) - there just talked myself out of a grant. lol.
@mistfpga, I think the focus in this discussion is on adding shielded address support to existing wallets (Ledger, Trezor, KeepKey, etc.) rather than from-scratch FPGA design. Targeting retail/small users who can’t afford expensive/clunky custom hardware.
So not quite what I think you have in mind… but maybe the two can be bridged? For example, are there some cheap-and-sufficiently-secure commodity FPGA platforms (not necessarily designed to be wallets, but easily purposed) that could answer the needs of retail/small users?
And of course, more expensive but powerful wallet/HSM solutions are also important; they just won’t answer this need.
We can make a comparable device using exactly the same chips to protect the priv keys. we cant do that for someone elses device though. (it will need a small fpga to make certain bits “quicker/possible”)
if you want a nano style z2z pocket wallet that isn’t a phone. sure. It isn’t actually that hard. I can see why it would be hard to retrofit but not to make with sapling transactions in mind (this device would only support sapling and beyond, it would not be backward compatible) and it would be a bit bigger than a usb stick. but not that much (unless it has a full on screen, which I think it should for memos)
Or maybe I can RE the nano, just looked a bit more about it, looks pretty easy to get the firmware off. It is about time I looked at the nano a forum member was kind enough to send me. I will look into the code tomorrow. But I don’t think it will be possible due to this:
So, I can probably botch something together, but I am pretty sure it would be illegal for me to distribute it. Although I am allowed to make the modifications perfectly legally in my country of residence.
the short answer is yes, the Zcash developers have been working on shielded support for Lite wallets and Hardware wallets. The Zcash developers are building the SDKs and libraries but it is up to the wallet makers to add the functionality.
