Feel so honored for this haha!
9 Likes
Hey Zcash community,
Last week was quite a productive one!
We successfully completed the POC for signing a transaction with Keystone. We extracted the message hash and other necessary data from the Orchard bundle of a transaction and provided it to Keystone. After Keystone signed it, the transaction was successfully accepted by the Zcash blockchain:
https://mainnet.zcashexplorer.app/transactions/134ccfcea3e7e5cf122d25c56e2fb3b4bf3ee77e525e8483bd01cc7576df8fb5
Moving forward, we will:
- Continue researching which data Keystone needs to obtain to display and verify for user asset security.
- Modify the dependency libraries used during the POC process to support subsequent formal development.
18 Likes
Hey Lixin IĀ“m Mine, designer from Zcash Brasil and I loved the idea! IĀ“d really like to participate!
4 Likes
Cool!!! Will contact you later!
1 Like
Hey Zcash fams,
This week, we mainly completed the initial extraction and modification of the Zcash dependency libraries (though it was a simple implementation in our repository and not an ideal approach). Currently, it can support the subsequent development of functions.
Next week, we will summarize a modification list based on the current changes to the dependency libraries and work with the Zcash Team to modify the librustzcash and orchard libraries, while also advancing the subsequent function development.
We also had a meeting with @Liz315 from LeastAuthority and we have confirmed the auditing scope:
- modified Zcash library by us which will be used on our firmware
- the Zcash rust app in our firmware
- the rust sdk for the other third party to use
Thanks everyone!
15 Likes
I really appreciate all the updates, thankyou.
I really look forward to purchasing one of these devices when you have completed the app
6 Likes
Excelente ideia!
Estou ansiosa para participar desse concurso!
2 Likes
Thanks @doloresampaio
I will do another post in the forum when we start doing this!
2 Likes
Hey Zcash community,
Here is the weekly report for the last week -
We focused on writing this documentation - Zcash Integration Summary which summarizes -
- The dependency libraries used for the integration so far and the corresponding modifications.
- The minimal data required by Keystone for displaying, verifying, and signing transactions.
This documentation has been shared with Zashi team asking for feedbacks.
Last week we have also started the formal development of Keystoneās support for Zcash (previously we were mostly working on POCs).
11 Likes
This week, the Zcash support entered the formal development phase.
The main achievements include:
- Drafted the Zcash-related QR code data protocol.
- Developed the Zcash receiving address and wallet connection features on Keystone.
More details: GitHub Pull Request #1366
15 Likes
We were having an offsite last week. So there is little progress.
This week we will resume to our full speed of building for $Zcash.
7 Likes
Last week, we proposed a draft data structure for PCZT (Partially Created Zcash Transaction).
A side note: this is one of the most important part of the grant as with this PCZT, any hardware wallet can follow this standard to be compatible with Zashi or any other software wallet. Or even any software wallet can be turned into a hardware wallet by turning the mobile phone into airplane mode and communicate with another online device through QR.
The idea comes from PSBT in Bitcoin. Reference - bitcoin/doc/psbt.md at master Ā· bitcoin/bitcoin Ā· GitHub
The Zashi team is also putting forward their ideas about the PCZT structure. We will discuss these two proposals this week.
9 Likes
FYI, itās been done by ywallet, but weāll gladly consider your proposal.
7 Likes
hmm. shouldnt this be just reused then?
was this ever proposed into a ZIP?
1 Like
This page contains no specification of the interchange format used, and nothing about interoperability at all. I went looking for this last week and found nothing. Ergo, right now your format is just a YWallet-internal offline signing protocol, and not PCZTs.
I would very much like to know what YWalletās constraints are on an offline wallet protocol, so that I can fold them into my PCZT structure proposal.
4 Likes
Thanks for this! As mentioned offline, Iāve been folding the aspects of your proposal that indicate what Keystone requires, into my PCZT structure proposal, which will also reflect the various discussions that have been ongoing in Standardize a protocol for creating shielded transactions offline Ā· Issue #693 Ā· zcash/zips Ā· GitHub. Aiming to have it up early this week.
4 Likes
Thatās right, itās not interoperable (and not designed to be). It is simply a serialization format for the transaction proposal before the signatures.
The format has changed between versions (when Orchard was added) and isnāt backward compatible.
The only thing I can think of is to include an account identifier so that the offline wallet can determine which set of keys to use. The rest is normal stuff.
However, since it contains all the unsigned transaction details, it is not friendly for hardware wallets. Scanning the 10 QR codes takes a while. If it were possible to support a subset of data for different targets, itād be useful, IMO.
5 Likes
BIP 174 (PSBTs) has a āBIP 32 identifierā that can (optionally) be added to signal which keys to use; I adapted that to a ZIP 32 identifier in my original Sapling PCZT PoC that Keystone worked from above, and weāll have something similar here.
In my PCZT design Iāve added a āRedactorā role that can remove information from a PCZT. The primary motivation is privacy (once certain information is no longer necessary, it should be removable; PSBTs donāt have that property AFAICT), but it can also be used to e.g. take a core PCZT and then tailor it for what different recipients need (e.g. for a Signer, removing alpha values that are only needed by the Prover and other Signers).
Thereās a limit to how much information can be removed though, depending on how much verification a Signer wants to be able to perform (as maximal validation basically requires the information that the Prover requires). I think the minimal amount of information that the PCZT will be able to contain will be what is necessary to derive a sighash (as just blindly trusting an opaque sighash is a very powerful and risky capability to expose).
3 Likes
Thatās great. I would have used it in the Ledger app because I donāt send all the memos, just their hashes.
Another thing I just remembered: Iād like to have the derivation paths if possible.
3 Likes