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.
My first call with @joshs was Jul 18th and our engineer started some research since then.
We setup our Slack channel with @joshs and other engineers on July 23rd (sorry canât provide a link as a proof). And we have technical discussion back-and-forth asynchronously based on our own research.
We had a more focused technical call with @joshs@daira@str4d and other folks from ECC team on Aug 5th.
And this is also the reason @daira@str4d is answering technical questions above (kudos to @daira@str4d and the whole ECC team which is super helpful).
With the early research and communication mentioned above, we are kind of confident that we can deliver this before the end of October. So we put this date in the application. But again, we will do our best and this is not a guarantee.
Also please kindly note that the final delivery date of this integration also depends on
when this grant is approved.
how long it takes for Zashi team to finish the integration on their end.
@Lixin at the most recent meeting, the @ZcashGrants Committee voted to conditionally approve this proposal with the stipulation that Least Authority review the SDK and address concerns before final payout. ZCG has requested that you provide monthly updates via the forum in this thread.
Hi @Lixin - Yes, Least Authority is a security auditing firm that is fulfilling a ZCG funded role as the Zcash Ecosystem Security Lead. See their monthly updates here.
@Liz315 can help facilitate with information about the auditing process and scoping that work. Least Authority is also available for consultation sessions related to your project if needed.
Hi @Lixin - Feel free to reach out with questions anytime. When convenient, it would be great for us to learn more about the scope and timeline so we can meet any necessary deadlines. You can send details to us or we can schedule a call to discuss it all.
Hey @Liz315 nice to e-mmet you here! And we are excited for our coming collaboration!
Do you mind joining our Slack channel with ECC team? So that they can be also synced with the collaboration between us and they may potentially have some comments too.
On the other hand, our dev set up a wallet with the command-line wallet provided by ECC team, with which we are going to make a demo for the integration to speed up the final integration with Zashi.
Currently, our dev is working on wallet address verification, which involves trying to generate a Zcash address using the same mnemonic in our codebase and checking if it matches the one generated by the software wallet.
Please kindly note that we received the confirmation email on Thursday and we only spent 2 days on the work mentioned above. Thanks!
You guys are awesome Lixin. So thankful to have folks like you in the hardware industry making an effort for this. Ledger has been a nightmare they are so slow and out of touch. It would be very impressive if we got shielded support on Keystone before LedgerâŚ
If Keystone releases their shielded app before Ledger, I will buy at least 2 Keystone wallets. I already planned to buy a Ledger Flex or Stax, but I think Keystone 3 Pro is better suited for me.
]
on radar, love it!
