New Zecwallet Lite wallets now start instantly (no sync!)

Community Collaborations
1

tldr;

  • New users of Zecwallet Lite no longer have to do the first time sync. The wallet is ready to use instantly.
  • Zecwallet Lite SDK adds a new “verify” command to verify, at any time, that the LightwalletD has not mislead the wallet
  • Zecwallet is now compatible with ECC’s LightwalletD. You no longer have to run a custom LightwalletD server
  • Preview BlazeSync: A new lightclient sync algorithm that will bring significantly faster sync speeds.

New Wallets now start instantly.

Zecwallet v1.6.0 now will start new wallets instantly! New wallet users no longer have to wait for the initial wallet sync, and Zecwallet achieves this without changing any of the existing security properties of the light wallet. Desktop and mobile versions are now available to download and update. (See the technical details section below for how it works.)

Here’s a quick comparision video

Two weeks ago, @ZcashGrants approved a grant to Zecwallet to work on improving Lightclient user experience. One of the most annoying issues for new users is that when they create a new wallet, there is an annoying sync, that can sometimes take a minute before their wallet is ready to use. We see a lot of new user drop off here, who get annoyed by this sync.

With this new version, the initial sync is so fast that it is not noticeable any more, and so it has been removed from the UX, allowing new users to instantly start using their wallets. They can receive and send shielded transactions immediately!

How it works

The Lightclient sync has two parts - (1) Updating the blocks and keeping track of the sapling commitment root and (2) Scanning all inputs and outputs to see if any transactions belong to the wallet.

When a new wallet is created, the wallet starts to sync from the last checkpoint. If the checkpoint is a few days behind, the initial sync can take a long time.

However, since a new wallet doesn’t have any transactions, there is no point in scanning for transactions belonging to the wallet. Zecwallet Lite v1.6.0 now does only the first part of the sync for new wallets. This is 10x (!) faster, allowing the wallet to scan over 20,000 block headers per second, so it can catch up to the latest block almost instantly.

Note that this doesn’t change any of the security properties - The wallet still scans from the last checkpoint coded into the app, so it has a way to verify if the LightwalletD has intentionally or accidentally omitted some transactions or included rouge ones.

But wait, we can do even better than the 10x faster sync. Since Zecwallet is now compatible with ECC’s LightwalletD, we can request the latest sapling root from the LightwalletD and get the wallet started instantly, while we wait a few seconds for the fast initial block header sync to catch up and verify the what the LightwalletD told us. This only takes a few seconds, even on mobile phones, so well before the user is ready to send their first transaction, the wallet will be ready and verified.

New “verify” command

Zecwallet Lite SDK now has a new “verify” command, that can verify, at any time, whether the LightwalletD has given us all the blocks and all the transactions in the blocks. This works by checking whether the latest sapling commitment root can be reached from a well known checkpoint coded into the SDK. This allows wallets to verify the state before sending or receiving any large transactions (or at any time, really). The verification uses this new fast sync, and only takes a few seconds.

Sneak Peak: BlazeSync

The fast initial sync we are introducing today is a part of “BlazeSync”, a brand new sync algorithm that Zecwallet will introduce over the next few weeks. This algorithm more than doubles sync speed, while also allowing near-instant access to the wallet’s most recent transactions. Some highlights:

  • BlazeSync syncs the latest block first, and then works backwards from there. This allows the user to view and spend recent transactions almost immediately, so you don’t have to wait for a sync to finish to spend funds.
  • BlazeSync decouples the trial decryptions from keeping sapling notes updated. This allows multiple Sapling spends and outputs to be scanned in parallel (They are all scanned one-by-one today), considerably improving performance
  • Since BlazeSync scans backwards, it knows which sapling notes haven’t been spent yet, so it can keep track of the commitment tree only for unspent notes. This saves a lot of compute and battery on phones, especially for rescans or restore-from-seed.

Keep tuned for more details!

24 Likes
2

