zcash/zcash#5987 added a bridge to `orchard::Bundle<Authorized, Amount>`
for `getrawtransaction`. This commit expands it to also cover the
consensus rules, by migrating over missing functionality from the
hand-written FFI methods, and exposing the Orchard `BatchValidator` type
directly (as with Sapling) instead of via the C++ `AuthValidator`
intermediary.
Part of zcash/zcash#6397.
As a pre-check inside `z_sendmany` we estimate the size of the
transaction that would be created, to confirm it won't exceed any
limits. We do this by creating a fake transaction with fake outputs and
measuring its size. In the case of Sapling recipients, we'd push an
empty `OutputDescription`.
In zcash/zcash#6459 we pulled in changes that improved type safety in
the Rust types. One of these changes was that the `cv` field in a
Sapling Output Description is now enforced at parsing time to be not
small order (where previously we enforced this at proof verification
time).
The two above paragraphs collide because when measuring the size of the
fake transaction, we convert a `CMutableTransaction` into a
`CTransaction`; this calls `UpdateHash` to pin its txid, and that causes
the transaction to be serialized and then parsed across the FFI. This
causes the null `OutputDescription` to reach the Rust parser which
treats it as invalid.
There are two solutions to this, which are used in various contexts:
- Avoid pushing a null `OutputDescription` into a `CMutableTransaction`.
This is the fix implemented in this PR for `z_sendmany`: we now call
`RandomInvalidOutputDescription()` which gives us a consensus-invalid
but parser-valid `OutputDescription`, suitable for estimating tx size.
- Use `UNSAFE_CTransaction` to avoid having `UpdateHash` be called on
construction. This type is used in tests where we explicitly want to
construct an invalid type in C++, for consensus checking purposes. One
of the `OutputDescription()` uses was in a test, but didn't trigger
the issue because the test was checking a different part of the
transaction being invalid. Technically no change is needed here;
however we now also call `RandomInvalidOutputDescription()` here for
uniformity.
Part of zcash/zcash#6509.
This adds two new CuckooCaches in validation, each caching whether all
of a transaction bundle's proofs and signatures were valid.
Bundles which match the validation cache never have proofs or signatures
added to the batch validators. For blocks where all transactions have
been previously observed in the mempool, the final validation of the
batches should be a no-op.
Part of zcash/zcash#6049.
Since the wallet ecosystem may not be fully updated to handle
v5 transaction parsing at the point of NU5 activation, some
nodes may prefer to construct V4 transactions when not including
Orchard transaction components.
This change adds a CLI flag that allows node users to specify
that preference.
Both transparent and shielded inputs have contextual checks that need to
be enforced in the consensus rules. For shielded inputs, these are that
the anchors in transactions correspond to real commitment tree states
(to ensure that the spent notes existed), and that their nullifiers are
not being double-spent.
When Sprout was first added to the codebase, we added input checks in
the same places that transparent inputs were checked; namely anywhere
`CCoinsViewCache::HaveInputs` is called. These all happened to be gated
on `!tx.IsCoinBase()`, which was fine because we did not allow Sprout
JoinSplits in coinbase transactions (enforced with a non-contextual
check).
When we added Sapling we also allowed coinbase outputs to Sapling
addresses (shielded coinbase). We updated `HaveShieldedRequirements` to
check Sapling anchors and nullifiers, but didn't change the consensus
code to call it on coinbase. This was fine because Sapling Spends and
Outputs are separate, and we did not allow Sapling Spends in coinbase
transactions (meaning that there were no anchors or nullifiers to
enforce the input rules on).
Orchard falls into an interesting middle-ground:
- We allowed coinbase outputs to Orchard addresses, to enable Sapling
shielded coinbase users to migrate to Orchard.
- Orchard uses Actions, which are a hybrid of Sprout JoinSplits and
Sapling Spends/Outputs. That is, an Orchard Action comprises a single
spend and a single output.
To maintain the "no shielded spends in coinbase" rule, we added an
`enableSpends` flag to the Orchard circuit. We force it to be set to
`false` for coinbase, ensuring that all Orchard spends in a coinbase use
dummy (zero-valued) notes. However, this is insufficient: the coinbase
transaction will still contain an Orchard anchor and nullifiers, and
these need to be correctly constrained.
In particular, not constraining the Orchard nullifiers in a coinbase
transaction enables a Faerie Gold attack. We explicitly require that
Orchard nullifiers are unique, so that there is a unique input to the
nullifier derivation. Without the coinbase check, the following attack
is possible:
- An adversary creates an Orchard Action sending some amount of ZEC to a
victim address, with a dummy spent note. The entire transaction can be
fully-shielded by placing the real spent note in a separate Action.
- The adversary uses the exact same dummy note in a coinbase
transaction, creating the exact same output note (same victim address
and amount).
- The victim now has two notes with the same ZEC amount, but can only
spend one of them because they have the same nullifier.
This commit fixes the consensus bug by calling `HaveShieldedRequirements`
outside of `!tx.IsCoinBase()` gates. To simplify its usage, there is now
a `Consensus::CheckTxShieldedInputs` function that handles the logging
and validation state updates. We also move shielded input checks from
`ContextualCheckInputs` to `ContextualCheckShieldedInputs`; these now
mirror each other in that they check contextual rules on transparent and
shielded inputs respectively, followed by checking signatures.
The ZIP 244 changes mean that we're going to need to alter every
callsite to pass through all of the transparent `CTxOut`s being spent.
Given that we need to pass it over to Rust, it makes more sense to just
have `PrecomputedTransactionData` be the vehicle for conveying this data
across.
The ZIP 244 changes mean that shielded signatures will now require
access to any transparent inputs of the transaction, so we need to
validate the shielded signatures around the same point during block
connection or `AcceptToMemoryPool` as when we validate transparent
signatures.
Add a field `strDebugMessage` which can be passed to DoS or Invalid,
and queried using GetDebugMessage() to add extra troubleshooting
information to the validation state.
(cherry picked from commit bitcoin/bitcoin@fbf44e6f3e)
The Rust parser is stricter than the C++ parser, so we can reach errors
now non-contextually that previously were thrown by the consensus rules.
Various tests have been updated to check for these exceptions, as they
can no longer instantiate these transactions to pass to the consensus
rules. The tests use an unsafe constructor so they can still check the
consensus rules.
This matches the existing transaction builder structs:
- SpendDescriptionInfo
- OutputDescriptionInfo
- TransparentInputInfo
It also removes the dependency of the transaction format on the proving
system.
This also includes the following:
commit b12adf605640abba4cef6ddab1a2797b12cbf454
Author: Kris Nuttycombe <kris.nuttycombe@gmail.com>
Date: Mon Aug 24 16:01:18 2020 -0600
Add assertions to ensure that dependencies between active upgrades are respected.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
crypto_sign_verify_detached is still used within the consensus rules
until Canopy activation. ed25519-zebra generates signatures that are
valid under both pre- and post-Canopy rules (for our honest usage),
so we can use it to generate transaction signatures now. Then once
Canopy activates, we can remove the remaining usages of crypto_sign.
Refactor ProofVerifier
`ProofVerifier` was previously used to conditionally verify pre-Sapling Sprout
proofs (based on `ProofVerifier::Strict` or `ProofVerifier::Disabled` being
used), but hybrid Sprout proofs bypassed it (so were being verified multiple
times during block verification), and once `libsnark` was removed in
zcash/zcash#4060 `ProofVerifier::check` was doing nothing.
This PR refactors `ProofVerifier`, moving it out of the `libzcash` compilation
unit (so that it can depend on `primitives/transaction.h`), and moving Sprout
verification from `JSDescription::Verify` to `ProofVerifier::VerifySprout`.
Verification-skipping for Sprout proofs is re-introduced.
Additionally, the `ZCJoinSplit` global is removed from the codebase, and
`ZCJoinSplit::prove` is converted into a static function. We load the hybrid
Sprout parameters dynamically at proving time within the Rust code, and no
longer require a C++ global for any proving parameters.
As a side-effect, `libzcashconsensus.la` building with `--with-libs` is fixed,
as `primitives/transaction.cpp` no longer depends on `librustzcash.h`.
ZIP212 implementation
Closes#4557.
(description by @ebfull, taken from #4575)
* The `SaplingNote` structure has a new enum called `zip212Enabled`. This
member is private and reflects whether the note was or is being created
using the derivation method of ZIP 212 (i.e., `BeforeZip212` or `AfterZip212`).
* The `SaplingNotePlaintext` structure has a new unsigned char member
`leadbyte`. This member is private and contains the leading byte of the
plaintext (e.g. `0x01`, `0x02`).
* The serialization of `SaplingNotePlaintext` sets `zip212Enabled` to
`BeforeZip212` iff the serialized note plaintext version is not `0x01`.
* The `r`/`rcm` fields have been removed and replaced with a private field
`rseed`. `SaplingNote` and `SaplingNotePlaintext` now have a helper method
`rcm()` which returns the `rcm` either by deriving it with `rseed`
(if `zip212Enabled` is `AfterZip212`) or returning `rseed` by interpreting
`rseed` as `rcm`.
* All the methods of obtaining a `SaplingNote` account for these changes:
- The `SaplingNote` constructor that is used by e.g. the transaction builder,
and internally samples random `rcm`, now takes a `zip212Enabled` argument
to decide whether to sample `rcm` the "old" way or the "new" way.
- The bare constructor for `SaplingNote` is removed.
- The other constructor which takes the raw contents of the note is only used
in tests or in `Note.cpp`, but now also takes a `zip212Enabled` argument.
- The other way of obtaining a note, by calling `SaplingNotePlaintext::note()`,
has been adjusted.
* The `SaplingNotePlaintext` class now has an `generate_or_derive_esk()` method
that either samples a random `esk` or derives it using the local `rseed`
depending on the value of `leadbyte`.
* The encryption routine is modified to consult `generate_or_derive_esk()` and
provide it to the note encryption object.
* The note encryption objects now take an optional `esk` as input and otherwise
sample a random `esk` internally. This API functionality is preserved to allow
for testing.
* The `SaplingNotePlaintext` decryption routines are modified:
- The out and enc decryption routines now check that `epk` is consistent with
the derived `esk`.
- The out decryption routine for plaintexts also checks that `esk` is
consistent with what is derived by the note.
* The miner and transaction builder consult the activation of Canopy when
creating `SaplingNote`s.
* The consensus rules are modified so that shielded outputs (miner rewards)
must have `v2` note plaintexts after Canopy has activated.
We don't support making pre-Sapling JoinSplit proofs, and we load the
parameters for post-Sapling JoinSplit proofs at proving time, so there
is no need for a global ZCJoinSplit to be passed through the APIs.
Jack Grigg
Jack Grigg
Kris Nuttycombe
Kris Nuttycombe
sasha
Wladimir J. van der Laan
Shaul Kfir
Larry Ruane
Homu
Kris Nuttycombe
therealyingtong
therealyingtong
Sean Bowe