That’s how ywallet can use the Ledger device in air gapped mode. You would have 1 online ywallet with the full viewing key that scans the blockchain and maintains your account balance and notes; 1 offline ywallet creating the proofs; and 1 ledger connected to the airgapped wallet.
When you make a TX, it creates a file or series of QR codes that have all the parameters, such as input amounts, Merkle paths, etc.
You transfer the file or scan the QR codes on your offline ywallet. It can compute the zk proofs but does not have the secret keys to sign the inputs.
That ywallet transfers the tx parameters to the Ledger and uses ZIP 244 for security (and performance, ZIP 244 allows the app to scale up to an unlimited tx complexity). Once the user validates, the signature is returned to the offline wallet, which combines the raw transaction.
Then, the data is sent back to the first ywallet (file / QR codes again) and transmitted via SendRawTransaction to lightwalletd.
To be clear, this workflow is implemented and tested.
This is a different workflow to what @daira described, which is to transfer blockchain updates to the offline wallet, and have the offline wallet do scanning.
Having an online wallet doing scanning and an offline wallet doing proving has minimal benefit, for two reasons:
Full viewing keys by definition give viewing capability for the private information of the wallet. Thus the online wallet still has to be trusted with the user’s privacy in this workflow.
In the case of Orchard, the full viewing key is also a capability for creating proofs, so the online and offline wallets have identical capabilities in this regard. (For Sapling there exists a separate proof creation key that is between the spending and viewing keys, but functionally this distinction is not useful due to the aforementioned fact that the viewing key itself confers a privacy trust assumption).
The main benefit you get from this workflow is that the Ledger’s USB connection is to an offline wallet, which is a good benefit! But Keystone uses QR codes for data transmission, so that particular attack vector is not present, and thus the offline wallet is not necessary if you are already trusting the online wallet with your full viewing key. Given that the online-offline-hw pathway is tested, it should be relatively straightforward to collapse that into an online-hw pathway.
If the wallet assumes be the only custodian of these particular funds, then its equivalent to the current spend before sync and there you go, but it’s kind of the same problem again with multiple seed instances. (And we did videos on Ywallet coldwallet and Ledger and they work good)
Our firmware is open source under MIT license. It can be rebuilt and verified. We do rely on some lib from MCU vendor. Because this MCU has some optimization on it, which is the main reason we choose it. I don’t think we can remove those dependencies.
Yes we do support that! And one thing worth mentioning is that Keystone 3 Pro can hold 3 recovery phrase simultaneously and users can access them through different PIN codes.
With that being said, users can have one BIP39 recovery phrase for Bitcoin, Ethereum and other cryptocurrencies. And one special one which is not BIP39 compatible for Zcash.
No it doesn’t. A pruned and/or spam-filtered copy of the chain would be sufficient. If we care only about the offline wallet spending from Orchard notes that remain after spam filtering, for example, then we only need the commitments and nullifiers for those (along with some other data needed to update the commitment tree, but that is relatively small). We don’t need proofs or signatures, and we can use the FlyClient support that was added in Heartwood to verify that we have a plausible chain (I think, and if there’s any problem with that we could fix it).
What matters is that the remaining anonymity set of filtered note commitments, nullifiers, and note ciphertexts (I’m handwaving slightly here) is both large enough, and includes the ones for the user’s notes.
It does: take a video of the animated QR code, send it through Signal or whatever, and play it back. (I believe the protocol has sufficiently few rounds for this to be feasible; you might need videos sent in each direction. It might also work on a video chat, but I’ve had problems getting even non-animated QR codes to scan via a webcam.)
well, if you send the video file by a digital media, then there is a risk that this channel is compromised .
I am not sure I see the advantage vs using a pbst like file.
I was just looking through KeystoneHQ/keystone3-firmware and couldn’t immediately see where those dependencies are declared. It would be good for that to be documented and linked from the README, so I opened an issue for that:
I was originally against filtering while the sandblasting was ongoing, because I thought it had too high a risk of false positives. We also observed that the filtering done by YWallet was in practice catching some false-positive transactions that we knew were not spam. It is slightly different to apply filtering retrospectively to a known span of time in which the sandblasting adversary can be observed with careful analysis to have been using particular strategies.
(Also, speaking frankly, if the engineers had had our way then ZIP 317 would have been deployed much earlier and the sandblasting would have been stopped earlier. I wasn’t anticipating that its deployment would be obstructed by then-ECC-management for so long, and that fed into why I originally thought filtering wouldn’t be needed.)
Yes, but that’s a privacy risk, not a spend authority risk (assuming the user thoroughly checks the transaction as displayed on the Keystone wallet). And if a user is transferring the QR video via a secure messaging app that they were relying on anyway for privacy of metadata around the payment, that seems like a reasonable choice they could make.
How do you get the file to the hardware wallet? If it’s a video then you can just play it to the wallet’s camera. Otherwise you need USB or Bluetooth which is extra attack surface (and not supported by Keystone). Note that a “video” could be an animated WebP file, which is widely supported and would be only a fairly small constant factor larger than the PCZT it encodes — small enough to be practical at current typical mobile data bandwidth, anyway. Also note that the grant includes specifying a PCZT format, so you can use that directly if you have software on a device physically close to the Keystone wallet that you can use to “play” it. Encoding it as a video is for the case where you don’t (i.e. you only have a device with a web browser or video player, and a camera for the other direction).
[Edit, since Discourse won’t let me make more than three posts in a row ]
I did an experiment, and this stands up: the “fairly small constant factor” is about 20.4 (edit: or 11.6 when using BC-UR with optimal parameters), which is fine for likely PCZT sizes and data connections.
How big is a WebP of an animated QR code, relative to the original file?
For this experiment we’ll use the TXQR format, and gif2webp from the libwebp library. We use a random file to simulate data that is not further compressible.
[Comprehensive instructions on how to reproduce this result.]
Conclusion
For an incompressible input file of 10000 bytes, a WebP-encoded TXQR is roughly 20.4 times larger than the original file. This does not change very much across input sizes. Using WebP saves a factor of ~5 relative to animated GIF.
Example resulting animated GIF (Discourse doesn’t allow WebP, but they look identical in a browser). This is not optimized for frame rate, size etc.:
Further edit: The format that Keystone actually uses is BC-UR, which is widely adopted in the Bitcoin world. A WebP-encoded BC-UR can be roughly 11.6 times larger than the original file if the max_fragment_size parameter is chosen optimally.
]
on radar, love it!