That’s great for user experience but it doesn’t have all features of the desktop version.It didn’t allow me to manually switch to another t-address.

3

@adityapk00 Great news!

I have a couple of questions regarding these new features

(Emphasis mine)

Does the verification protect the wallet against an adversarial Lightwalletd?

Does it mean that if I have a wallet that contains funds but was not used for months, now I can open the app - sync the last block and then spend some funds right away?

2 Likes
4

It makes it much harder for an adversarial LightwalletD to mislead the client and makes it impossible (I think) for it to steal funds if it mislead a client.

Earlier, a compromised LightwalletD could simply skip or insert rogue transactions and the client would have to believe it. With this change, the bad LightwalletD will have to re-compute the sapling commitment tree in such a way that it matches the bad or missing transactions, and simultaneously lines up with the latest blocks’s sapling root. And if it does this, the sapling root won’t match the real one that the network has, which makes it impossible for the LightwalletD to steal funds (Since the txns created by the client won’t be valid, and won’t get mined). Any outgoing transactions created by a client connected to a bad LightwalletD won’t be mineable.

In an upcoming update, it will become impossible for a adversarial LightwalletD to even mislead a client. I’m working on an update that will fetch the latest block header and sapling root from the P2P network. With this, the client will be able to detect a malicious LightwalletD.

Edit: I should add, the primary motivation for me to add this was to check if we’ve accidentally missed any CompactOutputs, for example in bad network conditions on mobile phones. It also has a nice side effect of making sure there are no bugs in the sync code and the wallet has not run into some weird edge case.

You won’t be able to spend the old funds instantly, but if you received new funds recently, you’ll be able to spend those right away. For example, research shows that a lot Zecwallet users open the wallet when either they just received funds or are expecting to receive funds shortly. In these cases, these new funds will be spendable immediately.

However note that BlazeSync will be faster in your case too - Since it decouples the trial decryptions from the merkle tree updates, it can update the old sapling note’s commitment tree much faster, allowing the funds to be ready to be spent ~5x faster than today.

2 Likes
5

Stealing funds isn’t going to happen. For that, the user must be tricked into signing a fake payment. As long as he checks the recipient address and amount, he will be safe.

But that’s really not as hard as it looks. The bad lightwalletd (LWD) is feeding you the data (rogue transactions). It can apply the same data to the tree state and then send you the final result. What your client does can clearly also be done by the bad LWD as well. In fact, this is checking that the LWD is consistent but not that it’s truthful.

You are right that the transactions will be rejected by the P2P network once they are submitted. But the client will send them through the bad LWD. Therefore the later can include them in its rogue set of transactions and recalculate the tree state accordingly. As a result, the wallet will think the transaction was mined.

IMO, the verification using only LWD does not really work and I agree that joining the P2P network will help. Please let us how this goes.

I understand. Conceptually, this is a new wallet that has a recent birth height that is overlaid to the existing wallet (I’m sure it’s implemented completely differently).

That’s a good idea!

1 Like
6

You’re right. I edited the my post to point out that my primary motivation was to check against accidental misses. That’s why, it’s just in the SDK for now (Not in the wallet UI yet). Once I add the P2P verification, then we can expose it in the wallet.

1 Like
7

Lots of improvements. Thanks for the update.

2 Likes
8

What do you mean by “accidental misses” ? A honest LWD missing transactions?

Currently decryption is performed in software on phones using arm64.
Using the dedicated hardware instructions should increase performance by x3 to x10. Is this research that @ZcashGrants would be open to sponsor?

For your reference:

ARM architecture[edit]

Programming information is available in ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile (Section A2.3 “The Armv8 Cryptographic Extension”) .[20]

  • ARMv8-A architecture
    • ARM cryptographic extensions optionally supported on ARM Cortex-A30/50/70 cores
  • Cryptographic hardware accelerators/engines
9

Great work @adityapk00! This is cutting edge and a giant leap forward in User Experience. I’ll be running this on my ZecWallet, first thing in the morning. I’m so very excited about the work you’re doing and I look forward to the next phases.

