Zecwallet Lightclient Protocol Research and Development

hanh · August 2, 2021, 4:50pm

Hi, do 1-block reorgs exist by protocol rules?
In bitcoin reorgs happen when the server sees a chain that has more POW, aka longer. Therefore it needs to be at least 2 blocks. A fork that differs by 1 block would have the same POW.
I think it is the same with zcash.

1337bytes · August 4, 2021, 12:10am

Hi, apologies if this has been answered already (quickly skimmed through the discussion here). I was wondering whether the possibility of using react-native-macos and react-native-windows instead of Electron has been looked into, allowing for more code reuse between zecwallet-mobile and zecwallet-lite.

I’m not very knowledgable on the specifics of performance/security between react-native-macos/windows compared to Electron, but this could be an interesting area to explore if working on the stack anyway, and could be a nicer system for Rust bindings; react-native-desktop-qt appears to have been abandoned though, so Electron would likely still be needed for Linux.

earthrise · August 5, 2021, 3:59pm

This has an effect on reliability and privacy. Any shielded transaction spending a note in a once-confirmed transaction that gets reorged away will become invalid (because the anchor changes), so there’s some additional probability that these transactions will fail. When that happens, the spent note’s nullifier will be exposed twice, first in the first attempt to spend and then again once the transaction is repeated, making it possible to link the two transactions together.

Will the wallet use the latest block’s anchor to generate all transactions? If not, an attacker can easily tell when the wallet is spending a note in the latest block since they will be distinguished by using the latest block’s anchor vs. an anchor further back. If yes, then all of the wallet’s transactions will suffer from the unreliability described above, not just 1-confirmation spends.

Shawn · August 5, 2021, 7:36pm

@adityapk00 It seems as though there are some open questions regarding privacy and security about this recent change.

I’m curious how you came to the decision to implement it and if you consulted any experts in the field prior to doing so. And if not, if you would be willing to roll back the change until it’s been reviewed more thoroughly.

adityapk00 · August 5, 2021, 8:57pm

I did consult with the ECC’s wallet team before making this change. Additionally, I think this is also the behaviour of the official zcashd wallet. It allows you to spend funds from the previous block (i.e., 1 conf), and seems to pick the latest witness (i.e, witness from the previous block). I modeled ZecWallet’s behaviour to be the same as zcashd’s.

With the latest updates, the lightclients are subject to approx. the same reorg risk as the zcashd wallet.

Isn’t zcashd subject to the same privacy/reliability problems?

Shawn · August 5, 2021, 9:10pm

I believe this behavior is possible with any wallet, inheriting from Bitcoin. My concern was not that it could, but if it should.

If @earthrise (a ECC core dev) and other community members claim it can have a negative impact on reliability or privacy of transactions, and with ZecWallet being such a prominent wallet, I think it’s at least worth taking the time to discuss further.

I’m not a core dev, or on the ECC wallet team. I’m simply trying to understand the benefit vs tradeoffs of this approach.

hanh · August 5, 2021, 11:36pm

@adityapk00, it’s true that zcashd uses minconf = 1 by default.

However, the recommendations are to use 15.

I think you could simply offer the user the option to set the value. That’s what I do in ZWallet.

hanh · August 6, 2021, 12:06am

Btw, I was commenting on this part ealier. 1-block reorg cannot be detected because they are not reorgs but valid forks. Let’s say, there is block A and then both miner B & C build on top of it.
There would be 2 forks: A-B and A-C. Both of them have the same POW and are equally valid. The network is split. Some servers will follow A-B, others A-C. It depends on which block they received first. It’s by design and entirely expected. In the original bitcoin paper, Satoshi talks about the gap between honest and attacker. There is no gap when the length is the same.

The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker’s chain being extended by one block, reducing the
gap by -1.

Now, even if you could detect potential reorgs, i.e. you see that zcashd has both chaintips, it could be too late to do anything. Your transaction is already out.

Scenario:

zcashd has A-B,
user posts tx based on anchor B
zcashd now sees A-C
zecwallet detects A-C (hypothetically)
… ouch too late.

adityapk00 · August 6, 2021, 1:02am

This is not correct.The 2 blocks B and C do not have the same PoW, they have the same difficulty target. One of them will have slightly more PoW, and zcashd will deterministically reorg to that block.

Please see Get latest block from zcashd by adityapk00 · Pull Request #348 · zcash/lightwalletd · GitHub

For eg, this block on the zcash mainnet was reorg’d at the same height:

{
"hash":"0000000000adca687b62d4915836fc8fd5d5dea6b3923942bef3b81b071f8d0f",
"height":1344662,"level":"warning","msg":"REORG/Current Block",
"reorg":0,"time":"2021-08-05T13:51:37-07:00"}

hanh · August 6, 2021, 1:28am

If they have the same difficulty target, they have the same POW. A block earns POW by passing the hash threshold criteria. It doesn’t matter whether it is just barely or by a lot.

The reason for that is to avoid miners continuing work secretly after a block is mined and later introducing a block that rolls back the blockchain.

I remember this because when I implemented a full validating bitcoin server the formula came up.

This is covered by a regression test in bitcoin core.

github.com/TheBlueMatt/test-scripts

FullBlockTestGenerator.java

