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>
* ZIP 239: Clarify the behaviour of zcashd and the intended behaviour for unrecognized inventory types.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
* Update zip-0239.rst
Co-authored-by: Deirdre Connolly <durumcrustulum@gmail.com>
* Add GitHub Actions workflow that renders and commits the spec pdfs
* Try to run make
* Try our custom action
* Add link to Dockerfile to make action happy
* Update render workflow to manual render only
* Update .github/actions/render-protocol-pdf/action.yml
* Update .github/dependabot.yml
In zcash/zips#577 we altered ZIP 244 to have shielded signatures commit
to the same data as transparent inputs, in transactions that contain
transparent components. However, the edge case of shielded coinbase was
not correctly handled; they contain both a consensus-required "dummy"
transparent input, and binding signatures which would be required to
commit to a `CTxOut` that does not exist.
We resolve this by partially reverting one of the zcash/zips#577 changes,
by having S.2 for coinbase transactions be identical to T.2. This reverts
binding signatures in coinbase transactions to effectively signing the
transaction ID.
At the same time, we also revert the same change for transactions with no
transparent inputs but some transparent outputs; these also now revert to
using the transaction ID for all shielded signatures (like fully-shielded
transactions). The hardware wallet edge case does not apply here, as all
input values are shielded and therefore directly committed to.
Daira Hopwood
dependabot[bot]
teor
mg0716
github-actions
Deirdre Connolly
Jack Grigg