Very exciting!

2 Likes
10

Trial note decryption is bottlenecked by variable-base scalar multiplication on the Jubjub curve, which isn’t helped by those ARM AES extensions.
(The symmetric cipher is ChaCha20, not AES, but that doesn’t matter anyway because it’s not the bottleneck. The BLAKE2b-based KDF and Poly1305 need to be computed for each decryption but they are also cheap compared to the scalar multiplication.)

2 Likes
11

Ah ok, sorry I didn’t pay close attention to the actual method used.
The scalar multiplication is coming from the key agreement, and the variable base is g_d ?

1 Like
12

Excellent News @adityapk00 ! congratulations!

2 Likes
13

This is awesome!

Is there anything special that zecwallet-light-cli users have to do to use these new features? Or do we just have to update?

Does this mean that if a lightwalletd tries to maliciously omit a transaction, or a memo, the wallet can catch it and warn the user?

(I didn’t realize it was possible to prove “this set of data is complete”, just that the transactions given were all valid.)

Can verify be run all the time, so that we always know we didn’t miss anything?

14

Yes, that’s right. The variable base is epk.

1 Like
15

I’m not sure you can actually be sure that all the transactions are valid because we have partial data.

In the lightwallet protocol doc, it says:

In particular, the underlying Zcash node / proxy combination is assumed to be “honest but curious” and is trusted to provide a correct view of the current best chain state and to faithfully transmit queries and responses. Methods for weakening this assumption are discussed in appendix FOO.

Then,

Appendix FOO
You can require the proxy to give you all the block headers to validate.

And,

Block header validation provides light clients with some assurance that the CompactOutputs being sent to them are indeed from valid blocks that have been mined. The strongest-possible assurance is achieved when all block headers are synchronised; this comes at the cost of bandwidth and storage.

I believe CompactOutputs can be checked because of the cmu must match the value recalculated from the note plaintext, and the final tree state must match the value in the block header.

But, (emphasis mine)

By default, CompactBlocks only contain CompactTxs for transactions that contain Sapling spends or outputs. Thus they do not contain sufficient information to validate that the received transaction IDs correspond to the transaction tree root in the block header. This does not have a significant effect on light client security: light clients only directly depend on CompactOutputs , which can be authenticated via block header validation.

@str4d , I thought that CompactSpends were used to identify which nullifiers are spent. Therefore the light client depends on their correctness too. Isn’t that so?

Do you mean that the note is marked spent by the client locally anyway? But then, what if it was spent from another wallet? (far fetched scenario)

16

You just have to update the zecwallet-light-cli dependency, and you’ll automatically get this update. If you’re running a custom LightwalletD server, you’ll have to update that as well (And now that Zecwallet Lite is compatible, you can also run the ECC LightwalletD)

verify right now only checks that the data is consistent (i.e., it makes it harder for a malicious LightwalletD to mislead the wallet). It doesn’t yet connect to the p2p network to get the actual sapling root, but that’s coming soon too. Once we have that, verify will ensure that any malicious activity will be detected.

17

Thanks for the reply!

So once my client knows the correct Sapling root, the lightwalletd can no longer omit a transaction without detection?

Will it be able to omit memos, without detection?

18

Correct. It will not be able to omit or insert any transactions. Or even reorder them.

No, it will not, since the memos are encrypted as a part of the transaction, and any tampering will be easily detectable.

19

This is great!

1 Like
20

@adityapk00 please point in right direction. I seem to have lost 60zec in Zec- wallet lite (which I have been using for a while now…) When I restore with my pass phrease, it gives me strange balance and unable to transact or see real balance.

I would not bother you, the developer, except, to me it is a lot of $. I have exported private keys, and also have seed phrase. No matter what machine I restore on, same result. … A trransparent address, missing some digits (which can be found in the private keys) and an old balance.

Sorry if rambling, please pint me in the right direction.

Thank you, @djlsnuff