211c2e72c


      
          NewBlock b1 = createNextBlock(chainHead, chainHeadHeight + 1, spendableOutputs.poll(), null);
          blocks.add(new BlockAndValidity(b1, true, false, b1.getHash(), chainHeadHeight + 1, "b1"));
          spendableOutputs.offer(b1.getCoinbaseOutput());
          
          TransactionOutPointWithValue out1 = spendableOutputs.poll(); checkState(out1 != null);
          NewBlock b2 = createNextBlock(b1, chainHeadHeight + 2, out1, null);
          blocks.add(new BlockAndValidity(b2, true, false, b2.getHash(), chainHeadHeight + 2, "b2"));
          // Make sure nothing funky happens if we try to re-add b2
          blocks.add(new BlockAndValidity(b2, true, false, b2.getHash(), chainHeadHeight + 2, "b2"));
          spendableOutputs.offer(b2.getCoinbaseOutput());
          // We now have the following chain (which output is spent is in parentheses):
          //     genesis -> b1 (0) -> b2 (1)
          //
          // so fork like this:
          //
          //     genesis -> b1 (0) -> b2 (1)
          //                      \-> b3 (1)
          //
          // Nothing should happen at this point. We saw b2 first so it takes priority.
          NewBlock b3 = createNextBlock(b1, chainHeadHeight + 2, out1, null);
          blocks.add(new BlockAndValidity(b3, true, false, b2.getHash(), chainHeadHeight + 2, "b3"));

steven-ecc · August 6, 2021, 2:52am

For clarification, the ECC wallet team was informed of the change but didn’t advise on the one-confirmation setting. Our apologies @adityapk00 if you were looking for more input than we provided.

The default behavior of zcashd is minconf=1 but as @hanh indicated our recommendation is 15. We had intended to set a default of 10 but have not made the change as of yet.

daira · August 6, 2021, 9:09am

Yes, and that is a long-standing bug: choose less recent JoinSplit, Spend, and Action anchors · Issue #1614 · zcash/zcash · GitHub

It’s always been the case that we recommend choosing anchors several blocks back. I’m sorry if there was a miscommunication about that.

earthrise · August 6, 2021, 5:02pm

I completely forgot zcashd let you do that (even though I’ve used that bug many times! it’s convenient!). Unfortunately because of that bug there will probably be a lot of recent-anchor transactions on the chain that you can tell didn’t from the mobile wallets because of the recent anchor, so we should plug that privacy leak in zcashd. It doesn’t necessarily have to be 10-15 confirmations if users are understanding and accepting of a speed-privacy trade-off, but we should look into how frequent N-block reorgs are. There’s some more discussion on the zcashd ticket about the privacy leaks.

dontbeevil · August 7, 2021, 5:14pm

Can Zcash move to account based model for shielded transactions like ethereum? What’s the technical limitation

dontbeevil · August 7, 2021, 5:18pm

Is there any reason why the ticket isn’t prioritized in ECC sprint? Wondering if we can for all the benefits. I was thinking before ECC looks into scalability & PoS, maybe ECC can dedicate some resources to closing some of the tickets that improves privacy & usability.

adityapk00 · August 12, 2021, 4:23pm

Project Milestone 3

Zecwallet is now about 2/3rd of the way through the this grant. Over the past 2 months, several features have been added to Zecwallet’s family of apps (See upstream in this thread for updates)

Mempool support for instant notifications
Much improved test coverage and build infra
LightwalletD compatibility and improvements like price API, Mempool streaming
Improved perf, including support for large wallets

Here’s the full list of milestones and their status

What’s next

For the last milestone (Milestone 4), we’ll focus on getting Orchard/Halo2 done and shipped in the wallet, including all the orchard features like unified addresses.

joshs · August 12, 2021, 11:06pm

Thanks @adityapk00. Are you planning to support Shielded by Default - using auto shielding in addition to UAs?

Autotunafish · August 12, 2021, 11:17pm

(I saw that blog post earlier, haven’t had a chance to read it yet)

adityapk00 · August 12, 2021, 11:39pm

Yes, very much so.

adityapk00 · September 10, 2021, 7:33pm

Final Milestone Change

Originally, the final milestone for this grant was the Halo2/Orchard update in Zecwallet, including unified addresses and auto shielding, which was scheduled to be completed by Oct 17th. However, due to the Halo2 timeline getting delayed to Jan 2022, we’re in a bit of a spot.

We didn’t want to delay this grant for 3 months, and have the team idle, nor would it make sense to mark this grant as “done” with only testnet support for Halo2.

So, Zecwallet consulted with the @ZcashGrants , and we’ve together agreed to to swap out the deliverables for the final milestone for this grant. The Halo 2/Orchard features will be done as a part of a new grant next year, and we’ll pull in some work we were planning on doing from next year into the current grant.

More specifically: We’ll replace the following deliverables in the final milestone:

Unified Addresses in wallet
Halo 2 / Orchard support

with the following:

Foundational work for Halo2/ Orchard
Multiple z and t address support in mobile wallets
Import / Export private / viewing keys directly (Including restore from private key instead of seed phrase for zcashd/Zecwallet Fullnode compatibility)
New Privacy options in mobile wallet:
- Download None / Wallet / All memos
- Use different lightwalletd servers to download blocks / download memos / sending txns, so no one server has all your info.
- Manual control over t-address shielding.

The timeline (deliver by Oct 17th) and the budget will remain the same

Topic		Replies	Views
Zecwallet Lite Security Updates and Review Applications	21	3055	April 16, 2021
ZecWallet Lightclient CLI beta ZecWallet	27	2584	September 27, 2019
Zecwallet-Lite UI - beta1 ZecWallet	1	1623	October 29, 2019
V1.0 of Zecwallet-Lite is now available! ZecWallet	10	2952	March 9, 2020
ZecWallet LightClient CLI Mainnet beta! ZecWallet	13	1948	October 10, 2019

Zecwallet Lightclient Protocol Research and Development

Project Milestone 3

What’s next

Final Milestone Change

Related topics