Error when sending: bad-tnx-sapling-unknown-anchor

[pacu]

What is the bug?
When sending a specific amount the tx submission fails with bad-tnx-sapling-unknown-anchor

Additional context
A note is marked as unspent when it is. Rescanning fixes the issue

Solution
"Rescan from height"

[gmale]

Mentioned internally here on 1/19 and here on 2/18 and here on 2/10 in the ECC Wallet and here on 3/7 in the Unstoppable wallet.

Note: I've linked to internal conversations rather than posting details here since the screenshots contain personal info and this is a public github issue.

[gmale]

Let's discuss all the analytics we'd like to have when this occurs in our internal wallet and then add whatever helpful information we can. For instance: a running list of reorgs that occurred and how far we rewound the chain to address them. Perhaps also the anchor height of a failed submission, along with a timestamp so we can cross-check the expected height at that time.

[pacu]

That's a great idea.

I don't think that we have access to the anchor height chosen but we can estimate it from the expiry height. Not the best solution though :/

[defuse]

We should investigate this issue thoroughly, add regression tests for whatever the problem is, and spend a bit of time looking for similar issues (I can do that once this one is understood), because this error message is proof that something is wrong with the wallet's note commitment handling, which is a critical security control in the wallet. A failure like this, if it can be controlled by an attacker, could lead to attacks where users are tricked into thinking they received funds when they didn't.

This could be a sign of a compromised lightwalletd messing with the notes it's sending to wallets, but that's very unlikely IMO because it's not showing up in situations where it would give an attacker any kind of benefit. Much more likely is that it's some bug that's being triggered accidentally. Even if that's the case and the bug only occurs rarely by accident, until we understand what's going on, we can't be sure that it's not something an attacker could trigger purposefully at-will, so I recommend treating it as high severity at least until we understand what the problem is.

[defuse]

Reorgs sound like the most likely culprit. Either the transaction is being generated just fine and a reorg is changing some notes that are being included in the anchor and invalidating the once-valid anchor (so log reorgs after transaction creation / broadcast as well), or there's a bug in the note handling logic, most likely triggered by weird reorg cases.

[pacu]

@defuse I can recreate the conditions based on our suspicions. That means, using librustzcash crates 0.4 crates with sdk 0.9.3, creating a no change transaction, send it to lwd and reorg the transaction. The problem is that we will never get to see the error in reality because darksidewalletd can't validate consensus rules since it holds a synthetic chain.

Any Ideas?

[pacu]

Here's the complete test on the experiment branch. it obviously fails because the code it uses does not have the bug fix. The problem is that we can only assert the preconditions for the real problem because the error in question is a consensus validation error from zcashd
https://github.com/zcash/ZcashLightClientKit/pull/new/experiment/bad-anchor-research

[defuse]

Ah, good point @pacu! To properly test this, lightwalletd will need to compute the correct merkle tree roots (anchors) and check that all the transactions that get submitted to it reference a valid anchor. It would also be nice to have lightwalletd check the zero-knowledge proof.

We should definitely avoid going down the path of re-implementing zcash consensus rules in darksidewalletd, because that will be a lot of work and it will inevitably behave differently from zcashd making the tests inaccurate. It's probably worth adding just these checks since they are what will catch the most severe kinds of scanning errors.

I'll open a ticket in the lightwalletd repository for discussing and tracking this.

[defuse]

zcash/lightwalletd#346