Have you considered exposing the getblockheader rpc from zcashd to lightwalletd? It would allow light clients to download headers from the server and verify that the sapling root matches the value from the get_tree_state rpc. Since itâs a merkle proof included in the pow header, it canât be tampered without considerable effort.
Edit: If this is ok, light wallets only have to download headers from the latest checkpoint.
@adityapk00 and @gmale, have you considered the above approach?
Iâm not sure but if my memory is correct this is also what youâd need to make âvery light clientsâ that rely on the transactions themselves being sent out-of-band and sync only tiny amounts of data.
I found [Sapling] Encode the root of the Merkle tree over commitments in the header of each block · Issue #2298 · zcash/zcash · GitHub where this idea was discussed by the dev team. Btw, thatâs kinda how SPV wallets work on bitcoin.
Got it.
Would this approach also work for a full node? Could a full node just sync headers up to some date? (e.g. the date the user started using the node?)
Well, full nodes have to validate transactions. They need to keep track of the state (note commitment tree, nullifier set, utxos, etc.).
Ethereum has a mechanism for getting a snapshot but that works because the state_root is part of the block header. In zcash, you canât trust other servers to give you a real snapshot.
Speaking of not trusting lightwalletd servers, I canât find code in the wallets which check the validity of the equihash solution.
Do you know where/if it is done?
I donât!
The Zecwallet and ECC folks I mentioned above would know.
On second thought, validating the header is a moot point. If the lightwalletd is compromised, it can send you fake compact blocks with fake compact transactions. There is no way you can check because even real ones are different that the complete tx and the merkle root will be different anyway.
This is described in the threat model: Wallet App Threat Model â Zcash Documentation 5.2.0 documentation about âLightwalletd-Compromising Adversaryâ.
So if you think the lightwalletd is sending you fake checkpoints, it seems to be compromised and a lot of bad things can happen.
If not, then checkpoints can be trusted.
In summary, if you donât trust lightwalletd for checkpoints, why would you trust it for block data?
The checkpoints are hard-coded in the wallet SDKs.
@hanh I invite you to join the Zcash Lightwallet R&D group for further discussions & optimizations as this is not the best thread to have a detailed discussion on 
FlyClient proofs can help a lot with this. In the near future, creating a new wallet can be instantaneous and trustworthy:
Currently, new wallets start with a known tree and update it from there and the time to do so grows linearly as the wallet release ages. In other words, itâs trustworthy but not instantaneous and with a small amount of effort, we could achieve the reverse (by just fetching the âuntrustworthyâ tree via GetTreeState).
Attaining both will take some effort.
I think you took my quote out of context. I was replying about having snapshot of full nodes. If Iâm mistaken and this is what you are referring to, I apologize.
Iâm not aware that zcash has a reference storage format for the entire state (incremental merkle tree and nullifier set) like Ethereum has with state_root and its patricia tree.
AFAIK, this verifies the validity of the block header with considerable improvement. However, arenât there ways for the untrustworthy lightwalletd to make the apparent wallet balance higher or lower than it should be? Even after it delivered the right headers.
My understanding is that compact blocks have no proof associated, and lightwalletd can omit compacttx, repeat them, erase notes, etc.
In fact, Iâm missing how compactblock content relate to the block header at all: I canât see a hash or a proof I could use.
In fact, Iâve looked around the code of librustzcash and found no place where a lightwallet client parses the block header. In Bitcoin SPV, that would be something that I would do. Tx is hashed, then checked against merkle proof and against block header merkle root.
Thanks,
âh
These are earnest questions but a bit of a departure from the topic of the Nighthawk wallet announcement. In fact, weâre walking into a tangent of the tangent around making new wallets sync faster. If I may summarize my response to your valid concerns:
You make a fair point that if lightwalletd is sufficiently compromised to send bad checkpoints, then we have bigger problems; so also trusting it for checkpoints is probably reasonable.
I like this idea.
Right. Though in the context of initial sync, I donât see the rationale in not trusting the get_tree_state API. As a matter of fact, about the usage of checkpoints in wallets:
Pros:
Cons:
Yes, but light wallets do not connect directly to zcashd. A compromised lightwalletd can easily forge fake compact blocks that would make light wallets believe the outbound transactions went through.
Iâd argue the level of trust in a lightwalletd is high. In zcash, you canât hardcode the genesis hash and verify the rest in SPV fashion.
Against zcashd, definitively so. But light wallets have a harder time.
FlyClient is cool but I think we need more overall trust reduction in lwd. It feels like installing bullet proof glass for your windows and a pad lock for the main door.
Iâll stop hijacking this threat and start another one if people are interested in discussing further.
Logo design update: Zcash mobile wallet Nighthawk gets a new logo and branding â coxy
Weâll be working on a Design sprint in our 3rd Milestone of Nighthawk Wallet Design & Development '21 grant. Cheers!
Thankyou for listening to feedback on the logo! I like the new one.
I tried restoring my wallet with this version yesterday & the sync died (no error, just restarts) after eleven hours 
It has 147 txns, syncing from Sapling activation - works on ZECwallet & Zwallet.
Hey @ChileBob What version of Nighthawk and what device did you test on? And did your wallet seed work in the earlier versions and break in the new one or did it never work?
(Please DM me or @NighthawkApps for support)
Last time, your Android One device was unable to complete syncing, and hereâs my reply.
Can you confirm if it is the same issue or a newly introduced one for a different device?
NOTE: Nighthawk will expand the supported devices list with optimizations in syncing. For now, the supported devices are limited to https://nighthawkwallet.com/supporteddevices/
Latest version, fresh install yesterday from Google Play on a phone that was factory reset.
Device is Nokia Android-One, Model: TA-1115
The error is different to last time, last time it died with âScan Failureâ, this time it just restarts after MANY hours of scanning.
I suggest you update the minimum hardware requirement on Google Play so this wallet is NOT offered for devices that are unable to use itâŠotherwise the users first impression of Zcash will be terrible.
Can we move the debugging of your issue to a new topic or DM? Iâd like to work with you if you donât mind enabling logging and sharing the logs. I think this is one thread started by you Testing Mobile Wallets : Here's what I found
FWIW The app is still compatible with older devices and is verified to work with slower chipsets than Nokia Android One. The âsupported devicesâ list points to the ones we provide active end user support per the limited bandwidth of the team.
I will happily test any new version, its something I try to do each weekend - but I donât have bandwidth for more than that.
Low-end phones are cheap, easier to get one & work directly?
Its very easy tell Playstore what your âsupported devicesâ are based on hardware spec, users wont read your list & expect everything to âJust Work âąâ if offered.