checkpoints on the Canopy activation block MAY validate Ed25519 signatures using
the post-Canopy rules for the whole chain.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
the consensus branch ID used for SIGHASH transaction hashes, should apply only
when effectiveVersion ≥ 5 (since v4 transactions did not explicitly encode the
`nConsensusBranchId` field.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
spending keys such that the corresponding internal incoming viewing key is 0
or ⊥. (This was already specified for the external incoming viewing key.)
Similarly in \crossref{orchardfullviewingkeyencoding}, do not consider a
decoded key valid if either its external or internal incoming viewing key
would be 0 or ⊥.
fixes#598
transaction in a block. This wording was copied from the Bitcoin Developer Reference
(https://developer.bitcoin.org/reference/transactions.html#coinbase-input-the-input-of-the-first-transaction-in-a-block),
but it does not match the implementation in zcashd that was inherited from Bitcoin Core.
Instead, a coinbase transaction should be, and now is, defined as a transaction with a
single null prevout. The specifications of consensus rules have been clarified and adjusted
(without any actual consensus change) to take this into account, as follows:
* a block MUST have at least one transaction;
* the first transaction in a block MUST be a coinbase transaction, and subsequent
transactions MUST NOT be coinbase transactions;
* a transparent input in a non-coinbase transaction MUST NOT have a null prevout;
* every non-null prevout MUST point to a unique UTXO in either a preceding block, or a
*previous* transaction in the same block (this rule was previously not given explicitly
because it was assumed to be inherited from Bitcoin);
* the rule that "A coinbase transaction MUST NOT have any transparent inputs with non-null
prevout fields" is removed as an explicit consensus rule because it is implied by the
corrected definition of coinbase transaction.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
but the type of incoming viewing keys should not include 0 because KA^Orchard.Private does not.
This is now handled by explicitly rejecting 0 as output from Commit^ivk when generating ivk
in \crossref{orchardkeycomponents}.
An encoding of ivk as 0 is also rejected in \crossref{orchardinviewingkeyencoding} when parsing
an incoming viewing key.
The action circuit needed no changes because pk_d already could not be the zero point, and
therefore the 'Diversified address integrity' condition fails when ivk = 0.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
for checkpointing, and allow nodes to impose a limitation on rollback depth. Also in
\crossref{bctv}, note that this checkpointing requirement mitigates the risks of not
performing BCTV14 zk proof verification.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Daira Hopwood
Jack Grigg
Kris Nuttycombe
github-actions