CC: @hanh may have some ideas
3 Likes
CC: @pacu for LCWG discussion
3 Likes
Which block ranges did you test?
could this be included as part of the lightwalletd API instead of using a fork? Proliferation of forks is not really desirable. Users need to know to which one connect and it will make the ecosystem more fragmented while we are trying to converge towards a globally available set of lightwalletd instances.
2 Likes
I believe Zingo and friends are working on a pure rust alternative to lightwalletd? @zancas
2 Likes
Hey! Here are some more specifics. Numbers will be different because I’m on quite a different machine than @Wollum-ChainSafe. More specifically I’m on a Macbook with 2.3 GHz Quad-Core Intel Core i7.
Block Range: [1702104, 1712104]
Download blocks and deserialization: 6509.64ms
Trial Decrypted Total 515508 Orchard Actions: 65995.94ms
Trial Decrypted Total 6377 Sapling Outputs: 940.2ms
If there are more interesting ranges that you would suggest, please do let us know.
3 Likes
Yes I don’t have specific ranges but from the top of my head I can recall the “sandblasted” blocks are mostly between 1.6M and 1.7M
Honestly I wouldn’t advise anyone to use a long living seed phrase on a browser extension. So sandblasted wallets should not be loaded into them. When using a browser extension wallet I always create a new wallet for the purpose I want and then destroy it.
But in terms of benchmark it would be useful to have those figures.
2 Likes
We’re not actively developing this right now. We’ll finish up adding regtest mode to zebrad first, then revisit the topic.
1 Like
I think you meant to say that they started somewhere in that range because they lasted for over a year… Into 2M+
4 Likes
Spam is the overall general term that we typically use for the entirety of the attack, though I don’t think anybody really meant to. The attacker did attempt a few different methods and sandblasting I believe refers to one of those specific parts of the attack, though don’t know which one exactly (I’ve personally never understood the analogy, sandblasting cleans stuff idk).
1 Like
I think this term was coined by some zcashers. Badam bum
1 Like
Yes, thanks. for the correction.
1 Like
It was coined by me.
1 Like
Yes… and Zcash was vulnerable to a DDOS. It no longer is. We’re “cleaner” now.
1 Like
Do Zcash wallets generally skip trial decrypting transactions which look like spam then? For example, skip over transactions that have like 100 outputs or something? If so whats the general heuristic?
3 Likes
Some wallets offer optional heuristics as the ones you describe. Users can actually choose whether they want to use those heuristics or not. It can be the case that you particularly receive those kinds of transactions and you don’t want them filtered
4 Likes
Cool! We will get numbers on NOT filtering any transactions as well as filtering out transactions with more than X outputs/actions where X may be like 50-100. Thanks 
2 Likes
As for heuristics you could check what Ywallet does. That has been empirically tested as a heuristic that worked for most people actually.
4 Likes
Hello Redwan, Program Lead for Chainsafe. I will take over from Liz for the admin things.
We are ready to deliver our final research report and the repo.
2 Likes
We are excited to conclude our web wallet feasibility study and share our results.
Despite being initially skeptical we are happy to say that between the fast implementations from librustzcash, parallelizm via Web Workers, and a few other tweaks, syncing (trial-decryption and witness updating) for up to 90 days worth of non-sandblasted blocks is possible in < 20 seconds on consumer hardware.
Please see the full report for the complete set of results.
Furthermore we encourage you to run your own experiments with your own machine using the handy web page we made - ZCash Webwallet Benchmarking. At the moment this requires running a grpc-web lightwalletd proxy locally but we are working to get a public proxy set up so this won’t be necessary. We are happy to accept any PRs with further improvements and this site can continue to exist as the communities shared best-effort for a web sync implementation.
8 Likes
The success of this project opens up a number of potential follow-ons:
- Development of a fully-featured Zcash web SDK (original proposal)
which could then be used to develop:
- A web wallet implementation with persistence
- A MetaMask Snap
The MetaMask integration is of particular interest to us (ChainSafe). We have experience in this area having previously developed the snaps for Filecoin and Polkadot.
This comes with its own challenges as the sandboxed snap environment is even more restricted than the browser. We have run a few quick benchmarks in the snap setting and it is definitely slower (limited to single thread) but still appears promising. Will post more on this soon.
Excited to continue furthering the Zcash ecosystem into the web!
7 Likes