Another useful thing would be the ability to hide this account from displaying in the settings.
Or some sort of special short code to display.
Hopefully @peacemonger will gather feedback after some time.
3 Likes
We also need a 25th word option working with zashi. Apparently is not supported yet.
2 Likes
PSA: Keystone walletâs tamper resistance functionality ceases to function in two years due to a battery powering the tamper watchdog.
If your threat model includes an adversary that could keep your hardware wallet for 2+ years, then potentially exploit future-discovered vulnerabilities in the physical device, you should be very aware of this.
It may also be wise to rotate to a new hardware wallet annually if you want to be completely sure that the tamper resistance is functioning.
Overall, great work to everyone involved with this project. Iâm thrilled to have a working shielded hardware wallet for Zcash!
3 Likes
This is in our backlog now.
2 Likes
Hi Zcash fams,
Although the integration between Keystone and Zcash was officially released before Christmas, our work is not yet complete.
Over the past month, we have been collaborating with Least Authority to conduct a code audit of our integration. The first round of the audit has now been completed, confirming the security and correctness of Keystoneâs support for Zcash. The following quote is from the initial audit report:
We analyzed the correctness of Keystone operations and the potential for sensitive data leakage and could not identify any critical issues in this regard. Additionally, we assessed the generation and use of randomness as well as the use of cryptographic building blocks, and did not identify any areas of concern.
However, while no critical issues were found in the first round of the audit, some suggestions for code optimization (such as adding more code comments) were made. We are currently working diligently to optimize the code based on the audit results.
We will continue to keep the community updated as we make further progress.
14 Likes
Previously, I served as the primary contact point for communication between the Keystone and Zcash communities.
Now that our integration with the Zashi wallet has been released, Iâve noticed a lot of product feedback and feature requests in this thread.
Iâve invited our customer service team to register a forum account as well. Moving forward, these product feedback and feature requests will be addressed by @Keystone.
13 Likes
Thank you for your interest. Currently, we do not support payments in Zcash. However, we are actively exploring the possibility of adding it in the future. Please rest assured that we prioritize the security and privacy of your information.
3 Likes
PSA: Zcash is no longer supported in Keystoneâs default firmware. It is now in their âcypherpunkâ build which does not support many other cryptocurrencies.
Be sure to tell this to people when you are onboarding them onto Keystone, they will need to use a different official firmware in order to use Zcash.
Frustrating on a few fronts, including that this removal was not mentioned in their release notes, but instead phrased as âsupportedâ on their cypherpunk build.
4 Likes
Wow. Whenever Keystone ends support of Zcash, how do we approach the problem? Would we get another batch of people locked out of their funds, with the only way out to use a hot wallet recovery?
Please stop with the FUD. They felt like they needed to seperate it out for now due to the size of the Zcash app.
2 Likes
Fortunately the Keystone is open source hardware. So in an absolute worst case, our community could build and sign an alternate firmware to run on the device. I do not expect it to ever come to that, and I donât believe that this shift was in bad faith - only poorly-communicated.
Itâs hard to squeeze support for so many currencies onto one device, in some ways I understand their decision to split into separate builds given limited firmware space.
It just would have been nice for this decision to be more clearly communicated in advance. Now our apps need to tell users to install a different (yet still official) build.
1 Like
How many people are comfortable switching firmware around? How is that helping our adoption that âdefaultâ Keystones wonât be able to take ZEC? Itâs a big deal.
And this very soon after ZEC was implemented on the Keystone, so I feel like it is very fair to be concerned of what may happen next, so we can be appropriately prepared.
Thatâs also why I keep saying that we should be very cautious before we instruct our shareholders to use a brand new shielded wallets.They must pass the test of time first. Something clearly ECC doesnât understand, but thatâs ok.
Thatâs good. Do you know who has the authority to sign though? I assume the wallet doesnât accept just any signature for a firmware?
By the same logic, Ledger also accepts third party apps. However, no one but the most hardcore zcash adopter would go through the steps of downloading an alternate firmware, check the private signature and bypass the huge warning that states that it is not officially signed.
Someone was asking why itâs so hard to get Zcash in the major hardware wallets.
Zcash market cap is not high enough to make the maintenance worthwhile. That is also why we are losing support even for transparent coins.
So either Zcash price goes up, or the protocol stops breaking HW so often.
Ledger does not develop app. Therefore every app has to go through a series of third-party audits from their approved audit firms. That takes time and money.
I wonât go through the history of it again, it is easy to find it on the forums, but I think it is one of the major failures of ZF leadership.
Trezor develops all their apps. They started but then came to the conclusion that the cost is prohibitive.
TLDR; Even if you can load unofficial firmware, the risks are too high and 99% of the users should not do it.
8 Likes
ZF leaders may think thought hardware wallet users are were not users.
It is mentioned in the release notes on their firmware page; the omission in the GitHub release notes is likely a mistake. Iâve asked them to update the GitHub release notes.
This was an unfortunate coincidence. Keystone supports firmware up to 15 MiB, which previously made adding new chain support easy to do without any optimisations. Their multicoin firmware happened to already be close to the limit when ZEC support was added; had Zcash been added a bit later, I expect that it would have been in a separate firmware from the start.
I analysed the contents of the multicoin firmware at version 1.8.2, and while Zcash is not the largest contributor to firmware size (Bitcoin is largest due to the 1.1 MiB libsecp256k1 C library alongside all its Rust code, followed by Cardano which has at least 600 kiB of Cardano-specific dependencies), it is large (545 kiB of Zcash-specific dependencies, plus around 200-ish kiB of additional binary size derived from existing multicoin dependencies). There are definitely opportunities for further optimisations (I see several duplicated implementations of various cryptographic primitives), but Iâm guessing that a separate firmware was easier to deploy in the short term.
4 Likes
This is a major advantage for the Keystone firmware. Due to a combination of Keystoneâs Rust-first approach and the direct efforts of myself and the other ECC engineers, the Keystone firmware depends directly on our Zcash Rust crates. The majority of Keystoneâs Zcash-specific maintenance can therefore be done by just updating crate dependencies and making new firmware releases.
The Zcash-specific code remaining in the firmware is IIRC:
- the Keystone-specific GUI and surrounding logic (which they need to maintain anyway);
- the Keystone-specific Zcash checks (some of which might be extractable to the Signer role in the
pcztcrate); and - the sighash logic (which will eventually be replaced with the logic in the
zcash_primitivescrate once weâve succeeded at refactoring ourTransactiontype to enable feature-flagging off thesapling-cryptodependency: `zcash_primitives`: Add `orchard` and `sapling` feature flags. ¡ Issue #1162 ¡ zcash/librustzcash ¡ GitHub).
7 Likes
From a technical standpoint it all makes sense. From a marketing and strategy standpoint, itâs certainly a bit unfortunate.
Could we turn this unfortunate situation to our advantage and have a Zcash only firmware that qualified people in our ecosystem would be authorized to sign? A multisig method would be ideal.
This could then be sold as the Keystone Zcash wallet and people wouldnât have to think twice about what firmware to install. This may seem like a detail to Zcash programmers, but itâd be quite a difference to newcomers in the Zcash ecosystem.
Indeed, but the resulting firmware tends to be larger than their C counterparts. It is an issue for the H/W where secure memory is expensive and scarce.
Ledger Nano has 4K of memory. It was really difficult to squeeze Sapling into it. The Nano X has less than 2 Mb. Trezor doesnât publish their specs but I heard it is about the same.
Going with the rust route, I doubt it will be possible to fit zcash into either H/W without removing other coins. Itâs a pity considering their represent the largest share of the market.
1 Like
I think those who bought Keystone for Zcash bought it for Zcash. Itâs the same with all other coins. Few people need these combines with a million coins from the space ecosystem and so on. We are on the same firmware as Monero and in my opinion this is a great marketing move. I am grateful to the @Keystone team for that. When ZEC is $1,000 per coin, those who want it will be able to buy themselves an extra Keystone. Itâs only $150 Đžr even $115 on a discount day. For the opportunity to have secure shielded storage. Itâs ridiculous to even talk about it.
3 Likes