I agree you can neither receive nor send to UA’s with the current version of Trezor Suite using a Model T-- a bit misleading. So I think what they added was firmware support, but unless you go into the weeds, you cant use it yet
UA support was added to the Trezor T firmware, but not to the Suite. Therefore Suite does not recognize UAs as valid atm. I will notice the Suite team about this issue.
We had that meeting. It was about hight-level architecture of spending and recieving shielded transactions on Suite.
Orchard-tests were added yesterday:
Wow. Thank you for watching and updating @artkor
We are glad to announce the submission of milestone M.3. This is what we’ve done:
- Trezor now supports v5 transaction format specified in ZIP-244.
- Interface for pasta_curves crate was added.
- Necessary Orchard primitives and schemes were re-implemented to fit the Trezor constrained environment.
- Signing protocol for shielded transaction was designed with theses properties:
- Amount of shielded inputs and outputs per transaction is not limited by the protocol.
- Signing process and proof computation process can be parallelized.
- Outputs are reviewed in order they were entered by the user.
- All randomness required for transaction shielding is derived deterministically, which minimizes communication cost and adds some extra security.
- This signing protocol was implemented as an extension of the current signing protocol for transparent transactions.
- Python module
trezorlibwas extended to support signing shielded transactions and getting viewing keys and shielded addresses.
- Trezor terminal client was extended to support getting viewing keys and shielded addresses.
- Device tests for getting shielded addresses and viewing keys were added.
- Device tests for signing shielded transactions (with test cases accepted by testnet) were added.
- Signing protocol was documented and illustrated .
At the moment, all new code related to shielded transactions is in the form of two pull requests ,. These PRs will be merged after merging some major UI and core Trezor firmware upgrades from the end 2022.
This closes the work on Trezor firmware and starts work on Trezor Suite in M.4.
For more detailed info see: ztrezor/M.3_report.md at main · jarys/ztrezor · GitHub
Thanks for your hard work and the detailed update @agi, many of us are waiting with baited breath! Happy New Year and all the best for you and the team as you move into 2023.
Thanks for the continued efforts, it’s good to see that solid progress is being made.
Any thoughts on rough timeline for M4 and M5 work?
Happy new year
@agi @hanh once shielded HW support is available a big thing IMO would be Integration with a GUI that would allow an average user to run a full node easily from the GUI. Not sure if this is something Trezor could support or if Ywallet for example could get a grant for this.
A few UX advantages Monero currently has over Zcash that would be great to have a solution for -
-Hardware wallet support(covered by this grant of course)
-GUI supporting hardware wallets allowing users to easily run a full node. Would be great to enable/incentivise users to run a full node(prior to POS)
-More recently ‘enterprise grade’ multisig solution. This might be further down the track once ZF have progressed further with Frost
awesum. seein it has taken longer den expected - will de integration to Trezor Suite not take dat long?
Any thoughts on rough timeline for M4 and M5 work?
will de integration to Trezor Suite not take dat long?
An estimation is 6 months for reaching M.4 and one month for M.5. I’m taking few days off now. We will set more precise timeline later and then I will update you.
a big thing IMO would be Integration with a GUI that would allow an average user to run a full node easily from the GUI
Thank you for an idea. From my perspective, this seems to be totally unrelated. Our GUI will be a part of Trezor Suite. There is definitely no plan to support running full nodes from Trezor Suite.
Hi everyone, I just wanted to let you that we at Trezor currently do not have the capacities to follow up on the M4 milestone and finish the integration in Trezor Suite. We are fully devoted to other priorities at the moment. I’d love to give you some more particular estimate but at this moment we can’t really guarantee any date. Thank you for your understanding.
Thank you for the information, Tomas! Hundreds if not thousands of eyes are looking in your direction and we will look forward to good news.
By the way, I have subscribe to your team’s github updates and I see that you are currently cooking a new model with two screens and a new filling.
Will you still support integration of Zcash app with Orchard support into Model T?
Hi tokidoki, at the moment, we do not have the capacity for any Zcash-related projects. Therefore, I am afraid the answer is no for now. Bear with us, and we will inform the community as soon as we decide to make some progress with the shielded transactions.
Thanks for the update
@Kat.Trezor will Trezor issue refunds for unused Trezors bought after this grant was approved with the understanding that this grant would be fulfilled?
we would like to share with you the background story of the Trezor support for shielded transactions, and explain the situation with the grant.
In 2021 the Zcash foundation reached out to us regarding the possibility to implement Zcash Shielded transactions. We are big fans of Zcash and anything that improves privacy and we definitely wanted to help out. We found a fantastic developer in Tomas Krnak who was willing to help us get started as at the time, we were not able to do it in-house. The grant helped to make this possible, and the development started. The grant consisted of five milestones:
- Firmware part I
- Firmware part II
1, 2 and 3 were finished by Tomas and we were super happy with his work. See the Pull requests here: Pull requests · trezor/trezor-firmware · GitHub
This finished the first 3 milestones and these specific milestones were delivered and paid for. The milestone payout was paid to Tomas since he did all the work in milestones 1-3. For Milestone 4-5, we hit certain roadblocks and these were not delivered and were never paid for.
At the time, on our side we looked at the possibilities as well on how to support this from all angle’s to help make Tomas’ work and the Zcash foundation’s ambitions become a reality. However, we found several blocking points internally.
- The size of the support in FW would take up all the space we have available, limiting our capacities to do anything else.
- A high amount of internal resources needed to develop this, which would block other prioritised activities.
- A lack of 3rd party wallets which support Zcash shielded transaction with Orchard support.
In the past the Trezor team reached out to Zcash to explain the situation and there was a mutual understanding and agreement around the situation, below was the post:
Hi Zcash Community,
We met with the Satoshi Labs team on March 21st to discuss their priorities, roadblocks, and see if there is anything that we can do to enable forward progress on the Trezor grant. Simon and Jan from Satoshi Labs discussed how the grant initially began with a different team who performed the work for the on-device integration. That work is now completed. What remains is to integrate this work with a user interface that enables shielded transaction functionality. The next grant milestone expects that shielded Zcash would be integrated into the Trezor Suite app. However, SatoshiLabs does not currently have the capacity to prioritize integrating this app into Trezor Suite. Getting the UX right is obviously more complex than the existing Zcash experience in Trezor Suite. SatoshiLabs noted that they would prefer if we could find an existing 3rd party wallet to integrate their app into a UI. Once this is complete, the UI is more fleshed out, and adoption is apparent, then they would look to finish integrating shielded Zcash into Trezor Suite. We plan to draft an RFP seeking proposals from existing Zcash wallet developers who are interested in integrating support for Trezor. Simon shared some libraries that may possibly be leveraged for the integration below and noted that Exodus wallet already has a Trezor integration for transparent ZEC and may be interested in performing this work.
Why are we posting this? Because we really wanted to support the Zcash community, but we could not get away from the roadblocks and we are sad to see negative commentary and misunderstanding on the grant situation which we prefer to be transparent about and clear things up as much as possible!
Currently, due to the reasons listed above we want to be clear that we do not plan to implement shielded transactions in Trezor Suite, or in the firmware unless we have a new architecture set up that can take care of this in a manageable manner. We truly value privacy in everything we do and think highly of the Zcash efforts, Tomas’ work and the good intent to bring this to users all over the world, but we also have to strike a healthy balance for the Trezor roadmap and feasibility.
To conclude, If there are still concerns with what we explained above, we would be able to refund the foundation for the amount of the grant that was given to Tomas out of our own pocket. This will then be with the condition that we stop to try and find new ways to make this happen in the future when the technical situation and resource prioritization allows us to do so. To re-iterate again we would like to state that the work has been done in the milestones agreed, and that this were paid out to Tomas for the successful delivery of the first 3 milestones.
- Tomas worked on and delivered the first three stages of the Shielded implementation in Trezor and we were very happy with the work done.
- We could not fulfil phase 4-5 as during the process technical challenges emerged.
- We (SatoshiLabs/Trezor) did not benefit from the grant.
- We currently don’t have a concrete plan to implement shielded transactions unless we have a new architecture set up that would solve the technical challenges.
Thanks for your clear retrospective.
Do you know why these show-stopping roadblocks were not explored beforehand? The Execution Risks section in the proposal points to potential problems with Orchard, but the roadblocks seem much more holistic than that.
Hey there, Trezor team and fellow enthusiasts,
First off, big ups to you for the transparency and dedication to privacy and security in the crypto world. It’s really cool to see all the work you’ve put into making Zcash shielded transactions possible, even if things didn’t pan out as expected. Shoutout to Tomas for his stellar work on the first three milestones!
But, here’s a thought: some of us tinkerers are itching to get our hands dirty. I’ve got a homemade Trezor running off a Raspberry Pi (Open source baby!), and from what I can gather, it should handle shielded transactions. Maybe some others in the community are in a similar spot.
So, what if you guys could whip up a guide to help us add Zcash shielded transactions to our DIY Trezors? I’m thinking, if you can’t do it officially yet, maybe we can take a crack at it. Heck, it might even be possible for you to apply for a grant for creating this guide.
Think about it - could be a way to move things forward, keep the community engaged and keep the spirit of open source innovation alive while staying within the technical and resource constraints.