Keystone Hardware Wallet Support Grant Application

[zerodartz]

@hanh

FYI, it’s been done by ywallet, but we’ll gladly consider your proposal.

hmm. shouldnt this be just reused then?

[tokidoki]

@hanh

it’s been done by ywallet

was this ever proposed into a ZIP?

[str4d]

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.

[str4d]

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.

[hanh]

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.

@str4d

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.

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.

[str4d]

@hanh

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.

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.

@hanh

If it were possible to support a subset of data for different targets, it’d be useful, IMO.

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).

[hanh]

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.

[hanh]

Can a redactor transform the data? Replace memos by their hashes for example?