ZIP-244 & ZIP-245: creation of non-malleable txids + TZE signature hashing #319
Conversation
nuttycom
force-pushed
the
nonmalleability
branch
from
9bce3c2 to
a7c96f7
Compare
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
nuttycom
force-pushed
the
nonmalleability
branch
2 times, most recently
from
0ae177e to
4d2bd72
Compare
nuttycom
force-pushed
the
nonmalleability
branch
from
6724e8b to
b9cbb30
Compare
| CompactSize::write(&mut ch, precondition.extension_id.try_into().unwrap()).unwrap(); | ||
| CompactSize::write(&mut ch, precondition.mode.try_into().unwrap()).unwrap(); | ||
| Vector::write(&mut ch, &precondition.payload, |w, e| w.write_u8(*e)).unwrap(); | ||
| ch.write_all(&value.to_i64_le_bytes()).unwrap(); |
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Ah, okay. I understand this better now than the last time we had this dicussion.
nuttycom
changed the title
|
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 |
|
Oops, that comment was supposed to go on the ZIP. |
|
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
force-pushed
the
nonmalleability
branch
from
6b3b59e to
df76955
Compare
Restructure txid generation via a hash tree structured such that all possible txid hash data is reused in the signature hashes.
This reverts changes that had inadvertently been made to the v4 sighash digest algorithm and physically isolates the code to help prevent similar errors in the future.
Hide ZCASH_TZE_INPUT_HASH_PERSONALIZATION behind `zfuture` flag
nuttycom
force-pushed
the
nonmalleability
branch
from
7aecc06 to
f13839b
Compare
|
subsumed by #375 |
No description provided.