Jack Grigg

Think of `vpub_new` as an input to the transparent part of the transaction. The address it goes to is therefore defined by the transparent outputs. If there aren't any, then...

Then the sum of the values of the transparent outputs must be less than or equal to `vpub_new`. More precisely, the balance equation is: ``` sum(tx_inputs) + sum(vpub_new) >= sum(tx_outputs)...

For reference, `hSig` calculation for verification happens [here](https://github.com/zcash/zcash/blob/master/src/zcash/JoinSplit.cpp#164).

The main problem with this proposal is it makes transaction parsing contextual: it becomes impossible to parse a transaction without knowing the full set of chain NUs. Obviously when a...

It is certainly one of intended outcomes of allowing Orchard outputs in coinbase transactions. Note however that we would require a consensus rule change anyway to alter the funding stream...

I would prefer that we use a Unified Address that we place additional restrictions on (if any, for simplicity). Those restrictions don't actually matter, since we'd be hard-coding the addresses...

Just to be clear, the above is intended as something concrete we can stare at and work on, not as the final proposal (though I think the above is a...

Updated draft to use `PrivateKey, PublicKey` traits inside `Signer` / `Verifier` structs, so they can be generalised over the backend (e.g. HSMs) a la #32.

My suggestion (which I'll write up next) is to have equivalent `Encryptor` / `Decryptor` objects. We could maybe treat these as block ciphers and use the `block-cipher-trait` traits, but it...

The struct-based API would be used something like this: ```rust use rsa::{pss::Signer, RsaPrivateKey}; use sha2::{Digest, Sha256}; use signature::DigestSigner; let privkey = RsaPrivateKey::from_wherever(); let signer = Signer::unblinded(&privkey); let digest = Sha256::digest(msg);...