mirror of https://github.com/zcash/zips.git
e381ded490
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> |
||
---|---|---|
.. | ||
Makefile | ||
README.rst | ||
blossom.pdf | ||
canopy.pdf | ||
heartwood.pdf | ||
incremental_merkle.odg | ||
incremental_merkle.png | ||
incremental_merkle.svg | ||
jubjub.png | ||
key_components.png | ||
key_components.svg | ||
key_components_orchard.png | ||
key_components_orchard.svg | ||
key_components_sapling.png | ||
key_components_sapling.svg | ||
latexmkrc | ||
mymakeindex.sh | ||
nu5.pdf | ||
protocol.pdf | ||
protocol.tex | ||
sapling.pdf | ||
sprout.pdf | ||
zcash.bib |
README.rst
============================== Zcash Protocol Specification ============================== Build dependencies on Debian-based systems include, at least: .. code:: apt-get install texlive texlive-science texlive-fonts-extra \ texlive-generic-recommended texlive-bibtex-extra biber latexmk perl awk Building -------- Use: * ``make nufour`` to make the draft specification for NU4 (``nufour.pdf``); * ``make heartwood`` to make the specification for Heartwood (``protocol.pdf``); * ``make blossom`` to make the specification for the Blossom upgrade (``blossom.pdf``); * ``make sapling`` to make the specification for the Overwinter and Sapling upgrades (``sapling.pdf``); * ``make sprout`` to make a version of the specification that does not include Overwinter or Sapling (``sprout.pdf``). ``make all`` is equivalent to ``make nufour heartwood blossom sapling sprout``. By default these use ``latexmk``. If you have trouble getting ``latexmk`` to work, you can instead use ``make nolatexmk-sapling``, etc. That is not the preferred way of building because it may not run ``pdflatex`` enough times. It is also possible to use the incremental (``-pvc``) mode of ``latexmk`` to automatically rebuild when changes in the source files are detected, by adding ``EXTRAOPT=-pvc`` to the ``make`` command line. In this case the updated PDF files will be in the ``aux/`` directory. Manual intervention is still needed when there are LaTeX errors. Alternative TeX engines ----------------------- There is experimental support for building the specification using LuaTeX or XeTeX; see the comments at the top of the `Makefile`. However, this will `currently produce poor output <https://github.com/zcash/zips/issues/249>`_. A warning is included below the Abstract to indicate this.