Add transaction-builder suport for TZE-bearing transactions.#12
Conversation
Codecov Report
@@ Coverage Diff @@
## zip-tzes #12 +/- ##
=============================================
- Coverage 64.62% 34.38% -30.25%
=============================================
Files 109 97 -12
Lines 15428 11663 -3765
=============================================
- Hits 9970 4010 -5960
- Misses 5458 7653 +2195
Continue to review full report at Codecov.
|
| consensus_branch_id, | ||
| SIGHASH_ALL, | ||
| Some((i, &info.coin.script_pubkey, info.coin.value)), | ||
| // tze equivalent is ??? |
There was a problem hiding this comment.
I think the approach we will end up taking is to serialize the TZE data in place of the transparent data, so this would become Option<InputData> with:
enum InputData {
Transparent {
index: usize,
script_pubkey: Script,
value: Amount,
},
Tze {
index: usize,
precondition: Vec<u8>,
value: Amount,
},
}and we would domain-separate the transparent and TZE data types in the signature hash.
There was a problem hiding this comment.
This is the one piece that I think we should perhaps pair on; does this require a change to the ZIP?
There was a problem hiding this comment.
Yes, the ZIP will need to be updated to describe how it changes ZIP 243.
There was a problem hiding this comment.
Canopy has a consensus branch ID now, but let's leave these as placeholders so that anything attached to the Canopy NU in this branch is explicitly domain-separated from anything that might end up on mainnet.
There was a problem hiding this comment.
There has to be a nicer way to handle this, but we can figure it out in a future refactor of the Rust crates.
6d18217 to
3b44c5b
Compare
3b44c5b to
4be71ef
Compare
Closes zcash/zcash#4506.