Zebra: Check sighash parameters in transaction verifier

[hdevalence]

Version

Git

Description

The sighash parameters in the transaction verifier are possibly incorrect and need to be checked.

[teor2345]

I've done some investigation, but I haven't discovered the fix yet.

Here's what I know:

• our sighash impl passes the zcashd test vectors
• Jubjub verification fails using our sighash impl
• transparent script verification succeeds
• I don't know if script verification uses an alternate sighash impl internally
• both batched and individual jubjub fail
• the parameters passed to sighash seem to match the spec
• I did a few quick checks, and it's not a simple output array reversal

Here's what we could check next:

• check if our Jubjub verification passes on the test vectors
• try to work out what Jubjub expects the hash to be
• try to work out if there's a simpler version of the problem, or a very simple transaction we can check in zcashd and Zebra
• work out if all 3 of our sighash usages are failing (there's 1 for sprout and 2 for sapling)

Here's what I think the bug could be:

• a byte order issue
• accidental trailing or truncated bytes
• some kind of issue in the glue code
• the test vectors don't cover the cases we're actually using (but they do cover Overwinter and Sapling)
• the zcashd impl doesn't quite match the spec
• an issue in the way we use the sighash in other code

[teor2345]

* work out if all 3 of our sighash usages are failing (there's 1 for sprout and 2 for sapling)

It looks like only the Sapling binding signature is failing - which means the bug is probably in the Sapling binding signature code.

I'd like to run a full sync on mainnet and testnet to be sure.

I'm using this code and dashboard:
https://github.com/teor2345/zebra/tree/sighash-diagnosis

[teor2345]

Notes:

• the "tmp" instances haven't synced past Canopy yet, so they're only verifying gossiped blocks
• some nodes could be sending blocks with bad binding signatures, but that seems unlikely

[teor2345]

Just confirming that it's only the binding signature, after syncing to tip.

Notes:

• this is showing up in 3 instances, but not in the other 3. That could be a port configuration issue on my end.