Synopsis: A bug in the Zcashd wallet could result in Sprout z-addresses displaying an incorrect balance. Sapling z-addresses are not impacted by this issue. This would occur if someone sending funds to a Sprout z-address intentionally sent a different amount in the note commitment of a Sprout output than the value provided in the ciphertext (the encrypted message from the sender).
A code fix for the wallet has been written and the integration into an official Zcash release is targeted for our next release (version 2.0.4, expected March 25th).
Who is affected: Users that receive payments to their Sprout z-addresses using the Zcashd wallet are vulnerable. Users who do not receive payments to Sprout z-addresses are unaffected.
What can Sprout users do to protect themselves? Sprout users should suspend their trust in the receipt of funds to Sprout z-addresses until they upgrade to zcash v2.0.4, which is expected to be released on March 25th. If users need the fix earlier, they can manually build their own daemon with the code available now: https://github.com/zcash/zcash/pull/3897.
Once a fix has been applied, users are strongly advised to issue a rescan of the blockchain with zcashd -rescan.
Acknowledgements: Thank you to Alexis Enston for bringing this to our attention.
So there’s a couple of ways that you could check a given address without applying the patch as well. Since the errors only happen on sending, you could move your funds between addresses that you control, and if someone has made it appear as though you have more funds than you really have, you’ll get an error when doing that. If you are able to send the funds to yourself then you can show that nobody has done that.
It’s much simpler just to not rely on the Zcashd wallet’s idea of what the balance of a Sprout z-address is until the official update comes out though.
Interestingly, this bug was also present in the prototype code of Zerocash (we think). It is a pure implementation bug; the specification was always correct.
More technical detail: the intended protocol requires the receiver of a note (section 4.16.2 for Sprout; sections 4.17.2 and 4.17.3 for Sapling) to recompute its note commitment, and compare it to the commitment revealed in the transaction. This check was also present in step 3 (b) ii of the Receive algorithm in Figure 2 of the original Zerocash paper. The code for Sprout omits this check; instead it trusts that the information in the decrypted note plaintext is correct. If it is not, then an attempt to spend the note will fail.
Right…so the announcement sounded at first like it’s a common thing, but now it sounds like very rare - has it ever happened as far as we know?
I mean it seems to require someone to manually mess with the note encryption.
So the user’s experience of issuing a z_sendmany to forward on an attacker-modified note that the user had received would result in the user experiencing a z_getoperationresult of “failed” with error “logic error: witness of wrong element for joinsplit input”. But that’s only if the daemon decided to use that note. If it picked another one, the user might be none-the-wiser. Hence, better not to trust the balance on Sprout addresses until you’ve installed 2.0.4 [edit by @daira: and ran once with -rescan].
Users should install this update and then rescan the blockchain by invoking zcashd -rescan . Sprout address balances shown by the zcashd wallet should then be correct.