ZIP-244 & ZIP-245: creation of non-malleable txids + TZE signature hashing

[nuttycom]

No description provided.

[codecov]

Codecov Report

Merging #319 (4d2bd72) into master (3a8e729) will increase coverage by 0.56%.
The diff coverage is 19.06%.

❗ Current head 4d2bd72 differs from pull request most recent head dad336a. Consider uploading reports for the commit dad336a to get more accurate results

@@            Coverage Diff             @@
##           master     #319      +/-   ##
==========================================
+ Coverage   64.64%   65.21%   +0.56%     
==========================================
  Files          69       65       -4     
  Lines        7079     6965     -114     
==========================================
- Hits         4576     4542      -34     
+ Misses       2503     2423      -80     

Impacted Files	Coverage Δ
zcash_primitives/src/transaction/sighash.rs	31.96% <9.55%> (-50.28%)	⬇️
zcash_primitives/src/transaction/blake2b_256.rs	33.33% <33.33%> (ø)
zcash_primitives/src/transaction/mod.rs	44.29% <39.70%> (-4.95%)	⬇️
zcash_primitives/src/transaction/tests.rs	88.46% <100.00%> (-9.54%)	⬇️
zcash_client_sqlite/src/error.rs	12.96% <0.00%> (-3.17%)	⬇️
zcash_history/src/node_data.rs	62.03% <0.00%> (-2.78%)	⬇️
zcash_client_sqlite/src/chain.rs	95.20% <0.00%> (-2.36%)	⬇️
zcash_primitives/src/keys.rs	63.04% <0.00%> (-2.18%)	⬇️
... and 52 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3a8e729...dad336a. Read the comment docs.

[nuttycom]

@str4d now that I'm revisiting this signature hash code that we originally worked on together, I'm puzzled here - why is there a value associated with the TZE input?

[str4d]

The logic for adding it was the same as for transparent inputs: without it, there's nothing in the spend that directly commits to the value of the spent output, so a hardware wallet can't verify the fee without being provided those input coins. By having the value be part of the signature digest, the hardware wallet can present accurate information without needing the coin being spent, and the resulting signature can only be used if the client wasn't lying about the coin's value.

This is also the thing I was saying we should check against the hardware wallet fee vulnerability from last year, which IIRC said that this defense was ineffective if the adversary could ask the user to sign multiple times.

[nuttycom]

Ah, okay. I understand this better now than the last time we had this dicussion.

[nuttycom]

A question about this ZIP arose this morning in a discussion between myself and @str4d. The current draft of this ZIP specifies that the consensus_branch_id be committed to as part of the personalization string for transaction identifier hashes. This could potentially pose a problem for off-chain protocols which require transaction identifiers to remain stable across network upgrade boundaries, such as BOLT.

One possible solution to this is to add the consensus_branch_id as an optional field to the transaction and include it as effecting data, such that a TxId may optionally (and would by default) commit to a consensus branch ID after which it would be considered invalid. This would make it possible to have transaction identifiers that remain stable across network upgrade boundaries, at the cost of replay protection. What do folks think here? Do protocols that depend on the consensus branch ID have to shut down or automatically terminate at network upgrade boundaries, or is there a better way?

cc/ @daira @dconnolly

[nuttycom]

Oops, that comment was supposed to go on the ZIP.

[daira]

It was a deliberate design decision to prioritize replay protection ahead of allowing transactions to remain valid across a network upgrade, when we designed Overwinter. I'm not saying we have to maintain that decision for all time; just pointing out that it wasn't something that happened accidentally.

[nuttycom]

subsumed by #375

[Baiju311]

Deleted due to spam comment.