Compare commits

...

1989 Commits

Author SHA1 Message Date
Daira Hopwood 4966a64340 Update the status of all previously activated ZIPs to Final.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-22 22:35:03 +01:00
Daira Hopwood 3152ed67b0 Withdraw ZIP 220, and reserve ZIPs 226 and 227 for Zcash Shielded Assets.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-22 22:29:36 +01:00
Daira Hopwood 54359a8809 Update the status of all NU5 ZIPs to Final.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-22 22:21:35 +01:00
Daira Hopwood 5980676b05 Regenerate PDFs. 2022-06-22 19:06:53 +01:00
Daira Hopwood fcf78b974c Cosmetics: regenerate HTML for ZIP 252.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-22 19:01:54 +01:00
Daira Hopwood 22370345a1 ZIPs 214 and 1014: update URL for Trademark Agreement.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-22 19:01:39 +01:00
Daira Hopwood 87c5aca5f3 Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-22 18:44:40 +01:00
Daira Hopwood 69939334f0 Cosmetics (don't include "No changes before" lines in Change History entries unless needed).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-22 18:44:40 +01:00
Daira Hopwood 5618352447 Document in \crossref{concreteed25519} that a full validator implementation that
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>
2022-06-22 18:44:40 +01:00
Daira Hopwood e2ccfc11b2 Update references for \cite{ECCZF2019} and \cite{ZIP-302} and \cite{ZIP-252}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-22 18:44:37 +01:00
Daira Hopwood 30ee914674 Makefile: correct a problem with the linkcheck target if pdfs are not built.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-22 18:34:38 +01:00
Daira Hopwood 43c9df8ba6 Regenerate PDFs. 2022-06-22 13:48:23 +01:00
Daira Hopwood 57f2abf5bd Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-21 17:19:36 +01:00
Daira Hopwood b4761037a4 In \crossref{networks}, update the settled activation block hashes to be those for NU5
on Mainnet and Testnet.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-21 17:19:36 +01:00
Daira Hopwood 1be8793401 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-21 17:19:36 +01:00
Daira Hopwood 9db08c218f In \crossref{sproutspendingkeyencoding}, remove the statement that future key representations
might use the padding bits of Sprout spending keys.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-21 17:19:36 +01:00
Daira Hopwood adce640cb0 Rename ExcludedPointEncodings to PreCanopyExcludedPointEncodings.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-21 17:19:36 +01:00
Daira Hopwood 7fe898c231 Give a full-text URL for \cite{Nakamoto2008}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-21 17:19:36 +01:00
Daira Hopwood a02401a61e Correct the history entry for v2022.3.2 to include the entry about `sizeProofsOrchard`.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-21 17:19:36 +01:00
Daira Hopwood e84ce9423f Regenerate PDFs. 2022-06-06 20:30:40 +01:00
Daira Hopwood 840674803f Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-06 20:25:53 +01:00
Daira Hopwood 984c14da9e Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-06 20:22:40 +01:00
Daira Hopwood 8bc9244a47 Correction in \crossref{constants}: Uncommitted^Orchard is not a bit sequence.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-06 20:18:56 +01:00
Daira Hopwood 8d9b70b0e4 Cosmetics (spacing in v5 transaction encoding table).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-06 20:18:56 +01:00
Daira Hopwood 2336f6f345 Make \crossref{overview} more precise about chain value pools.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-06 20:18:56 +01:00
Daira Hopwood b12bb61103 An [NU5 onward] consensus rule requiring the `nConsensusBranchId` field to match
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>
2022-06-06 20:18:56 +01:00
Daira Hopwood 17042258cd Correct and improve presentation of \crossref{networkupgrades}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-06 20:18:56 +01:00
Daira Hopwood 22b7191bc3 README: update activation date for NU5 and say that it has activated.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-06-06 15:29:09 +01:00
Jack Grigg a0767f42fe Add value of sizeProofsOrchard to protocol spec §7.1 and ZIP 225 2022-06-06 10:17:33 -04:00
Kris Nuttycombe 32870a93af Fix rendering issue. 2022-05-11 21:03:29 -07:00
Kris Nuttycombe a25f2b92a7 Set NU5 activation height in the protocol specification. 2022-05-11 14:31:54 -07:00
Kris Nuttycombe ffc0ed95fa
Merge pull request #613 from nuttycom/set_nu5_activation
Set NU5 Activation Height in ZIP 252
2022-05-11 15:28:16 -06:00
Deirdre Connolly 1905603579 Fill in NU5 mainnet activation version for zebrad 2022-05-11 15:26:09 -06:00
Kris Nuttycombe 43f1404974 Set NU5 Activation Height in ZIP 252 2022-05-11 15:26:05 -06:00
Kris Nuttycombe 78f61ebc25
Merge pull request #609 from daira/zip-0316-first20
ZIP 316: at least the first 20 characters of a UA/UVK MUST be shown
2022-04-28 14:27:07 -06:00
Daira Hopwood e4ed372840 ZIP 316: specify that at least the first 20 characters of a UA/UVK MUST be shown.
fixes #571

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 21:09:04 +01:00
Daira Hopwood aec1fef7cd Regenerate PDFs. 2022-04-28 20:39:30 +01:00
Daira Hopwood ed82b5bf85 Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 20:34:21 +01:00
Daira Hopwood be7df83b10 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 20:33:57 +01:00
Daira Hopwood 2d2508d06c In \crossref{orchardkeycomponents}, do not allow construction of Orchard
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
2022-04-28 20:33:06 +01:00
Daira Hopwood dbd7339c3f Cleanup: remove duplicate macro \CommitIvkRandom in favour of \CommitIvkRand.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 20:28:07 +01:00
Daira Hopwood 0c53d8815f Clarify how to determine which table in \crossref{txnencoding} to use for transaction parsing,
depending on the effectiveVersion as determined by the `header` field. fixes #603

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 20:28:07 +01:00
Daira Hopwood 9000614a63 Add an acknowledgement to Mary Maller for reviewing the Halo 2 security proofs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 20:27:15 +01:00
Daira Hopwood 11b44b4490 Cosmetic indexing fixes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 20:27:15 +01:00
Daira Hopwood 3c3da6d6dc Correct "block chain branch" to "consensus branch" to match ZIP 200.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 20:27:15 +01:00
Daira Hopwood deafb410de Add an acknowledgement to Josh Cincinnati for discussions on the Zcash protocol,
and to more people associated with the ZK Podcast.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 20:27:15 +01:00
Daira Hopwood 99b881e8f2
Merge pull request #608 from daira/zips-32-and-203
Updates to ZIPs 32 and 203
2022-04-28 19:39:03 +01:00
Daira Hopwood d9ab7909ec ZIP 32: Point out that Sapling and Orchard keys can be invalid.
fixes #561

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 16:38:15 +01:00
Daira Hopwood fb223c206d ZIP 32: Expose DeriveInternalFVK^Orchard for use by the protocol spec.
refs #598

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 16:38:15 +01:00
Daira Hopwood b870363ae6 ZIP 203: Remove incorrect dependency between expiry heights and lock times.
fixes #569

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-28 16:38:15 +01:00
dependabot[bot] d4324bb8cb Bump actions/checkout from 3.0.0 to 3.0.2
Bumps [actions/checkout](https://github.com/actions/checkout) from 3.0.0 to 3.0.2.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v3.0.0...v3.0.2)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-04-27 17:03:59 -04:00
Daira Hopwood ae1180f6d3 ZIP 316: make the limitation on total size of encodings more explicit.
fixes #570

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-18 22:25:47 +01:00
Daira Hopwood 5aabc86e21 ZIP 252: Use present tense to refer to zcashd v4.7.0 and say that it needs the `-rescan` option.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-15 12:15:59 +01:00
Daira Hopwood 9a742b3e6c ZIP 252: Set NU5 Testnet reactivation height.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-04-14 00:10:07 +01:00
teor aa084d4c89 Update HTML for Zebra NU5 changes 2022-04-06 17:05:11 -04:00
teor bc9427282a Update Zebra release and connection behaviour 2022-04-06 17:05:11 -04:00
Daira Hopwood 12ff90a307 ZIP 252: Clarify that the activation at block 1599200 was on Testnet.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-30 17:24:34 -04:00
Daira Hopwood 0f84a7234e ZIP 252: Update 'Support in Zebra' section.
Co-authored-by: teor <teor@riseup.net>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-30 17:24:34 -04:00
Daira Hopwood 2d538c4888 ZIP 252: clarify that a paragraph applies only to Testnet.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-30 17:24:34 -04:00
Daira Hopwood dec7e4423b ZIP 252: zcashd will disconnect from Testnet nodes with peer protocol version < 170040.
refs zcash/zcash#5753

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-30 17:24:34 -04:00
Daira Hopwood 34c0c8212b ZIP 252: Updates for NU5 Testnet reactivation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-30 17:24:34 -04:00
Daira Hopwood a223dfd931 ZIP 155: change peer protocol version for `addrv2` support to ${PLACEHOLDER}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-25 16:49:30 +00:00
Daira Hopwood f6e044429d ZIP 239: remove an inessential reference to the specific peer protocol version that signals NU5 support on Testnet.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-25 16:42:57 +00:00
dependabot[bot] a5a3ffa19c
Bump EndBug/add-and-commit from 8.0.2 to 9 (#595)
* Bump EndBug/add-and-commit from 8.0.2 to 9

Bumps [EndBug/add-and-commit](https://github.com/EndBug/add-and-commit) from 8.0.2 to 9.
- [Release notes](https://github.com/EndBug/add-and-commit/releases)
- [Changelog](https://github.com/EndBug/add-and-commit/blob/main/CHANGELOG.md)
- [Commits](https://github.com/EndBug/add-and-commit/compare/v8.0.2...v9)

---
updated-dependencies:
- dependency-name: EndBug/add-and-commit
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

* Specify full semver

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
2022-03-23 17:09:39 -04:00
Daira Hopwood 6b8fca949c Regenerate PDFs. 2022-03-18 08:54:50 +00:00
Daira Hopwood 634e274df6 Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-18 08:49:31 +00:00
Daira Hopwood c7ad527f38 Fix an undefined reference in the history entry for 2021.2.17, in pre-Canopy versions.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-18 08:49:31 +00:00
Daira Hopwood 5d3b4ef038 NU5 proposal -> NU5
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-18 01:51:34 +00:00
Daira Hopwood e381ded490 \crossref{coinbasetransactions} effectively defined a coinbase transaction as the first
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>
2022-03-18 01:51:33 +00:00
Daira Hopwood e123584794 Document the consensus rule that coinbase script length MUST be {2..100} bytes. fixes #589
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-18 01:09:11 +00:00
Daira Hopwood c506a972ac Cosmetics and improvements to indexing.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-18 01:02:24 +00:00
Daira Hopwood 8f77f6f1df Acknowledge the developers of Bitcoin Core (as distinct from the designers of the
Bitcoin protocol).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-03-18 00:58:54 +00:00
Daira Hopwood 27f5bb1e68 Correct a type error in the usage of Commit^ivk: the output type Commit^ivk.Output includes 0,
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>
2022-03-18 00:56:59 +00:00
Daira Hopwood 5c7c728e63 In \crossref{blockchain}, define what a settled network upgrade is, specify requirements
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>
2022-03-18 00:50:06 +00:00
dependabot[bot] a2efd493bb Bump actions/checkout from 2 to 3
Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v2...v3)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-03-02 16:29:17 -05:00
Daira Hopwood c94c2a5517 ZIP 239: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-02-23 21:26:59 +00:00
Daira Hopwood 6bf7703684
ZIP 239: Clarify the behaviour of zcashd and the intended behaviour for unrecognized inventory types (#545)
* 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>
2022-02-23 16:21:28 -05:00
Daira Hopwood 28a3404ce0 Fix typo in README.template (which generates README.rst and index.html).
Co-authored-by: mg0716 <matt.galligan@gmail.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-02-16 21:07:06 +00:00
mg0716 0275b41fb0 Fix typo in README.rst 2022-02-16 15:19:23 -05:00
dependabot[bot] 73dc201033 Bump EndBug/add-and-commit from 7.5.0 to 8.0.2
Bumps [EndBug/add-and-commit](https://github.com/EndBug/add-and-commit) from 7.5.0 to 8.0.2.
- [Release notes](https://github.com/EndBug/add-and-commit/releases)
- [Changelog](https://github.com/EndBug/add-and-commit/blob/main/CHANGELOG.md)
- [Commits](https://github.com/EndBug/add-and-commit/compare/v7.5.0...v8.0.2)

---
updated-dependencies:
- dependency-name: EndBug/add-and-commit
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-02-10 19:51:17 -05:00
github-actions ba9137def1 Commit from GitHub Actions (Render pdfs) 2022-02-09 21:46:28 +00:00
Deirdre Connolly f56cf0d38e
Add GitHub Actions workflow that renders and commits spec pdfs (#579)
* 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
2022-02-09 16:34:55 -05:00
Daira Hopwood 81af218ef3 ZIP 316: further clarify which OVK is to be used when the sending Account is undetermined.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-02-07 14:51:53 +00:00
Daira Hopwood 0bfb157db3 ZIPs 143 and 243: fix links to zcash-test-vectors code.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-29 22:27:56 +00:00
Daira Hopwood dba647f121 ZIP 224: fix a broken link.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-29 21:02:24 +00:00
Daira Hopwood 8e2215c577 ZIP 32: Fix an error in #588; "ZcashIP32_Sprout" was a personalization for BLAKE2b-512, not BLAKE2b-256.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-28 18:33:31 +00:00
Daira Hopwood 2a4ab049b9
Merge pull request #588 from daira/zip-32-remove-sprout-hd
ZIP 32: Remove Sprout-related specifications
2022-01-28 18:24:51 +00:00
Daira Hopwood 7bd2845dbd ZIP 32: Remove Sprout-related specifications. fixes #581
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-28 17:44:15 +00:00
Deirdre Connolly de6dcad4df
Merge pull request #587 from str4d/zip-244-coinbase-fix
ZIP 244: Fix ill-defined commitments for shielded coinbase
2022-01-26 16:20:01 -05:00
Jack Grigg 4075c18cc4 ZIP 244: Fix ill-defined commitments for shielded coinbase
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.
2022-01-24 22:46:41 +00:00
Daira Hopwood 43c8cae266
Merge pull request #576 from daira/internal-key-derivation
ZIPs 32 and 316: add internal key derivation for Sapling, Orchard, and P2PKH
2022-01-19 19:12:14 +00:00
Daira Hopwood 8734965d0c ZIPs 32 and 316: Regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:11:28 +00:00
Daira Hopwood df0f9e6bee ZIP 32: Wording improvements to avoid implying that we want an internal address/FVK for every
external address/FVK.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:09:56 +00:00
Daira Hopwood 8b8b3f7c5d ZIP 316: UAs can be used in Payment Requests without any change to ZIP 321.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:52 +00:00
Daira Hopwood c562b100f8 ZIP 316: add "Usage of Outgoing Viewing Keys" section.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:52 +00:00
Daira Hopwood ca302f40ef ZIPs 32 and 316: update and correct protocol spec references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:52 +00:00
Daira Hopwood 2b5c860df5 ZIP 32: Add Sean Bowe, Kris Nuttycom and Ying Tong Lai to Credits.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:52 +00:00
Daira Hopwood 61223ae9b0 ZIP 32: Simplify Orchard internal key derivation diagram.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:51 +00:00
Daira Hopwood d27d2fd836 ZIP 316: Clarify that UAs/UVKs MUST contain at least one shielded item. This is stronger than
the former requirement that a UA/UVK MUST NOT contain only P2SH or P2PKH items, due to the
existence of Typecodes that are not currently defined.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:51 +00:00
Daira Hopwood 4683507160 ZIP 316: add Deriving Internal Keys section, and minor cleanups.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:51 +00:00
Daira Hopwood 7b70d343b7 ZIP 316: link to the section of the protocol spec describing QR encoding.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:51 +00:00
Daira Hopwood 79e6a10f0a ZIP 32: add internal key derivation for Sapling and Orchard.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:51 +00:00
Daira Hopwood 98515d003f ZIP 32: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:51 +00:00
Daira Hopwood d2b0f2d861 ZIP 32: disambiguate ToScalar and DiversifyHash for Sapling vs Orchard.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 19:00:51 +00:00
Daira Hopwood 82c59282fe Regenerate PDFs. 2022-01-19 18:16:51 +00:00
Daira Hopwood 81858fff41 Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 18:09:23 +00:00
Daira Hopwood 6c32c7c7ea Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 18:09:23 +00:00
Daira Hopwood dcc5532d61 In \crossref{sighash}, add a consensus rule that SIGHASH type encodings MUST be canonical
for v5 transactions.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 18:09:23 +00:00
Daira Hopwood 24cfab0b55 Add reference to [BCGGMTV2014] when discussing an example of an incorrect security claim.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 18:09:23 +00:00
Daira Hopwood 4ef578706b In \crossref{internalh}, add a security argument for why the SHA-256-based commitment scheme
NoteCommit^Sprout is binding and hiding, under reasonable assumptions about SHA256Compress.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 18:09:23 +00:00
Daira Hopwood 0cdab5071b In \crossref{joinsplit}, clarify that balance for JoinSplit transfers is enforced by the
JoinSplit statement, and that there is no consensus rule to check it directly.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-19 18:09:23 +00:00
Daira Hopwood ac9dd97f77
Merge pull request #577 from str4d/574-changes-to-zip-244-transparent
[ZIP 244] Changes to transparent component of signature digest
2022-01-13 14:32:13 +00:00
Daira Hopwood 2ae8fc6cec Minor wording nits.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-13 14:29:30 +00:00
Jack Grigg 1b30e57bde ZIP 244: Commit to scriptPubKey in txin_sig_digest instead of scriptCode
This is a no-op for every scriptPubKey format except P2SH, where we now
commit to the digest of the redeemScript instead instead of redeemScript
directly.
2022-01-12 22:08:22 +00:00
Jack Grigg 509b7a2b0c ZIP 244: Rename script_codes_sig_digest to scriptpubkeys_sig_digest 2022-01-12 16:00:23 +00:00
Jack Grigg 8e74c62a21 ZIP 244: Fix numbering of BIP 341 references
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
2022-01-12 15:58:51 +00:00
Jack Grigg 9e12b49e03 Merge branch 'main' into 574-changes-to-zip-244-transparent 2022-01-12 15:58:36 +00:00
Daira Hopwood aef6aad4fc [Dark mode] Remove unimportant "!important" annotation in section anchor style.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-11 13:24:24 +00:00
Daira Hopwood 0ada3050af [Dark mode] Fix the background colour of the section anchor image.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-11 13:19:12 +00:00
Daira Hopwood 3ba7b5f246 ZIP 243: clarify in "Backward compatibility" that the reason why the ZIP 243 sighash algorithm
is used for all transactions from Sapling activation, is that v3 transactions are no longer valid.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-11 13:09:11 +00:00
Kris Nuttycombe 30ff9f6ddb Regenerate HTML 2022-01-07 16:46:10 -07:00
Deirdre Connolly a3a86b4a44
Update zip-0244.rst
Co-authored-by: str4d <thestr4d@gmail.com>
2022-01-06 13:54:49 -05:00
Daira Hopwood bdfe15bb3f Apply suggestions from code review
Co-authored-by: Kris Nuttycombe <kris.nuttycombe@gmail.com>
2022-01-05 17:37:33 +00:00
Jack Grigg 2671741042 ZIP 244: Regenerate HTML 2022-01-04 00:54:16 +00:00
Jack Grigg 68b6147c02 ZIP 244: Reverse order of value and script_code in txin_sig_digest
This matches the order in which they are committed to in BIP 341 (and
also at the transaction level in S.2).
2022-01-04 00:52:07 +00:00
Jack Grigg 89f46c2d99 ZIP 244: Add hash_type to the S.2 digest input
This was committed to by the ZIP 143 and ZIP 243 transaction digest
algorithms, but had been accidentally omitted from ZIP 244. It is not a
security issue because the encoding of each layer uses sentinel values,
meaning we were indirectly committing to hash_type (unlike BIP 341, which
conditionally omits commitments based on hash_type and therefore needs to
directly commit to it). But not committing directly to hash_type would
complicate security analysis of the digest, and including it keeps the
transparent part of ZIP 244 closer to BIP 341.

We additionally import two new consensus rules from BIP 341 that apply
to hash_type.

Co-authored-by: Daira Hopwood <daira@jacaranda.org>
Co-authored-by: Kris Nuttycom <nuttycom@electriccoin.co>
2022-01-04 00:45:47 +00:00
Jack Grigg c2585a4fc9 ZIP 244: Extend S.2 to be used for shielded signatures
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2022-01-03 23:49:04 +00:00
Jack Grigg daac926497 ZIP 244: Add new S.2 commitments to input amounts and scriptCodes
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2022-01-03 23:47:13 +00:00
Jack Grigg 2442192519 ZIP 244: Change semantics of `sequence_sig_digest`
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2022-01-03 22:39:38 +00:00
Daira Hopwood 8572075604 Regenerate PDFs. 2022-01-03 22:20:04 +00:00
Daira Hopwood 02adb44328 Set Change History entry date, and update version year to 2022.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-03 22:15:14 +00:00
Daira Hopwood b57f6d1487 Correct the note about domain separators for PRF^expand in \crossref{abstractprfs},
and ensure that new domain separators for deriving internal keys from ZIPs 32 and 316 are included.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-03 22:15:14 +00:00
Daira Hopwood cf1995c2ed Fix stale links, and correct the accenting of [MÁEÁ2010].
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-03 22:15:14 +00:00
Daira Hopwood 59a220d59e Change the types of cm_x, Uncommitted^Orchard, and ak in Orchard to { 0 .. q_P-1 },
avoiding type errors and reflecting the implementation in zcashd. This eliminates all uses of P_x
(except that ak in an Orchard full viewing key is still required to be a valid Pallas affine
x-coordinate). Also clarify the coordinate system whenever we refer to coordinates.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-03 22:15:14 +00:00
Daira Hopwood b6e00e0d41 Refine the security argument in the note about partitioning oracle attacks.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2022-01-03 22:15:14 +00:00
Daira Hopwood 1571c1b345 ZIP 316: update Feistel diagrams to include border (needed for dark mode), and add source SVG files.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-31 16:24:58 +00:00
Daira Hopwood 75ae51c6b2 CSS: support dark mode.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-31 13:58:40 +00:00
Daira Hopwood ae78770474 CSS: fix heading bottom padding.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-30 10:14:23 +00:00
Daira Hopwood cfba8e4c59 CSS: tweak heading sizes and spacing.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-30 10:05:49 +00:00
Daira Hopwood abb898f484 ZIP 244: fix heading levels for Orchard digests.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-30 10:05:16 +00:00
Daira Hopwood dfd7a5a561 ZIP 244: add Jack Grigg to authors.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-30 10:03:12 +00:00
Daira Hopwood ee70cc53c3 ZIP 316: update Acknowledgements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-28 15:30:44 +00:00
Daira Hopwood 1d75ed6548 ZIP 316: more changes to include UVKs and Metadata Items where applicable.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-28 15:30:15 +00:00
Daira Hopwood 200e243e14
Merge pull request #575 from daira/zip-316-key-structure-and-change
[ZIP 316] Change to item ordering; clarifications of metadata/experimental usage; and correction to rationale
2021-12-28 13:43:23 +00:00
Daira Hopwood fbad8acac0 ZIP 316: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-28 13:40:13 +00:00
Daira Hopwood 2d5159361e ZIP 316: add rationale for unlinkable address derivation, with a caveat about Metadata Items.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-28 13:39:01 +00:00
Daira Hopwood b7e69cc10a ZIP 316: add rationale for requiring ordering by Typecode.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-28 13:39:01 +00:00
Daira Hopwood e8df7fbb65 ZIP 316: unrecognized metadata items should be dropped when deriving UFVK -> UIVK and UIVK -> UA.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-28 13:14:17 +00:00
Daira Hopwood 06b945bfe7 ZIP 316: change ordering of items.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-22 19:08:13 +00:00
Daira Hopwood 22840e1fc5 ZIP 316: clarify usage of Metadata Items and experiments.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-22 19:07:46 +00:00
Daira Hopwood 1a59063e81 ZIP 316: correct the rationale for the minimum size of the Bech32m-decoded byte sequence.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-22 19:07:19 +00:00
Daira Hopwood 227db1e047
Merge pull request #564 from daira/zip-ivk-changes
ZIPs 32 and 316: Refine how IVK components are derived, and other cleanups
2021-12-08 23:49:47 +00:00
Daira Hopwood 12a1678681 ZIPs 32 and 316: Regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 23:47:06 +00:00
Daira Hopwood 4a23875519 ZIP 316: Clarify derivation of P2PKH IVK from FVK.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 23:46:09 +00:00
Deirdre Connolly 96c5ad3f69 ZIP 316: Clarify position of Transparent IVKs in the key tree.
Co-authored-by: Kris Nuttycombe <kris.nuttycombe@gmail.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 23:34:12 +00:00
Deirdre Connolly 110fe1a84e ZIP 316: Update wording for Transparent P2PKH Receiver derivation.
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 23:32:02 +00:00
Deirdre Connolly 682308e33b ZIP 32: There will not be a zcashd 4.5.2, there will be 4.6.0. 2021-12-08 21:24:55 +00:00
Daira Hopwood 0db40ef927 ZIP 32: Note that legacy Sapling addresses use hardened derivation for `address_index`. 2021-12-08 21:24:51 +00:00
Daira Hopwood d325f0b3b4 ZIP 316: Fix link.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:29:03 +00:00
Daira Hopwood 0e83a55a05 ZIP 316: Clarify requirements for HD-derived items and remove redundancy.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:27:08 +00:00
Daira Hopwood 208d9b39c1 ZIP 316: Update Sapling and transparent viewing key encodings.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:27:08 +00:00
Jack Grigg 026977744c ZIP 316: Fix bug in transparent constraint on diversifier index
The largest valid integer for any BIP 32 path element with a defined
hardening state (in this case, non-hardened) is 2^32 - 1 (being the
31-bit integer with all bits set to 1). The range of valid diversifier
indices for transparent-including UAs is defined as end-inclusive in
the ZIP, but used the end-exclusive bound 2^32.
2021-12-08 00:27:08 +00:00
Jack Grigg 78b7d8489f ZIP 32: Revert all refinements
The hardened change path approach is being dropped. ZIP 316 will include
separate amendments (to be made later) that derive change addresses
within each protocol's key tree, instead of at the spend authorization
level.
2021-12-08 00:27:08 +00:00
Daira Hopwood dfdb4242f5 ZIP 32: Change the address index used to derive "legacy" Sapling addresses to 0x7FFFFFFF.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:27:08 +00:00
Daira Hopwood 9a4df93e97 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:27:08 +00:00
Daira Hopwood 5c402793c3 Corrections for Orchard Viewing Keys.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:27:08 +00:00
Daira Hopwood 880bf02301 Don't use UFVK or UIVK when referring to Viewing Key components.
(A UFVK or UIVK is properly only the whole thing.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:27:08 +00:00
Daira Hopwood b85a249a59 ZIP 316: clarify how P2PKH addresses are derived.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:27:08 +00:00
Daira Hopwood 4d0477ce5f ZIPs 32 and 316: refine how UIVK components are derived for Orchard and Transparent P2PKH.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:27:08 +00:00
Daira Hopwood 4d536ff421 ZIP 32: Add a note saying how zcashd uses a non-hardened `address_index` path level for Sapling.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:27:08 +00:00
Daira Hopwood 9dbe0a50f7 ZIP 32: minor wording changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-08 00:27:08 +00:00
Daira Hopwood ea53ac9d6f links_and_dests.py: fix false positive "Missing link target" errors for links into rendered BIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-03 14:54:22 +00:00
Daira Hopwood c3dac4e458 Regenerate PDFs. 2021-12-01 18:16:14 +00:00
Daira Hopwood 82c4e49155 Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-01 18:09:12 +00:00
Daira Hopwood d6a33fc056 Add note about resistance of note encryption to partitioning oracle attacks \cite{LGR2021}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-01 18:09:12 +00:00
Daira Hopwood 67a4b35dcd Add acknowledgement to Sasha Meyer.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-01 18:09:12 +00:00
Daira Hopwood eab1ef1a1a Add acknowledgement to Mihir Bellare for contributions to the science of zero-knowledge proofs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-01 18:09:12 +00:00
Daira Hopwood 36252cebf6 Add "note commitment scheme" as a term.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-01 18:09:12 +00:00
Daira Hopwood 089a9cb8be Make consistent use of "spending authority", and add this term to the index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-01 18:09:12 +00:00
Daira Hopwood 4da403f470 Add notes in each Appendix B that z_j may be sampled from {0 .. 2^{128}-1} instead of {1 .. 2^{128}-1}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-01 18:09:12 +00:00
Daira Hopwood e539eeb9a8 ZIP 416: Change title to be more general than RPC support.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-12-01 18:07:44 +00:00
Daira Hopwood 49df75d888 ZIP 221: fix broken links.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-10-02 01:06:21 +01:00
Daira Hopwood 2398e1e012 ZIP 252: fix a reference to ZIP 155.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-10-02 00:53:26 +01:00
Daira Hopwood 474330a8f4 ZIP 155: change peer protocol version for activation of this ZIP to 170017.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-10-02 00:50:02 +01:00
Daira Hopwood d1909fb05a ZIPs 239 and 252: updates for revised testnet activation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-10-02 00:46:18 +01:00
Daira Hopwood 52abb0c609 ZIP 225: add links to zcashd and librustzcash PRs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-10-02 00:46:17 +01:00
Daira Hopwood 5ced374bf1 Update references to protocol spec from process and consensus ZIPs (0 to 252 inclusive, and 1014).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-10-02 00:46:17 +01:00
Daira Hopwood 1ac6d917b8 Regenerate PDFs. 2021-09-30 17:03:08 +01:00
Daira Hopwood feb864b672 protocol/Makefile: fix `release` target to use `main` branch rather than `master`.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-30 16:56:40 +01:00
Daira Hopwood b1a707e963 Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-30 16:56:40 +01:00
Daira Hopwood bab61e8ecf Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-30 16:56:40 +01:00
Daira Hopwood 97fa264611 * Witness g_d^new and pk_d^new in Orchard as non-identity Pallas points, rather than witnessing
their representations as bit sequences.
* Note that ak^P in Orchard cannot be the identity.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-30 16:56:40 +01:00
Daira Hopwood 7bf094e827 * Use complete addition in SinsemillaCommit.
* Correct the proof of Theorem 5.4.6.
* Change the type of cm_old in Orchard to P rather than P*, i.e. allow the identity point.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-30 16:56:40 +01:00
Daira Hopwood 06706937d5 Change the type of rt^Orchard from P_x to {0..q_P-1}. This reflects the zcashd implementation;
also checking rt^Orchard \in P_x would require a square root and is unnecessary.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-30 16:56:40 +01:00
Daira Hopwood b8f83aac4b Correct the consensus rule about the maximum value of outputs in a coinbase transaction:
it should reference the block subsidy rather than the miner subsidy.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-30 16:56:40 +01:00
Daira Hopwood 5688e5cbbd Fix some cross-references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-30 16:56:40 +01:00
Daira Hopwood d4cddc0615 ZIP 316: correct wording that assumed zero padding (i.e. had not been updated for inclusion of HRP).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-21 11:16:13 +01:00
Daira Hopwood a31336c9c6
Merge pull request #551 from daira/zip-316-large-ua
ZIP 316: support larger Unified Addresses and Unified Viewing Keys
2021-09-18 21:49:41 +01:00
Daira Hopwood f8529b3186 ZIP 316: Regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 15:35:50 +01:00
Daira Hopwood 96277a1a14 ZIP 316: Expand "Message Authentication Code", and a wording improvement.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 15:30:56 +01:00
Daira Hopwood 39998c226c ZIP 316: Clarify wording for UFVK or UIVK Encoding, and the reason why P2SH UFVK/UIVKs are not supported.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 14:41:27 +01:00
Daira Hopwood 0e057c3c8c ZIP 316: Clarify that the experimental Typecodes are for use before proposing a ZIP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 14:33:50 +01:00
Daira Hopwood 17229163f9 ZIP 316: Define a named constant \ell^MAX_M to replace the magic number 4194368.
Also define \ell_H = 64.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 14:26:58 +01:00
Daira Hopwood 067befbb08 ZIP 316: The P2PKH extended public key format can be used in place of a P2PKH-only UFVK/UIVK.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 14:21:18 +01:00
Daira Hopwood a00006d7bd ZIP 316: Clarify conformance levels.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 14:03:43 +01:00
Daira Hopwood ed4ba8d38b ZIP 316: Update references to the protocol spec and add reference to spec notation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 13:59:53 +01:00
Daira Hopwood 2d20028ecf ZIP 316: Remove an incorrect parenthetical about the memory usage of streamed unjumbling.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 13:59:53 +01:00
Daira Hopwood 460c5b2ccc ZIP 316: Require that `typecode` and `length` are <= 0x2000000.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 13:59:53 +01:00
Daira Hopwood d6a32d4757 ZIP 316: Resolve a TODO by punting to ZIP 315.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 13:59:53 +01:00
Daira Hopwood 986b9dedfe ZIP 316: Improve definitions, requirements, and specification for viewing keys.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 13:59:53 +01:00
Daira Hopwood 0c14637429 ZIP 316: Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 13:55:19 +01:00
Daira Hopwood cf0219cd67 ZIP 316: Clarify a security requirement for streamed calculation of F4Jumble^-1.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 13:51:16 +01:00
Daira Hopwood 6611f7a245 ZIP 316: Updates for longer UAs/UVKs and experimental types.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 13:51:04 +01:00
Daira Hopwood 043672cc07 ZIP 401: revert change to use wtxid.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-17 13:10:02 +01:00
Daira Hopwood e309225495 ZIP 316: Update terminology to better account for viewing keys.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-15 21:07:11 +01:00
Daira Hopwood 49faaafe4d README: update planned NU5 activation date and add ZIP 401 (clarified) to the set of relevant ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-13 20:26:54 +01:00
Marek 9c47cbe6ec Fix typo. closes #557
Co-authored-by: Marek <mail@marek.onl>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-13 15:09:53 +01:00
Daira Hopwood 763a9cdd4f
Merge pull request #556 from daira/fix-dockerfile
Update Dockerfile to use an updated package that should work in more recent Debian
2021-09-10 08:45:06 +01:00
Daira Hopwood f4cb2806a7 ZIP 202: fix link.
This should also republish GitHub Pages after renaming the `master` branch to `main`.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-09 15:29:09 +01:00
Daira Hopwood 2630966bc4
Merge pull request #558 from daira/better-link-checking
Better link checking
2021-09-09 15:06:01 +01:00
Daira Hopwood db418a5dd5 Fix all links in ZIPs (and almost eliminate plain http links).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-09 15:02:46 +01:00
Daira Hopwood 195b8147eb Update links_and_dests.py to support HTML files and rate limiting (part 2).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-09 14:58:42 +01:00
Daira Hopwood 4af8a9684d Update links_and_dests.py to support HTML files and rate limiting (part 1).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-09 14:57:51 +01:00
Daira Hopwood e4c68a0e7a Update Dockerfile to use an updated package that should work in more recent Debian.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-07 15:16:17 +01:00
Daira Hopwood d12f31bbb9
Merge pull request #547 from tromer/patch-1
ZIP 307: clarify that epk is needed
2021-09-07 14:47:19 +01:00
Daira Hopwood 14326d0f9a ZIP 307: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-07 14:46:47 +01:00
Daira Hopwood dcb4c4e89a Regenerate PDFs. 2021-09-01 13:43:18 +01:00
Daira Hopwood c871d448ce Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-01 13:26:34 +01:00
Daira Hopwood 21f384dcda Fix URL links to \cite{BBDP2001} and \cite{BDJR2000}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-01 13:26:34 +01:00
Daira Hopwood a5c4f139c9 protocol/links_and_dests.py: Some DOI links (i.e. to https://doi.org/) redirect to link.springer.com
in a way that requires cookies (booo!). We allow this for DOI links, but for all other links we
simulate a client that never sets cookies.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-01 13:19:33 +01:00
Daira Hopwood a918bbc6d7 protocol/Makefile: add `discard` target, and make the `linkcheck` target depend on `all-specs`.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-01 13:17:06 +01:00
Daira Hopwood 0d2b01e602 Cosmetics (captialization of ZKProof).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-01 11:44:16 +01:00
Daira Hopwood b7f0a0bd0d Correct a minor error in the proof of \theoremref{thmsinsemillacr}:
the condition SinsemillaHashToPoint(D, M) ≠ ⊥ is required in the proof.
(The case SinsemillaHashToPoint(D, M) = ⊥ is covered by \theoremref{thmsinsemillaex}.)
The proof had not been updated correctly when the statement was revised in v2021.2.0.
Also add a missing D argument to SinsemillaHashToPoint in that proof.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-01 11:44:16 +01:00
Daira Hopwood 324c9ae7b9 Add \zcashdref for referencing zcashd versions (also \zebraref which is currently unused).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-01 11:44:16 +01:00
Daira Hopwood 7e5272e70b Add \historyref for referencing Change History versions.
Also fix an incorrect reference to v2019.0-beta-40 that should be v2019.0.0.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-01 11:44:16 +01:00
Eran Tromer 42e05529a4
ZIP 307: clarify that epk is needed
The current phrasing implies the 580-byte memo ciphertext suffices for detection. Clarify that the 32-byte ephemeral public key is also needed.

Also added "public" to "ephemeral key" further down.
2021-08-25 19:29:49 -04:00
Daira Hopwood 93e5ec04fe
Merge pull request #543 from daira/zip-155
Add ZIP 155 (addrv2 message), and update ZIP 252 to reference it
2021-08-23 16:01:40 +01:00
Daira Hopwood 7dc6682326 Only say that valid, potentially routable addresses SHOULD be gossiped.
(It is up to the node implementation what addresses on each network are considered valid
and potentially routable.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-23 15:58:52 +01:00
Daira Hopwood e179eb88c7 ZIP 401: update for wtxid.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-23 15:49:09 +01:00
Daira Hopwood fc6e752b05 ZIP 155: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-17 15:50:43 +01:00
Daira Hopwood a9fa1f4d18
Apply suggestions from code review 2021-08-17 15:49:56 +01:00
Daira Hopwood 955a81e9bd
Apply changes from ZIP sync review
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
2021-08-17 15:47:42 +01:00
Daira Hopwood 40bf218f1b
Merge pull request #544 from zancas/patch-3
Typo Fix:  Update zip-0201.rst
2021-08-16 21:41:50 +01:00
Daira Hopwood acf3d949eb ZIP 201: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-16 21:41:05 +01:00
Za Wilcox df6aff4313
Update zip-0201.rst 2021-08-16 13:44:00 -06:00
Daira Hopwood 11b8688a1d Correct references to the title of ZIP 200.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-15 23:47:48 +01:00
Daira Hopwood 784c889d00 Change planned activation date of NU5 on mainnet to mid-to-late November 2021.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-15 23:45:29 +01:00
Daira Hopwood 57e0f6035d ZIP 155: clarify handling of `addr` messages.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-13 19:43:31 +01:00
Daira Hopwood 9d61bec954 ZIP 155: add Pull-Request field.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-13 17:43:48 +01:00
Daira Hopwood e77ba6bbf0 Add ZIP 155 (addrv2 message), and update ZIP 252 to reference it.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-13 17:41:49 +01:00
Daira Hopwood 473306e4d0 ZIP 252: Support for NU5 on testnet will be implemented in zcashd version 4.5.0, not 4.4.0.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-13 13:49:03 +01:00
Daira Hopwood b5e5276c4a Regenerate PDFs. 2021-08-12 21:48:43 +01:00
Daira Hopwood 3ebba2652a Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-12 21:44:17 +01:00
Daira Hopwood 8f8ef49618 Add Change History entry for fixing [ZIP-239] in the References.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-12 21:43:39 +01:00
Marek 01dbecefea Fix a typo in bibliography. 2021-08-12 21:40:29 +01:00
Daira Hopwood 219a4ef253 Clarify wording in the Change History entry for v2021.2.13.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-12 21:38:20 +01:00
Daira Hopwood 8718157af0 Reword the reference to a Sapling full viewing key in \crossref{saplingdummynotes}
(the full viewing key would include ovk, although it is not used in that section).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-12 21:37:35 +01:00
Daira Hopwood b2e0184fe5 ZIP 211: wording improvement suggested by Canopy audit.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-04 15:35:46 +01:00
Daira Hopwood cdb30d10ca ZIP 215: add a citation for reference to https://zips.z.cash/protocol/protocol.pdf#concreteed25519
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-08-04 15:22:46 +01:00
str4d 88bc08b6e3
Merge pull request #538 from daira/zip-316-update
ZIP 316: Define HRPs for Unified Viewing Keys, and include the HRP in the padding
2021-07-30 14:53:05 +01:00
Daira Hopwood 0ae051226e Regenerate PDFs. 2021-07-29 17:35:14 +01:00
Daira Hopwood 045a3a9e54 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-29 17:30:21 +01:00
Daira Hopwood a6fd0153d2 Add a consensus rule in \crossref{merkletree} that a block MUST NOT add note commitments that
exceed the capacity of each of the Sprout, Sapling, and Orchard note commitment trees.

Also add a cross-reference for constants used in \crossref{merkletree}.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-29 17:30:21 +01:00
Daira Hopwood 8b8761b302 Regenerate PDFs. 2021-07-29 15:48:31 +01:00
Daira Hopwood 1aefc848bf Change the number of partial rounds, R_P, for Poseidon from 58 to 56.
This matches the number calculated by `calc_round_numbers.py` (for 128-bit security "with margin")
in Version 1.1 of the Poseidon reference implementation.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-29 15:43:24 +01:00
Daira Hopwood cecfb9b0e4 Regenerate PDFs. 2021-07-20 06:05:58 +01:00
Daira Hopwood 411f39e231 Change the definition of inputs to the action circuit to split enableSpends and enableOutputs
into two field elements.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-20 06:00:31 +01:00
Daira Hopwood 5e0769d295 Include the Human-Readable Part in the padding used to check for malleation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-13 23:51:02 +01:00
Daira Hopwood 5d98ec714a Add Human-Readable Parts for UVKs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-13 23:50:01 +01:00
Daira Hopwood 8c510a1415 Regenerate PDFs. 2021-07-13 15:55:15 +01:00
Daira Hopwood 36e2059de0 Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-13 15:50:46 +01:00
Daira Hopwood ffd97926a8 Clarify in \crossref{transactions} that the remaining value in a transparent transaction value pool
is only available to miners as a fee in the case of non-coinbase transactions, and that the remaining
value in the transparent transaction value pool of a coinbase transaction is destroyed.

Co-authored-by: Teor <teor@riseup.net>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-13 15:50:46 +01:00
teor e628134536 Make heightBytes encoding match NU5 coinbase nExpiryHeight
Since nExpiryHeight is limited to `2^32 - 1`, heightBytes is limited to 5 bytes.

Co-authored-by: Teor <teor@riseup.net>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-13 15:50:46 +01:00
Daira Hopwood 819761ef67 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-13 15:50:46 +01:00
Daira Hopwood 8c7b2f2a95 Add cross-references for CanopyActivationHeight, ZIP212GracePeriod, and BlockHeight.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-13 15:50:46 +01:00
Daira Hopwood 0ad0d3d57a Clarify that decomposition of scalars for scalar multiplication in the action circuit MUST be canonical,
unless a non-canonical decomposition can be proven to result in an equivalent statement -- and clarify
for which multiplications the latter case applies.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-13 15:50:46 +01:00
Daira Hopwood f97ef3ae72 Remove a spurious reference to rseed in \crossref{sproutinband}. There were no changes for Sprout in ZIP 212.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-13 15:50:46 +01:00
Daira Hopwood 65ff47a022
Merge pull request #536 from daira/zip-316-clarification
ZIP 316: clarify requirements, especially for Unified Viewing Keys
2021-07-13 14:49:20 +01:00
Daira Hopwood fed2bc0438 ZIP 316: more instances of Sender that should be Consumer.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-12 16:04:10 +01:00
Daira Hopwood af1bee056f ZIP 316: clarify requirements, especially for Unified Viewing Keys.
This required introducing the Consumer definition, since a Consumer
of a UVK is not necessarily a Sender.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-12 13:18:31 +01:00
Daira Hopwood 9d6fa7d8ec ZIP 316: add links to implementation PRs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-12 12:20:09 +01:00
Daira Hopwood f0858810a2 Regenerate PDFs. 2021-07-01 20:01:41 +01:00
Daira Hopwood fb83397ad7 Set the Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood 2814e00a1a Cosmetics and cross-referencing improvements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood 4821afe9ba Add a clarification in \crossref{txnconsensus} that after Heartwood and before Canopy activation,
Sapling outputs of a coinbase transaction MUST have note plaintext lead byte equal to 0x01.
This was implied by the existing rule that such outputs MUST decrypt successfully with an
all-zero outgoing viewing key.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood 172573e686 Correct an erroneous statement in \crossref{transactions} that claimed transaction IDs are not part
of the consensus protocol.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood 55052e4e54 Add a consensus rule for version 5 or later transactions, that if `nActionsOrchard` > 0 then
at least one of `enableSpendsOrchard` and `enableOutputsOrchard` MUST be 1.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood 3f9ede243b Replace "must" with "MUST" in two consensus rules specified in \crossref{txnencoding}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood 7102635fc6 Correct l to l⋆ in two places in \crossref{saplingmerklecrh}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood 3159602dfc Fix a typo in the Security Requirements for \crossref{orchardmerklecrh}: the length of the input
to SinsemillaHash is 10 + 2·ℓ^Orchard_Merkle bits, not 6 + 2·ℓ^Orchard_Merkle bits.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood 1ed8e47d56 Allow the Merkle path validity check in the Action circuit to pass if any output of
MerkleCRH^Orchard is 0, and add a note in \crossref{merklepath} arguing that this is safe.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood 0b7aeae33e Change the type of MerkleCRH^Orchard to have MerkleHash^Orchard in place of MerkleHash^Orchard ∪ {⊥}
for the inputs and output, and map a ⊥ output from SinsemillaHash to 0.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood c33e23e0c2 Delete the consensus rule in \crossref{transactions} that required checking that each intermediate
Merkle root of the note commitment tree is not ⊥. Checking this rule would have imposed a
significant performance penalty, since intermediate roots do not otherwise need to be computed.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-07-01 19:54:54 +01:00
Daira Hopwood a39618ff66
Merge pull request #529 from nuttycom/zip_0302_fix_indentation
Fix bullet points in the future-reserved section of zip-0302
2021-06-30 23:33:51 +01:00
Kris Nuttycombe bcb9845f00 Fix bullet points in the future-reserved section of zip-0302 2021-06-29 12:25:47 -06:00
Daira Hopwood 076af3f055 Regenerate PDFs. 2021-06-29 18:08:21 +01:00
Daira Hopwood 75e2ae585d Set Change History entry height.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-29 18:03:43 +01:00
Daira Hopwood 7f04e327ad Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-29 18:02:17 +01:00
Daira Hopwood b3aad58459 Add a section \crossref{txnidentifiers} on how to compute transaction IDs and \wtxids.
Split the transaction-related consensus rules into their own subsection \crossref{txnconsensus},
for more precise cross-referencing.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-29 18:02:00 +01:00
Daira Hopwood 4c118b813e Describe transaction IDs and wtxids in \crossref{transactions}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-29 17:59:15 +01:00
Daira Hopwood 9eec2ec378 Change one of the [Sapling onward] consensus rules in \crossref{txnencodingandconsensus} to have
the correct applicability: [Sapling to Canopy inclusive, pre-NU5].

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-29 17:57:03 +01:00
Daira Hopwood 27dc2a5fc4 Regenerate PDFs. 2021-06-28 18:10:48 +01:00
Daira Hopwood 671451008a Add a step to the algorithm for generating an Orchard note in \crossref{orchardsend}, to restart if esk = 0.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-28 18:06:10 +01:00
Daira Hopwood b4928747cc Explicitly say that padding in \crossref{concretesinsemillahash} is by appending zero bits.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-28 18:06:10 +01:00
Daira Hopwood c6247f4bd5 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-28 18:06:10 +01:00
Daira Hopwood ca6d988177 Correct the type of Uncommitted^Orchard, which should be P_x rather than a bit sequence.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-28 18:06:10 +01:00
Daira Hopwood 3d5f16a0a5 ZIPs 212 and 213: updates for Orchard.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-27 14:09:22 +01:00
Daira Hopwood 33c7ac6b3f ZIP 203: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 21:36:35 +01:00
Daira Hopwood 4e138b244e ZIP 203: changes for Blossom and NU5.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 21:36:35 +01:00
Daira Hopwood ab2ec000c2 ZIP 203: keyword arguments to the RPC were not implemented.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 21:36:35 +01:00
Daira Hopwood 38fe5c3b10 ZIP 203: corrections.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 21:36:35 +01:00
Daira Hopwood e433e8ae4e ZIP 203: line wrapping and formatting.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 21:36:35 +01:00
Daira Hopwood aec18d6aa8 Regenerate PDFs. 2021-06-26 21:32:35 +01:00
Daira Hopwood dea48add07 Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 21:27:26 +01:00
Daira Hopwood 00074e8084 Add ZIPs 203, 212, and 213 to the list of ZIPs updated for NU5.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 21:27:26 +01:00
Daira Hopwood 048c1bf24c Update \crossref{notept} for Orchard.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 18:41:37 +01:00
Daira Hopwood 7a8b12d945 * Require that from NU5 activation, the `nExpiryHeight` field of a coinbase transaction is set
to the block height. This is needed to maintain the property that all transactions have unique
  transaction IDs, as explained in a note in \crossref{txnencodingandconsensus}.
* In order to avoid the block height being limited to 499999999, we also remove that bound on
  `nExpiryHeight` for \coinbaseTransactions.
* Remove the recommendation to support 63-bit block heights in \crossref{blockchain} (since it is
  incompatible with the above consensus rule for coinbase `nExpiryHeight`).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 18:41:37 +01:00
Daira Hopwood ad8bd025b1 The Groth16 `zkproof` field in a JoinSplit description should be colour-coded for Sapling.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 18:41:37 +01:00
teor 5503f766fd Explicitly apply `MAX_MONEY` to Orchard.
Co-authored-by: teor <teor@riseup.net>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 18:41:37 +01:00
Daira Hopwood 4ca7409f6f Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 18:41:37 +01:00
Daira Hopwood 5dff090737 Give cross-references to \crossref{notation} where $\optsqrt$ and $\possqrt$ are used.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 18:41:37 +01:00
Daira Hopwood f31b335fe9 Refine the key components diagram in \crossref{addressesandkeys} to show that Orchard incoming
viewing keys include both dk and ivk.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 18:41:37 +01:00
Daira Hopwood 6055cca71e Ensure that the layer number is passed to MerkleCRH in \crossref{merklepath}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-26 18:41:36 +01:00
Daira Hopwood 1fd7c73f68 Add ZIP 212 and 213 to list of updated ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-22 15:52:10 +01:00
Daira Hopwood 7421696ffa ZIP 225: Correct the size of an Orchard Action encoding in vActionsOrchard.
(The same error was corrected in v2021.2.1 of the protocol spec by 3f3195eb5c12c94b9e38ab7dfa5d660e144a97d3.)
fixes #525

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-22 07:27:28 +01:00
Daira Hopwood 1458078183
Merge pull request #523 from daira/zip-221-pseudocode
ZIP 221: update pseudocode for NU5, and fix a typo
2021-06-20 20:53:46 +01:00
Daira Hopwood 9dba127d7c ZIP 221: update pseudocode for NU5, and fix a typo.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-20 20:48:55 +01:00
Daira Hopwood 721dd2483f Regenerate PDFs. 2021-06-19 20:12:11 +01:00
Daira Hopwood ea0f196a92 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-19 20:05:47 +01:00
Daira Hopwood 09f944d90c Change the consensus rule that requires at least one input to, and at least one output from a v5
or later transaction, to take into account the enableSpendsOrchard and enableOutputsOrchard flags.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-19 20:05:47 +01:00
Daira Hopwood 321eed99b4 Correct the type of Extract_P^bot imported in \crossref{concretesinsemillahash}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-19 20:05:47 +01:00
Daira Hopwood 6e6fd1605e Add ZIP 209 to the list of ZIPs updated for NU5.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-19 20:05:47 +01:00
Daira Hopwood a893eca4d9
Merge pull request #521 from daira/zip-209-orchard
ZIP 209: apply this ZIP to the Orchard chain value pool.
2021-06-16 04:04:25 +01:00
Daira Hopwood 4fbf8e5da2
Merge pull request #520 from nuttycom/zip244-clarify_auth_tree
ZIP 244: Clarify contruction of `hashAuthDataRoot`
2021-06-16 04:03:59 +01:00
Daira Hopwood 5a87ccd87d ZIP 209: apply this ZIP to the Orchard chain value pool.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-15 16:43:40 +01:00
Daira Hopwood 604c40a5c0 ZIP 244: add a note that the empty authorization data tree cannot occur.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-15 15:24:09 +01:00
Kris Nuttycombe f0c438de9b Clarify contruction of `hashAuthDataRoot`.
This changes the specification of hashAuthDataRoot to state that leaves
of the Merkle tree used to construct hashAuthDataRoot should have the
null hash value, while empty internal nodes should be hashes of empty
leaves. It also defines an all-FFs placeholder value to be used for
pre-v5 transactions in this tree.

Co-authored-by: Kris Nuttycom <nuttycom@electriccoin.co>
Co-authored-by: Jack Grigg <jack@electriccoin.co>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-15 15:14:44 +01:00
Daira Hopwood 814ad87b40 Regenerate PDFs. 2021-06-08 12:39:25 +01:00
Daira Hopwood cc71722eca Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-08 12:33:29 +01:00
Daira Hopwood ebd54d5ad6 Add an explicit consensus rule in \crossref{txnencodingandconsensus} that the reserved bits of
the flagsOrchard field MUST be zero.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-08 12:33:08 +01:00
Daira Hopwood d25f3c1f47 Correct a cut-and-paste error algorithm for \crossref{orcharddummynotes},
which should refer to the Action statement rather than the Spend statement.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-08 10:00:44 +01:00
Daira Hopwood 7d2480648a Regenerate PDFs. 2021-06-06 03:45:32 +01:00
Daira Hopwood 0a985b9c13 Set date for Change History entry.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-06 03:39:06 +01:00
Daira Hopwood 106e73e461 Make the NU5 specification the default.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-06 03:39:06 +01:00
Daira Hopwood e3667dc30d Add ZIP 239 to the list of ZIPs included in NU5.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-06 03:39:06 +01:00
Daira Hopwood 577bb20832 Use "Bech32[m]" when saying that there is no dedicated string encoding for Orchard payment addresses
and viewing keys.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-06 03:24:47 +01:00
Daira Hopwood 8f3f36fef5 Specify that Orchard spending keys are encoded using Bech32m.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-06 03:02:44 +01:00
Daira Hopwood ccaa100141 Reference [SVPBABW2012]: link to the ePrint summary page rather than the PDF.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:55:05 +01:00
Daira Hopwood 99e5d92843 Clarify that epk encoded in an Action description cannot be the zero point.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:55:05 +01:00
Daira Hopwood c4b65c39cc Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:55:05 +01:00
Daira Hopwood 9bc46070f3 Say that the round constants as well as the MDS matrices are generated according to Version 1.1
of the Poseidon reference implementation.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:55:05 +01:00
Daira Hopwood 5fa8a60b08 Specify (as a note in \crossref{actionstatement}) the encoding of primary inputs to the action circuit.
This uses new helper functions $\Selectx$ and $\Selecty$ defined in \crossref{concreteextractorpallas}.
The specification of Extract_P has also been refactored to use $\Selectx$ (this does not change the Orchard protocol).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:55:05 +01:00
Daira Hopwood 6a0c15df29 Move the section on abstraction to the Abstract Protocol section, and split section 5.2 to avoid renumbering.
fixes #512

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:55:05 +01:00
Daira Hopwood f4a0a1284e Delete a misleading sentence about Ed25519 encodings being specified in \cite{BDLSY2012}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:55:05 +01:00
Daira Hopwood 9e2938b555 Correct an error in the specification of height-in-coinbase for block heights 1..16.
Also clarify requirements on the range of block heights that should be supported.
fixes #517

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:55:05 +01:00
Daira Hopwood 530f00e150 Update title of ZIP 316.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:55:05 +01:00
Daira Hopwood 5a925a44fe ZIP 224: update for unified addresses and viewing keys.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:54:41 +01:00
Daira Hopwood cbf2878cbe ZIP 224: describe rivk.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:53:59 +01:00
Daira Hopwood ce13aeb945 ZIP 316: change title to "Unified Addresses and Unified Viewing Keys".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 16:52:41 +01:00
Daira Hopwood 15457d4198 ZIP 224: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 15:59:56 +01:00
Daira Hopwood 35f42b8a49 ZIP 225: document that all fields are little-endian.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 15:49:13 +01:00
Daira Hopwood c63b6c9c42 ZIP 224: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 15:32:57 +01:00
Daira Hopwood 2f7954abc3 ZIP 239: backward compatibility for MSG_WTX.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 15:10:20 +01:00
Daira Hopwood 5b5dd20516 ZIP 252: add reference to ZIP 32.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-05 15:05:38 +01:00
Daira Hopwood 72d37b803c ZIP 239: resolve open issue.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-04 21:12:48 +01:00
Daira Hopwood e81037731b Rename reserved ZIP 204.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-03 23:17:21 +01:00
Daira Hopwood 43b03a7a98
Merge pull request #516 from daira/zip-239
Add ZIP 239: Relay of Version 5 Transactions
2021-06-03 22:56:35 +01:00
Daira Hopwood 4ff6ec345f
Merge pull request #518 from zcash/zip-216-fix
ZIP 216: Fix description of non-canonical identity encoding
2021-06-02 12:54:32 +01:00
Daira Hopwood 6ec85a6014 ZIP 216: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-02 12:53:44 +01:00
str4d 587e8f7e70
ZIP 216: Fix description of non-canonical identity encoding 2021-06-02 03:36:21 +01:00
Daira Hopwood f15f263023 Add definitions; terminology changes; and rename `MSG_TXV5` to `MSG_WTX`.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-06-01 17:01:02 +01:00
Daira Hopwood 1b5786ea38 Leave it unspecified whether MSG_TXV5 is used for v6 and later transactions.
The previous wording could have been misinterpreted to require not using MSG_TXV5 for these,
and was partly redundant. Also mention in Motivation that the format of serialized
v5 transactions is not consensus-critical.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-30 10:51:16 +01:00
Daira Hopwood 864e1eaa8d ZIP 252: add references to ZIP 239.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-29 18:25:13 +01:00
Daira Hopwood 50e4914b01 ZIP 239: message type -> inv type.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-29 18:01:01 +01:00
Daira Hopwood a756260c05 ZIP 239: mention `getdata` in Motivation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-29 17:58:08 +01:00
Daira Hopwood 16f48e70d2 Add ZIP 239.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-29 17:50:53 +01:00
Daira Hopwood b4386f93b8 Minor updates to ZIP titles. Also add a reference to ZIP 316 from ZIP 252.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-29 17:30:29 +01:00
Daira Hopwood 44ad348ce6 Regenerate PDFs. 2021-05-20 22:27:53 +01:00
Daira Hopwood c3f48359e6 Clarify that v4 transactions continue to use the ZIP 243 SIGHASH algorithm after NU5 activation.
fixes #510

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-20 22:23:19 +01:00
Daira Hopwood 572a0d6e4f Regenerate PDFs. 2021-05-20 22:02:23 +01:00
Daira Hopwood 0ab0bcb7cb Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-20 21:57:49 +01:00
Daira Hopwood eb5a018396 Note that [JT2020] proves a tight reduction from finding a nontrivial discrete log relation to DLP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-20 21:57:03 +01:00
Daira Hopwood b6e50f8252 Clarify the distinction between Orchard incoming viewing keys and KA^Orchard private keys.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-20 21:47:34 +01:00
Daira Hopwood e7ec658413 Cosmetics and indexing.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-20 21:45:59 +01:00
Daira Hopwood c90528fa5c Change the notation \mathcal{I}^D_i for a Sapling Pedersen generator to \mathcal{I}(D, i).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-18 21:11:09 +01:00
Daira Hopwood 9f948307cf Change the type of Orchard Merkle hashes to \mathbb{P}_x, with a corresponding change to the
signature of MerkleCRH^Orchard. Add a note to \crossref{merklepath} clarifying that non-canonical
encodings are allowed as input to MerkleCRH^Orchard.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-18 21:07:10 +01:00
Daira Hopwood 67cea8589a Add a note to \crossref{merklepath} clarifying the encoding of rt^Sapling as a primary input to
the Sapling spend circuit, and that non-canonical encodings are allowed as input to MerkleCRH^Sapling.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-18 20:39:42 +01:00
Daira Hopwood c5589648c1 Cosmetics (vertical spacing for the non-NU5 spec).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-18 15:37:06 +01:00
Daira Hopwood 79d1a477db Add Change History entry for the correction to the size of vActionsOrchard.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-18 15:37:06 +01:00
teor 3f3195eb5c Fix Orchard Action byte size
Since the signature is now separate, the size is 64 bytes smaller.
2021-05-18 15:37:06 +01:00
Kris Nuttycombe 2b520f41f9
Merge pull request #505 from nuttycom/zip_244_empty_hashes
The roots of empty transaction hash subtrees are now uniformly committed to with empty hashes.
2021-05-18 08:16:46 -06:00
Kris Nuttycombe 97aa1be78e Regenerate HTML 2021-05-18 08:16:15 -06:00
Kris Nuttycombe 9ccd44743f
Apply suggestions from code review
Make the specification of the cases in which empty hashes are produced more
explicit, and less dependent upon how these rules are scoped.

Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-05-18 08:16:00 -06:00
Kris Nuttycombe 12fa6ffa8e Remove trailing whitespace. 2021-05-18 08:05:07 -06:00
Kris Nuttycombe 8d21457112 Add a note about the signedness of `value` 2021-05-18 07:53:40 -06:00
Daira Hopwood 8e6b15e9e9 ZIP 316: minor clarification.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-12 19:15:20 +01:00
Daira Hopwood 0cda82ce0f ZIP 316: remove a TODO.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-12 15:34:52 +01:00
Daira Hopwood 6b1db880c8 ZIP 316: fix a typo in the description of the attack against a 3-round Feistel.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-12 15:31:25 +01:00
Daira Hopwood f42dfd4260 ZIP 316: improve resolution and size of Feistel diagrams.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-12 15:26:08 +01:00
Daira Hopwood 935b3ea767 ZIP 316: define the inverse.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-12 10:29:11 +01:00
Daira Hopwood 615a4e0505 ZIP 316: formatting of quoted ASCII strings.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-12 10:28:34 +01:00
Kris Nuttycombe becbec175c Fix rendering of txin_sig_digest 2021-05-11 08:16:33 -06:00
Kris Nuttycombe 0bc4726a79 Regenerate ZIP-244 HTML. 2021-05-10 17:44:08 -06:00
Kris Nuttycombe d023ef8220
Update zip-0244.rst
Co-authored-by: str4d <jack@electriccoin.co>
2021-05-10 17:42:51 -06:00
Kris Nuttycombe 622179e574
Apply suggestions from code review
Co-authored-by: teor <teor@riseup.net>
2021-05-10 14:14:39 -06:00
Daira Hopwood e9430c3752 Regenerate PDFs. 2021-05-07 16:41:22 +01:00
Daira Hopwood 74c83f6d59 Set history entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:35:22 +01:00
Daira Hopwood 205b2f5861 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:35:22 +01:00
Daira Hopwood d0caaa2ee9 Clarify that transparent inputs are prohibited in coinbase transactions only if they have a non-null `prevout` field. closes #498
Co-authored-by: teor <teor@riseup.net>
Co-authored-by: Jack Grigg <jack@electriccoin.co>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:35:13 +01:00
teor 330254c9ca Add ZIP-244 block commitments as a consensus rule. closes #499
It's currently just a note, which makes it look like the Heartwood rule might still apply.

Co-authored-by: teor <teor@riseup.net>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:34:36 +01:00
Daira Hopwood 296b8e6543 Make "Discrete Logarithm Problem" and "Decisional Diffie–Hellman Problem" indexed terms.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 1db1224657 Unlinkability of diversified addresses depends on DDH, not DLP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 4353accc0e Add [Canopy onward] and [NU5 onward] to a couple of notes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood e4af6e42a0 State explicitly that valueBalanceOrchard can only be negative in a coinbase transaction if
it has ZIP 213 shielded outputs.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 639a554a04 Change the statement of Theorem 5.4.3 to exclude ⊥ outputs from SinsemillaHashToPoint.
Previously the proof did not match the statement.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood d7bd67900a Update the list of ZIPs relevant to NU5 in \crossref{networkupgrades}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 00c39b73e0 Delegate to ZIP 316 for the specification of unified payment addresses and unified viewing keys.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 38b740aad2 Caveat how the result of \cite{GG2015} applies to analysis of PRF^nfOrchard in \crossref{concreteprfs}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 4804f6040e Add a paragraph to \crossref{truncation} covering Orchard.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 748e6f8f37 Typo.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 35c8af6e47 DJB's "High-speed cryptography" book seems completely stalled.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 58add67726 * Specify that diversifier indices for Orchard should be chosen uniquely, not randomly.
* Vanity diversifiers are not an issue for Orchard given that it does not have its own
  payment address format, and given the use of "jumbling" (ZIP 316) in unified addresses.
  Remove the corresponding note from \crossref{orchardkeycomponents}.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 2cf14204ae Clarify the definition of pad in \crossref{concretesinsemillahash} by disambiguating M^pieces from M^padded.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood ac16945288 Clarify notation by changing ℓ_rcm to ℓ^Sprout_rcm.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood 3034a2a662 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood adc28d2bb1 Include ρ as an input to the derivation of ψ, esk, and rcm in Orchard.
This was originally intended and as described in Section 3.5 of the Orchard Book.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 16:03:16 +01:00
Daira Hopwood c9470820b7 ZIP 221, 143, and 243: minor wording improvements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-07 15:22:56 +01:00
Kris Nuttycombe f22a6d4151 Clarify hashes over authorizing data. 2021-05-06 16:06:03 -06:00
Kris Nuttycombe eea56aa173 The roots of empty transaction hash subtrees are now uniformly committed to with empty hashes. 2021-05-06 15:49:50 -06:00
Daira Hopwood 419c7e4ff4 Renumber ZIP 218 stub to ZIP 220.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-05 21:44:00 +01:00
Daira Hopwood b30e1b6568 Add stub for ZIP 416: RPC support for Unified Addresses in zcashd.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-05 12:34:24 +01:00
teor 528eb6685d ZIP 221: fix block height description.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-04 17:25:53 +01:00
Daira Hopwood 36643173bf
Merge pull request #501 from daira/zip-0321-no-slashslash
ZIP 321: clarify that only URIs that parse according to the grammar are accepted
2021-05-04 15:16:37 +01:00
Daira Hopwood b7e72d020c ZIP 321: make the "//" invalid example clearer by ensuring it is invalid for only that reason.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-04 15:14:15 +01:00
Daira Hopwood 3246eddc69 ZIP 321: clarify that only URIs that parse according to the grammar are accepted.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-05-03 10:06:33 +01:00
Daira Hopwood 4dfd956819 zip-guide: update dependencies.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 23:34:10 +01:00
Daira Hopwood 4f391743ab Update README to list NU5-relevant ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 23:10:23 +01:00
Daira Hopwood 76c8a4689a Regenerate PDFs. 2021-04-23 22:39:41 +01:00
Daira Hopwood 4f590fb8cd ZIP 225: add nConsensusBranchId field to the v5 transaction format.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 22:34:20 +01:00
Daira Hopwood 21d3c13d4f Update references to the protocol spec for all NU5-related ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 22:33:56 +01:00
Daira Hopwood 71a19e7484 Clarify that only an outgoing cipher key is strictly needed to decrypt an outgoing ciphertext.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 22:31:37 +01:00
Daira Hopwood 27aa7c484a Remove an unused precomputation in \crossref{concretegrouphashpallasandvesta}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 22:31:37 +01:00
Daira Hopwood ecba2451bc Include the diversifier key in an encoded Orchard Incoming Viewing Key.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 22:31:37 +01:00
Daira Hopwood 4dbf2f02d4 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 22:31:37 +01:00
Daira Hopwood 710fee607a Add the nConsensusBranchId field to v5 transactions, matching the consensus branch ID
used for SIGHASH transaction hashes.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 22:31:37 +01:00
Daira Hopwood 10710d92a6 Explicitly say that coinbase transactions MUST NOT have transparent inputs
(this is a consensus rule inherited from Bitcoin which has been present since launch).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 22:31:37 +01:00
Daira Hopwood 9a1334a454
Merge pull request #496 from nuttycom/zip-244/fix_outputs_hash
Correct the description of the outputs_digest hash.
2021-04-23 16:51:16 +01:00
Daira Hopwood 89f5a20d6d ZIP 244: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-23 16:50:22 +01:00
Kris Nuttycombe 827637cc17 Correct the description of the outputs_digest hash. 2021-04-23 08:20:20 -06:00
Daira Hopwood 1e955a803a ZIP 316: fix link syntax in Related Work section.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-22 23:23:27 +01:00
Daira Hopwood 0168ce7ec3 ZIP 316: corrections to minimum lengths.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-22 23:18:34 +01:00
Daira Hopwood 24957b6745 ZIP 316: update protocol spec references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-22 22:43:34 +01:00
Daira Hopwood 6caaca962d
Merge pull request #485 from daira/zip-316
ZIP 316: Unified Addresses
2021-04-22 22:26:06 +01:00
Daira Hopwood cec980b004 Correct minimum length.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-22 22:23:41 +01:00
Daira Hopwood 95f596ea16 Tighten up validation requirements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-22 22:10:41 +01:00
Daira Hopwood fbdbead6d5 Add support for UFVKs and UIVKs.
Append 16 zero bytes on encoding and check them on decoding, to prevent malleability attacks.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-22 22:00:33 +01:00
Daira Hopwood f4a3b99589 WIP 2021-04-21 00:15:05 +01:00
Daira Hopwood 3de014d33c ZIP 316 Work in Progress.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-21 00:13:13 +01:00
Daira Hopwood cb141ac91e ZIP 244: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-21 00:12:46 +01:00
Deirdre Connolly 4c081eaa54 Make a note that the post-memo 'suffix' is the AEAD tag 2021-04-20 18:08:59 -04:00
teor ef5f47ca08
ZIP-244: Clarify sapling shared anchor hashing (#490)
* ZIP-244: Clarify sapling shared anchor hashing

Unlike the orchard shared anchor, the sapling v5 transaction shared anchor
is hashed into *each* spend.

* Uppercase Sapling and Spend

Co-authored-by: Deirdre Connolly <durumcrustulum@gmail.com>
2021-04-20 18:08:12 -04:00
Daira Hopwood 2e6cdb3945 Regenerate PDFs. 2021-04-19 00:36:48 +01:00
teor 0cfeea2ecb Use a different symbol for each v5 Sapling field cardinality rule.
Currently, the spec uses the double dagger symbol for both:
* present if and only if `nSpendsSapling + nOutputsSapling > 0`;
* present if and only if `nSpendsSapling > 0`.

To avoid confusion, use dagger for the first rule, and double dagger for the second rule.

Co-authored-by: teor <teor@riseup.net>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-19 00:32:00 +01:00
Daira Hopwood 1c46e9aa5d Add Change History entries for already committed changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-19 00:18:47 +01:00
Daira Hopwood c4d7331191 Set Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-19 00:12:37 +01:00
Daira Hopwood 65590101a8 When creating Orchard notes, repeat with another rseed if cm is \bot.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-19 00:12:37 +01:00
Daira Hopwood 3d230f8d26 Type corrections for Orchard.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-19 00:12:37 +01:00
Daira Hopwood 15d59f11c4 Add note about non-uniformity of Orchard ivk.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-19 00:12:37 +01:00
Daira Hopwood 119abe37c3 ExtractP(\ZeroP) should be 0, and ExtractP^\bot(\bot) should be \bot.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-19 00:12:37 +01:00
Daira Hopwood 1df0f60deb Add support for link checking to protocol/links_and_dests.py and protocol/Makefile.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-19 00:12:37 +01:00
Daira Hopwood 65ebb2266d Fix some URLs in references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-19 00:12:37 +01:00
teor 572338f01a Add action descriptions to the Note Commitments section intro 2021-04-13 09:45:33 -04:00
Deirdre Connolly 20053e286c
Merge pull request #486 from teor2345/patch-11
Typo: Decription -> Description
2021-04-13 09:42:24 -04:00
teor 151e8c9661
Typo: Decription -> Description 2021-04-12 11:07:03 +10:00
Daira Hopwood fb9c5514bd Add stubs for ZIP numbers 314, 315, 316, 322, and 323.
Remove stub for ZIP 22 which has been renumbered to 323.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-07 10:12:11 +01:00
Daira Hopwood 761485e6c6 Regenerate PDFs. 2021-04-05 23:09:13 +01:00
Daira Hopwood e23cc72ac6 Work around bug in `release` target of protocol/Makefile.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-05 23:03:52 +01:00
Daira Hopwood 88c338b9e1 Specify that a unified payment address MUST contain at least one shielded payment address.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-05 22:12:29 +01:00
Daira Hopwood 18fbfdefe5 Correct ZKSpend.Verify to ZKOutput.Verify in \crossref{outputdesc}. fixes #481
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-05 22:00:53 +01:00
Daira Hopwood cc9c41a598 More clarifications to \theoremref{thmsinsemillacr}.
Co-authored-by: Taylor Hornby <taylor@electriccoin.co>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-05 21:51:59 +01:00
Daira Hopwood 1f041f955a Add links_and_dests.py.
This can be used to print outgoing links and targets in the PDF, and detect a subset of errors.
It depends on the PyPDF2 library (pip3 install PyPDF2).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-05 21:51:05 +01:00
Daira Hopwood 4f50d5e515 Make sure that Change History entries are URL destinations. fixes #462
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-05 21:51:00 +01:00
Daira Hopwood 46fefcaf56 Update all references to https URLs (and the year of the Unicode Standard to 2020).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-05 21:44:19 +01:00
Daira Hopwood e4cc1f7f82 Say that Canopy activated.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-05 20:30:33 +01:00
Daira Hopwood db3b2f72d4 Remove link to the "GNU Kind Communication Guidelines" given Richard Stallman's involvement
(see https://rms-open-letter.github.io/appendix), and that document's stance on pronouns.

In particular, although the document has changed since the open letter's reference to it, its
current version says that gender-neutral pronouns "don't conflict with any possible gender
identity". That is incorrect, and not compatible with our CoC. Always use a person's stated
pronouns if they are known; use gender-neutral pronouns only when the correct ones are unknown
or when not referring to a specific person.

Besides the pronoun issue and the association with RMS, a universal exhortation to "assume good
faith" is verging on tone-policing when applied to marginalized communities. In any case,
ZIP 0 is not about that topic and the link is out-of-place.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-04 15:20:45 +01:00
Daira Hopwood 404248cb92 Regenerate PDFs. 2021-04-01 02:19:32 +01:00
Daira Hopwood a0d048ed1e Update Change History entry date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 417076e50d Make a note in \crossref{inbandrationale} of the divergence of ivk from a uniform scalar.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 1eec1f9832 Remove anchorSapling field when there are no Spends.
This corresponds to e0b08fd576 in ZIP 225.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 49f3b206f5 Fix type error in kdfinput for KDF^{Sapling,Orchard} (`ephemeralKey` is already a byte sequence).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 41580ec06d Cosmetics in Sapling Output statement.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood c367a22098 Explicitly note that the end of the ZIP 212 grace period precedes NU5 activation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 3a312dc5a9 Expand the set of ZIPs associated with NU5 in \crossref{networkupgrades}, and reference the Orchard and halo2 books there.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 6c3099843d Add a caveat about reuse of rivk between PRF^expand and Commit^ivk.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 3826d43930 Correct the set of inputs to PRF^expand used for ZIP 32 and Orchard in \crossref{abstractprfs}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood de0bc97bb2 Cosmetics (page breaking).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood bb985e039a Section \crossref{concreteorchardkdf} should be in the NU5 colour (slate blue).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Deirdre Connolly ec6c10fc5c Add a note to the Sending Notes (Orchard) section about using a dummy note for ρ.
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 6c8f9fb478 Update the Sprout key component diagram in \crossref{addressesandkeys} to remove magenta highlighting.Remove magenta highlighting
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood e1f105eaa1 Add note about use of big-endian order in the encoding of BLS12-381 points.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 3a55af9b1f Cosmetics and indexing.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 7bfdce2d6a Write caution about linkage between the abstract and concrete protocols in \crossref{cautionlinkage}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood 1097313feb Fix errors in the Sinsemilla proofs:
* SinsemillaHash is defined in terms of SinsemillaHashToPoint, which also takes the D argument.
* correct errors due to 1-based indexing.
* the argument for exceptional cases got the scalars and range of j wrong.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood cce172ace8 Cosmetics (page breaking).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
Daira Hopwood f45b6b5d66 Add Action Statement ref to flags note
This change makes it clearer that the note spend and creation
rules are implemented as part of the proof.

Co-authored-by: teor <teor@riseup.net>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 02:11:35 +01:00
teor ecb2ccd3f4 Copy outCiphertext description to the encoding tables 2021-04-01 02:11:35 +01:00
Daira Hopwood 0eca13f809
Merge pull request #479 from nuttycom/zip_225-sapling_anchors
Remove anchorSapling field when there are no spends.
2021-04-01 00:59:47 +01:00
Daira Hopwood 89596379ff ZIP 225: Cosmetics (trailing spaces).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 00:58:37 +01:00
Kris Nuttycombe e0b08fd576 ZIP 225: Remove anchorSapling field when there are no spends.
Co-authored-by: Kris Nuttycombe <kris@electriccoin.co>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-04-01 00:58:23 +01:00
Daira Hopwood 1bed047c0e ZIP 221: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-31 13:40:26 +01:00
Daira Hopwood c9f9d0b36b ZIP 221: fix rst formatting.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-31 13:37:49 +01:00
Daira Hopwood 31e8b03491 ZIP 244: update link to protocol spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-30 20:19:33 +01:00
Daira Hopwood b0c65971d7
Merge pull request #467 from nuttycom/zip_225-ncc_fixes
Fixes for ZIP 225 issues identified by the NCC audit.
2021-03-30 20:10:43 +01:00
Kris Nuttycombe 0dd2982ec3 Update generated HTML. 2021-03-30 11:13:28 -06:00
Kris Nuttycombe 6ecba03a2a Fix vSpendAuthSigsOrchard field name. 2021-03-30 10:57:24 -06:00
Kris Nuttycombe f7461d62e5
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-03-30 10:45:49 -06:00
Kris Nuttycombe e936a21a6b
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-03-30 09:40:13 -06:00
Kris Nuttycombe 02fd26fc1f Make ordering of Orchard txid hash fields consistent with field order.
Also fixes a few conflicting/incorrect digest references and
removes some spurious duplication.

Co-authored by: Daira Hopwood <daira@jacaranda.org>
2021-03-30 08:28:09 -06:00
Daira Hopwood 64484cb945
Merge pull request #477 from daira/nu5-update-zip221
ZIP 221 and 252 updates for NU5
2021-03-30 14:59:42 +01:00
Deirdre Connolly 0d67dcf681 Update zip-0221.rst
Co-authored-by: Deidre Connolly <deirde@zfnd.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-30 14:58:30 +01:00
Daira Hopwood 5c6ab07f15 ZIP 252: mention amended ZIP 221, and the halo2 book.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-29 23:19:55 +01:00
Daira Hopwood 37479f7a11 ZIP 221: NU5 updates.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-29 23:19:13 +01:00
Daira Hopwood b16cf169e4 ZIP 221: renamed fields.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-29 23:18:45 +01:00
Daira Hopwood 306c575b87 ZIP 244: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-29 16:52:29 +01:00
Daira Hopwood 17818f0b32
Merge pull request #474 from teor2345/patch-8
[ZIP 244]: Be explicit about immediate hashBlockCommitments activation
2021-03-29 16:51:55 +01:00
teor 96efd54702
Be explicit about hashBlockCommitments activation 2021-03-29 14:14:12 +10:00
Kris Nuttycombe 4b2af700ef Add non-requirement for non-malleable transaction IDs for v4 transactions. 2021-03-26 16:37:30 -06:00
Kris Nuttycombe f202b83a9d Remove Sprout commitments from ZIP 244; include flagsOrchard in txid. 2021-03-26 16:37:30 -06:00
Kris Nuttycombe e4bc6ad354 Fixes for ZIP 225 issues identified by the NCC audit. 2021-03-26 16:37:29 -06:00
Daira Hopwood b0180c76f8 ZIP 216: fix section numbers.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 20:03:19 +00:00
Daira Hopwood d713d35f54 ZIP 216: fix references to the NU5 protocol spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 20:00:44 +00:00
Daira Hopwood 0f427feb5b Regenerate PDFs. 2021-03-26 19:45:47 +00:00
Daira Hopwood f66887cdee Fix an off-by-one error.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 19:40:57 +00:00
Daira Hopwood 3898e2f571 Regenerate PDFs. 2021-03-26 19:38:49 +00:00
Daira Hopwood b4aac633f4 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 19:31:45 +00:00
Daira Hopwood 17a6a72974 Merge branch 'orchard-wip'
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 19:27:21 +00:00
Daira Hopwood 2f246ce24d Other fixes to the Orchard specification, including generation of dummy notes and output notes.
fixes #465

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 19:17:33 +00:00
Daira Hopwood aa86282e16 Change the specifications of note decryption to return the note and memo, rather than a note plaintext.
Generalize the specification of block chain scanning to support Orchard.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:58 +00:00
Daira Hopwood c50bdbd9ce Delete a confusing part of the definition of concatbits that we don't rely on.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:58 +00:00
Daira Hopwood b27213dfd3 Move the definition of ⊥ to before its first use.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:58 +00:00
Daira Hopwood cd1b4de8f9 Update the hashFinalSaplingRoot/hashLightClientRoot/hashBlockCommitments field for NU5.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:58 +00:00
Daira Hopwood 74dfa80194 Fix errors in Orchard due to cut-and-paste from Sapling.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:58 +00:00
Daira Hopwood 4d3204b8e1 Describe the recommended way to encode a Sapling or unified payment address as a QR code.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:58 +00:00
Daira Hopwood bbc6131f29 Update specification of Poseidon.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:58 +00:00
Daira Hopwood 212fdc8752 Add references for the halo2 book.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 5e55821889 NCC audit: Make the description of when fields are included in v5 transactions consistent
between the protocol specification and ZIP 225. Also regenerate the HTML for ZIP 225.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 55af963e53 NCC audit: Add a definition for the section symbol in \crossref{introduction}, before its first use.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood eff39611f8 ZIP 225: Correct the size of the outCiphertext field in a Sapling Output description.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 3d386eeec0 ZIP 225: Update references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 5fef9270e2 NCC audit: Correct the sizes of SpendDescriptionV5 and OutputDescriptionV5 in the version transaction format.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood bfc6a8e33c NCC audit: Document the limitation on the domain separation string for the group hash into Pallas/Vesta.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood a68c7d24d0 NCC audit: Document that the choice of nonsquare for λ_G in \crossref{concretegrouphashpallasandvesta} makes no difference
to the output of map_to_curve_simple_swu.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood fa2b1c6ce9 Correct the output type of sqrt_ratio.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood ab0e248036 NCC audit: Document that the use of k = 256 in hash_to_field is intentional,
despite the Pallas curve only having 126-bit conjectured security against generic attacks.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 9d62142142 NCC audit: Fix a discrepancy between \crossref{concretegrouphashpallasandvesta} and \cite{ID-hashtocurve}.
The zero padding in expand_message_xmd should be 128 bytes (matching the input block size of
BLAKE2b), rather than 64 bytes.

See also https://github.com/zcash/pasta/pull/2 and https://github.com/zcash/pasta_curves/issues/7

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 5d15a3d91e NCC audit: Fix type confusion between integers and field elements (including additional cases
not found in the audit, involving nullifiers and cm_x).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 7ccbf44c30 NCC audit: Define \mathbb{G} in \crossref{concretegrouphashpallasandvesta}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 4d983aa855 NCC audit: Make the naming of enableSpends and enableOutputs consistent.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood e5336bb536 Various rationale updates for NU5.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 8f1ff76417 Add proof of collision resistance for Sinsemilla.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 591c7e45cc NCC audit: Restrict the definition of a short Weierstrass elliptic curve
to base fields of characteristic greater than 3.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 2e50a09e97 NCC audit: Correct the definition of PRFnf^Orchard by changing Poseidon to PoseidonHash.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood b7d61884e1 NCC audit: Propagate \bot from the inputs of MerkleCRH^Orchard to its output, and add an explicit
consensus rule that rt^Orchard computed from appending a note commitment is not \bot.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood c11c329beb NCC audit: Propagate \bot intermediate results to the output of Sinsemilla primitives.
Change the output types of NoteCommitAlg^Orchard and CommitIvkAlg to reflect that these can
return \bot, and change the action statement to be satisfied if they do.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood 20478ae40d Credit Eirik Ogilvie-Wigley as a designer of the Zcash protocol. Add Andre Serrano, Brad Miller,
Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart,
Kevin Gorham, Larry Ruane, Marshall Gaucher, and Ryan Taylor to the acknowledgements.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:57 +00:00
Daira Hopwood b14c332910 NCC audit: Correct the definition of c in \crossref{concretesinsemillahash}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:23:51 +00:00
Daira Hopwood 54a0894acf NCC audit: fix 'reasonable' typo.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:22:50 +00:00
Daira Hopwood 02db965036 Cosmetics and trivial changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-26 18:22:50 +00:00
str4d 41afbd3c66
Merge pull request #105 from zcash/memo-field-specification
[ZIP 302] Standardized Memo Field Format
2021-03-25 10:22:03 +13:00
Kris Nuttycombe 7752911cb6 Generate ZIP 302 HTML 2021-03-24 15:16:26 -06:00
Kris Nuttycombe 14b975622b Merge remote-tracking branch 'upstream/master' into memo-field-specification 2021-03-24 15:13:16 -06:00
Deirdre Connolly 2ec19b5fcc
Merge pull request #463 from zcash/dconnolly-patch-1
s/enableSpendsOrchard/enableOutputsOrchard/ re: no new notes
2021-03-23 17:25:25 -04:00
Daira Hopwood 44c45004df Cosmetics and trivial changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-23 20:01:13 +00:00
Daira Hopwood 218196f8dd Output ciphertext -> outgoing ciphertext.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-23 19:27:47 +00:00
Daira Hopwood e1bdfce3bc Remove specification of memo contents, which will be in ZIP 302.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-23 19:21:56 +00:00
str4d 75b94ce063
ZIP 302: Remove remaining reference to TLV scheme 2021-03-23 13:46:14 +13:00
str4d 00864688d2
ZIP 302: Sort reserved ranges. 2021-03-23 13:42:53 +13:00
Deirdre Connolly 75a8a944d4 s/enableSpendsOrchard/enableOutputsOrchard/ re: no new notes 2021-03-19 15:14:26 +00:00
Daira Hopwood a859014b98 Correct the description of `length` in \crossref{unifiedpaymentaddrencoding}.
(It is the length of `addr`, not the length of the raw encoding; they differ for t-addrs.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-19 15:14:25 +00:00
Daira Hopwood 781ec6896d Correct the type signature of DiversifyHash^Orchard in \crossref{abstracthashes}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-19 15:14:25 +00:00
Daira Hopwood 3e160d6ecb 2^16 -> 2^{16}. fixes #461
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-19 15:14:25 +00:00
Daira Hopwood 9af5978852 Remove magenta highlighting of differences from Zerocash.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-19 15:14:25 +00:00
Daira Hopwood 78e3d68539 Remove support for generating the Sprout-only specification (sprout.pdf).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-19 14:00:19 +00:00
Deirdre Connolly ed81c92365
s/enableSpendsOrchard/enableOutputsOrchard/ re: no new notes 2021-03-19 02:08:46 -04:00
str4d de694d4509
Final changes to remove undecided parts of the draft 2021-03-19 11:28:50 +13:00
Kris Nuttycombe eecb7dc43e
Update zip-0302.rst 2021-03-18 11:20:25 -06:00
Kris Nuttycombe 4e32c8da28
ZIP 302: Update 0xF5 section. 2021-03-18 11:16:46 -06:00
Kris Nuttycombe 2cbfb93ac9 Merge remote-tracking branch 'upstream/master' into memo-field-specification 2021-03-18 10:22:05 -06:00
Kris Nuttycombe 14fa0591c7 ZIP 302: Reword the motivation for clarity and to narrow to the scope of the ZIP. 2021-03-18 09:09:28 -06:00
Kris Nuttycombe a4e93decc7 ZIP 302: Fix references 2021-03-18 08:52:55 -06:00
Kris Nuttycombe 8ac3fa19ea ZIP 302: Wrap lines. 2021-03-18 08:44:02 -06:00
Kris Nuttycombe 45d6cdc3d8 ZIP 302: Clarify first byte references and use conformance language.
Co-authored-by: Kevin Gorham <kevin.gorham@electriccoin.co>
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-03-18 08:31:26 -06:00
Daira Hopwood ebe3800b2b Regenerate PDFs. 2021-03-17 20:00:51 +00:00
Daira Hopwood f0fa13761e Regenerate PDFs. 2021-03-17 19:55:50 +00:00
Daira Hopwood 3b558b2146 Set date in Change History entry for v2021.1.19.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-17 19:55:49 +00:00
Daira Hopwood c5c34cf93c Cosmetics (spacing).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-17 19:55:49 +00:00
Daira Hopwood 0b8a4b3d90 Correct the range of input to ValueCommit^Orchard in the action statement, and the corresponding security argument in \crossref{orchardbalance}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-17 19:55:48 +00:00
Daira Hopwood e31f33c678 Fix a type error in the non-normative note at the end of \crossref{concretesinsemillacommit}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-17 19:55:48 +00:00
Daira Hopwood 867d0cc712 Make DiversifyHash^Orchard total, by replacing an output of the zero point with another base.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-17 19:55:48 +00:00
Daira Hopwood c9b918a654 Fix a typo: 2^16 -> 2^{16}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-17 19:55:48 +00:00
Daira Hopwood 17518632e1 Update the consensus rules that prevent trivial transactions (with no inputs or outputs)
to take into account action transfers in the v5 transaction format.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-17 19:55:48 +00:00
Daira Hopwood 0dfe5df5e3 ZIP 225: fix rst errors.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-17 18:15:11 +00:00
Daira Hopwood 9ab9857bba
Merge pull request #453 from nuttycom/225_remove-sprout-alternative
Proposal to remove Sprout fields from the V5 transaction format.
2021-03-17 18:09:19 +00:00
Daira Hopwood 6abc86fb98 ZIP 225: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-17 18:08:29 +00:00
Kris Nuttycombe 09597dd1ee
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-03-17 11:54:51 -06:00
Kris Nuttycombe 9627ad7c49 Fix zip-0222 reference. 2021-03-17 11:54:07 -06:00
Kris Nuttycombe fbddfafef4 Update the alternatives section of ZIP-0225 to reflect the adopted alternative. 2021-03-17 11:28:13 -06:00
Daira Hopwood cec8b904c5 Regenerate PDFs. 2021-03-17 02:11:38 +00:00
Daira Hopwood 36074af67b Version 2021.1.18:
* Define unified payment addresses in place of the Bech32 form of Orchard addresses.
* Remove Sprout-specific fields from the v5 transaction format.
* The rho value for an Orchard output note was incorrectly described as being derived from
  rseed, instead of being set to the nullifier from the same action description as intended
  (fixes #459 ).
* The psi value is now derived using the PRF^expand input [9], instead of [10] (refs #459 ).
* Correct a note about the range of the Merkle hash inputs in \crossref{actionstatement}.
* Correct the validity condition for ak in \crossref{orchardfullviewingkeyencoding}.
* Add a definition for K^Orchard in \crossref{commitmentsandnullifiers} (fixes #460 ).
* Correct the number of full and partial rounds for Poseidon.
* Add a note explaining the origin of the 2^{65} constant in the definition of PoseidonHash.
2021-03-17 02:06:38 +00:00
Daira Hopwood 27a39088d6 Regenerate PDFs. 2021-03-15 16:27:53 +00:00
Daira Hopwood bed110f816
Merge pull request #441 from daira/orchard-circuit
NU5 specification
2021-03-15 16:22:53 +00:00
Daira Hopwood ad032d456a More WIP:
* fix the use of inputs to PRF^expand in Orchard note encryption;
* rename "hash extractor" to "coordinate extractor";
* miscellaneous minor fixes;
* set date of Change History entry.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood 37d8221c4d Mainly fixes to the Action statement.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood d79de34b4a Update key components diagram.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood 7cc31111bb Yet more WIP. Nullifier derivation for Orchard is correct now.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood f6fb3c80d7 More WIP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood 6ac5901a42 More WIP, and rename orchard.pdf to nu5.pdf.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood dae8852187 More Orchard WIP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood e62d57959e More WIP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood 6453611314 * More Orchard WIP;
* The definition of a represented group abstraction function incorrectly required canonicity;
* Note about non-canonical encodings in the Jubjub gave incorrect values for encodings of the point of order 2;
* Change the spec of decryption with ovk to match zcashd (by adding \bot and subgroup checks);
* Add a note saying that a node impl that checkpoints on Sapling can omit verifying BCTV14 proofs.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood 68cb4c6d5f Font hack to make sure that italic bold is not too wide.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood a81cfdb693 More WIP!
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood ad9c631ee0 More WIP for Orchard, including hashing to Pallas and Vesta.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood 6215dce577 More WIP
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood 0b6faf673d Update spec for Orchard up to and including section 3 (Concepts).
This includes the key derivation diagram in section 3.1.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood 300df42bf3 More WIP for Orchard
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood c2c4160151 WIP: Orchard
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-15 16:18:54 +00:00
Daira Hopwood 7cf44fe6bc
Merge pull request #458 from daira/zip-216-redundancy
ZIP 216: non-canonical encodings of SpendDescription.{cv, rk} and OutputDescription.{cv, epk} will already be rejected
2021-03-13 10:08:51 +00:00
Daira Hopwood b336b8936d ZIP 216: non-canonical encodings of SpendDescription.{cv, rk} and OutputDescription.{cv, epk} will already be rejected.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-11 18:53:45 +00:00
Daira Hopwood 18d30f3f82 ZIP 216: specify the requirement for pk_d and ak in imported addresses and FVKs to be in the prime-order subgroup.
This is not a consensus rule, so MAY be enforced before NU5 activation.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-10 16:01:55 +00:00
Daira Hopwood 1c663f53cd _config.yml: attempt to fix unreliable GitHub pages updates.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-07 19:51:37 +00:00
Daira Hopwood 5df826f0f6 ZIP 244: formatting fix.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-07 19:34:11 +00:00
Daira Hopwood 65ce3b9c55 Make sure that headings are larger than body text.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-07 19:29:54 +00:00
Daira Hopwood 58b4f05984 ZIP 225: editorial updates, generate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-04 03:41:19 +00:00
Daira Hopwood 4e2e7a64e8
Merge pull request #446 from teor2345/zip-252-nu5
[ZIP 252] Network Upgrade 5
2021-03-04 03:40:17 +00:00
Daira Hopwood 7e21ab57ac Push draft of NU5 spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-04 03:27:02 +00:00
Daira Hopwood 45e175512e ZIP 32: fix a type error in dk derivation for Orchard.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-03 22:48:38 +00:00
Daira Hopwood 81136fe7ab ZIP 245: add Created date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-03 16:47:59 +00:00
Daira Hopwood 559291b192 ZIPs 224, 225 and 245: add MIT licensing.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-03 16:34:12 +00:00
Daira Hopwood f06f5539d8 ZIP 224 and 225: add Created dates.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-03 16:23:50 +00:00
Daira Hopwood e95695d3bf
Apply suggestions from code review 2021-03-03 15:32:34 +00:00
Kris Nuttycombe 9a4b2e9afe
Update zip-0225.rst
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-03-02 20:24:28 -07:00
Kris Nuttycombe 0fc45a53ca Proposal to remove Sprout fields from the V5 transaction format. 2021-03-02 17:58:12 -07:00
Daira Hopwood ecec91883b
Merge pull request #448 from str4d/zip-224
Updates to ZIP 32 and ZIP 224 for Orchard
2021-03-02 22:22:18 +00:00
Daira Hopwood 62c31fda89 ZIP 224 editorial changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-02 22:21:26 +00:00
Daira Hopwood e40bb506ab ZIP 32 editorial updates.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-02 22:20:42 +00:00
Daira Hopwood e79401a10c Apply suggestions from ZIP review
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
2021-03-02 22:20:42 +00:00
Jack Grigg dd8b82f567 ZIP 32: Address Orchard review comments 2021-03-02 22:20:42 +00:00
Jack Grigg 9cae4aeedc ZIP 224: Motivation 2021-03-02 22:20:42 +00:00
Jack Grigg 95ea11de9d ZIP 32: Clarify the diversifier key capabilities of an Orchard fvk 2021-03-02 22:20:42 +00:00
Jack Grigg 2ae31ccdb7 ZIP 224: Minor fixes 2021-03-02 22:20:42 +00:00
Jack Grigg 6fa961877c ZIP 224: The normative reference for Orchard is the protocol spec 2021-03-02 22:20:42 +00:00
Jack Grigg 630280869e ZIP 224: Clarify that the IETF hash-to-curve ID is not normative 2021-03-02 22:20:42 +00:00
Jack Grigg 2961726557 ZIP 224: Additional rationale
This is in addition to the design rationale included by reference.
2021-03-02 22:20:42 +00:00
Jack Grigg 6631754e19 ZIP 224: Security and privacy considerations 2021-03-02 22:20:42 +00:00
Jack Grigg 9fd129ff86 ZIP 224: Document that \rho is set to the action's nullifier 2021-03-02 22:20:42 +00:00
Jack Grigg ca326ab40e ZIP 224: Add links to test vectors and reference implementation 2021-03-02 22:20:42 +00:00
Jack Grigg f2eb24ae6e ZIP 32: Specify Orchard key derivation 2021-03-02 22:20:42 +00:00
Jack Grigg 7350f94b0e ZIP 224: Add references to specification and design rationale 2021-03-02 22:20:42 +00:00
teor 8a1fd5f469
ZIP-252: Add draft ZIPs for NU5 2021-03-03 08:08:26 +10:00
teor b18bc9eeb5
ZIP-252: Avoid codename confusion 2021-03-03 08:07:54 +10:00
teor cfc8b116fd
ZIP-252: Fix a format typo 2021-03-03 08:07:30 +10:00
Daira Hopwood a55581bae5 Regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-02 20:24:31 +00:00
Daira Hopwood 286af0335c
Merge pull request #449 from nuttycom/225_nu5-tx-format
ZIP 225 - Transaction Format & Transaction Identifier Updates for Orchard
2021-03-02 20:19:40 +00:00
Daira Hopwood 35b04b3115 ZIP 225: rst fixes and minor editorial changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-02 20:18:41 +00:00
Daira Hopwood 98bfb28fe7
Merge pull request #450 from daira/withdraw-zip-0210
Withdraw ZIP 210 in favour of ZIP 225.
2021-03-02 09:49:18 +00:00
Daira Hopwood c0632d26a3 Withdraw ZIP 210 in favour of ZIP 225.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-02 00:00:16 +00:00
Daira Hopwood 2318a5c823
Merge pull request #442 from str4d/zip-0216
[ZIP 216] Require Canonical Jubjub Point Encodings
2021-03-01 23:55:23 +00:00
Daira Hopwood faf27e276d ZIP 216: generate HTML and update index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-03-01 23:53:42 +00:00
Kris Nuttycombe ed25876e21 Add flagsOrchard field 2021-03-01 16:14:04 -07:00
Kris Nuttycombe 96b8fd1e35 Clean up RST tables and more quoting fixes. 2021-03-01 15:50:11 -07:00
Kris Nuttycombe 9663e146a9
Apply suggestions from code review
* Consistency in naming of spends and actions
* Proper quoting of identifiers within rst tables
* Fix to aggregated Orchard proof size

Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-03-01 15:21:39 -07:00
Kris Nuttycombe 62dca39483 Separate Sapling effecting data from authorizing data in the transaction format.
This change restructures the wire format of Sapling spend and output
descriptions to segregate authorizing data from the data describing the
effects of the transaction in a similar fashion as has been done for
Orchard. The result is now symmetric between Sapling and Orchard, and
also simplifies slightly the description of the computation of the
authorizing data commitment in ZIP 244.
2021-03-01 10:55:11 -07:00
Daira Hopwood afc3ae4d1b edithtml.sh: fix to links of the form "foo.rst#anchor".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-02-28 21:24:26 +00:00
Daira Hopwood 65026436b7 * Don't imply that the non-canonical encoding of (0, -1) is not a problem; it is.
* Rewrite Specification section.
* Additions to Rationale section.
* Wording improvements.
* Note the history of adjustments to the protocol spec.
* Fix rst syntax.
* Change license to MIT.
* MUST NOT is not used.
* Move draft to Proposed.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-02-28 21:11:55 +00:00
Kris Nuttycombe 267bced55a Draft of ZIP 225 2021-02-28 12:32:29 -07:00
teor 1dbc893db5
ZIP-252: Transaction version change 2021-02-24 08:09:49 +10:00
teor 98982f63a7
ZIP-252: Remove heights until decisions are made
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-02-24 08:02:15 +10:00
teor 5b5b6c2759
ZIP-252: Fix zcashd version
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-02-24 08:01:40 +10:00
teor 52e448556b
ZIP-252: Formatting tweaks and typos
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-02-24 08:00:45 +10:00
teor ab71570ad7 ZIP-252: Clarify protocol versions 2021-02-23 19:46:55 +10:00
teor 3e2310d017 ZIP-252: Pick NU5 constants 2021-02-23 19:44:50 +10:00
teor 2834b6d2ae ZIP-252: Add a Zebra section 2021-02-23 19:09:53 +10:00
teor 143dc209a8 ZIP-252: Guess zcashd versions
And add TODOs
2021-02-23 18:56:25 +10:00
teor 28a9136d70 ZIP-252: Split network protocol versions into a table 2021-02-23 18:41:50 +10:00
teor 0b63982042 ZIP-252: Split out zcashd-specific behaviour 2021-02-23 18:41:28 +10:00
teor 3baafb5d50 ZIP-252: Delete Canopy ZIPs
And add TODOs.
2021-02-23 18:22:12 +10:00
teor d2c1d9b910 ZIP-252: Replace Canopy with NU5 2021-02-23 18:21:43 +10:00
teor c075253206 ZIP-252: update metadata 2021-02-23 18:10:22 +10:00
teor a6ea584c0b ZIP-252: copy ZIP-251 - Canopy as a template 2021-02-23 18:08:10 +10:00
teor 2fae6cdb3b ZIP-252: start draft 2021-02-23 18:07:41 +10:00
Daira Hopwood 5a92818183
Apply suggestions from code review
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
2021-02-17 21:47:41 +00:00
Daira Hopwood 368890ae8f Add stub for ZIP 225 (Version 5 Transaction Format).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-02-15 21:03:28 +00:00
Daira Hopwood 4b5ce259d1 Move ZIP 244 to Proposed and ZIP 245 to Draft.
Also fix an rst syntax error in ZIP 245.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-02-15 20:52:40 +00:00
Daira Hopwood feda12fab6
Merge pull request #433 from nuttycom/wip/transaction_malleability
[ZIPs 244, 245] Specify an algorithm for non-malleable txid creation.
2021-02-15 20:35:28 +00:00
Kris Nuttycombe d610b8ca17 Regenerate html. 2021-02-15 10:00:04 -07:00
Kris Nuttycombe 566be18f40 Rename signature digests to clarify differences wrt txid digests. 2021-02-15 09:59:01 -07:00
Kris Nuttycombe a779c1043d
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-02-15 09:52:53 -07:00
Jack Grigg c4a863096c ZIP 216: Fix references 2021-02-11 22:38:22 +00:00
Jack Grigg acf88b883c ZIP 216: Rename to only apply to Jubjub points 2021-02-11 22:34:00 +00:00
Jack Grigg fd63a498f2 ZIP 216: Main draft 2021-02-11 22:32:13 +00:00
Kris Nuttycombe 506c3d0df3 Regenerate HTML 2021-02-09 08:07:53 -07:00
Kris Nuttycombe cdb7144519
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-02-09 08:06:00 -07:00
Kris Nuttycombe 62331bbbb6 Add decoupling of wire format from consensus rules to motivation. 2021-02-08 11:19:14 -07:00
Kris Nuttycombe a424153462 Clarify rationale for personalization changes.
Also clarify terminology around signature hash flags vs. types.
2021-02-04 10:59:51 -07:00
Kris Nuttycombe 4b8a78c51b Specify exclusion of spend authorization sigs from txid. 2021-02-02 14:11:09 -07:00
Kris Nuttycombe 90e83ad754
Note number of underscores in hash personalization strings.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-02-02 13:22:02 -07:00
Kris Nuttycombe 4da60ce58b Fix authorizing commitment to include spend_auth_sigs 2021-02-02 13:06:43 -07:00
Kris Nuttycombe 862f0e8ed0 Update ZIP 222 to refer to ZIP 245 2021-02-01 16:55:11 -07:00
str4d 7f7bf5f04b
Merge pull request #439 from acoglio/patch-1
Add a paragraph break
2021-02-02 04:56:43 +13:00
Kris Nuttycombe 3bc233bafb Clean up HTML rendering of the RST. 2021-01-26 15:29:24 -07:00
Kris Nuttycombe e3729e8e7c Fix rst rendering errors. 2021-01-26 15:06:30 -07:00
Kris Nuttycombe 7558c6995d Add signature digest algorithm for TZEs. 2021-01-26 14:32:26 -07:00
Kris Nuttycombe 7fbe3780d9
Apply suggestions from code review
Co-authored-by: Deirdre Connolly <durumcrustulum@gmail.com>
2021-01-26 08:47:57 -07:00
Kris Nuttycombe c693ab88bd Fix outputs digest in signature hash. 2021-01-21 17:23:09 -07:00
Kris Nuttycombe 56dd669368 Add block commitment hash changes. 2021-01-21 12:52:53 -07:00
Kris Nuttycombe c689a58731 Include signature hash & auth commitment sections. 2021-01-20 17:28:39 -07:00
Kris Nuttycombe becda9c543 Add alternatives section to record zkproofs discussion. 2021-01-19 15:37:36 -07:00
Alessandro Coglio 08fcc0c1f0
Add a paragraph break
It seems that this should get its own paragraph, for symmetry with nearby paragraphs.
2021-01-15 18:09:09 -08:00
Kris Nuttycombe 08faa9f8f8 Fix reference links. 2021-01-13 16:59:24 -07:00
Kris Nuttycombe e1558317bb
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2021-01-13 16:57:38 -07:00
Kris Nuttycombe 05f86c7cc5 Use ZIP 244 for nonmalleability, ZIP 245 for TZE-related digests. 2021-01-13 16:27:19 -07:00
Kris Nuttycombe 381b67a650 Add hash algorithm for authorizing data. 2021-01-13 16:26:18 -07:00
Kris Nuttycombe 71e90991e8 Fully specify the txid digest algorithm. 2021-01-13 16:26:17 -07:00
Kris Nuttycombe cfe018c3b3 Initial sketch of transaction non-malleability requirements. 2021-01-13 16:26:17 -07:00
Daira Hopwood 4f1ce394fe Regenerate PDFs. 2021-01-11 00:15:27 +00:00
Daira Hopwood 894c979a3d protocol/Makefile: add new .pdf files if needed.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-11 00:10:37 +00:00
Daira Hopwood adced97391 Update Change History version and date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-11 00:08:20 +00:00
Daira Hopwood 6dc375e9ec Add (experimental, unused) support for linking consensus rules with the corresponding code.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-10 23:56:30 +00:00
Daira Hopwood 9bc9823a23 Add macros and Makefile support for building the Orchard draft specification.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-10 23:56:30 +00:00
Daira Hopwood 3751c9973d QED-it changed the spelling of their company name to QEDIT.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-10 23:46:24 +00:00
Daira Hopwood a5b78961f4 Clarify the encoding of block heights for the "height in coinbase" rule.
The description of this rule has also moved from 'Block Header Encoding and Consensus' to
'Transaction Encoding and Consensus'.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-10 23:45:53 +00:00
Daira Hopwood 0bd8580d1a Include the activation dates of Heartwood and Canopy in 'Network Upgrades'.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-10 23:40:03 +00:00
Daira Hopwood 1ddc19ffaa Section links in the Heartwood and Canopy versions of the specification now go to the correct document URL.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-10 23:37:16 +00:00
Daira Hopwood 34de56533f Protocol spec: use cmap package to attempt to improve search/copy-paste on some PDF readers.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-10 23:32:54 +00:00
Daira Hopwood 1556f34277 ZIP 224 stub: link to Halo Book and tickets.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-08 20:29:42 +00:00
Daira Hopwood 68527a38c6 ZIP 224 stub: link to a section of the Orchard Book that has been started.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-08 18:25:56 +00:00
Daira Hopwood 8abbcbf33f ZIP 224: add links to existing Orchard technical content.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-08 18:23:11 +00:00
Daira Hopwood 62eaddbd8f ZIP 224 stub: fix Kris' and Ying Tong's email addresses.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-08 16:47:04 +00:00
Daira Hopwood 6f34b9fed2 Add reserved ZIP 245.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-07 22:23:16 +00:00
Daira Hopwood 1bb2f5fab8 Add ZIP 224.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-01-07 22:04:24 +00:00
Daira Hopwood ec7d7928f1 ZIP 401: reduce threshold for low_fee_penalty to match the new conventional fee specified in ZIP 313.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:50:55 +00:00
Daira Hopwood 744aca3136 ZIP 313: fix link.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:41:46 +00:00
Daira Hopwood d62bf4065f
Merge pull request #408 from nighthawk24/master
[ZIP 313] Reduce Conventional Transaction Fee to 1000 zatoshis
2020-12-23 02:38:28 +00:00
Daira Hopwood 4a36917e50 ZIP 313: final editing, and add more detail about zcashd support.
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:35:47 +00:00
Daira Hopwood 3a2adec658 Rename zip-reduce-shielded_tx_fee.rst to zip-0313.rst .
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:29:23 +00:00
Adí 0aa739fd43 Remove guarantee wording. 2020-12-23 02:28:02 +00:00
Adí 4051868b09 Formatting, Suggestions and add Acknowledgement 2020-12-23 02:28:02 +00:00
Adí 67bbc459cb Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 755d79f4f2 Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 79afded365 Update grammar
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 8639b3e3da Update wording
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí ba7eb97b04 Move text
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 38d0a8c95f Move text
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 2dae307127 Fix grammar
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 1b4698c960 Remove ZIP Comments field
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 730d2b45b0 Add Ian Miers name
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 6bb093a0ec Add Zooko's last name
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí fc3f63a5ae Fix formatting
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 9b321cf200 Include all tx types in scope
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí c02bb0cf8b Update wording and harmonizing.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 147cae0059 Update status
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí ea4ff4b713 Update category
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 5ec589fb9b Remove Original-Author field
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí 842d1e3d00 Modify ZIP to specify default fee for all transactions
Update naming from zats to zatoshis

Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-12-23 02:28:02 +00:00
Adí dc52b7e6e6 Add notice to wallet devs to monitor Zcash network 2020-12-23 02:28:02 +00:00
Adí 8049d103dc Update zip-reduce-shielded_tx_fee.rst
Co-authored-by: Nathan Wilcox <nathan-at-least@users.noreply.github.com>
2020-12-23 02:28:02 +00:00
Adí 4210404693 Accept suggestions to change Editors to Owners.
Co-authored-by: Nathan Wilcox <nathan-at-least@users.noreply.github.com>
2020-12-23 02:28:02 +00:00
Adí 0795dd67cf Update Activation Schedule 2020-12-23 02:28:02 +00:00
Adí 9e663595eb Update zip-reduce-shielded_tx_fee.rst
Co-authored-by: Nathan Wilcox <nathan-at-least@users.noreply.github.com>
2020-12-23 02:28:02 +00:00
Adí 549403dad5 DoS section
Co-authored-by: Nathan Wilcox <nathan-at-least@users.noreply.github.com>
2020-12-23 02:28:02 +00:00
Adí a39730ce76 Update zip-reduce-shielded_tx_fee.rst
Co-authored-by: Nathan Wilcox <nathan-at-least@users.noreply.github.com>
2020-12-23 02:28:02 +00:00
Adí ccef71edef Update zip-reduce-shielded_tx_fee.rst
Co-authored-by: Nathan Wilcox <nathan-at-least@users.noreply.github.com>
2020-12-23 02:28:02 +00:00
Adí adaf4cf84a Update zip-reduce-shielded_tx_fee.rst
Co-authored-by: Nathan Wilcox <nathan-at-least@users.noreply.github.com>
2020-12-23 02:28:02 +00:00
Adí ccbb876fe8 ZIP ownership terminology
Co-authored-by: Nathan Wilcox <nathan-at-least@users.noreply.github.com>
2020-12-23 02:28:02 +00:00
Adí f4c6935530 Added Support Wallets
Updated activation terminology.
2020-12-23 02:28:02 +00:00
Adí bd1e9b2631 Fix typo 2020-12-23 02:28:02 +00:00
Adí bb2acb6c14 Update ZIP #313
Add Activation & UX Guidance.
2020-12-23 02:28:02 +00:00
Adí 05a6e97aab Update zip-reduce-shielded_tx_fee.rst
Co-authored-by: Dimitris Apostolou <dimitris.apostolou@icloud.com>
2020-12-23 02:28:02 +00:00
Adí a62c68a5ec Update zip-reduce-shielded_tx_fee.rst
Fix spelling.

Co-authored-by: Dimitris Apostolou <dimitris.apostolou@icloud.com>
2020-12-23 02:28:02 +00:00
Adí 0973905d60 Update zip-reduce-shielded_tx_fee.rst
Fix formatting.

Co-authored-by: Dimitris Apostolou <dimitris.apostolou@icloud.com>
2020-12-23 02:28:02 +00:00
nighthawk24 3cf9d11da8 Draft ZIP for reducing default tx fee 2020-12-23 02:28:02 +00:00
Daira Hopwood 4b33cd97cf Add reserved ZIPs 218 (User-Defined Assets and Wrapped Assets) and 219 (Disabling Addition of New Value to the Sapling Chain Value Pool).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-12-21 00:49:11 +00:00
Daira Hopwood 3eb098fb26
Merge pull request #419 from daira/zip-1014-networks
ZIP 1014: clarify that the specification is to be interpreted as applying to Mainnet
2020-11-16 20:37:07 +00:00
Daira Hopwood a492c3a4bb ZIP 1014: clarify that the specification is to be interpreted as applying to Mainnet.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-14 22:33:44 +00:00
Daira Hopwood 8382a31fae ZIP 211: add missing reference to the protocol spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-14 22:17:27 +00:00
Daira Hopwood c05613af27 ZIP 0: cosmetics and wording improvements. Also say that ZIPs can be written in Markdown.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-14 22:17:27 +00:00
Daira Hopwood 947f0b6649 Regularize ZIP categories.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-14 22:17:27 +00:00
Daira Hopwood a3189affb2
Merge pull request #417 from zcash/416-fix-min-difficulty
Change the specification of minimum-difficulty blocks to reflect the zcashd implementation
2020-11-13 18:51:10 +00:00
Daira Hopwood ec045af263 ZIPs 205 and 208: wording tweak.
Co-authored-by: teor <teor@riseup.net>
2020-11-13 18:44:17 +00:00
Daira Hopwood 1ea9859e14 ZIPs 205 and 208: conformance language.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-12 06:43:35 +00:00
Daira Hopwood 9a4ebc97ba ZIP 208: "at least" -> "greater than". refs https://github.com/ZcashFoundation/zebra/issues/1276
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-12 06:42:15 +00:00
Daira Hopwood 8c289078cb Change the specification of minimum-difficulty blocks to reflect the zcashd implementation
(which alters nBits rather than just the target threshold). fixes #416

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-11 21:43:53 +00:00
Daira Hopwood 806076c48c ZIP 205 and 208: ensure that specification of minimum difficulty blocks matches zcashd.
Fixes https://github.com/ZcashFoundation/zebra/issues/1276 .

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-10 15:32:59 +00:00
Daira Hopwood 8b311e9651
Merge pull request #409 from amiller/1014-update
[ZIP 1014] Updates for Bootstrap Project
2020-11-10 15:22:18 +00:00
Daira Hopwood ca17b7f5f2 ZIP 207: rename ECC slice to BP slice.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-10 15:20:41 +00:00
Daira Hopwood 6f2a534deb ZIP 1014: refer to current Community Advisory Panel and define it in the Terminology section.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-10 15:20:19 +00:00
Daira Hopwood 03e57714c1 ZIP 207: remove example implementation and add links to zcashd PRs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-10 14:55:48 +00:00
Daira Hopwood ef94502ba3 ZIP 307: update to reflect corrections in protocol spec v2020.1.15.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-10 14:51:57 +00:00
Daira Hopwood 1d30b9fe88 ZIP 202: cosmetics, and make "Transaction Validation" a subsection of "Specification".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-10 14:50:34 +00:00
Daira Hopwood c762d1ca67 Regularize references, especially to RFCs and the Protocol Spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-09 15:59:51 +00:00
Daira Hopwood c136527758 Regenerate PDFs. 2020-11-06 01:09:37 +00:00
Daira Hopwood 3274aa10de Avoid undefined references when building sprout.pdf.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 9a8f72c5e3 Add release date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 7999296d7d Minor corrections.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 6e3c173538 Update a comment about BIPs (which is not in the rendered document).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood c278c2f93a Reserve transaction version 0x7FFFFFFF and version group ID 0xFFFFFFFF for experimental use.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 9257be1d1f Add a consensus rule that the (zero-valued) coinbase transaction output of the genesis block cannot be spent.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 917dbf5c46 Add a missing consensus rule that has always been implemented in zcashd: there must be at
least one transparent output, Sapling output, or JoinSplit in a transaction.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 94ec65564c Define Sprout/Sapling chain value pool balances, and include consensus rules from ZIP 209.
This includes updates to ZIPs 209 and 211 for consistency of terminology (also addressing
a nit from the NCC Canopy report).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 71cee89a18 Corrections to note decryption algorithms:
* ephemeralKey is kept as a byte sequence rather than immediately converted to a curve point;
  this matters because of non-canonical encoding.
* The representation of pk_d in a note plaintext may also be non-canonical and need not be in the
  prime subgroup.
* Move checking of cm_u in decryption with ivk to the end of the algorithm, to more closely match
  the implementation.
* The note about decryption of outputs in mempool transactions should have been normative.

Also change ZIP 212 to say that it is aligned with this version of the protocol spec.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 775b5f3b5d Use "let mutable" to introduce mutable variables in algorithms.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 9c9ad74fad Acknowledge Alexandra Elbakyan for her work on Sci-Hub.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 0ed38ec775 Acknowledge Izaak Meckler, Zac Williamson, and Vitalik Buterin for discussions of the protocol.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood a5db85828c Acknowledge Jack Gavigan as a co-designer of Sapling and of the Zcash protocol.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 924fd97422 Remove a statement that the language consisting of key and address encoding possibilities is prefix-free
(the raw encodings are not).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 85b8f1647b Include a reference to [BFIJSV2010] for batch pairing verification techniques.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-11-06 01:00:58 +00:00
Daira Hopwood 2f75f92fea
Update wording to reflect the fact that the Founders' Reward was not directed to a 501(c)3 2020-11-03 18:25:10 +00:00
Daira Hopwood 901f807125
Merge pull request #412 from daira/zip214-bootstrap
ZIP 214 changes to add mainnet addresses and take into account Bootstrap Project
2020-11-03 15:39:45 +00:00
Daira Hopwood a34ef1a152
Remove "of the Code" since "Section 501(c)(3)" is now defined terminology 2020-11-03 15:33:41 +00:00
Andrew Miller 07c18efafc bootstrap updates to 1014
fixes after comments

remove some redundant

typo fix

Co-authored-by: Daira Hopwood <daira@jacaranda.org>

undo space changing

reference

Apply suggestions from code review

Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-10-28 23:27:08 -05:00
Daira Hopwood ff8d70ae6f ZIP 214: ensure consistent naming of funding streams.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-27 14:41:48 +00:00
Daira Hopwood 8095727eaf ZIP 214: wording changes to take account of the role of Bootstrap Project.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-27 14:41:48 +00:00
Daira Hopwood 6f94cb6b70 ZIP 214: add Mainnet funding stream addresses.
These were added to zcashd in https://github.com/zcash/zcash/pull/4700 .

Also rename the funding stream from FS_ZIP214_ECC to FS_ZIP214_BP (see
https://github.com/zcash/zcash/pull/4830), and "ECC slice" to "BP slice".

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-27 13:22:53 +00:00
Daira Hopwood 2c5ab50526 Regenerate index page.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-26 19:10:05 +00:00
Daira Hopwood 9a6f61bc95 Replace the invite link to the zCash Discord (which is overrun by spam) with the ZcashCommunity Discord.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-26 19:07:47 +00:00
Daira Hopwood 6aa2e03ef6 ZIP 212: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-23 11:32:46 +01:00
Daira Hopwood 18e8643953 Add stubs for ZIPs 217 (Aggregate Signatures) and 313 (Reduce Default Transaction Fee).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-23 11:17:48 +01:00
Daira Hopwood da9e9af6ef Original-Author -> Original-Authors.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-19 14:07:11 +01:00
Daira Hopwood 3a72b4cf60 ZIP 307: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-16 03:04:30 +01:00
Daira Hopwood e63f046675 ZIP 307: changes needed for ZIP 212.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-16 03:04:14 +01:00
Daira Hopwood b7f9fbb06b ZIP 307: update Owners.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-16 03:01:55 +01:00
Daira Hopwood e72404eeaf ZIP 304: type issues.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-08 15:02:57 +01:00
Deirdre Connolly 482f0267ed
Clarify length field size in bytes 2020-10-07 10:37:15 -04:00
Deirdre Connolly 03675c4c4a
Add reference to variable length integer 2020-10-07 10:36:45 -04:00
Deirdre Connolly b4fc3dcb9e
Merge pull request #406 from nuttycom/zip-0321-labels
Clarify "payment" naming, purpose of the "label" field.
2020-10-07 10:25:12 -04:00
Daira Hopwood 15f8fb70ac ZIP 321: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-07 15:21:39 +01:00
Kris Nuttycombe 3327bdd2dc
Update zip-0321.rst
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-10-07 08:13:40 -06:00
Kris Nuttycombe 9d6684aa5b Clarify "payment" naming, purpose of the "label" field. 2020-10-06 17:21:44 -06:00
Daira Hopwood b882644b01 ZIP 403 stub: Verification Behaviour of zcashd
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-06 14:21:16 +01:00
Kris Nuttycombe cbbc1f9d4c
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-10-05 12:43:59 -06:00
Kris Nuttycombe c41d94d53d
Merge pull request #403 from daira/zip-0321-addresses
ZIP 321 address-related updates
2020-10-03 18:04:07 -06:00
Daira Hopwood 8c4e0b5e14 ZIP 321: Add restrictions on addresses and split the URI Syntax section into Syntax and Semantics.
Also tidy up references.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-03 20:03:51 +01:00
Daira Hopwood b7c849f85c ZIP 321: Sapling addresses are not base58.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-03 20:03:51 +01:00
Daira Hopwood ebe3839640
Merge pull request #402 from nuttycom/zip-0321-tweaks
ZIP 321 tweaks
2020-10-02 16:51:18 +01:00
Daira Hopwood e82757b7a6 ZIP 321: regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-02 16:48:15 +01:00
Daira Hopwood 45f7c632d2 ZIP 321: double blank line before top-level sections.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-02 16:48:03 +01:00
Daira Hopwood a9a78b6e3d ZIP 321: clarify where percent encoding is allowed.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-02 16:47:38 +01:00
Daira Hopwood eee512bda4 ZIP 321: require that amounts are no greater than 21000000 ZEC.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-02 16:27:03 +01:00
Daira Hopwood c195d8877b ZIP 321: Expand on backward compatibility.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-10-02 16:26:34 +01:00
Kris Nuttycombe bc6a1a0554 Strengthen request for use of hier-part for addresses in single-payment URIs. 2020-10-02 08:18:13 -06:00
Kris Nuttycombe 099c389046 Add restriction on param indices to be at most 4 digits. 2020-10-01 11:35:22 -06:00
Daira Hopwood bcfafc268d
Merge pull request #401 from nuttycom/fix/zip-0321_t_memos
Fix invalid ZIP-0321 sample URL.
2020-09-30 22:36:08 +01:00
Kris Nuttycombe 5e15a53b22 Fix invalid ZIP-0321 sample URL.
This sample URI inadvertently contained a memo at the paramindex
for a transparent address.
2020-09-30 12:17:32 -06:00
Daira Hopwood 9cc2a8200d ZIP 222: generate HTML and index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-29 17:39:09 +01:00
Daira Hopwood eab1de360a ZIP 222: rST table fixes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-29 17:38:39 +01:00
Kris Nuttycombe 87659ef23b Clarify statement about transparent value balance.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-29 16:51:46 +01:00
Kris Nuttycombe b3355cc2f2 Weaken ZIP-222 constraint on precondition and witness constant-length. 2020-09-29 16:51:46 +01:00
Kris Nuttycombe 061b212274 Remove unnecessary terminology, email addresses & correct quoting.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-29 16:51:46 +01:00
Kris Nuttycombe 374a3fb812 Clarify conditions where only TZE inputs or outputs are present.
Add links to librustzcash & zcashd reference implementation pull
requests.
2020-09-29 16:51:46 +01:00
Kris Nuttycombe 48830325ce Update protocol links
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
2020-09-29 16:51:46 +01:00
Kris Nuttycombe 6317563dbd Update zip-0222.rst
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-29 16:51:46 +01:00
Kris Nuttycombe 794e8a88f7 Update zip-0222.rst
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
2020-09-29 16:51:46 +01:00
Kris Nuttycombe d572d086f5 Clarify "efficient manner" 2020-09-29 16:51:46 +01:00
Kris Nuttycombe 42a707193c Apply suggestions from code review
Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
2020-09-29 16:51:46 +01:00
Deirdre Connolly fb73913e1d Words - Update zip-0222.rst
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-29 16:51:46 +01:00
Kris Nuttycombe 1102c225e6 Minor reordering of zip-222 specification section text. 2020-09-29 16:51:46 +01:00
Kris Nuttycombe fe0c5a294c Clarify precondition encoding. 2020-09-29 16:51:46 +01:00
Kris Nuttycombe 042cf998cb Address review comments. 2020-09-29 16:51:46 +01:00
Kris Nuttycombe 1b1e4d3808 Apply suggestions from code review
Co-authored-by: str4d <thestr4d@gmail.com>
2020-09-29 16:51:46 +01:00
Kris Nuttycombe 64d75e3643 Add encoding of TZE in/out in transactions + consensus rules. 2020-09-29 16:51:46 +01:00
Jack Grigg b3f1e773ee Various small modifications to ZIP 222
- Narrow requirements for prefix-free encodings.
- Clarify that TZEs need to define the four properties for each mode.
- Allow for potential future relaxation of cross-TZE restrictions.
- Expand some explanations.

Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-29 16:51:46 +01:00
Jack Grigg 23fee236a4 Remove malleability content from ZIP 222 motivation
This will be part of the non-malleability ZIP.
2020-09-29 16:51:46 +01:00
Jack Grigg aa4c219af4 Add consensus rule preventing cross-protocol attacks between TZEs 2020-09-29 16:51:46 +01:00
Jack Grigg b39847f3db Add TZE modes 2020-09-29 16:51:46 +01:00
Jack Grigg 4df4efa9bc Rename program -> extension 2020-09-29 16:51:46 +01:00
Jack Grigg 5757acc67e Completely remove scriptPubKey and scriptSig usage from ZIP 222 2020-09-29 16:51:46 +01:00
Jack Grigg 07dc209557 Rename ZIP 222 to "Transparent Zcash Extensions"
The content will be reworked to reflect the current design in subsequent
commits.
2020-09-29 16:51:46 +01:00
Jack Grigg caaa34d883 Assigned ZIP number 222 2020-09-29 16:51:46 +01:00
Jack Grigg 26b80bf3c2 [ZIP ???] Whitelisted Transparent Programs 2020-09-29 16:51:46 +01:00
Daira Hopwood a78a1291fa ZIP 321: rST fixes; generate HTML and index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-24 18:53:28 +01:00
Daira Hopwood 70e5729e79
Line wrapping 2020-09-24 18:48:05 +01:00
Daira Hopwood e4e589a223
base64 -> base64url 2020-09-24 18:42:33 +01:00
Kris Nuttycombe 05daae97ac
Add multiple-payments as a feature to be considered under the grace period clause.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-24 09:46:38 -06:00
Daira Hopwood ae5ebe4b54
Clarifications
Cosmetics.
2020-09-24 16:44:45 +01:00
Daira Hopwood 57cd724f71
Clarifications
Co-authored-by: Kris Nuttycombe <kris.nuttycombe@gmail.com>
2020-09-24 16:44:10 +01:00
Kris Nuttycombe e2ffce08e3 Remove param.0 qualification, as it's invalid. 2020-09-24 09:26:40 -06:00
Kris Nuttycombe 27ac9af545
Mark ZIP as Proposed
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-24 07:56:57 -06:00
Daira Hopwood 0fd0a89fd3
Delete a confusing sentence. 2020-09-24 14:35:10 +01:00
Daira Hopwood 38b45cdac2
Treat an empty paramindex as equivalent to .0 2020-09-24 14:33:54 +01:00
Daira Hopwood b8ed65ad39
Clarify some things. 2020-09-24 14:22:09 +01:00
Daira Hopwood 7a8b2c345e
Clarify base64url alphabet. 2020-09-24 14:09:45 +01:00
Daira Hopwood 3dc98a86ce
Don't allow fractional zatoshi (continued). 2020-09-24 14:07:39 +01:00
Daira Hopwood b44c11e8c7
Don't allow fractional zatoshi. 2020-09-24 14:06:55 +01:00
Kris Nuttycombe 1f50661820 Merge remote-tracking branch 'upstream/master' into zip-0321 2020-09-22 18:56:28 -06:00
Kris Nuttycombe 5e30adb94e Add sample URLs 2020-09-22 18:51:29 -06:00
Daira Hopwood 7f75d91dbf Reserve ZIP numbers 216 (Require Canonical Point Encodings) and 309 (BOLT).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-22 13:50:26 +01:00
Kris Nuttycombe 61338366a3
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-21 09:51:38 -06:00
Kris Nuttycombe 2a08b20ba3
Update zip-0321.rst
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-18 22:35:09 -06:00
Kris Nuttycombe 78b4fadd6c Require leading zero for decimal amounts. 2020-09-17 17:46:52 -06:00
Kris Nuttycombe 43315630b7
Apply suggestions from code review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-17 12:26:22 -06:00
Kris Nuttycombe f9be8c6a70 Fix missing memoparam 2020-09-16 22:24:49 -06:00
Kris Nuttycombe 4f8c148e67
Apply suggestions from code review
Replace `-` with `.` for parameter index delimiter and clarify specification of amount and address values.

Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-09-15 11:48:48 -06:00
Daira Hopwood 766376664a For no good reason at all, wildcard doesn't sort on *some* versions of Gnu make: <https://savannah.gnu.org/bugs/index.php?52076>.
This change isn't semantically necessary, but the `make` output is easier to read if the files are sorted.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-15 15:15:01 +01:00
Daira Hopwood 127c387e99
Merge pull request #123 from arcalinea/xcat-draft
[ZIP 300] Cross-chain Atomic Transaction Standards
2020-09-15 14:41:17 +01:00
Daira Hopwood 689e5a9501 ZIP 300: generate HTML and index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-15 14:39:44 +01:00
Daira Hopwood e9f7b48e41 ZIP 300: add Status section.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-15 14:39:32 +01:00
Daira Hopwood 49b7eae44f ZIP 300: formatting changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-15 14:33:11 +01:00
Daira Hopwood 14630b1c44 ZIP 300: reformat preamble and headings.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-15 14:26:19 +01:00
Daira Hopwood 5d9e790e17 Move Jay's XCAT draft to be ZIP 300.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-15 14:22:11 +01:00
Jay Graber cb5a29f355 Change wording 2020-09-15 14:22:11 +01:00
Jay Graber bb8dc9acba Add to section on timeout periods 2020-09-15 14:22:11 +01:00
Jay Graber 3f571ce717 Add draft of XCAT ZIP 2020-09-15 14:22:11 +01:00
Daira Hopwood c08ae12d85 More header updates.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-14 16:56:21 +01:00
Daira Hopwood f99ae34685 More Discussions-To: and Pull-Request: headers.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-14 16:53:38 +01:00
Daira Hopwood 22cf2a2465 ZIP guide: Use Python 3 version of rst2html5.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-14 15:55:33 +01:00
Daira Hopwood 917c85380c Add placeholder ZIPs for reserved numbers.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-14 15:53:54 +01:00
Daira Hopwood 858984ae0b Replace Heartwood with Canopy ZIPs in README.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-14 14:18:01 +01:00
Daira Hopwood 80d1fa8c2e Add Pull-Request header.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-14 14:16:43 +01:00
Daira Hopwood fb84bd8084 Ensure that URLs enclosed in <> in header fields are linked.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-14 14:12:49 +01:00
Daira Hopwood e02cc853d9 Dockerfile: update dependencies, use Python 3 version of rst2html5, and correct the ENTRYPOINT.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-07 15:29:26 +01:00
Daira Hopwood 4533e07cdc ZIP 207: address NCC comment that Address(height) should be scoped to a FundingStream.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-05 13:23:33 +01:00
Daira Hopwood 3e6886705a ZIP 207: the mechanism to change addresses is provided but is not necessarily used for a given stream.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-05 13:23:00 +01:00
Daira Hopwood 3efc1217bd Update ZIP statuses:
* ZIPs 213, 221, 250 -> Final
* ZIPs 207, 251 -> Implemented (zcashd)
* ZIP 1014 -> Active.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-09-05 13:11:28 +01:00
Kris Nuttycombe 40cd0eca63 ZIP-321 add ALPHA reference. 2020-09-04 12:24:46 -06:00
Kris Nuttycombe 8a6db78df2 ZIP-321 remove Non-requirements section 2020-09-04 12:23:02 -06:00
Kris Nuttycombe 312ef45964 ZIP-321 Add detail about amount semantics and memo field contents. 2020-09-04 12:20:47 -06:00
Kris Nuttycombe 9b5f4824d1 Use rst code-block directive for EBNF (ZIP-0321) 2020-09-04 12:00:40 -06:00
Kris Nuttycombe 890eda3bd0 ZIP-321: Payment Request URIs 2020-09-04 10:56:06 -06:00
Daira Hopwood de2429ac00 ZIP 211: clarification of the wallet rule, per NCC audit.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-30 21:16:47 +01:00
Daira Hopwood 36b35dbf4a Regenerate PDFs. 2020-08-30 21:12:40 +01:00
Daira Hopwood 906838f3b6 Minor fixes to Change History.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-30 21:07:46 +01:00
Daira Hopwood 4d00112f5d Explicitly state the consensus rule that a coinbase transaction must not spend more than is available from the block subsidy and transaction fees.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-30 21:07:34 +01:00
Daira Hopwood c7180872a3 Specify where PRF^expand is used and with what inputs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-30 21:06:29 +01:00
Daira Hopwood ea59cda07f Fix a type error in the output of PRF^nfSapling; a Sapling nullifier is a sequence of 32 bytes, not a bit sequence.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-30 21:01:51 +01:00
Daira Hopwood b3da7a14ee Remove a silly comment from the LaTeX source.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-30 21:01:51 +01:00
Daira Hopwood 87a0670225 protocol/Makefile: ensure that we don't release from a branch other than master or a dirty working tree.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-30 21:01:50 +01:00
Daira Hopwood 1ce341565f
Merge pull request #392 from str4d/zip-143-test-vector-fixes
ZIP 143 test vector fixes
2020-08-25 15:58:58 +01:00
Daira Hopwood 5cdc09daa4 ZIP 143: regenerate HTML. 2020-08-25 15:58:12 +01:00
Daira Hopwood 017c0c6662 ZIP 400: Add HTML and regenerate index. 2020-08-25 15:53:16 +01:00
Daira Hopwood fee786080f
Merge pull request #372 from oxarbitrage/zip400
ZIP400 - informational wallet db format
2020-08-25 15:47:58 +01:00
Daira Hopwood e783a1bf72
Rewrite Wallet Recovery section
The `-salvagewallet` option doesn't work well in practice, so don't mention it.
2020-08-25 15:47:21 +01:00
Deirdre Connolly 043d08473c
Clarify Sapling z-addr description 2020-08-25 10:41:26 -04:00
Daira Hopwood 639226dd50 Regenerate PDFs. 2020-08-19 22:03:26 +01:00
Jack Grigg b73265fd09 ZIP 143: The test vectors use the Overwinter consensus branch ID 2020-08-19 02:00:44 +01:00
Jack Grigg cf50caf4da ZIP 143: Specify the correct preimages for the test vectors
The test vectors were updated in zcash/zips#162 (after changes to the
Python code that generates them), but the concatenated preimages were
missed.
2020-08-19 01:58:11 +01:00
Daira Hopwood b2a7e1deb0 Fix a type error in the output of PRF^nfSapling.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-17 21:33:05 +01:00
Daira Hopwood 850e7ea019 Correct an off-by-one in an expression used in the definition of c for windowed Pedersen commitments
(this does not change the value of c).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-17 21:32:15 +01:00
Deirdre Connolly d9e23f194b
Tidy recovery
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-08-12 13:05:38 -04:00
Deirdre Connolly f6dcf0fe78
Clarify RPC call to z_getnewaddress
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-08-12 13:03:14 -04:00
Deirdre Connolly 3c031e0c8b
All fields that allow multiple instances are denoted by a * in the table
With cleanups for field descriptions 

Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-08-12 12:58:30 -04:00
Deirdre Connolly 566711de46
Remove reference to removed link
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-08-12 12:43:01 -04:00
Deirdre Connolly 7bd8753fa5
Remove link to ZIP400Attempt
Either we will pull in these format examples directly into this document or not reference this un-merged ZIP at all.

Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-08-12 12:42:15 -04:00
Deirdre Connolly 335f9d0a69
Clarity around wallet.dat migrations between zcashd instances
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-08-12 12:39:31 -04:00
Deirdre Connolly 5929112c4d
Words
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-08-12 12:37:28 -04:00
Deirdre Connolly f029a1a675
Be explicit that this is per zcashd
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-08-12 12:35:47 -04:00
Deirdre Connolly b919012b1e
Monospace 'wallet.dat' 2020-08-12 12:33:01 -04:00
Deirdre Connolly 626aee93ec
Some wording
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-08-12 12:31:15 -04:00
Daira Hopwood 243de7399d ZIP 304: more cosmetics (math fonts).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 19:50:08 +01:00
Daira Hopwood 9dee5a8700 ZIP 304: cosmetics (math fonts).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 19:42:42 +01:00
Daira Hopwood 6e5278ed95 Canopy ZIPs: update status and references to the protocol spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 16:28:15 +01:00
Daira Hopwood bd755610ac ZIP 212: update status to Implemented (zcashd).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 16:13:57 +01:00
Daira Hopwood e975aacb0e ZIP 212: add links to implementation PRs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 16:08:42 +01:00
Daira Hopwood de0b5de140 ZIP 212: updates for grace period.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 16:07:59 +01:00
Daira Hopwood b83f2b9542 Regenerate PDFs. 2020-08-11 14:44:38 +01:00
Daira Hopwood e1cac0c48a Make the Canopy specification the default.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 13:56:46 +01:00
Daira Hopwood 19ba684f2c Minor wording improvement.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 13:56:19 +01:00
Daira Hopwood 55c51715b5 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 13:56:08 +01:00
Daira Hopwood 7032c07fb8 Make Halving(height) return 0 (rather than -1) for height < SlowStartShift.
This has no effect on consensus since the Halving function is not used in that case,
but it makes the definition match the intuitive meaning of the function.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 13:55:38 +01:00
Daira Hopwood d117273977 Refine the domain of HeightForHalving from N to N^+.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 13:54:06 +01:00
Daira Hopwood 9dbac78f29 Rename some section titles under 'Consensus Changes from Bitcoin' to use 'Encoding and Consensus'.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 13:52:58 +01:00
Daira Hopwood 6fbe17da59 Updates to reflect ZIP 211: add a consensus rule on v^pub_old, and a rule about node and wallet support for sending to Sprout addresses.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 13:49:36 +01:00
Daira Hopwood 1d71f6cb31 Rename the type of Sapling transmission keys from KA^Sapling.PublicPrimeOrder to KA^Sapling.PublicPrimeSubgroup.
This type is defined as J^(r), which reflects the implementation in zcashd (subject to the point below);
it was never enforced that a transmission key (pk_d) cannot be the zero point.

Add a non-normative note saying that zcashd does not fully conform to the requirement to treat
transmission keys not in KA^Sapling.PublicPrimeSubgroup as invalid when importing payment addresses.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 13:43:00 +01:00
Daira Hopwood e1037ff046 Wording improvements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 01:57:49 +01:00
Daira Hopwood d11304c7d1 Add indexing for "halving".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 01:54:48 +01:00
Daira Hopwood a651ad7fe7 Modify funding stream tables and notes to reflect changes in ZIP 214.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 01:52:06 +01:00
Daira Hopwood fd2416d9ea Set CanopyActivationHeight for Testnet.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-11 01:48:59 +01:00
Daira Hopwood fb64b2e430 Regenerate PDFs. 2020-08-03 12:19:11 +01:00
Daira Hopwood 17def33bf8 Use abstBytes_{Ed25519} and reprBytes_{Ed25519} for conversions in Ed25519 batch signature validation, and
fix a missing requirement that S_j < \ell for all signatures.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-03 12:14:34 +01:00
Daira Hopwood ff3c7c2bce Move the footnote about (x, y) notation for Ed25519 to where this notation is first used.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-03 12:11:08 +01:00
Daira Hopwood 13b6f0e120 Delete a potentially misleading Sprout-specific comment.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-03 12:10:20 +01:00
Daira Hopwood 31b844c37c Give a definition for SHA-512. Also some refactoring of hash macros.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-03 12:09:33 +01:00
Daira Hopwood 6a4b1f5f6c Add a reference to [BCCGLRT2014].
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-08-03 12:05:33 +01:00
Daira Hopwood 408a0a744c ZIP 32: fix an off-by-one error pointed out by @bigbrain.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-31 17:27:27 +01:00
Alfredo Garcia bcd1e282d2
remove sentence 2020-07-29 17:29:48 -03:00
Daira Hopwood 9a6aa31d93 ZIP 32: correction for seeds longer than 32 bytes. refs https://github.com/zcash/zcash/issues/4641
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-29 20:07:07 +01:00
Daira Hopwood 60db5fe85d ZIP 32: fixes https://github.com/zcash/zcash/issues/4641
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-29 19:33:49 +01:00
Daira Hopwood c25fc6e899 ZIP 212: fix typo.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-29 14:52:41 +01:00
Daira Hopwood 8116ff7b90
Merge pull request #385 from daira/zip-214-update
Update the funding stream start and end heights and addresses for the Dev Fund on Testnet, and set the Canopy Testnet activation height
2020-07-28 17:58:12 +01:00
Daira Hopwood 03be5a67c0 ZIP 251: set Canopy Testnet activation height.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-25 01:59:04 +01:00
Daira Hopwood 63922ecb63 Update the funding stream start and end heights for the Dev Fund on Testnet.
The old heights were incorrect because the different activation heights for Blossom
on Mainnet and Testnet had not been taken into account. Also, Testnet requires 3 extra
addresses for each stream, to account for the start height being before the first halving.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-25 00:04:19 +01:00
Daira Hopwood 4b1e4829b8 ZIP 1014: regenerate HTML (Howard Loo removed from credits on his request).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-20 22:32:40 +01:00
Daira Hopwood f8930bb489
Merge pull request #383 from hloo/patch-1
Remove Howard Loo from credits section
2020-07-20 22:30:13 +01:00
Daira Hopwood b0fcda8dfd Publish ZIP 304: generate HTML and index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-19 00:45:06 +01:00
Deirdre Connolly 97aa6bf1ca Add prefix on the base64 encoding of sigs for zip304
And give a reference to Base64 RFC
2020-07-19 00:44:08 +01:00
Jack Grigg 206ac7e65f ZIP 304: Sapling Address Signatures 2020-07-19 00:44:08 +01:00
Alfredo Garcia 96f0747e17
redo wallet state section 2020-07-18 11:10:46 -03:00
Alfredo Garcia d5336ffecc
add bdb reference 2020-07-16 19:00:34 -03:00
Deirdre Connolly 25f24bd457
Apply suggestions from code review
Co-authored-by:  Daira Hopwood <daira@jacaranda.org>
2020-07-15 12:54:43 -04:00
Howard Loo 6d5f557c7d
Remove Howard Loo from credits section
I request that my name please be removed from this ZIP. I do not support it and as a member of the Community Panel I voted against it. I merely provided @tromer with some brief feedback one evening about the copyright portions of the ZIP. I did give permission for my name to be mentioned publicly as having provided feedback, but I did not realize that my name would be part of the actual ZIP text. Thank you for considering my request.
2020-07-15 09:26:24 -07:00
Daira Hopwood 1e6b2f8815 Regenerate PDFs. 2020-07-13 18:54:03 +01:00
Daira Hopwood b2f033f84d Add spec changes for ZIPs 207 and 214.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-13 18:45:16 +01:00
Daira Hopwood bc809dae5d Add note about full viewing key decryption of mempool transactions.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-13 18:45:16 +01:00
Daira Hopwood 0248a44a05 Change instances of "the production network" to "Mainnet", and "the test network" to "Testnet".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-13 18:45:16 +01:00
Daira Hopwood baad229598 Update stale references to Bitcoin documentation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-13 18:45:16 +01:00
Daira Hopwood 5d2a48ce9d Regenerate PDFs. 2020-07-07 00:25:02 +01:00
Daira Hopwood a67b74aede Corrections to a note in section 'Ed25519'.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-07 00:21:14 +01:00
Daira Hopwood 9473b9d4af Regenerate PDFs. 2020-07-06 23:10:15 +01:00
Daira Hopwood 0bfbbd54e2 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-06 22:58:29 +01:00
Daira Hopwood 4d148920ae Add a missing cross reference for Jubjub.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-06 22:58:29 +01:00
Daira Hopwood 5e8ae9bb89 Precisely specify the encoding and decoding of Ed25519 points.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-06 22:58:29 +01:00
Daira Hopwood 3e3bf8a79b Add 'Mainnet and Testnet' section.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-06 22:58:29 +01:00
Daira Hopwood e87177f97f Add end comments for conditional blocks in history entries.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-06 22:58:29 +01:00
Daira Hopwood 3f41a13087 Corrections to the specification of \abstJ and the security argument for GroupHash.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-06 22:58:29 +01:00
Daira Hopwood 32a55b0939 Add Jane Lusby and Teor to acknowledgements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-06 22:58:29 +01:00
Daira Hopwood 5504c17ab0 Make duplicate labels work as intended.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-06 22:58:29 +01:00
Daira Hopwood a83a64fefc ZIPs 207, 214, 215 and 251: some suggested changes from NCC audit.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-05 17:27:20 +01:00
Daira Hopwood bbb2bac1ac Makefile: add 'discard' target, to discard changes to checked-in generated files.
This is useful to avoid conflicts when merging / rebasing / doing 'git stash pop'.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-05 17:27:20 +01:00
Daira Hopwood 9acf1b6667 Makefiles: add 'release' targets that perform a protocol spec release.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-05 17:27:20 +01:00
Daira Hopwood 844afbd2ae ZIPs 173 and 213: fix URLs in references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 04:03:54 +01:00
Daira Hopwood b398183fb0 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 04:02:54 +01:00
Daira Hopwood 9321a0d9fc Arguments to PRF^expand don't need to be specified as hex.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 03:59:17 +01:00
Daira Hopwood 553be0f9eb In RedDSA verification, clarify that \underline{R} used as part of the input to H^\ast must be exactly as encoded in the signature.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 03:59:17 +01:00
Daira Hopwood cbf4cb52f1 Adjust the order of operations in Sapling decryption to more closely match the implementation, and improve the notes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 03:59:17 +01:00
Daira Hopwood 47a2c78990 Correct a bug: esk is only to be checked against ToScalar(PRF^expand_rseed([4])) when the lead byte != 0x01.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 03:28:36 +01:00
Daira Hopwood 5689d59d32 Specify that shielded outputs of coinbase transactions MUST use v2 note plaintexts after Canopy activation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 03:28:36 +01:00
Daira Hopwood 9b55332fc2 Add Ying Tong Lai and Kris Nuttycombe as Zcash protocol designers.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 03:18:52 +01:00
Daira Hopwood b915222d96 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 03:18:16 +01:00
Daira Hopwood 154da511c6 Specify \abstJ to be as implemented, and adjust the security argument for \GroupJHash.
Also modify \exclusivefun to take an excluded set rather than a single element.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 03:17:49 +01:00
Daira Hopwood a7f7befe24 Add \optsqrt macro for "arbitrary square root".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-04 03:12:00 +01:00
Daira Hopwood e4315ad6a7 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-07-01 19:22:38 +01:00
Daira Hopwood b16f8c8909 ZIP 307: update header.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 22:30:06 +01:00
Daira Hopwood 7a0e41021d ZIP 307: Zcash Company -> Electric Coin Company.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 22:26:09 +01:00
Daira Hopwood 98b854de95 ZIP 307: add notes about differences from the implementation (see https://github.com/zcash/zips/issues/341#issuecomment-622262394 ).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 22:25:50 +01:00
Daira Hopwood 327746929e ZIP 307: use math markup for the decryption algorithm, and add TODO for ZIP 212/Canopy.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 22:24:42 +01:00
Daira Hopwood d229f7b9ce ZIP 307: arch.png -> zip-0307-arch.png
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 20:15:21 +01:00
Daira Hopwood c29d801825 ZIP 301: minor cleanups.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 20:06:51 +01:00
Daira Hopwood 03dd67c296 ZIP 301 index and HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 17:44:02 +01:00
Daira Hopwood a194f13466 Move ZIP 301.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 17:42:14 +01:00
Daira Hopwood f8b6b259e2 ZIP 301 (Stratum) updates.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 17:40:21 +01:00
str4d e5dd57d588 Update example version string
See https://github.com/zcash/zcash/issues/1481
2020-06-29 17:40:21 +01:00
str4d 23f3c31086 Move CONNECT_HOST/PORT to end of mining.subscribe for compatibility 2020-06-29 17:40:21 +01:00
str4d 42404ba4c3 Update protocol message rendering 2020-06-29 17:40:21 +01:00
str4d 160feb10b6 Clarify that the compactInt must be in canonical form 2020-06-29 17:40:21 +01:00
str4d 20fa2c5544 Clarify that reserved field is expected to be filled 2020-06-29 17:40:21 +01:00
str4d 233cf43dd8 Update acknowledgements 2020-06-29 17:40:21 +01:00
str4d 5c7ec37c04 Specify Equihash solution format 2020-06-29 17:40:21 +01:00
str4d 565ceecfb4 Improve specification for nonce parts 2020-06-29 17:40:21 +01:00
str4d 1ee4ba1409 Use block quotes for protocol messages, emphasise parameters 2020-06-29 17:40:21 +01:00
str4d f4fe8fea10 Miners can use error code for deriving human-readable messages 2020-06-29 17:40:21 +01:00
str4d 26d4d827d8 Correct boolean methods to follow JSON-RPC 1.0 2020-06-29 17:40:21 +01:00
str4d 0b2941372e Correct order of parameters in mining.subscribe response 2020-06-29 17:40:21 +01:00
str4d 1f001c06ee Clarify that block header parts use block header encoding 2020-06-29 17:40:21 +01:00
str4d fe0574906f Specify error objects 2020-06-29 17:40:21 +01:00
str4d a396f5b973 Minor tweaks 2020-06-29 17:40:21 +01:00
str4d 6ea4d05e76 Specify session resuming 2020-06-29 17:40:21 +01:00
str4d b2d405ced0 Add comment about id uniqueness 2020-06-29 17:40:21 +01:00
str4d 2aabd172bd Extract definition of nonce parts into a separate section 2020-06-29 17:40:21 +01:00
str4d 1e21aeb83e Add Daira as editor 2020-06-29 17:40:21 +01:00
str4d 5dc732e7ef Add reference to Bitcoin block header 2020-06-29 17:40:20 +01:00
str4d 47eb8924c9 Reference P2Pool 2020-06-29 17:40:20 +01:00
str4d fcf68b6200 Reference original Stratum docs in motivation section 2020-06-29 17:40:20 +01:00
str4d e3af1254c5 Add reference to ZIP-1 2020-06-29 17:40:20 +01:00
str4d 33a2d8f35f Move motivation section just under abstract 2020-06-29 17:40:20 +01:00
str4d 11e51b6349 Specify encoding of VERSION and TIME 2020-06-29 17:40:20 +01:00
str4d becff6ffdd Improve specification of target 2020-06-29 17:40:20 +01:00
str4d 4a8cce90b7 Require error messages for false boolean results 2020-06-29 17:40:20 +01:00
str4d 30d06746c9 Add specification overview and protocol flow 2020-06-29 17:40:20 +01:00
str4d 2a7d10c053 Explain link between worker names and job IDs 2020-06-29 17:40:20 +01:00
str4d 437100c81c Explain the host and port fields in mining.subscribe 2020-06-29 17:40:20 +01:00
str4d 5723b79f69 Use definition lists for variable definitions 2020-06-29 17:40:20 +01:00
str4d 569aa36450 First draft of Zcash Stratum protocol 2020-06-29 17:40:20 +01:00
Daira Hopwood bba80b5b0b ZIP 307: fix a reference.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 17:15:57 +01:00
Daira Hopwood 513e6ef89a Update README.rst.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 17:14:12 +01:00
Daira Hopwood 909b60e942 ZIP 307: add HTML and index entry.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 17:13:17 +01:00
Daira Hopwood e8e41470f8 zip-XXX-light-payment-detection.rst -> zip-0307.rst
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 17:12:04 +01:00
Daira Hopwood 1c5281f906 ZIP 307 updates.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-29 17:12:04 +01:00
Jack Grigg 8574f3df93 Block header validation 2020-06-29 17:12:04 +01:00
Jack Grigg 201609ad7e Expand note witness handling 2020-06-29 17:12:04 +01:00
Jack Grigg 8bfa5e60b4 Describe interaction changes when importing a seed 2020-06-29 17:12:04 +01:00
Jack Grigg 481436cc00 Reformat client-server interaction and block privacy sections 2020-06-29 17:12:04 +01:00
Jack Grigg 3c534067bf Client operations 2020-06-29 17:12:04 +01:00
George Tankersley 81fc443ec1 zipXXX: add description of API 2020-06-29 17:12:04 +01:00
George Tankersley e0ec6d5eff zipWIP: add diagrams and tables 2020-06-29 17:12:04 +01:00
George Tankersley 8f11e9dee1 zipWIP: light payment draft 2020-06-29 17:12:04 +01:00
Daira Hopwood 03932d2335 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-26 21:24:41 +01:00
Daira Hopwood a333649a4e Cosmetic change to the 2020.1.6 history entry. 2020-06-26 20:57:39 +01:00
Daira Hopwood 3ce9bd9823 Replace the block interval 32256 with the constant ZIP212GracePeriod.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-26 20:57:39 +01:00
Daira Hopwood 66acf80d18 Other cosmetic changes to the batch validation equations.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-26 20:57:39 +01:00
Daira Hopwood 45c2b616e2 Fix sign errors in the fixed-base terms of the batch validation equations in Appendices B.1 and B.3.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-26 20:57:39 +01:00
Daira Hopwood 3e98e63a6c For Sprout, add an explicit lead byte field to note plaintexts.
For Sapling, define note plaintext lead bytes as just bytes (so that decoding always succeeds and error handling is more explicit).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-26 20:47:32 +01:00
Daira Hopwood a3e4403f50 Delete some 'new' superscripts that only added notational clutter.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-26 18:58:17 +01:00
Daira Hopwood 3567634837 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-17 23:32:25 +01:00
Daira Hopwood af41efa40c Protocol spec: ZIP 212 changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-17 23:28:27 +01:00
Daira Hopwood eb222b4fe0 Remove some unused macros.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-17 23:01:13 +01:00
Daira Hopwood 8ccd4e656b Add an appendix on Ed25519 batch validation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-17 23:01:13 +01:00
Daira Hopwood 6e781c5905 Ed25519 updates. This corrects an error in the specification of valid public keys
(they are not checked against ExcludedPointEncodings), and includes changes for Canopy.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-17 23:01:13 +01:00
Daira Hopwood ec5eda1d9c Better positive square root symbol.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-17 23:01:13 +01:00
Daira Hopwood 43e4e71989 Corrections to ZIP references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-17 23:01:13 +01:00
Daira Hopwood 4f063850d5 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-17 23:01:13 +01:00
Daira Hopwood 1a24d6232c Consistently use "signing key" and "validating key" for signatures.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-17 23:01:13 +01:00
Daira Hopwood 1f0052d62e ZIP 214: changes in response to NCC's audit.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-17 23:01:13 +01:00
Daira Hopwood be9733228f Add rel="bookmark" to permalinks.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-15 14:04:25 +01:00
Daira Hopwood b9f87da380 Makefile: document perl and sed as dependencies.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-15 14:04:24 +01:00
Daira Hopwood f1a4631b9f protocol/Makefile: remove dependency on awk.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-15 14:04:24 +01:00
Daira Hopwood d0d4abac2e edithtml.sh: argument quoting.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-15 13:20:57 +01:00
Daira Hopwood 673be69531 style.css: improve font size of code in headings.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-15 13:20:57 +01:00
Daira Hopwood aaf0c04f79 edithtml.sh: make it work on macOS (by using perl instead of sed).
Also add permalink anchors to headers containing <code>...</code>.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-15 13:20:57 +01:00
Deirdre Connolly c367f32ab8
Update memo encoding description
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-06-09 11:25:04 -04:00
Deirdre Connolly 956bf5bcd9
Update owner email address
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-06-09 11:24:33 -04:00
Daira Hopwood 5ef8079d32 Correct references to ZIPs with changed titles.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-09 13:19:59 +01:00
Daira Hopwood fb8b435b4c ZIP 215: "validation criteria" -> "validity criteria".
(Validity is the condition of being valid, validation is what you do to check validity.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-09 13:14:23 +01:00
Daira Hopwood a93aa6d142 ZIP 251: fix an incorrect reference for ZIP 207.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-09 12:57:46 +01:00
Daira Hopwood cf70811274 Use "validate" rather than "verify" for signature validation in ZIPs.
"Validate" is also used for blocks and transactions, but not for proofs, commitments, or Merkle paths.

The same change will be made to the protocol specification in the next version.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-09 12:56:33 +01:00
Daira Hopwood 092e79e017 ZIP 215: use terminology consistent with the protocol spec for the Ed25519 curve.
("The Edwards form of Curve25519" is not a unique description; there are multiple
twisted Edwards curves birationally equivalent to Curve25519, but only one is
called Ed25519.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-05 16:37:29 +01:00
Daira Hopwood c6a925a30b ZIP 215: formatting.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-05 16:12:44 +01:00
Daira Hopwood 99a55bf3c9 ZIP 215: minor clarifications.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-05 16:10:28 +01:00
Daira Hopwood 0a773f1b50 ZIP 212: fix typo.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-05 15:55:07 +01:00
Daira Hopwood 1fafff988a ZIP 215: editorial and formatting changes; regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-05 15:54:52 +01:00
Henry de Valence e38d52c46f
[ZIP 215] Fix Ed25519 validation rules to allow batch verification (#355)
* First draft of Ed25519 validation rules.

* Add ZIP number.

* Clarify language.

* Remove Original-Authors when Owners has same value

Co-authored-by: Daira Hopwood <daira@jacaranda.org>

* Status: Active -> Proposed

Co-authored-by: Daira Hopwood <daira@jacaranda.org>

* Tidy words

Co-authored-by: Daira Hopwood <daira@jacaranda.org>

* Clarify libsodium divergence

Co-authored-by: Daira Hopwood <daira@jacaranda.org>

* Link to rfc8032

* Include references section

* Redo

* Math syntax

Co-authored-by: Daira Hopwood <daira@jacaranda.org>

* Update math syntax to match spec for byte-arrays

Co-authored-by: Daira Hopwood <daira@jacaranda.org>

* Define only the RFC words that are used

* Link to spec

* Fleshout title

* Deployment section

* Update zip-0215.rst

* Add linebreak

Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
2020-06-02 17:54:54 -04:00
Daira Hopwood 3d8b0363c7 Update activation heights, branch IDs, and references for Heartwood and Blossom.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-02 18:35:15 +01:00
Daira Hopwood 84f962e857 ZIPs 211, 212, 221: tools.ietf.org -> www.rfc-editor.org.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-02 18:35:15 +01:00
Daira Hopwood 564d7f630e Protocol spec: regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-02 18:35:15 +01:00
Daira Hopwood b9fb26f5d5 Protocol spec: fix undefined references for sprout.pdf.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-02 18:35:13 +01:00
Daira Hopwood e61e2460a0 Protocol spec: improve index; cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-02 18:35:13 +01:00
Daira Hopwood 9bac0682c3 Protocol spec: NU4 -> Canopy; ZIPs 211 and 212 are now published.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-02 18:35:13 +01:00
Daira Hopwood d53ab5fcbc Protocol spec: reference ZIP 173 instead of BIP 173.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-02 18:35:13 +01:00
Daira Hopwood dbe5b9a36e
Merge pull request #222 from ebfull/unlinkable-addrs
[ZIP 212] Allow recipient to derive Sapling ephemeral secret from note plaintext
2020-06-01 00:30:39 +01:00
Daira Hopwood b1bd2f49a7 ZIP 212: Daira's editorial changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-06-01 00:29:27 +01:00
Sean Bowe dbfdf2ea00 ZIP for "Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext" 2020-06-01 00:12:54 +01:00
Daira Hopwood da3eb7d5c7 ZIPs 250 and 221 to Implemented (zcashd).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 17:19:19 +01:00
Daira Hopwood 479a0f6bdf ZIPs 250 (for Heartwood) and 251, 207, 214 (for Canopy) to Proposed.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 17:16:56 +01:00
Daira Hopwood 39d236f76c ZIP 211: update Daira's email address and remove Sean's.
(Credits fields shouldn't have email addresses.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 17:11:29 +01:00
Daira Hopwood 65864c0bde ZIP 211 to Proposed.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 17:08:28 +01:00
Daira Hopwood 1be6f06c5e ZIP 211: fix links to other ZIPs, and update link to ECC blog.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 16:59:32 +01:00
Daira Hopwood 4f2d353bae Update index to add ZIP 211.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 16:51:46 +01:00
Daira Hopwood cbba3507f9 Some edits made to README.rst should have been made to README.template instead.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 16:51:19 +01:00
Daira Hopwood c9fd9f2bd5
Merge pull request #214 from daira/disable-sprout-outputs
[ZIP 211] Disabling Addition of New Value to the Sprout Value Pool
2020-05-30 16:45:40 +01:00
Daira Hopwood 9f3548602f ZIP 211: add HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 16:42:33 +01:00
Daira Hopwood ed85d1ff39 ZIP 211: remove unused reference to the protocol spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 16:38:36 +01:00
Daira Hopwood 0a57e268ca ZIP 211: Update reference to protocol spec.
Signed-off-by: Daira Hopwood <daira@katava.local>
2020-05-30 16:35:53 +01:00
Daira Hopwood 330a1d5e3f ZIP 211: deployment and reference implementation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 16:35:53 +01:00
Daira Hopwood 3cfc9660d4 ZIP 211: typo fix and clarification.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 16:35:53 +01:00
Daira Hopwood 21c556e4a2 ZIP 211: More accurate title.
Signed-off-by: Daira Hopwood <daira@katava.local>
2020-05-30 16:35:53 +01:00
Daira Hopwood 73b3ccb65c ZIP 211: Address review comments and correct the list of used RFC 2119 keywords.
Clarify that supporting Sprout outputs is already OPTIONAL.

Signed-off-by: Daira Hopwood <daira@katava.local>
2020-05-30 16:33:22 +01:00
Daira Hopwood dfed189b26 Move ZIP 211 out of drafts directory.
Signed-off-by: Daira Hopwood <daira@katava.local>
2020-05-30 16:33:22 +01:00
Daira Hopwood cd60f6891a Just require vpub_old = 0.
Signed-off-by: Daira Hopwood <daira@katava.local>
2020-05-30 16:31:17 +01:00
Daira Hopwood 2465eb6fd8 Draft ZIP "Disabling Sprout Outputs": address review comments and correct rST errors.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 16:31:17 +01:00
Daira Hopwood 65443520b5 [ZIP 211] Add Sean to credits.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 16:31:17 +01:00
Daira Hopwood fe37d147c3 Add draft ZIP to disable Sprout outputs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-30 16:31:17 +01:00
Daira Hopwood c29c57c8e7
Merge pull request #370 from acityinohio/patch-1
changes Foundation ZIP editor
2020-05-27 17:41:20 +01:00
Josh Cincinnati 38da0790b8 ZIP 0: changes Foundation ZIP editor.
Deirdre Connolly will now be representing the Foundation as ZIP Editor. Thanks to George for all his previous input!

Author: Josh Cincinnati <acityinohio@users.noreply.github.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-27 17:38:49 +01:00
Daira Hopwood e4d9d2cace Regenerate PDFs. Note that nufour.pdf is now canopy.pdf.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-27 17:28:06 +01:00
Daira Hopwood 66ba1aad3e Network Upgrade 4 is now called Canopy.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-27 17:24:29 +01:00
Daira Hopwood 092e6092ef Remove the claim that Discrete Logarithm Independence is stronger than collision resistance of GroupHash.
(That's not clearly true, and it's irrelevant.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-27 17:20:27 +01:00
Daira Hopwood 8d19a94716 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-27 17:18:41 +01:00
Daira Hopwood c8e08b0e96 Improve description of key structures taking into account ZIP 32. fixes #187
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-27 15:53:09 +01:00
Daira Hopwood 3ce628ab73 edithtml.sh: make tests portable to any correct POSIX shell.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-27 15:29:01 +01:00
Alfredo Garcia 7372acfd64
Create zip-0400.rst 2020-05-26 19:57:15 -03:00
Daira Hopwood 441d66dd3d Fix GitHub COPYING link again.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-26 23:25:20 +01:00
Daira Hopwood 2425a5bf7a Update README.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-26 23:21:50 +01:00
Daira Hopwood 62a1d5c103 Update ZIPs 207, 214, 251, and 1014 to use Canopy name for NU4.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-26 23:06:08 +01:00
Daira Hopwood 66a41077ca Support writing ZIPs in Markdown, generating the HTML using pandoc.
This has some minor deficiencies in math support and formatting of references.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-26 23:06:08 +01:00
Daira Hopwood 198241c077
Merge pull request #371 from zcash/spec-latex-portability
Protocol spec: improve LaTeX portability
2020-05-26 16:00:42 +01:00
Daira Hopwood 456c899627 Protocol spec: improve LaTeX portability.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-12 17:58:42 +01:00
Daira Hopwood 2af6223455 Fix COPYING link in README.rst (for GitHub version).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-12 16:00:09 +01:00
Daira Hopwood dd31106723 Add COPYING.html.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-12 15:57:01 +01:00
Daira Hopwood f856210617 COPYING -> COPYING.rst
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-12 15:55:46 +01:00
Daira Hopwood 92349aa776 Makefile: tweak title generation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-12 15:55:06 +01:00
Daira Hopwood d8951f74f5 Makefile: python3 transition.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-12 15:54:17 +01:00
Daira Hopwood a3f0295cb6 ZIP 32: formatting.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-05-01 10:16:18 +01:00
Daira Hopwood 9c0bf830e5 style.css: portability.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-30 13:21:16 +01:00
Daira Hopwood 95240be273 protocol/README.rst updates.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-27 15:57:30 +01:00
Daira Hopwood 681fbec905 Upgrade MathJax to v3. fixes #353
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 18:22:08 +01:00
Daira Hopwood 36c4eb4dae More math css tweaking.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 18:06:26 +01:00
Daira Hopwood 228108ea6b style.css: make the math blend in better with the surrounding text.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 17:44:54 +01:00
Daira Hopwood 894b839502 style.css: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 17:44:18 +01:00
Daira Hopwood 1b56c887db Upgrade to MathJax 2.7.7.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 17:26:27 +01:00
Daira Hopwood 69ef14ce8a ZIP 32: add more line break opportunities in math.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 14:37:07 +01:00
Daira Hopwood c79a0cff92 Upgrade to MathJax 2.7.5.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 14:36:04 +01:00
Daira Hopwood 882aeb9aa5 Makefile: HTML generation should depend on edithtml.sh.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 14:35:00 +01:00
Daira Hopwood 6c6843154d ZIP 32: use :math: markup for better rendering.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 11:41:16 +01:00
Daira Hopwood b9968a3bca ZIP 250: Update Heartwood testnet activation height and versions.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 01:38:37 +01:00
Daira Hopwood f0ba5495d5 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 01:35:48 +01:00
Daira Hopwood ca802490a5 Correct a wording error transposing transparent inputs and transparent outputs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-22 01:32:26 +01:00
Daira Hopwood df126fb35b
Merge pull request #332 from daira/zip-0251
[ZIPs 207, 214, 251] Consensus ZIPs for Zcash Development Fund
2020-04-21 23:25:23 +01:00
Daira Hopwood 9f8ddba41e .gitignore: add another pattern for nano save files.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-14 13:10:23 +01:00
Daira Hopwood 3fad940acf Dockerfile: entrypoint should be "make all", to also make the protocol spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-14 13:09:42 +01:00
Daira Hopwood 283480c802 Makefile: rebuild index if files have been deleted.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-14 13:08:16 +01:00
Daira Hopwood 604532cca1 Makefile: add dot to filename of .Makefile.uptodate
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-14 13:06:08 +01:00
Daira Hopwood 2c37d28a82 ZIP 200: further clarification.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-14 09:23:00 +01:00
Daira Hopwood ae834f371e ZIP 200: clarify that following a pre-upgrade branch can normally only happen if EoS halt is bypassed.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-14 09:19:28 +01:00
Daira Hopwood 79b932e841 ZIP 200: rename "auto-senescence" to "End-of-Service halt".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-14 09:10:55 +01:00
Daira Hopwood 3693c9edd6 ZIP 251: update versions of zcashd that are planned to support NU4.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-11 20:16:46 +01:00
Daira Hopwood ec7b435480 ZIPs 208, 250 and 251: keep `NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD` the same
in terms of blocks, but it represents 1.5 days for the Heartwood upgrade onward.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 5182e212d0 ZIP 207: improvements to the pseudocode.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 27accd4cc3 ZIP 214: allow addresses within a funding stream to be repeated.
Remove definitions of unused RFC 2119 keywords.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood d3784f64c4 ZIP 214: blockchains -> block chains.
Co-Authored-By: str4d <thestr4d@gmail.com>
2020-04-02 14:49:39 +01:00
Daira Hopwood 5fa56e83bf Protocol spec: add references for the NU4 upgrade.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood edc43904c9 Protocol spec: clarify note about hashFinalSaplingRoot/hashLightClientRoot.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 9ac5984f54 ZIP 207: reference fix and HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 9ce78b04f5 ZIP 207: be more explicit about which consensus rule is no longer active after NU4 activation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 1ec5ac7281 ZIP 207: in the example implementation, ensure that multiplication by the numerator won't overflow.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood b70ba3406d ZIP 207: use math markup.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood c9ae7af581 ZIP 207: simplify wording about using a proportion of block subsidy.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 3cca1cc108 Scrunch pre and math blocks a bit more.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 1f77e08d4f "branch" -> "consensus branch"
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 0bd85486fe ZIP 214: add rationale section.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 4fd8f06bc1 ZIP 214: change wording to reflect the fact that ZEC != TAZ.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 0a26121691 ZIP 214: state explicitly that start height is inclusive and end height is exclusive.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 624ce6d6b0 ZIP 207: add definitions of "branch" and "network upgrade".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood e73e517fbf ZIP 214 is applicable only to Zcash.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 83abb5f5d3 ZIP 207: s/founders reward/Founders' Reward/
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 45833a1588 ZIP 251: remove trailing whitespace.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 0fdd5de149 ZIP 214: Update version in Protocol Specification reference.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 272f085f8c ZIP 251: Add wording about transaction digest algorithm and reference ZIP 243.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 6526ebb088 Add ZIPs 214 and 251.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 811fb7e0ce Reintroduce ZIP 207.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
Daira Hopwood 3fc7a9a2b8 ZIP 207: line wrapping (to reduce the subsequent diff).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-02 14:49:39 +01:00
str4d 829060aad6
Merge pull request #340 from daira/zip-0221-activation-fix
ZIP 221: fix problem at activation block
2020-04-03 00:33:08 +13:00
Daira Hopwood 711a88b545 ZIP 221: set hashLightClientRoot to all-zero in the block that activates the ZIP.
Also don't assume activation at Heartwood in the main specification, to improve
applicability to non-Zcash chains.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-01 11:40:21 +01:00
Daira Hopwood bbe73d0893 ZIP 221: fix typo.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-04-01 11:36:29 +01:00
Daira Hopwood 6cce68e02a ZIP 211 pseudocode: correct missing consensusBranchId argument in call to H.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-31 13:54:41 +01:00
Daira Hopwood 577a5048f0 Regenerate ZIP index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-26 22:16:51 +00:00
Daira Hopwood ff9c8cf7cd
Merge pull request #336 from daira/zip-0310
[ZIP 310] Security Properties of Sapling Viewing Keys
2020-03-26 22:13:20 +00:00
Daira Hopwood 2e896d322c ZIP 310: add Abstract and Motivation. Resolve TODO re: relation between tallies and spending keys.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-24 23:39:53 +00:00
Daira Hopwood 9a9b7f1a44 Add draft ZIP 310.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-24 23:15:05 +00:00
str4d 981f3b20de
Merge pull request #335 from daira/zip-0221-daa-caveat
ZIP 221: strengthen caveat about FlyClient security in chains with rapid difficulty adjustment, and change pseudocode so that CONSENSUS_BRANCH_ID doesn't look like a constant
2020-03-25 12:12:11 +13:00
Daira Hopwood e0c2123b05 ZIP 221: change the pseudocode so that CONSENSUS_BRANCH_ID doesn't look as though it's a constant.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-24 14:53:50 +00:00
Daira Hopwood 7196ab330c ZIP 221: update the discussion of difficulty adjustment in security considerations, per @str4d's review.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-24 14:52:44 +00:00
Daira Hopwood 238d00275e ZIP 221: strengthen caveat about FlyClient security in chains with rapid difficulty adjustment.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-23 16:31:39 +00:00
Daira Hopwood fbf0575252 ZIP 213: cosmetic wording change to match the protocol spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:32:49 +00:00
Daira Hopwood a8adb58654 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:32:29 +00:00
Daira Hopwood 7fd9cc9f73 Protocol spec: add page break before appendices.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:28:41 +00:00
Daira Hopwood 4b08221dd2 Protocol spec: wording clarification about motivations for Equihash.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:10:30 +00:00
Daira Hopwood 32cb319cc7 Protocol spec: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:10:30 +00:00
Daira Hopwood a593018417 Protocol spec: fix the Ed25519 specification mess.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:10:30 +00:00
Daira Hopwood 161c9d05f8 Protocol spec: \hexints and \hexarray macros.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:10:30 +00:00
Daira Hopwood 9d7f700c35 Protocol spec: LaTeX cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:10:29 +00:00
Daira Hopwood 2fefae9e47 Protocol spec: RFC references to www.rfc-editor.org, not tools.ietf.org.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:10:29 +00:00
Daira Hopwood 32a0709ffc Protocol spec: clarify that the transaction and header encodings should be read in the context of consensus rules in those sections.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:10:29 +00:00
Daira Hopwood 0dc531d04c Protocol spec: add Heartwood consensus rules.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:10:29 +00:00
Daira Hopwood 731ddfd9f6 Protocol spec: colour-code transaction fields that were added in Sapling.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:06:52 +00:00
Daira Hopwood 892bdfde1b Protocol spec: colour-code "pre-X" consensus rule markers according to X (since that is when the rule changed).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:06:52 +00:00
Daira Hopwood ef78d9d94c Protocol spec: make Heartwood colour a darker orange.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:06:52 +00:00
Daira Hopwood 69562802cf Protocol spec: add macro and Makefile support for NU4.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:06:52 +00:00
Daira Hopwood 70cc1347f6 protocol/Makefile: make the Heartwood spec the default.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 16:06:52 +00:00
Daira Hopwood afae0efdb8 protocol/Makefile: silence noise about index entries.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 15:41:18 +00:00
Daira Hopwood 37277c3ef7 protocol/Makefile: remove unneeded files for `make clean` that were only generated by pvc targets.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 15:41:18 +00:00
Daira Hopwood 19bfc96a0c protocol/Makefile: remove pvc* targets.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 15:41:18 +00:00
Daira Hopwood e87feda358 Protocol spec: add \Makefile macro.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-20 15:11:00 +00:00
Daira Hopwood 60485864f9 ZIP 202: "version group id" -> "version group ID"
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-17 15:15:24 +00:00
Daira Hopwood 5edc36cff1 ZIP 221: update ZIP links in references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-17 14:26:38 +00:00
str4d 702cfc9d80
Merge pull request #333 from daira/zip-0221-upgrade-ambiguity
ZIP 221: resolve ambiguities for the first block of a network upgrade
2020-03-17 14:29:19 +13:00
Daira Hopwood 03dac17d2a ZIP 221: resolve ambiguities for the first block of a network upgrade.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-16 21:36:05 +00:00
Daira Hopwood 62e4a4228d "branch" -> "consensus branch"
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-16 21:02:36 +00:00
str4d b2c36ca621
Merge pull request #331 from daira/zip-0250
Add ZIP 250: Deployment of the Heartwood Network Upgrade.
2020-03-11 11:27:35 +13:00
Daira Hopwood 9641e2fc0b ZIP 250: Add wording about transaction digest algorithm and reference ZIP 243.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 22:26:20 +00:00
Daira Hopwood 6a03fed583 ZIP 250: Assign consensus branch ID for Heartwood.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 22:13:57 +00:00
Daira Hopwood 9dfbb58dce ZIP 0: fix an error.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 19:36:42 +00:00
Daira Hopwood 86dbc09fc3 ZIP 221: update note about uint32 time overflow.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 19:16:55 +00:00
Daira Hopwood fd151499d5 ZIPs 205 and 206: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 17:51:50 +00:00
Daira Hopwood 94f8cdcae5 Add ZIP 250: Deployment of the Heartwood Network Upgrade.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 17:20:18 +00:00
Daira Hopwood 1aa17db44e Update .gitignore to ignore `Makefile.uptodate`.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 17:01:13 +00:00
Daira Hopwood 3c91090657 README: update the title of ZIP 221.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 17:00:37 +00:00
Daira Hopwood 42cdefaf35 README: update link to ZIP 221 and NU3 schedule.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 16:57:25 +00:00
Daira Hopwood 9aa520bbb3 ZIP 221: more cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 16:54:14 +00:00
Daira Hopwood 053e86f87f ZIP 221: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 16:50:39 +00:00
Daira Hopwood a9ce93846a Rebuild HTML. (This should be a no-op; my version of rst2html5 changed.)
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 16:43:19 +00:00
Daira Hopwood 2093c1c2e9 ZIP 1011: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 16:43:19 +00:00
Daira Hopwood c4457ae78f ZIP 221: Document that nTime fields will overflow on 2106-02-07.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 16:43:19 +00:00
Daira Hopwood ef987f67b2 Ensure that changing a Makefile rebuilds everything on the next run.
Also change the default target for protocol/Makefile to not build unconditionally.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 16:43:19 +00:00
Daira Hopwood ab4898c500
Merge pull request #220 from therealyingtong/master
[ZIP 221] FlyClient - Consensus-Layer Changes
2020-03-10 16:16:31 +00:00
Daira Hopwood 6d471d6cff ZIP 221 to Proposed.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 16:01:14 +00:00
Daira Hopwood 564ef9461a ZIP 221: correct Ying Tong Lai's name.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 16:00:05 +00:00
Daira Hopwood b25ab9caa1 ZIP 221: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 15:59:38 +00:00
Jack Grigg 9b87a3ef00 Minor fixes 2020-03-10 13:14:29 +00:00
Jack Grigg 1af5d1a076 Cosmetic changes
Co-Authored-By: Daira Hopwood <daira@jacaranda.org>
2020-03-10 13:14:29 +00:00
Jack Grigg 5e4a71e367 Clean up ZIP metadata and abstract 2020-03-10 13:14:29 +00:00
Jack Grigg 7b98f97f5d Rework paragraph to eliminate incomplete sentence 2020-03-10 13:14:29 +00:00
Jack Grigg f503789adf Clarify explanations in Background section 2020-03-10 13:14:29 +00:00
Jack Grigg bf159d1221 Use "altitude" to measure peaks instead of "height"
"Height" is used elsewhere in the ZIP to refer to block heights.
2020-03-10 13:14:29 +00:00
Jack Grigg 9eee0edd0c Remove emails for Original-Authors
People in the Original-Authors field are not contact points for a ZIP.
2020-03-10 13:14:29 +00:00
Jack Grigg 1ad94f26c7 Remove external figures
Figures should be stored in a subdirectory, but the source files for the
figures have not been provided, and one of the figures contains an error.
2020-03-10 13:14:29 +00:00
Jack Grigg d5e033bba9 Specify block header consensus rules, remove version change 2020-03-10 13:14:29 +00:00
Jack Grigg 069fa9c179 Fix typo in Background 2020-03-10 13:14:29 +00:00
Jack Grigg 5fd74c8a14 Commit to number of Sapling transactions instead of shielded transactions 2020-03-10 13:14:29 +00:00
Jack Grigg c8193992d4 Clarify calculation of block ranges 2020-03-10 13:14:29 +00:00
Jack Grigg 6d64ce0c87 Fix vulnerability in get_peaks() pseudocode
This addresses finding NCC-1908_Zcash-002.
2020-03-10 13:14:29 +00:00
Jack Grigg 5b411837f4 Fix vulnerability in append() pseudocode.
This addresses finding NCC-1908_Zcash-001.
2020-03-10 13:14:29 +00:00
Jack Grigg a627029132 Fix bugs in delete() pseudocode 2020-03-10 13:14:29 +00:00
Jack Grigg 1ef1388501 Move bag_peaks() pseudocode into the first block it is used in 2020-03-10 13:14:29 +00:00
Jack Grigg be5dd9c66e Fix bugs in make_parent() pseudocode 2020-03-10 13:14:29 +00:00
Jack Grigg a239b8e3c9 Consistent BLAKE2b capitalization 2020-03-10 13:14:29 +00:00
Jack Grigg f04f47f251 Fix reference to ZIP 307 2020-03-10 13:14:29 +00:00
Jack Grigg 630a4160f2 Explicitly note that wrapping addition is fine for nSubTreeTotalWork 2020-03-10 13:14:29 +00:00
Jack Grigg 893d06ab9b Move Security and Privacy Considerations to below Rationale 2020-03-10 13:14:29 +00:00
Jack Grigg b5b545f088 Use header characters consistent with other ZIPs 2020-03-10 13:14:29 +00:00
Jack Grigg 752f2c2c01 Use variable names in pseudcode that match the specification fields
The pseudocode is Python-esque, so snake_case makes sense for other
variables, but as the pseudocode is intended for specification clarity
it should defer to the specification's naming scheme.
2020-03-10 13:14:29 +00:00
Jack Grigg 7032b92143 Reference block work definition in the protocol spec 2020-03-10 13:14:29 +00:00
Jack Grigg 5aa4db445c Fix typographical errors 2020-03-10 13:14:29 +00:00
Jack Grigg f569d2863d Spell Zcash correctly 2020-03-10 13:14:29 +00:00
Jack Grigg 609a15c8e4 Wrap all lines 2020-03-10 13:14:29 +00:00
Jack Grigg 14709c4fa2 Transfer ownership of ZIP 221 to Jack Grigg 2020-03-10 13:14:29 +00:00
ying tong 0ac23578de update append pseudocode (fixes by @prestwich) 2020-03-10 13:14:29 +00:00
James Prestwich 8f3339dfc8 remove typo 2020-03-10 13:14:29 +00:00
James Prestwich d159df6791 rename zip-0211.rst to zip-0221.rst. Change type of nSubTreeTotalWork to uint256 from CompactSize uint 2020-03-10 13:14:29 +00:00
therealyingtong 626de177c7 rename zip-0311.rst to zip-0211.rst 2020-03-10 13:14:29 +00:00
therealyingtong f5d399ba46 include detailed spec (joint work with James Prestwich and Georgios Konstantopoulos 2020-03-10 13:14:29 +00:00
Ying Tong cccbcad5d6 Add files via upload 2020-03-10 13:14:29 +00:00
Ying Tong 88e643e805 Create zip-0311.rst 2020-03-10 13:14:29 +00:00
Daira Hopwood f724bdef18 README: clarify how to start contributing.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 13:06:13 +00:00
Daira Hopwood 0449b3583e Makefile: remove duplication and refine the rule for considering README.rst out-of-date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-10 13:05:31 +00:00
Daira Hopwood 5195bd4ab1 Move ZIP 213 to Implemented (zcashd).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-03-06 11:18:13 +00:00
Daira Hopwood d44cf352ba ZIP 213: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-29 16:26:03 +00:00
Daira Hopwood 88f4db3c6a ZIP 213: update HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-29 16:23:54 +00:00
Daira Hopwood 09b3f6955c Link to https://www.rfc-editor.org/rfc/rfcXXXX.html for RFCs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-29 16:00:39 +00:00
str4d 2575a8b805
Merge pull request #325 from str4d/zip-213-clarify-rationale
ZIP 213: Clarify rationale for no shielded coinbase maturity
2020-02-28 17:38:08 +13:00
Daira Hopwood 29e39136ca ZIP 173: fix missing Status field.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-27 23:59:00 +00:00
Daira Hopwood e9aeb94611
Merge pull request #207 from daira/zip-0173
[ZIP 173] Bech32 Format
2020-02-27 23:51:41 +00:00
Daira Hopwood cd7558ab84 Add ZIP 173.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-27 23:50:23 +00:00
Daira Hopwood ac05aa3bf6 Add SVG source for section-anchor.png.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-27 23:13:44 +00:00
Daira Hopwood 9838693599 Obsolete ZIPs 1001 to 1013 inclusive, and regenerate ZIP index and HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-27 17:54:18 +00:00
Daira Hopwood 4aea56d915
Merge pull request #324 from ZcashFoundation/ecc-zf-zip-1014-changes
Mutually agreed modifications to zip-1014
2020-02-27 17:46:11 +00:00
Josh Cincinnati 1a0d105a2c
Merge pull request #1 from daira/ecc-zf-zip-1014-changes
Editorial changes to Dev Fund ZIP
2020-02-26 16:26:18 -05:00
Daira Hopwood c040121fc1 ZIP 1014 Status to Proposed.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-26 19:58:13 +00:00
Daira Hopwood 4392f80542 ZIP 1014: delete "and any other pertinent governance processes" from the description of process for which
it is desirable to develop "robust means of decentralized community voting and governance".

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-26 19:58:13 +00:00
Daira Hopwood 12b3f0e25f ZIP 1014: add "(current or future)" to other obligations under U.S. IRS 501(c)(3).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-26 19:58:13 +00:00
Daira Hopwood de48022622 ZIP 1014: include the Zcash Trademark Donation and License Agreement as part of the definition of "network upgrade".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-26 19:58:09 +00:00
Daira Hopwood c3dad3f1ed ZIP 1014: wording clarification. 20% of the block subsidy is allocated from *each* block.
(The previous wording could have allowed an interpretation of any allocation that sums to 20%
over four years, which was not the intent.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-26 19:58:03 +00:00
Daira Hopwood a27f08ab90 Add alt="" for anchor image, since it is "decorative" in the sense of <https://www.w3.org/WAI/tutorials/images/decorative/>.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-25 17:05:50 +00:00
Daira Hopwood a6567d6377 Regenerate HTML with section anchors.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-25 14:59:43 +00:00
Daira Hopwood ef117e9874 Add section anchors.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-25 14:59:08 +00:00
Daira Hopwood 36cf64abc3 edithtml.sh: replace MathJax URL.
Regenerate ZIP 1011 HTML.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-25 12:44:22 +00:00
Daira Hopwood a0aa25c407 Factor out HTML editing from Makefile into edithtml.sh
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-25 12:42:17 +00:00
Jack Grigg 9e45264d9d ZIP 213: Clarify rationale for no shielded coinbase maturity 2020-02-24 12:21:21 +00:00
Daira Hopwood 51224cbca1 ZIP 1014: change title to disambiguate from ZIP 1012.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-20 00:48:50 +00:00
Daira Hopwood dbd3001774 ZIP 1014: add "for example" to sentence about ecosystem growth.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-20 00:48:50 +00:00
Daira Hopwood 573ea33397 ZIP 1014: minor wording fixes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-20 00:48:50 +00:00
Daira Hopwood 36efce62ac ZIP 1014: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-20 00:48:50 +00:00
Daira Hopwood e2de904356 ZIP 1014: add ZIP numbers to references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-20 00:48:47 +00:00
Daira Hopwood 5811fadeef ZIP 1014: terminology.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-20 00:47:56 +00:00
Daira Hopwood 8cfeb65925 Obligations under 501(c)(3) are not only reporting requirements.
This responds to one part of @tromer's point at
https://forum.zcashcommunity.com/t/final-text-of-zip-1014/36002/3

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-15 12:50:00 +00:00
Daira Hopwood f7229384d9 Clear up a stale reference to "both of these processes"
(originally one of the processes referred to was the Community Panel's
power to change the Funding Cap, which no longer exists).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-15 03:31:57 +00:00
Daira Hopwood d3d52c75fe Resolve a wording ambiguity: Major Grant funding decisions are intended to be subject to veto if they violate any U.S. law,
not just law relating to the ZF's reporting requirements.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-15 03:30:31 +00:00
Daira Hopwood 7448bba530 Rename the "ZF-MG" slice to "MG", and the "ZF-GU" slice to "ZF".
Clearer, and reflects common use in the forum and Helios poll.

Based on 1f851eb1c3

Co-authored-by: Eran Tromer <eran@tromer.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-15 03:28:45 +00:00
Josh Cincinnati 4f5f2aa4c3 mutually agreed modifications to zip-1014 2020-02-14 16:21:13 -07:00
Daira Hopwood 206ff55aff
Merge pull request #322 from daira/spec-resolve-memo-conflict
Resolve conflicts in the specification of memo fields by deferring to ZIP 302
2020-02-13 14:34:34 +00:00
Daira Hopwood 2e5aad23a1 Regenerate PDFs for protocol spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-13 14:18:01 +00:00
Daira Hopwood 2e26bb072d Resolve conflicts in the specification of memo fields by deferring to ZIP 302.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-13 14:13:10 +00:00
Daira Hopwood 35d34967ee Add link to protocol spec on index page.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-07 11:08:05 +00:00
Daira Hopwood 258c3729de
Merge pull request #320 from daira/spec-timejacking-fix
Protocol Specification version 2020.1.0
2020-02-07 11:02:35 +00:00
Daira Hopwood 7af527675b Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-07 10:56:58 +00:00
Daira Hopwood 849d9435ae Use the term monomorphism for an injective homomorphism, in the context of a "signature scheme with key monomorphism".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-06 23:03:58 +00:00
Daira Hopwood 0d582758dd Specify a retrospective soft fork implemented in zcashd v2.1.1-1 that limits the nTime field
of a block relative to its median-time-past.
Correct the definition of median-time-past for the first PoWMedianBlockSpan blocks in a chain.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-06 22:40:00 +00:00
Daira Hopwood ed6baf0fef Change History entry.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-06 22:38:15 +00:00
Daira Hopwood 0a3ef33991 Update incremental Merkle tree diagram.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-02 16:46:34 +00:00
Daira Hopwood 62251dc54f Change 'Payment address' to 'Shielded payment address' in key components diagrams.
Also remove obsolete key_components.{odg,pdf} files.

Co-Authored-By: Za Wilcox <zancas@protonmail.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-02 16:45:47 +00:00
Daira Hopwood 20d506168b Add Acknowledgements to Henry de Valance, Deirdre Connolly, Chelsea Komlo, and Trail of Bits.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-02 15:10:19 +00:00
Daira Hopwood 8a6dc9c9fe Wording tweak: replace "it" with "the note".
I was able to read this "it" as a reference to "the transaction".
closes #174

Author: Za Wilgustus <zancas@protonmail.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-02 15:10:03 +00:00
Daira Hopwood 3e7d58efe7 ZIP 208: minor wording improvements, make Final.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-02-02 14:46:40 +00:00
Daira Hopwood 5651875ca8 ZIP 206: minor wording improvements; make Final.
MIN_PEER_PROTO_VERSION is 170002 for Blossom nodes, not 170007.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-31 13:50:38 +00:00
Daira Hopwood 168b4e49ab Reference the published ZIP 213 as an NU3 ZIP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-30 17:25:51 +00:00
Daira Hopwood 70596553a2 Regenerate index and HTML to add ZIP 213.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-30 17:21:23 +00:00
Daira Hopwood 124476baa4
Merge pull request #217 from str4d/zip-str4d-shielded-coinbase
[ZIP 213] Shielded Coinbase
2020-01-30 17:19:36 +00:00
Jack Grigg d388e80a53 Include more precise consensus rule wording matching the protocol spec 2020-01-28 17:53:27 +00:00
Jack Grigg 4781183ab9 Add a note about post-quantum privacy to ZIP 213 privacy considerations 2020-01-27 20:32:53 +00:00
Jack Grigg 84517efcd1 Remove unused term 2020-01-27 20:26:59 +00:00
Jack Grigg 84bbeaaed4 Clarify that coinbase spending restrictions only apply to transparent outputs 2020-01-27 20:23:23 +00:00
Jack Grigg 83e8313045 Add link to reference implementation of ZIP 213 2020-01-27 20:21:05 +00:00
Jack Grigg c7d1afe2ab Reference Heartwood in ZIP 213 2020-01-27 20:20:39 +00:00
Jack Grigg 5d9b1b747d Clarify specification of decryption with all-zero ovk 2020-01-27 20:18:44 +00:00
Jack Grigg b09b53bea1 Remove "Interaction with funding streams"
ZIP 207 will not be deployed before this ZIP, so interactions should be
handled there.
2020-01-27 20:15:58 +00:00
copernicus-mogley 8e80fff644 Fix definition list and <pre> styles 2020-01-24 16:23:03 +00:00
Daira Hopwood 0823b3f85a
Merge pull request #317 from zcash/css-2020-01
Style improvements
2020-01-24 15:45:39 +00:00
Daira Hopwood c0631d6488 Regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-24 15:36:47 +00:00
Daira Hopwood 6d8c63916f ZIP 0: replace nonbreaking spaces with ordinary spaces.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-24 15:33:58 +00:00
Daira Hopwood 119b7c8ca1 Try to improve consistency of whitespace behaviour for sed on macOS.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-24 15:33:58 +00:00
copernicus-mogley 45cf08e21d Correct padding on index of zips table top row 2020-01-24 15:33:58 +00:00
copernicus-mogley 9e203fca7e Adjust list item margins 2020-01-24 15:33:58 +00:00
copernicus-mogley 4311620e41 Match footnote font size to body 2020-01-24 15:33:58 +00:00
copernicus-mogley 9cbd29042a Add font-size to body for rem reference 2020-01-24 15:33:58 +00:00
copernicus-mogley e609e7be46 Make <pre> font-size consistent between browsers @ 15px 2020-01-24 15:33:58 +00:00
copernicus-mogley 60d4e8c8b9 Remove vertical scroll bar on maths 2020-01-24 15:33:58 +00:00
copernicus-mogley 37351710da Add 1ex margin-bottom to lists and table 2020-01-24 15:33:58 +00:00
copernicus-mogley 36b707451e Font size <pre> and reference table margin styles per Daira 2020-01-24 15:33:58 +00:00
copernicus-mogley e1fde7fda1 Make table overflow-x scroll only on small viewports and not footnote tables at all 2020-01-24 15:33:58 +00:00
copernicus-mogley 6fe1065ffd Remove extra border from tables 2020-01-24 15:33:58 +00:00
Daira Hopwood 2b62e7574b Move custom stylesheet to css/style.css
Author: copernicus-mogley <ryan@z.cash>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-24 15:33:40 +00:00
copernicus-mogley 25ada6f826 Update Makefile and makeindex.sh to run without errors on MacOS 2020-01-24 15:30:53 +00:00
copernicus-mogley d724d9e6e3 Remove side padding on span.math 2020-01-24 15:30:53 +00:00
copernicus-mogley c87ac8a92a Add margin around blockquote, except top 2020-01-24 15:30:53 +00:00
copernicus-mogley f0a898c6e3 Make math scroll when it's too wide for the viewport 2020-01-24 15:30:53 +00:00
copernicus-mogley 3a0c82234f Don't apply <pre> styles to <code> tags 2020-01-24 15:30:53 +00:00
copernicus-mogley b506217b2b Remove unnecessary stylesheet from second instance and replace with viewport meta tag 2020-01-24 15:30:53 +00:00
copernicus-mogley 0c0d2f04e2 Add viewport meta tag for responsive display 2020-01-24 15:30:53 +00:00
copernicus-mogley fb8dafb3d8 Remove commented-out CSS, unnessary css files and stylesheet tag 2020-01-24 15:30:53 +00:00
copernicus-mogley c29e582944 Style touchups per Daira's notes 2020-01-24 15:30:53 +00:00
copernicus-mogley fc0cb8af7c Fix pre styles 2020-01-24 15:30:53 +00:00
copernicus-mogley 2c84f207dc Line break <pre> and add element scroll bar on overflow-x 2020-01-24 15:30:53 +00:00
copernicus-mogley 72a8e7a802 Add content section with for xxl displays 2020-01-24 15:30:53 +00:00
copernicus-mogley 09091814b5 Add responsive widths to content section 2020-01-24 15:30:53 +00:00
copernicus-mogley 25d295ea38 Table styles 2020-01-24 15:30:53 +00:00
copernicus-mogley 694b4948e3 First pass at styles 2020-01-24 15:30:53 +00:00
Daira Hopwood feca6f4b26 ZIP 31: child ask_i and nsk_i keys are intended to be taken modulo r_J.
Technically the ZIP was already correct because I_{ask}, I_{nsk}, ask_{par}, and nsk_{par} are all F_{r_J} elements,
but that assumes a lot of familiarity with the spec notation.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-21 13:32:30 +00:00
Daira Hopwood c01c5defb1 ZIP 308: clarification about notes eligible for migration.
Co-Authored-By: Simon Liu <simon@bitcartel.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-20 16:10:22 +00:00
Daira Hopwood 20ebcf4a27 Update ZIPs 208 and 308 to show the interaction between Blossom and Sprout->Sapling migration.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-20 16:08:12 +00:00
Daira Hopwood 6674a859d1
Merge pull request #315 from daira/rm-audited
ZIP 1014: remove "audited" from "Annual audited financial report"
2020-01-12 17:57:45 +00:00
Daira Hopwood 242148b92d ZIP 1014: remove "audited" from "Annual audited financial report". fixes #313
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-12 00:42:59 +00:00
Daira Hopwood 775d718d87
Merge pull request #314 from daira/rename-funding-target-to-cap
ZIP 1014: rename Funding Target to Monthly Funding Cap
2020-01-12 00:33:45 +00:00
Daira Hopwood 136835232a ZIP 1014: Funding Cap -> Monthly Funding Cap.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-12 00:23:28 +00:00
Daira Hopwood 803aea13f3 ZIP 1014: rename Funding Target to Funding Cap, as suggested by @aristarchus.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-11 03:10:11 +00:00
George Tankersley 9dc6913989 zip-1014: clarify review of indefinite duration grants
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-08 15:51:50 +00:00
Daira Hopwood f7806f03c4 Set theme jekyll-theme-tactile 2020-01-07 19:21:45 +00:00
Daira Hopwood c3635e6406 Update index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 19:21:02 +00:00
Daira Hopwood b9b5ffc646 Trivial change to poke GitHub Pages.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 19:14:00 +00:00
Daira Hopwood 2db3287d57
Merge pull request #312 from daira/zip-1014a
ZIP 1014: Dev Fund to ECC + ZF + Major Grants
2020-01-07 18:52:58 +00:00
Daira Hopwood aa6c2df6f5 Regenerate index and HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 18:50:12 +00:00
Daira Hopwood 5e44e622a7 ZIP 1014: updates from review with Gtank.
Update Discussions-To: URL.
Delete section on differences from Matt Luongo's proposal.
Clarify wording on large or long-duration Major Grants.
Reporting requirement for how "fair market value" is computed.
RFC 2119 conformance language.
"$" -> USD.
Copyediting.

Co-Authored-By: Daira Hopwood <daira@jacaranda.org>
Co-Authored-By: George Tankersley <george@zfnd.org>
Co-Authored-By: Josh Cincinnati <acityinohio@users.noreply.github.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 18:49:57 +00:00
Daira Hopwood 6a86d4a853 ZIP 1014: update Acknowledgements.
Contains some text from b8f9eb3c0b

Co-Authored-By: Josh Cincinnati <acityinohio@users.noreply.github.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 18:13:03 +00:00
Daira Hopwood befd65d99d ZIP 1014: delete Disclosures section.
Originally part of b8f9eb3c0b

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 18:09:55 +00:00
Daira Hopwood 8ed505a6c9 ZIP 1014: Add reference to the Open Source Definition.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 16:05:19 +00:00
Daira Hopwood fe161c5537 ZIP 1014: RFC 2119 conformance language.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 16:03:56 +00:00
Daira Hopwood a23752742b ZIP 1014: remove redundant credit line and fix potentially bad incentive structure in volatility reserve.
Originally 71de73058e

Co-Authored-By: Josh Cincinnati <acityinohio@users.noreply.github.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 15:59:39 +00:00
Daira Hopwood 642f7c6f1a ZIP 1014: clarify language around the criteria for awarding Major Grants.
No normative changes intended, other than removal of "new" in
item 4, which conflicts with the "maintain the existing teams
and capabilities" goal of this ZIP.

Originally
* 517562aae3
* f7277c6777

Co-Authored-By: Eran Tromer <eran@tromer.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 15:54:24 +00:00
Daira Hopwood e6a5a5380c ZIP 1014: clarify how Volatility Reserve is managed and by whom.
Originally 8ab85986be

Co-Authored-By: Eran Tromer <eran@tromer.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 14:07:16 +00:00
Daira Hopwood 46690175b9 ZIP 1014: rename Community Advisory Panel to Community Panel.
Originally 6ad20895a4

Co-Authored-By: Daira Hopwood <daira@jacaranda.org>
Co-Authored-By: Josh Cincinnati <acityinohio@users.noreply.github.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 11:45:07 +00:00
Daira Hopwood 08f48b1b9b ZIP 1014: copyediting from Daira's review.
Originally
* c093569d53
* e7ddc76496
* deae965edc
* bac8679e83
* 2d6645b732

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 11:39:23 +00:00
Daira Hopwood f20542877c ZIP 1014: ECC may distribute Dev Fund proceeds in fair-market-value compensation to contractors, as well as employees.
Originally 3558d34601

Co-Authored-By: Daira Hopwood <daira@jacaranda.org>
Co-Authored-By: Josh Cincinnati <acityinohio@users.noreply.github.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 11:31:45 +00:00
Daira Hopwood cfe18281eb ZIP 1014: wording updates; volatility reserve is per organization.
Deletes "ZF may award grants as profit-sharing contracts".
Adds "The ECC will not be eligible for Major Grants if they have any funds available in their slice's Volatility Reserve" (which is later deleted).
Transfers responsibility for Major Grants awards from the ZF Board of Directors to a separate committee.

Originally 025dc79858

Co-Authored-By: Josh Cincinnati <acityinohio.users.noreply.github.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 11:26:28 +00:00
Daira Hopwood cafed14a2e Create ZIP 1014 from ZIP 1012.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-07 11:04:07 +00:00
Daira Hopwood 901c1a7963
Merge pull request #311 from nathan-at-least/render-via-docker
Support rendering via Docker.
2020-01-06 04:39:55 +00:00
nathan d81c846af0 Modify root Makefile to build protocol with the 'all' target; update Docker to include protocol render toolchain. 2020-01-05 12:54:51 -08:00
nathan 3aba19102e Support rendering via Docker. 2020-01-02 11:58:44 -08:00
Daira Hopwood a8d7af462b Remove email addresses from Original-Authors fields.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-01 16:34:13 +00:00
Daira Hopwood 41ec7e7820 Remove email addresses from Credits fields.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2020-01-01 16:28:27 +00:00
Daira Hopwood f1230509d8 Regenerate PDFs (and add heartwood.pdf).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-12-27 11:57:21 +00:00
Daira Hopwood b2c58d414c Blossom clarifications.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-12-27 11:57:20 +00:00
Daira Hopwood 54624a8a6f Specify the height at which Blossom activated.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-12-27 11:57:20 +00:00
Daira Hopwood de0d60efff Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-12-27 11:57:20 +00:00
Daira Hopwood 149dfcdb53 Add Makefile changes and macros for Heartwood spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-12-27 11:57:20 +00:00
Daira Hopwood 624aa9eaa1 Improve formatting of appendix cross-references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-12-27 11:57:20 +00:00
Daira Hopwood 7f55b54b7c
Merge pull request #305 from daira/zip1008
ZIP 1008 changes
2019-11-29 11:47:00 +00:00
Daira Hopwood e4ebd818d6 ZIP 1008: see discussion at https://forum.zcashcommunity.com/t/kek-s-proposal-fund-ecc-for-2-more-years/34778/29 and subsequent comments.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-29 11:45:07 +00:00
Daira Hopwood 374ef5c5fc
Merge pull request #304 from tromer/zip1012-fix-sectioning
Fix sectioning in draft ZIP 1012
2019-11-29 09:52:45 +00:00
Daira Hopwood b739429387 Regenerate ZIP 1012 HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-29 09:52:00 +00:00
Eran Tromer 5871bc3f4f Fix sectioning in draft ZIP 1012
"ZF Board Composition" and "Future Community Governance" should be subsections
under "Specification".
2019-11-28 23:33:17 -05:00
Daira Hopwood 588b7cb392 ZIP 1010: correction to an Editor note.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-29 03:50:45 +00:00
Daira Hopwood 8c327e6a4c ZIP 1012: fix an inconsistency between the Abstract and the Specification, as per
https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fund-to-ecc-zfnd-major-grants/35364/43

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-29 03:29:30 +00:00
Daira Hopwood 367862f968 ZIP 1012: add Discussions-To and other cosmetic updates.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-29 02:39:51 +00:00
Daira Hopwood 3154bd7fdf Generate ZIP 1012 HTML and index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-29 02:11:16 +00:00
Daira Hopwood 9400bfea47 Merge branch 'master' of github.com:zcash/zips into dev-fund-to-ecc-zfnd-mg 2019-11-29 02:10:05 +00:00
Daira Hopwood 3ce38d841f Move zip-XXXX.rst -> zip-1012.rst.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-29 02:08:51 +00:00
Daira Hopwood e2dfec033f ZIP 1012: Editing to regularize all of the dev fund ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-29 02:07:47 +00:00
Daira Hopwood 4c3d52b342
Merge pull request #302 from daira/zip1013
ZIP 1013: Keep It Simple, Zcashers: 10% to ECC, 10% to ZF
2019-11-27 16:50:53 +00:00
Daira Hopwood 46a1dbbfd3 ZIP 1013: Editing to regularize all of the dev fund ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-27 16:49:51 +00:00
Gordon Mohr 2b59d069fb typo 2019-11-27 16:32:35 +00:00
Gordon Mohr 9b21100974 ZIP-####-KISZ.rst "Keep It Simple, Zcashers (KISZ): 10% to ECC, 10% to ZFnd" 2019-11-27 16:32:35 +00:00
Daira Hopwood db98f093ea
Merge pull request #301 from daira/decentralize-the-dev-fee
ZIP 1011: Decentralize the Dev Fee
2019-11-26 03:57:21 +00:00
Daira Hopwood 5bfd63a7f7 ZIP 1011: Editing to regularize all of the dev fund ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-26 03:55:17 +00:00
Matt Luongo d7e673ff87 🐛 Actually remove the principal developer seat
As originally attempted in 4524d8cd3028d, thanks for catching that
@mlphresearch!
2019-11-26 01:32:35 +00:00
Matt Luongo d3f95d6df5 Thank @tromer and cite his alternative proposal 2019-11-26 01:32:35 +00:00
Matt Luongo 2d38080008 Update to reflect the ECC/ZF trademark agreement 2019-11-26 01:32:35 +00:00
Matt Luongo 5db9d91870 Correct my Bitcoin history
Thanks @lightcoin!
2019-11-26 01:32:35 +00:00
Matt Luongo 08e5ee6d5b Replace the principal developer board seat
Removing the seat simplifies Foundation governance, and appears to be a
popular move. More discussion can be found on the forum https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fund-to-ecc-zfnd-major-grants/35364/17?u=mhluongo
2019-11-26 01:32:35 +00:00
Matt Luongo 3d60f88bfa Move from a fixed to max principal dev allocation
Based on feedback from @tromer as well as thoughts from the ECC on the
forum
(https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252/92?u=mhluongo)
2019-11-26 01:32:35 +00:00
Matt Luongo f7a3f3ea12 Replace the burn mechanism with grant funding
Thanks @tromer for the extended discussion on today's Foundation grant
system!

More details on some issues with burn were discussed on the forum https://forum.zcashcommunity.com/t/protect-the-integrity-of-the-monetary-base-supply-schedule/35283/11
2019-11-26 01:32:35 +00:00
Matt Luongo dad1b516cf Further clarify that ZF is free to continue R&D 2019-11-26 01:32:35 +00:00
Matt Luongo f1b392c7c9 🐛: Fix the dev fee easing function
Refs https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252/50?u=mhluongo
2019-11-26 01:32:35 +00:00
Matt Luongo 2d16ce3037 🐛: 501(c)(3) board members can't be paid in the US 2019-11-26 01:32:35 +00:00
Matt Luongo 078bc24c37 Include disclosures and acknowledgements 2019-11-26 01:32:35 +00:00
Matt Luongo 71b454d1a9 Include an abstract 2019-11-26 01:32:35 +00:00
Matt Luongo aabd16d911 Move from a dev fee ceiling to an easing function 2019-11-26 01:32:35 +00:00
Matt Luongo 04e844ea6d Strengthen the role of principal developer 2019-11-26 01:32:35 +00:00
Matt Luongo bf5cfa4806 Clarify dev fee changes via network upgrade
This structure makes it clear that the Foundation isn't "paying" the dev
fee recipients -- a logistics mess -- and instead recommends changes per
network upgrade.
2019-11-26 01:32:35 +00:00
Matt Luongo c458556923 Include requirements and non-requirements 2019-11-26 01:32:35 +00:00
Matt Luongo 46dcc1a626 Clean up the narrative language 2019-11-26 01:32:35 +00:00
Matt Luongo 885f99b30a Clarify the board's discretion around elections 2019-11-26 01:32:35 +00:00
Matt Luongo c559e51df9 Clarify that developers decide and execute...
roadmaps.
2019-11-26 01:32:35 +00:00
Matt Luongo 39606562f9 Allow room for Foundation board self-selection
... while heavily favoring formal board experience.

A board stacked with researchers isn't representative and is unlikely to
have the leverage it needs.
2019-11-26 01:32:35 +00:00
Matt Luongo 9ceeeddaea Fix a couple lists 2019-11-26 01:32:35 +00:00
Matt Luongo 82f4327fb3 Include the bulk of the dev fee proposal 2019-11-26 01:32:35 +00:00
Matt Luongo a14b7ecb4a Describe the "crowding out" problem 2019-11-26 01:32:35 +00:00
Matt Luongo 666aca0fe5 Describe issues with today's Zcash governance 2019-11-26 01:32:35 +00:00
Matt Luongo a4f857bd3d Zcash can be more than "Bitcoin, but private" 2019-11-26 01:32:35 +00:00
Matt Luongo 50ac7ca9f8 Introducing my interest in Zcash 2019-11-26 01:32:35 +00:00
Matt Luongo ee0215cc88 Another take on a dev fee ZIP.
We need to separate the foundation and the ECC, and we need to ecourage
third-party investment in Zcash development.

Let's do this.
2019-11-26 01:32:35 +00:00
Daira Hopwood 9bfc711287
Merge pull request #300 from daira/compromise-dev-fund
ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams
2019-11-25 21:26:11 +00:00
Daira Hopwood f36e0320a2 ZIP 1010: Editing to regularize all the dev fund ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-25 21:21:49 +00:00
Josh Cincinnati 22b350cf20 removes trust cost question 2019-11-25 14:57:11 +00:00
Josh Cincinnati feeb659064 significant rewrite of the proposal 2019-11-25 14:57:11 +00:00
Josh Cincinnati f39dfae9ee more grammar fixes
Co-Authored-By: John Light <john-light@users.noreply.github.com>
2019-11-25 14:57:11 +00:00
Josh Cincinnati 42df5af63e grammar fix
Co-Authored-By: John Light <john-light@users.noreply.github.com>
2019-11-25 14:57:11 +00:00
Josh Cincinnati 698a826c78 adds my dev fund proposal 2019-11-25 14:57:11 +00:00
Daira Hopwood f97027827d
Merge pull request #299 from daira/zip1009
ZIP 1009: Five-Entity Strategic Council
2019-11-22 23:25:07 +00:00
Daira Hopwood 5b9a851bec ZIP 1009: Editing to regularize all the dev fund ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-22 23:21:24 +00:00
avichal 02ddf95e05 Update 5-entity-strategic-council.rst 2019-11-22 20:48:03 +00:00
avichal 63a9da281f Update 5-entity-strategic-council.rst 2019-11-22 20:48:03 +00:00
avichal 9213bb5e17 Create 5-entity-strategic-council.rst 2019-11-22 20:48:03 +00:00
Daira Hopwood 4ce5018fb3 Change styling of Editor notes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-22 18:08:51 +00:00
Daira Hopwood 6d88eef819
Merge pull request #298 from daira/zip1005
ZIP 1005: Zcash Community Funding System
2019-11-22 16:53:17 +00:00
Daira Hopwood f0f22b5005 ZIP 1005: Editing to regularize all the dev fund ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-22 16:51:14 +00:00
Sonya Mann 98155b9eb5 Create zcash-community-funding-system.rst 2019-11-22 15:59:58 +00:00
Daira Hopwood 00ed0aecea
Merge pull request #297 from daira/amiller-zip1004
ZIP 1004: Miner-Directed Dev Fund
2019-11-22 15:33:36 +00:00
Daira Hopwood 331098ae10 ZIP 1004: Editing to regularize all the dev fund ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-22 15:31:13 +00:00
Andrew Miller 0651307139 Create miner-directed-devfund.rst 2019-11-22 15:28:51 +00:00
Daira Hopwood 31b35d5a88 ZIP 1003: In the event that no voting system is implemented before the 3rd halving period, express the outcome as not minting the coins that would be allocated by that system.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-22 15:26:25 +00:00
Daira Hopwood ac7594e6ca
Merge pull request #295 from daira/zip1003
ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate
2019-11-21 15:51:53 +00:00
Daira Hopwood d5a6735bdc ZIP 1003: Editing to regularize all the dev fund ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-21 15:47:10 +00:00
Sonya Mann 07102cf762 Create ecc-zf-split-plus-voting.rst 2019-11-20 11:40:32 +00:00
Daira Hopwood 348ae34c78
Merge pull request #294 from daira/blocktown-dev-fund
ZIP 1006: Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity
2019-11-17 20:48:18 +00:00
Daira Hopwood 9a0173e086 ZIP 1006: Editing to regularize all the dev fund ZIPs
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-17 20:45:11 +00:00
Daira Hopwood 8d536a262f Convert Blocktown ZIP draft to .rst format.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-17 18:17:03 +00:00
JamesTodaroMD 549f2300b3 OFFICIAL Blocktown ZIP Draft for Zcash Dev Fund
This is the UPDATED and OFFICIAL Blocktown ZIP draft that is submitted before the August 31, 2019 deadline and up for review.
2019-11-17 18:17:03 +00:00
JamesTodaroMD bd404bae69 Update Blocktown ZIP Draft for Dev Fund 2019-11-17 18:17:03 +00:00
JamesTodaroMD 500513c9be Update Blocktown ZIP Draft for Dev Fund 2019-11-17 18:17:03 +00:00
JamesTodaroMD caa95026c3 Update Blocktown ZIP Draft for Dev Fund 2019-11-17 18:17:03 +00:00
JamesTodaroMD aca7029cfa Update Blocktown ZIP Draft for Dev Fund 2019-11-17 18:17:03 +00:00
JamesTodaroMD a3516758ef Update Blocktown ZIP Draft for Dev Fund 2019-11-17 18:17:03 +00:00
JamesTodaroMD 990d5db7a9 Blocktown ZIP Draft for Dev Fund
This is Blocktown's proposal for a Zcash Development Fund of 10% in a 2-of-3 multisig agreement.
2019-11-17 18:17:03 +00:00
Daira Hopwood 8bbe71f5d7 Lighten background colour to increase contrast (short-term hack).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-17 17:50:48 +00:00
Daira Hopwood 7226b805e2 Add Status field to new ZIPs, and regenerate index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-17 17:42:10 +00:00
Daira Hopwood c13faee763 Fix a Makefile bug that could result in the index failing to be regenerated when needed.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-17 17:41:37 +00:00
Daira Hopwood 707e7509a2 ZIP 1008: Editing to regularize all the dev fund ZIPs.
Added editor's notes and revised references to specific block heights.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-17 17:22:42 +00:00
mistfpga 80c8bc8913 ZIP 1008: Fund ECC for Two More Years
This was proposed by user kek on the Zcash forums. They are unable to continue
with this proposal due to real life stuff. They have asked me to act as advocate.
I am pushing this ZIP forward until kek gets time and would like to come back and
take over.

Signed-off-by: Daira Hopwood <daira@electriccoin.co>
2019-11-17 17:21:42 +00:00
Daira Hopwood af094bdcb3 ZIP 1007: Editing to regularize all of the dev fund ZIPs.
Added an editor's note.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-17 17:21:42 +00:00
mistfpga 286679b5ac ZIP 1007: Enforce Development Fund Commitments with a Legal Charter
This was written up by @mistfpga, but this is 100% lex-node's proposal.
I have taken some liberty when addressing comments; lex-node seemed happy
with my answers.

Signed-off-by: Daira Hopwood <daira@electriccoin.co>
2019-11-17 17:21:42 +00:00
Daira Hopwood 874010a2c3 ZIP 1002: Editing to regularize all of the dev fund ZIPs.
The word "genuine" has been dropped from the title to make it more value-neutral.
Also "protocol-level" has been dropped since it is unclear whether or not the
proposal requires consensus protocol changes. Editor's notes have been added.
Some references to the Zcash Foundation have been changed to also include ECC,
since that seems to reflect the author's intent per
https://forum.zcashcommunity.com/t/final-zip-proposal-genuine-protocol-opt-in-out-donation-feature-updated-02-sept/33846/24

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-17 17:21:42 +00:00
mistfpga 07cd5145b9 ZIP 1002: Opt-in Donation Feature
Thanks to:
* Sonya for her extensive help with this.
* Nathan, Daira and Str4d for their extensive feedback.
* Everyone else on the forum and ECC/Zfnd that helped me with this.

Co-Authored-By: Sonya Mann <sonya@zfnd.org>
Co-Authored-By: Nathan Wilcox <nathan@electriccoin.co>
Co-Authored-By: Daira Hopwood <daira@electriccoin.co>
Co-Authored-By: Jack Grigg <str4d@electriccoin.co>
Signed-off-by: Daira Hopwood <daira@electriccoin.co>
2019-11-17 17:21:42 +00:00
Daira Hopwood 30f418c4c6 ZIP 1001: Editing to regularize all of the dev fund ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-17 17:21:42 +00:00
mistfpga ae47544e49 ZIP 1001: Keep the Block Distribution as Initially Defined -- 90% to Miners
Thanks to:
* Str4d for the help with the specification.
* Daira for pointing out issues with my interpretation of how the current FR/ECC structure works.
* Sonya for her extensive help with this.
* Everyone else on the forum and ECC/Zfnd that helped me with this.

Co-Authored-by: Jack Grigg <str4d@electriccoin.co>
Co-Authored-by: Daira Hopwood <daira@electriccoin.co>
Co-Authored-by: Sonya Mann <sonya@zfnd.org>
Signed-off-by: Daira Hopwood <daira@electriccoin.co>
2019-11-17 17:21:42 +00:00
Daira Hopwood b7dc78cf3e Change current owners of ZIP 0 to Daira and Gtank.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-16 17:40:42 +00:00
Daira Hopwood 3d792d49d2
Merge pull request #251 from sonyamann/patch-1
Add link to ZIP 0 in README
2019-11-16 17:35:45 +00:00
Daira Hopwood 41582539ee Add link to ZIP 0 in README.
Co-Authored-By: Sonya Mann <sonya@zfnd.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-16 17:34:32 +00:00
Eran Tromer 0fc5a6f9b0 Update differences from Matt Luongo's proposal 2019-11-15 06:00:15 -05:00
Eran Tromer a43deabd7a Changed slice percentages from third-third-third 35%-25%-40%
Changed slice percentages from third-third-third to 35% ECC, 25% Zfnd-GU, 40% Zfnd-MG (harmonizing with Matt Luongo's updated proposal).
2019-11-15 05:30:56 -05:00
Eran Tromer dc23447dfd Minor/typo tweaks 2019-11-15 05:30:56 -05:00
Eran Tromer 627487f356 Update proposal following community feedback
* Dev Fund will last for 4 years, and terminate at the 2nd halving in 2024, rather than continuing in perpetuity.
* Forbid ECC equity holders from serving on Zfnd's Board of Directors.
* Zfnd should formally integrate robust means of decentralized community voting into its Board of Director elections by 2021.
* Major Grants are no longer limited in duration, and can be ongoing, but have semiannual review points.
* Require ECC and Zfnd to publish "grant proposals" and reports that are at least as detailed as other Dev Fund recipients.
* Strive for metrics and KPIs in funding decisions.
* Clarify that Volatility Reserve investment profits stay in it, and remove the investment constraints.
* Discussed profit-sharing provisions in grants.
* Another grant priority: supporting ecosystem growth.
2019-11-14 03:48:49 -05:00
Eran Tromer 3e8e6e9a9e Forked proposal: Dev Fund to ECC + Zfnd + Major Grants 2019-11-11 13:12:48 -05:00
Daira Hopwood 8827ef0815 ZIP 32: update spec references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-10 16:47:16 +00:00
Daira Hopwood 98b01feeb0 Fix links to NU3 ZIPs from index.
(The .rst suffix was getting deleted for all links rather than just relative links as intended.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-09 17:50:56 +00:00
Daira Hopwood 2ea3609133 Improve references to protocol spec from ZIPs 143 and 243.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-09 17:49:49 +00:00
Daira Hopwood 3c63d327a7 Test linking into a section of the protocol spec from a ZIP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-07 20:37:09 +00:00
Daira Hopwood 1db4f4efe1 Use relative links from ZIPs to other ZIPs and the protocol spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-07 20:28:29 +00:00
Daira Hopwood 4b20dd87bb Really fix links in index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-07 20:00:20 +00:00
Daira Hopwood 5bf0ca45c4 Fix links, maybe.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-07 19:49:41 +00:00
Daira Hopwood a213e2863f
Merge pull request #275 from daira/zip-daira-mempool-limitation
[ZIP 401] Addressing mempool denial-of-service
2019-11-07 19:41:47 +00:00
Daira Hopwood 77df9d90c9 Regenerate HTML and index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-11-07 19:39:00 +00:00
Eirik Ogilvie-Wigley 4d66799a1b Finalize ZIP 401 2019-11-07 12:30:57 -07:00
Eirik Ogilvie-Wigley 8deea8dbe8 Update constant name and reference implementation 2019-11-07 12:21:58 -07:00
Eirik Ogilvie-Wigley 209718e956 Rename parameters to match implementation 2019-11-07 11:45:44 -07:00
Eirik Ogilvie-Wigley 5fd8a3069b Move and rename draft zip - now 401 2019-11-07 11:41:18 -07:00
Matt Luongo cece2e3538
🐛: Fix the dev fee easing function
Refs https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252/50?u=mhluongo
2019-11-01 17:36:22 -04:00
Za Wilcox 62e61fd1ac
This relabeling brings the figures into closer agreement with the surrounding text. 2019-11-01 13:47:45 -06:00
Matt Luongo e34b79e6b9 🐛: 501(c)(3) board members can't be paid in the US 2019-10-25 14:54:00 -04:00
Matt Luongo 25bfae89ba Include disclosures and acknowledgements 2019-10-25 13:55:23 -04:00
Matt Luongo 725acfafc1 Include an abstract 2019-10-25 13:55:23 -04:00
Matt Luongo 841b2920ac Move from a dev fee ceiling to an easing function 2019-10-25 13:55:23 -04:00
Matt Luongo 52e2876add Strengthen the role of principal developer 2019-10-25 13:55:23 -04:00
Matt Luongo 49e63fe239 Clarify dev fee changes via network upgrade
This structure makes it clear that the Foundation isn't "paying" the dev
fee recipients -- a logistics mess -- and instead recommends changes per
network upgrade.
2019-10-25 13:55:23 -04:00
Matt Luongo 3c35f28272 Include requirements and non-requirements 2019-10-25 13:55:17 -04:00
Matt Luongo 66eb89c7f3
Clean up the narrative language 2019-10-19 23:01:07 -04:00
Jack Grigg 90ad18ff22
s/when a rollback occurs/when a reorg or rollback occurs/ 2019-10-19 16:44:27 +13:00
Jack Grigg 821bd9f8f1
ZIP 213: Remove hypothetical about Sapling FR addresses
If a future ZIP is proposed, it can specify its own consensus rules.
2019-10-19 16:43:35 +13:00
Matt Luongo f78cade025
Clarify the board's discretion around elections 2019-10-17 22:40:43 -04:00
Daira Hopwood 5199cdcc0b
Assign ZIP number 401 2019-10-17 13:47:35 -07:00
Matt Luongo 7b7b8ecb05
Clarify that developers decide and execute...
roadmaps.
2019-10-15 19:55:12 -04:00
Matt Luongo a3e5153e98
Allow room for Foundation board self-selection
... while heavily favoring formal board experience.

A board stacked with researchers isn't representative and is unlikely to
have the leverage it needs.
2019-10-12 06:54:30 -04:00
Matt Luongo 2277417172
Fix a couple lists 2019-10-12 06:38:44 -04:00
Matt Luongo 6265c0009a
Include the bulk of the dev fee proposal 2019-10-06 19:03:53 -04:00
Matt Luongo da2761d81d
Describe the "crowding out" problem 2019-10-06 17:02:29 -04:00
Matt Luongo 1c288d7922
Describe issues with today's Zcash governance 2019-10-06 16:44:57 -04:00
Matt Luongo a43b8a4e7f
Zcash can be more than "Bitcoin, but private" 2019-09-27 15:01:38 -04:00
Matt Luongo 0b32b51ff1
Introducing my interest in Zcash 2019-09-27 14:45:27 -04:00
Matt Luongo ef1b750c95
Another take on a dev fee ZIP.
We need to separate the foundation and the ECC, and we need to ecourage
third-party investment in Zcash development.

Let's do this.
2019-09-27 14:22:09 -04:00
Daira Hopwood 2df1c61e06 Clarify weighting.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-27 04:52:55 +01:00
Daira Hopwood f7e6215524 Explain "five times as likely".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-27 04:50:44 +01:00
Daira Hopwood ba9e5cf21f MUST -> SHOULD in response to @gtank's review comment.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-27 04:49:16 +01:00
Daira Hopwood 8496471750 zcashd -> ``zcashd``
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-27 04:48:16 +01:00
Daira Hopwood eef0b96916 Say that this is independent of the Blossom network upgrade.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-27 04:44:46 +01:00
Daira Hopwood 96d5f3a79d Use a constant for the size of RecentlyEvicted and fix inconsistencies.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-27 04:44:26 +01:00
Daira Hopwood 4e7886498c Separate cost from eviction weight.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-27 04:40:01 +01:00
Daira Hopwood 8e1c43b50a Add ZIP Draft: Addressing mempool denial-of-service
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-26 16:54:52 +01:00
Daira Hopwood 89de83447a Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-24 01:34:27 +01:00
Daira Hopwood 59aabd6fb5 Fix a typo in the generator for S_1 found by magrady.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-24 01:32:02 +01:00
Daira Hopwood a5eef5d9fc Clarify the type of v^new when sending a Sapling note. fixes #262
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-24 01:17:48 +01:00
Daira Hopwood 746bcca4b3 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-24 00:53:05 +01:00
Taylor Hornby a4c521a96c Explain the discrepancy in the number of constraints for BLAKE2s found by QED-it.
Co-authored-by: Taylor Hornby <taylor@defuse.ca>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-24 00:50:12 +01:00
Daira Hopwood 4326655e59 Merge branch 'can' of github.com:nvesely/zips into spec-updates 2019-09-24 00:36:58 +01:00
Daira Hopwood 07417709da Set date for change entry.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-24 00:31:52 +01:00
Daira Hopwood 080cfb00bf Fix an error in the expression for Δ in Pedersen hashing, and add acknowledgement to Kobi Gurkan.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-24 00:30:41 +01:00
Weikeng Chen 3b111df058 fix a small typo in 4.8 Merkle path validity
Similarly, let MerkleCRH be MerkleCRH^{Sprout} for Sprout, or **MerkleDepth^{Sapling}** for Sapling.

becomes

Similarly, let MerkleCRH be MerkleCRH^{Sprout} for Sprout, or **MerkleCRH^{Sapling}** for Sapling.

Co-authored-by: Weikeng Chen <w.k@berkeley.edu>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-24 00:28:12 +01:00
Daira Hopwood d69d5e1a0c Protocol spec Makefile: 'all' is now the default target.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-03 20:51:01 +01:00
Daira Hopwood 8c6eb6c741 Protocol spec Makefile improvements to suppress unneeded output.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-03 20:51:01 +01:00
Daira Hopwood e0ddb5ed54 Remove ZIP 207 as a reference.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-03 20:51:01 +01:00
Daira Hopwood 9dfa6a981b Fix a missing reference warning for the Sprout spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-03 20:51:01 +01:00
Daira Hopwood 81767ac18f Update references to ZIPs and to the Electric Coin Company blog.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-03 20:51:01 +01:00
Daira Hopwood 175986b0a2 ZIP 0: fix a typo.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-03 17:24:39 +01:00
Daira Hopwood b5b89264d3 ZIP 0: add section on ZIP numbering conventions.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-03 17:20:26 +01:00
Daira Hopwood 0c7fcf636b zip-guide.rst: clarify that an Abstract should not contain specification.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-03 14:19:44 +01:00
Daira Hopwood b25a4e6889 Makefile improvements; delete obsolete index.rst.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-09-03 14:19:25 +01:00
Daira Hopwood 72ca40e99d Fix README.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-24 14:42:31 +01:00
Daira Hopwood b215c96a34 Let's see if this fixes the README on both GitHub and GitHub pages.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-24 14:35:07 +01:00
Daira Hopwood 2815bee6f9 Change README from Markdown to rST (for uniformity and to avoid GitHub pages caching problems).
Also regenerate HTML.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-24 14:29:17 +01:00
Daira Hopwood 9040eed545 Improve ZIP index: format in a table, include status, and cross out Withdrawn/Rejected/Obsolete ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-24 10:50:03 +01:00
Daira Hopwood 5a4c216568 Minor updates to README.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-24 10:47:58 +01:00
Daira Hopwood 485942ecdf Regenerate PDFs. Also remove protocol.ver and adjust .gitignore .
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-23 20:05:43 +01:00
Daira Hopwood b7e6c187d4 Replace dummy Blossom activation height with the testnet height, and a reference to ZIP 206.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-23 20:02:00 +01:00
Daira Hopwood bcf8705de1 ZIP 206: update testnet activation height.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-23 20:00:56 +01:00
Daira Hopwood 496b291fbb ZIP 206: add note about the transaction version not changing.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-23 15:30:51 +01:00
Daira Hopwood e32e960b22 ZIP 206: add consensus branch ID and testnet activation height.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-23 15:30:51 +01:00
Daira Hopwood a7ea92955a Regenerate PDFs, and delete blossom.pdf since Blossom is now included in protocol.pdf.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-23 15:29:52 +01:00
Daira Hopwood 0c060a7a4e Add Change History date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-23 15:25:48 +01:00
Daira Hopwood 6a92b3459e Make the Blossom spec the default.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-23 15:25:37 +01:00
Daira Hopwood c62ebaa504 Note that zcashd uses ZIP 32 extended spending keys instead of sk.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-23 15:24:57 +01:00
Daira Hopwood ae16d11150 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-23 15:14:48 +01:00
Daira Hopwood f21cd8eb1b Generalize the definition of c for the Pedersen hash so that people can apply it to other curves (if they're careful!)
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-22 19:16:27 +01:00
Daira Hopwood 1c7a9abee6 Correct the packing of nf^old into input elements in the Sapling Spend circuit. fixes #264
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-22 18:20:08 +01:00
Daira Hopwood 1cea0d7786 Remove unneeded \textbnx macro.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-22 18:17:20 +01:00
Daira Hopwood 8253c352b2 Add epigraph from Hunting of the Snark.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-22 18:16:33 +01:00
Daira Hopwood 8e21be9a73 Suppress insignificant "Overfull vbox" warnings.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-08 16:38:48 +01:00
Daira Hopwood 1147fe4eff Make the label boxes link to the correct URL.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-08 16:37:46 +01:00
Daira Hopwood 588bc39a77 Protocol spec: note the change to the minimum-difficulty threshold time on the test network for Blossom.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-07 11:18:57 +01:00
Daira Hopwood ccac68b60f Protocol spec: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-07 11:18:57 +01:00
Daira Hopwood 7ea6510a05 Protocol spec: index improvements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-07 11:18:57 +01:00
Daira Hopwood fbacfdc358 Protocol spec: remove HTML Makefile targets.
The original intent was to allow external linking into the spec, but that never worked for
HTML, and is now possible with PDF. Also, the HTML output was very large, and typographically
unsatisfactory.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-07 11:18:57 +01:00
Daira Hopwood 7985249119 Protocol spec: remove "optimized" Makefile targets (which actually produced a larger PDF, with TeXLive 2019).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-07 11:18:57 +01:00
Daira Hopwood cad4baf2e1 Protocol spec: silence overfull/underfull hbox warnings from the theorem list.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-07 11:18:57 +01:00
Daira Hopwood 6dc1d7fff0 Protocol spec: silence a spurious warning from imakeidx.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-07 11:18:57 +01:00
Daira Hopwood 3201fab5ab Add *.save to .gitignore .
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-07 11:14:33 +01:00
Josh Cincinnati d3e49e42c7 updates zip-0000
...to make George the Foundation ZIP Editor :)
2019-08-06 17:52:31 -04:00
Daira Hopwood c333fe2b0b Simplify command to make HTML from a ZIP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 19:57:47 +01:00
Daira Hopwood 878b38116d css/zip-style.css: add some bottom margin.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 15:49:01 +01:00
Daira Hopwood d23c9b9d97 Indent definitions.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 15:46:03 +01:00
Daira Hopwood 5be384497d ZIP 209: add section heading for References.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 15:45:47 +01:00
Daira Hopwood c61640143c ZIP 208: fix reference link.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 15:28:58 +01:00
Daira Hopwood 60adcd0e5c Improvements to css/zip-style.css .
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 15:20:13 +01:00
Daira Hopwood fcdde6f89a Switch from pandoc to rst2html5.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 13:58:27 +01:00
Daira Hopwood 65af4c7de4 Fix rst warnings.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 13:58:09 +01:00
Daira Hopwood ccc989e91c ZIP 0: fix formatting and link.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 12:56:14 +01:00
Daira Hopwood d90238c971 Add index of ZIPs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 12:41:46 +01:00
Daira Hopwood 58c50ad351 Simplify css/zip-style.css .
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 04:24:40 +01:00
Daira Hopwood 3669cb1d79 Style the HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 04:19:55 +01:00
Daira Hopwood 4ee74f4322 Markdown didn't work out for ZIPs, try HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 01:05:27 +01:00
Daira Hopwood 1e0a45b9ba Add generated .md files.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 00:47:11 +01:00
Daira Hopwood 4c1939cc39 Add Makefile to generate .md files.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-06 00:47:11 +01:00
Daira Hopwood baefc22e49 Create CNAME 2019-08-05 18:01:51 +01:00
Daira Hopwood b8e255775c ZIP 208: clarify that if -txexpirydelta is set, its value is used both before and after Blossom activation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-01 13:02:57 +01:00
Daira Hopwood a189090b8a ZIP 208: section on EstimateNetHeight.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-01 12:34:52 +01:00
Daira Hopwood 562c78f29b
Merge pull request #258 from daira/zip208-updates
[Blossom] Add ZIP 206 and update ZIP 208. Also clean up ZIP metadata.
2019-08-01 09:40:43 +01:00
Daira Hopwood f56419d47c ZIP 207: clarify Withdrawn status, and fix a link.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-01 09:36:56 +01:00
Daira Hopwood c8f535c401 Update URLs for Zcash blog posts that have moved to the ECC blog.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-01 09:36:25 +01:00
Daira Hopwood 012fcc676f ZIP 0: make a distinction between Owners and authors, and other minor corrections.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-01 09:19:27 +01:00
Daira Hopwood 3ccf1c37d1 Various ZIPs: clean up header metadata.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-01 09:18:23 +01:00
Daira Hopwood 2825f8767e ZIP 208: formatting.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-08-01 09:15:25 +01:00
Daira Hopwood fd499bc3a8 ZIP 208: additional non-consensus issues.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-31 17:52:29 +01:00
Daira Hopwood dcb22488f7 ZIP 208: add reference to an Ethereum blog post suggested by Simon.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-31 17:52:08 +01:00
Daira Hopwood e793368cf5 ZIP 208: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-31 17:51:33 +01:00
Daira Hopwood b026aecfc1 ZIP 208: correct the Created date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-31 17:48:13 +01:00
Daira Hopwood 179c1a9b69 Add ZIP 206 (Blossom deployment).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-30 17:55:39 +01:00
Daira Hopwood d9763c0a1c ZIP 208: correction to the block request timeout.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-30 14:53:55 +01:00
Daira Hopwood 48f5d2636e ZIP 208: PR link.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-29 17:05:30 +01:00
Daira Hopwood 44b7eb851b ZIP 208: minimum difficulty change.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-29 17:05:01 +01:00
Daira Hopwood 8d9e729a25 ZIP 208: clarification.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-29 17:04:39 +01:00
Daira Hopwood d1a0afb8a6 ZIP 208: non-consensus changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-29 17:03:58 +01:00
Daira Hopwood af6b9096d7 ZIP 208: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-29 17:03:12 +01:00
Daira Hopwood 6d5a6ccae3 ZIP 208: PostBlossomPoWTargetSpacing is now final at 75 seconds.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-29 17:01:46 +01:00
Daira Hopwood a884fad84d Make "Don't Panic" larger and friendlier.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-23 15:37:59 +01:00
Daira Hopwood 3329a7caca zip-guide.rst: add Eran's suggested "Don't Panic" paragraph.
Co-Authored-By: Eran Tromer <eran@tromer.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-23 15:26:05 +01:00
Daira Hopwood fa484ecbeb Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-23 15:07:29 +01:00
Daira Hopwood 8d14678190 Protocol spec: set date of Change History entry. Also fix a typo.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-23 15:04:31 +01:00
Daira Hopwood 7e8ff18f82 Protocol spec: more vertical spacing fixes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-23 14:58:28 +01:00
Daira Hopwood 70e920e1c8 Protocol spec: minor wording changes, added cross-references, and better "changed" marking.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-23 14:14:01 +01:00
Daira Hopwood b684ce88e2 Protocol spec: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-23 13:48:42 +01:00
Daira Hopwood 9ac2beeed8 Protocol spec: add some index macros.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-23 13:48:42 +01:00
Daira Hopwood 8e52e03761 Protocol spec: vertical spacing cosmetics.
(The new macro definitions for notes, consensus rules, etc. generally require fewer
and/or smaller spacing adjustments.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-22 22:34:46 +01:00
Daira Hopwood 4379eaf89c Add support for showing labels, by clicking on any title.
This will not work in all PDF readers, but it works in enough readers to be useful.

Also add a list of theorems and lemmata.
This required switching to the ntheorem package rather than amsthm.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-22 22:19:23 +01:00
Daira Hopwood caa5da0cc2 Draft ZIP guide.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-22 18:52:32 +01:00
Daira Hopwood d3bebc6c49 Delete CNAME 2019-07-15 23:55:00 +01:00
Daira Hopwood c15eb07d9e Create CNAME 2019-07-15 23:54:22 +01:00
George Tankersley 960c5b4820 Add high level NU4 deadlines to README 2019-07-15 18:47:29 -04:00
Daira Hopwood 8579893230 Protocol spec: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-11 17:57:39 +01:00
Daira Hopwood 4eed11f925 Changes needed to support TeXLive 2019.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-11 17:57:22 +01:00
Daira Hopwood 234e0faf0b Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-09 00:06:35 +01:00
Daira Hopwood 0ab4949653 Protocol spec: set date of Change History entry.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-08 22:59:16 +01:00
Daira Hopwood 8570f6f5a6 Protocol spec: use microtype package.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-08 22:58:17 +01:00
Daira Hopwood 7656d39204 Protocol spec: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-08 22:57:50 +01:00
Daira Hopwood 76bfab70a1 Protocol spec: correct an omission in the Change History.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-08 22:56:55 +01:00
Daira Hopwood fe92918c87 Protocol spec: add labels to all sections (for external referencing).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-08 22:56:19 +01:00
Daira Hopwood 77ebb8614a Protocol spec: improvements to indexing.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-08 22:53:39 +01:00
Daira Hopwood 6e2b8f0ebf Protocol spec: Initial index support.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-08 22:42:16 +01:00
Daira Hopwood a5e5f3e307 Protocol spec: Makefile fixes for nolatexmk targets.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-08 22:14:28 +01:00
Daira Hopwood 8adfcb5ce0 Protocol spec: Experimental LuaLaTeX and XeLaTeX support. refs #249
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-08 22:12:54 +01:00
Daira Hopwood fca48cf94f Protocol spec: README corrections.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-08 21:44:00 +01:00
Daira Hopwood 3e027d2126 Fix typos in comments about the (no longer used) newtxmath package.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-05 13:46:26 +01:00
Daira Hopwood 95f07ed666 README.md: fix link to MMR ZIP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-07-01 13:37:55 +01:00
Daira Hopwood a9ec23b50d Merge branch 'master' of github.com:daira/zips
(Merge GitHub Pages experiment.)
2019-06-28 13:25:47 +01:00
Daira Hopwood f5117e74fd Set theme jekyll-theme-tactile 2019-06-28 12:13:08 +01:00
Jack Grigg fc896078f7
Assigned ZIP number 302 2019-06-27 15:17:31 +02:00
Jack Grigg 784973277a
Add header to memo field specification ZIP 2019-06-27 15:15:54 +02:00
Daira Hopwood 1c7fdad7b1 Add protocol/aux/ to .gitignore.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-19 00:00:57 +01:00
Daira Hopwood 7b7eb100b4 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-19 00:00:41 +01:00
Daira Hopwood ecc92df195 Correct a misstatement in the security argument for balance / binding signatures.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-18 23:53:35 +01:00
Daira Hopwood 8fddbe438c Protocol spec: specify which changes in this version are for Sapling, and LaTeX comment nits.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-18 23:52:43 +01:00
Daira Hopwood 847a002eff Clarify that Theorem 5.4.2 depends on the parameters of the Jubjub curve.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-18 23:52:43 +01:00
Daira Hopwood f4f4682d57 Give a definition for complete twisted Edwards elliptic curves.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-18 23:52:43 +01:00
Daira Hopwood 2379ba88d7 Protocol spec: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-18 23:52:43 +01:00
Daira Hopwood 2766855113 Protocol spec: silence useless warnings on first latex run.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-18 22:34:04 +01:00
Daira Hopwood 6e3ff4364e Protocol spec: resolve bibliography warnings.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-18 22:33:10 +01:00
Daira Hopwood a1cb36a19a Protocol spec: fix optimization and links.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-18 22:32:14 +01:00
Daira Hopwood af95317ce7 Protocol spec: fix incompatibility with recent TeXLive.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-18 22:29:50 +01:00
Daira Hopwood 2cd929c225 README.md: fix link to draft ZIP 211.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-06-18 20:27:59 +01:00
str4d 4f067aeb6c
Merge pull request #162 from str4d/zip-143-updates
ZIP 143 updates
2019-06-05 14:13:00 +01:00
str4d 591ffa642a
Merge pull request #208 from str4d/zip-243-updates
[Updates ZIP 243] Update test vectors to match generator output
2019-06-05 14:12:40 +01:00
Daira Hopwood 3031d1bbf9 Make ZIP 209 (Prohibit Negative Shielded Value Pool) Final.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-23 01:33:01 +01:00
Daira Hopwood acff8a6825
Merge pull request #237 from daira/zip-0208-updates
Add ZIP 208 (Shorter Block Target Spacing)
2019-05-23 01:32:36 +01:00
Daira Hopwood 607ccaa732 ZIP 208: update references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-20 11:20:55 +01:00
Daira Hopwood d39ed004f6 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-20 11:12:00 +01:00
Daira Hopwood 7152d677c8 Use IsBlossomActivated in the definition of FounderAddressAdjustedHeight for consistency.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-20 11:09:19 +01:00
Daira Hopwood c699bd4ba1 Minor fix to the list of integer constants in the Notation section.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-20 11:08:53 +01:00
Daira Hopwood 9e2d6352d9 Make ZIP 208 consistent with the protocol specification as of version 2019.0.0.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-20 11:07:47 +01:00
Daira Hopwood c0c5f35af2 ZIP 208 minor rewording.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-17 18:19:44 +01:00
Daira Hopwood 756c9cdd49 Move Blossom ZIP interactions discussion to ZIP 207.
Co-authored-by: Jack Grigg <jack@z.cash>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-17 18:19:44 +01:00
Daira Hopwood 98bcfd9ab4 ZIP 208: cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-17 18:19:44 +01:00
Daira Hopwood 426ed5e77d ZIP 208: misc changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-17 18:19:44 +01:00
Daira Hopwood 8e6881730f ZIP 208: cosmetics, and separate current from pre-Blossom spec references.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-17 18:19:44 +01:00
Daira Hopwood d530096d09 Add comment about measurements needed to decide on block time.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-17 18:19:44 +01:00
Daira Hopwood b3f3977906 Draft ZIP 208: Shorter Block Target Spacing
Co-authored-by: Simon Liu <simon@z.cash>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-17 18:19:44 +01:00
Daira Hopwood da380e579a
Merge pull request #236 from garethtdavies/patch-1
Fixing link to ZIP 213
2019-05-16 14:43:32 +01:00
Gareth Davies 1798ad5681
Fixing link to ZIP 213 2019-05-15 14:15:48 -07:00
Daira Hopwood b510cafc3d
Merge pull request #235 from str4d/zip-210-assigned
Update ZIP 210 with assigned number
2019-05-14 00:30:40 +01:00
Jack Grigg 614fdd6d7e
Update link to ZIP 210 in README 2019-05-14 00:13:23 +01:00
Jack Grigg e599a1f65c
Assigned ZIP number 210 2019-05-14 00:11:23 +01:00
Daira Hopwood 8b0d50586e
Merge pull request #232 from daira/zip-0308-updates
ZIP 308 updates
2019-05-12 12:22:50 +01:00
Daira Hopwood a7683fbca6 ZIP 308: Correct `vpub_out` to `vpub_new`.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-10 20:32:49 +01:00
Daira Hopwood f7eec5124d ZIP 308: Add list of implementing zcashd PRs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-10 20:28:42 +01:00
Daira Hopwood 482f4c0468 ZIP 308: Mark Status as Final.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-10 20:28:19 +01:00
Daira Hopwood 4861f55830 ZIP 308: Migration transactions MUST have an expiry delta of 450 blocks.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-10 20:27:45 +01:00
Daira Hopwood d7bed44d73 ZIP 308: Migration txns SHOULD only be sent if the timestamp of the block used to trigger sending a batch is more recent than 3 hours ago according to the node's adjusted clock.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-10 20:26:45 +01:00
Daira Hopwood cee6562813 ZIP 308: Specify that `[un]finalized_migrated_amount` does not include fees.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-10 20:25:44 +01:00
Daira Hopwood 5f50fe0fca ZIP 308: In `z_getmigrationstatus` change occurrences of the word 'confirmed' to 'finalized'.
Also add "at least" to the definition of finalized.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-10 20:24:38 +01:00
Daira Hopwood 0a202f8c35 ZIP 308: Update RPC names to begin with `z_`.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-10 20:22:31 +01:00
Daira Hopwood 6c47fbc21a ZIP 308: ovk SHOULD be generated as if for a transfer from a t-addr.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-10 20:21:09 +01:00
Jack Grigg bc6ee29250
Make funding stream consensus rules conditional on ZIP 207 deployment
ZIP 207 was withdrawn from the Blossom network upgrade, and this ZIP can
no longer assume that it will already be deployed.
2019-05-02 12:02:22 +01:00
Jack Grigg df70f410f3
Assigned ZIP number 213 2019-05-02 11:50:06 +01:00
Jack Grigg fcb49762f1
Address Daira's comments 2019-05-02 11:49:14 +01:00
Daira Hopwood 40e609444d Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-01 11:21:21 +01:00
Daira Hopwood 6e32abdfaa Adjust revision date and version. (No longer beta! Wooo! :3 )
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-01 11:02:42 +01:00
Daira Hopwood 07334dad30 Correction to FounderAddressAdjustedHeight.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-01 10:59:21 +01:00
Daira Hopwood 1a00b68e7e Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-01 10:59:21 +01:00
Daira Hopwood ea346eaca8 Add type declarations for height in difficulty adjustment functions.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-01 10:59:21 +01:00
Daira Hopwood 65d43bfac4 Correct an error pointed out in NCC's Blossom audit affecting the first 10 blocks of the chain.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-01 10:59:07 +01:00
Daira Hopwood 1258385ab5 Add reference to [SVPBABW2012] for the idea of using multiplicative inverses for nonzero constraints.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-01 10:57:45 +01:00
Daira Hopwood feae1e7e12 Fix a spec error in Founders' Reward calculation during slow start period.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-01 10:57:31 +01:00
Daira Hopwood 5e5413f536 Adjust Founders' Reward payment.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-01 10:43:05 +01:00
Daira Hopwood b934946949 Revert "ZIP 207 changes"
This reverts commit d6ed011d5e.

Co-authored-by: Jack Grigg <jack@z.cash>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-05-01 10:43:05 +01:00
Josh Cincinnati 7e35c0a763
Merge pull request #201 from str4d/blossom-split-founders-reward
[ZIP 207] Split Founders' Reward
2019-04-30 12:26:47 -04:00
Josh Cincinnati 18523f8b0c
updates zip-207 to change status to withdrawn 2019-04-30 12:24:01 -04:00
Daira Hopwood 35cb6b6d78
Merge pull request #212 from str4d/zip-str4d-sapling-anchor
[ZIP 210] Sapling Anchor Deduplication within Transactions
2019-04-25 17:14:13 +01:00
Daira Hopwood 7f17eaaab1 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:28:39 +01:00
Daira Hopwood 395af7f309 Cosmetics and Change History date.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:24:36 +01:00
Daira Hopwood 18184803f4 The block time is not 2.5 minutes after Blossom activation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:24:16 +01:00
Daira Hopwood 6d714ee508 Add acknowledgement to Mary Maller for the observation that
diversified address unlinkability can be proven in the same
way as key privacy for ElGamal.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:23:54 +01:00
Daira Hopwood 81b9eaf515 Zerocoin Electric Coin Company -> Electric Coin Company.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:22:46 +01:00
Daira Hopwood 4faaf8d305 Use "ctEdwards" to refer to complete twisted Edwards curves.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:21:22 +01:00
Daira Hopwood b4e384cb22 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:17:05 +01:00
Daira Hopwood e47ed372d4 Add Change History entries for protocol spec README and Makefile.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:06:41 +01:00
Daira Hopwood 3c0fd3f56c Update protocol/README.rst for Blossom changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:04:35 +01:00
Daira Hopwood 13b84cdb0f Minor updates to .gitignore.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:04:12 +01:00
Daira Hopwood 03e3e19a4f Update git commits for sam2p and pdfsizeopt.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:03:40 +01:00
Daira Hopwood cca702c505 Fix Makefile bugs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-18 17:03:25 +01:00
Josh Cincinnati 79dcd1d36f
Merge pull request #225 from acityinohio/adds-nu3-zips-to-readme
Adds list of network/consensus ZIPs that could be included in NU3 to …
2019-04-16 11:08:18 -04:00
Josh Cincinnati 081abeb616
Merge pull request #224 from acityinohio/change-discussion-preferences
Removes development mailing list and changes to community forums
2019-04-16 11:07:00 -04:00
Daira Hopwood 07405b4089 ZIP 308: fix another instance of `txids` -> `migration_txids`.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-16 13:30:31 +01:00
Daira Hopwood 352f77d1da ZIP 308: rST formatting.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-16 13:25:40 +01:00
Daira Hopwood cde0876c79 ZIP 308: use consistent time-of-writing USD price.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-16 13:25:22 +01:00
Daira Hopwood c7c5b894e8 ZIP 308: add "Status: Draft".
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-16 13:20:43 +01:00
Daira Hopwood 50cd043d99
Merge pull request #197 from daira/zip-0308
[ZIP 308] Sprout to Sapling Migration
2019-04-16 13:16:25 +01:00
Daira Hopwood 4e748c8262 ZIP 308: fix typos.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-16 13:14:00 +01:00
Daira Hopwood 4e0d11f3b2 ZIP 308: update a sentence that depended on the exponent range.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-16 13:12:59 +01:00
Daira Hopwood 192907b9fc Fix rST errors.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-12 17:25:32 +01:00
Daira Hopwood 5986a2e2ad Change exponent range to 6..8.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-04-12 17:18:16 +01:00
Josh Cincinnati 1db43e879f Adds list of network/consensus ZIPs that could be included in NU3 to the README 2019-04-10 00:02:29 +00:00
Josh Cincinnati c7cd1904da fixes merge conflict 2019-04-09 23:34:15 +00:00
Josh Cincinnati bb306ec6b3 removes development mailing list and changes to community forums 2019-04-09 22:30:47 +00:00
Daira Hopwood 159d1a6976
Merge pull request #223 from zcash/makes-zip-0-active
Updates ZIP 0 to be Active rather than Draft. Also change "Type" in the preamble to "Category".
2019-04-04 22:28:38 +01:00
Josh Cincinnati 9584e4c879 also replaces type with category 2019-04-04 16:24:46 -04:00
Josh Cincinnati a46ee1f99e
updates zip 0 to be active rather than draft 2019-04-04 16:20:05 -04:00
Daira Hopwood 207fbcec47
Merge pull request #218 from acityinohio/add-wip-to-zip-0
adds WIP and ecosystem dev link to ZIP 0
2019-04-01 12:34:20 +01:00
Josh Cincinnati 731cfe6f3e adds WIP and ecosystem dev link 2019-03-30 13:30:15 -04:00
Jack Grigg 845ca0f811
Draft ZIP: Shielded Coinbase
Part of https://github.com/zcash/zcash/issues/2488
2019-03-30 04:47:27 -03:00
Josh Cincinnati 8af142b670
Merge pull request #206 from acityinohio/master
ZIP 0: ZIP Process
2019-03-28 13:59:16 -04:00
Daira Hopwood 3158debe54
Merge pull request #210 from ebfull/pool-balance-softfork
ZIP 209: Prohibit Negative Shielded Value Pool
2019-03-26 23:50:26 +00:00
Daira Hopwood 584531e5b8
Update zip-0209.rst
Co-Authored-By: ebfull <ewillbefull@gmail.com>
2019-03-26 17:47:42 -06:00
Daira Hopwood 4036974dba
Update zip-0209.rst
Co-Authored-By: ebfull <ewillbefull@gmail.com>
2019-03-26 17:47:28 -06:00
Daira Hopwood b720dee526
Update zip-0209.rst
Co-Authored-By: ebfull <ewillbefull@gmail.com>
2019-03-26 15:55:30 -06:00
Daira Hopwood 30ecac8148
Update zip-0209.rst
Co-Authored-By: ebfull <ewillbefull@gmail.com>
2019-03-26 15:55:17 -06:00
Jack Grigg 4aefbb8a17
Draft ZIP: Sapling Anchor Deduplication within Transactions
Part of https://github.com/zcash/zcash/issues/3375
2019-03-27 07:23:06 +13:00
Josh Cincinnati f4ffdb3c60 removes readme step for editors 2019-03-25 13:31:34 -04:00
Daira Hopwood f61e720c02 s/Champion/Owner/g
Co-authored-by: Josh Cincinnati <acityinohio@users.noreply.github.com>
2019-03-20 03:28:18 +00:00
Daira Hopwood d22670e43a moves motivation section and adds auxilary file clarity
Co-authored-by: Josh Cincinnati <acityinohio@users.noreply.github.com>
2019-03-20 03:28:18 +00:00
Daira Hopwood 0105afc51f Minor updates.
Co-authored-by: str4d <thestr4d@gmail.com>
Co-authored-by: Josh Cincinnati <acityinohio@users.noreply.github.com>
2019-03-20 03:28:09 +00:00
Daira Hopwood ee74933826 Fix references.
Co-authored-by: str4d <thestr4d@gmail.com>
Co-authored-by: Josh Cincinnati <acityinohio@users.noreply.github.com>
2019-03-20 03:28:00 +00:00
Daira Hopwood 7c9bbc7a36 Zcash Company -> Electric Coin Company.
Co-authored-by: str4d <thestr4d@gmail.com>
Co-authored-by: Josh Cincinnati <acityinohio@users.noreply.github.com>
2019-03-20 03:27:38 +00:00
Daira Hopwood 331e487a2b adds implementation description
Co-authored-by: Josh Cincinnati <acityinohio@users.noreply.github.com>
2019-03-20 03:21:19 +00:00
Daira Hopwood 998047b350 adds security and privacy considerations section
Co-authored-by: Josh Cincinnati <acityinohio@users.noreply.github.com>
2019-03-20 03:21:14 +00:00
Daira Hopwood 04f4c32dda Mostly trivial wording changes and cosmetics; some simplifications.
Remove OPL licensing; BSD 2-clause is sufficient.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-03-20 03:04:02 +00:00
Josh Cincinnati 14da9191fb Add ZIP 0 draft.
Author: Daira Hopwood <daira@jacaranda.org>
Author: Josh Cincinnati <acityinohio@users.noreply.github.com>
2019-03-20 03:04:02 +00:00
Daira Hopwood 10b35bdd19 Remove obsolete draft version of ZIP 0 (superseded by #206).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-03-20 01:42:40 +00:00
Sean Bowe e83b59b645
Rename to ZIP209. 2019-03-14 22:00:00 -06:00
Sean Bowe d6181913b8
Make slight adjustments 2019-03-14 19:32:12 -06:00
str4d 9c65d64012
Merge pull request #209 from str4d/zips-207-208
Update protocol spec with ZIPs 207 and 208
2019-03-08 17:59:17 +13:00
Sean Bowe d4e37652ad
Use code comments for field names. 2019-02-25 15:14:24 -07:00
Sean Bowe de2002a63e
Prohibit Negative Shielded Value Pool 2019-02-25 15:10:48 -07:00
Daira Hopwood ce803ea0b4 Correct generators for BLS12-381.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-24 05:59:14 +00:00
Daira Hopwood 86319cfe89 Address Daira's review comments.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-24 02:06:23 +00:00
Daira Hopwood 5cf59663d9 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-24 02:05:58 +00:00
Daira Hopwood 4284a49a20 Add bibliography entries for ZIPs 207 and 208.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-24 02:02:54 +00:00
Daira Hopwood fa41eae110 Fix a Makefile bug.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-24 02:02:16 +00:00
Jack Grigg d6ed011d5e
ZIP 207 changes 2019-02-23 19:21:19 +00:00
Jack Grigg 2fc1b8cc9c
ZIP 208 changes
Includes additional changes to constants in sections 7.7 and 7.8 which
are needed to compile, and not part of ZIP 208, but will be altered by
ZIP 207.
2019-02-23 19:21:17 +00:00
Jack Grigg 0f32bd8494
ZIP 243: Update test vectors to match generator output
Correct as of zcash-test-vectors commit 38cdeda51c0bf1d4714fc3a0b955b519c0373c20
2019-02-22 23:30:50 +00:00
Daira Hopwood 4a9eb35910 ZIP 32: fill in links to reference implementation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 22:54:16 +00:00
Daira Hopwood d7d12b82b5 ZIP 243: add a missing reference.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 22:53:34 +00:00
Daira Hopwood 34967ee7c5 ZIP 143: Clarify testing for SIGHASH_SINGLE and SIGHASH_NONE. fixes #169
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 16:03:10 +00:00
Daira Hopwood e01760a60d ZIP 243: fix broken links, and clarify that test vectors do not necessarily pass full validation.
fixes #188, #193

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 15:52:13 +00:00
Daira Hopwood 1fa1a91f32 Regenerate PDFs (including the new blossom.pdf).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 13:54:50 +00:00
Daira Hopwood 5097fc7c4e Add macros and Makefile support for building the Blossom specification.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 13:49:08 +00:00
Daira Hopwood 7f435cd37d Fix a typo in appendix B.2 and clarify the costs of Groth16 batch verification.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 13:49:08 +00:00
Daira Hopwood f3c5ed99e2 Remove the rule that miners SHOULD NOT mine blocks that chain to other blocks with version number > 4.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 13:49:08 +00:00
Daira Hopwood 06725e94b9 Correct the rule about when a transaction is permitted to have no transparent inputs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 13:34:25 +00:00
Daira Hopwood 95d95bc4c4 Clarify which transaction fields are added by Overwinter and Sapling.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 13:33:39 +00:00
Daira Hopwood 8e9171d512 Clarify that Equihash is based on a *variation* of the GBP, and cite [AR2017].
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 13:17:07 +00:00
Daira Hopwood c57d51d7a0 More references and corrected description of Groth16.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-22 12:49:22 +00:00
Daira Hopwood d84390beb6 Addressed comments in pairing with Eirik and Simon.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-21 23:09:09 +00:00
Daira Hopwood 3ef1646c6e Address review comments.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-20 16:31:25 +00:00
Daira Hopwood 0b626b087a Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-10 03:30:26 +00:00
Daira Hopwood ba949107ab Correct isis agora lovecruft's name.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-10 03:20:47 +00:00
Daira Hopwood 2dc3a10bfe Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-09 01:02:01 +00:00
Daira Hopwood 64c268fdd7 Add Eirik Ogilvie-Wigley and Benjamin Winston to acknowledgements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-09 01:00:03 +00:00
Daira Hopwood fb9faa3835 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-09 00:37:00 +00:00
Daira Hopwood 0988966fdc Remaining fixes and clarifications for BCTV14 vulnerability.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-09 00:37:00 +00:00
Daira Hopwood e17905a0a3 Specify the difficulty adjustment change on testnet.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-09 00:37:00 +00:00
Daira Hopwood d4a9158323 Say when Sapling activated, and reference ZIP 205.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-09 00:37:00 +00:00
Daira Hopwood d18edb4abc Rename zk-SNARK Parameters sections according to the proving system.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-08 22:59:38 +00:00
Daira Hopwood 0d8430799c Correct [SBB2019] to [SWB2019], and note that the BCTV14 vulnerability affected Soundness.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-05 19:29:31 +00:00
Daira Hopwood 36eeeba15e Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-05 16:55:42 +00:00
Daira Hopwood 9a7ebd326e Disclose BCTV14 vulnerability.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-02-05 16:45:09 +00:00
Jack Grigg c7e79e2909
Add dummy recipient addresses
With Blossom activation targeted for October 2019, and the first halving
estimated for October 2020, this should result in 12 funding periods for
the funding streams defined in this ZIP.
2019-02-01 12:01:57 +00:00
Jack Grigg 95f9ef67af
Define eight funding streams instead of three
This comes from an external requirement that the funding streams be more
finely subdivided.
2019-02-01 11:56:43 +00:00
Jack Grigg 3322acf19e
Fix AddressPeriod(height) to align with halving heights 2019-02-01 11:17:42 +00:00
Jack Grigg 2f0817d567
List ZIP 208 as an example of a block target time change 2019-02-01 10:46:39 +00:00
Jack Grigg 0e5701144a
Specify the correct start and end heights for new funding streams 2019-02-01 10:41:58 +00:00
Jack Grigg e2b5431316
Fix reference for SlowStartShift 2019-02-01 10:23:47 +00:00
Jack Grigg 6b02900eb4
Clarify that funding periods do not align with pre-Blossom FR periods 2019-02-01 10:20:51 +00:00
Jack Grigg c4bfbb4f4a
Use PostBlossomHalvingInterval instead of HalvingInterval 2019-02-01 10:20:50 +00:00
Jack Grigg ee39523b75
Add type for recipient address vectors 2019-01-25 02:14:43 +00:00
Jack Grigg c5513d6de1
Align funding periods across funding streams 2019-01-25 02:08:11 +00:00
Jack Grigg 36d4481d7e
Explicitly parameterise FundingStream in specification 2019-01-25 02:08:06 +00:00
Jack Grigg cffde64533
Add a TODO 2019-01-25 01:48:31 +00:00
Jack Grigg 4b8685cdd9
Bugfix in example implementation 2019-01-25 01:48:26 +00:00
Jack Grigg 2d62a442f5
Remove some TODOs 2019-01-25 01:48:22 +00:00
Jack Grigg 2c7b2d4dbd
Define AddressChangeInterval in terms of HalvingInterval 2019-01-25 01:48:17 +00:00
Jack Grigg 60bdbd0686
More text changes per Nathan 2019-01-25 01:48:13 +00:00
Jack Grigg 0575989ddb
Rename funding streams per Nathan's comments 2019-01-25 01:48:09 +00:00
Jack Grigg 41e077a354
Switch from a constant value per block to a block reward fraction 2019-01-25 01:48:04 +00:00
Jack Grigg 2c4989a120
Set addresses in example implementation 2019-01-25 01:48:00 +00:00
Jack Grigg 363decd737
Assigned ZIP number 207 2019-01-25 01:47:55 +00:00
Jack Grigg 3ecf6c8134
Additional to-do items 2019-01-25 01:47:51 +00:00
Jack Grigg 93487a1d9b
Specify halving height precisely in spec, and numerically in motivation 2019-01-25 01:47:46 +00:00
Jack Grigg 2250e3355e
Refine description of consensus rules 2019-01-25 01:47:41 +00:00
Jack Grigg 4ae1207623
Simplify funding stream address indexing 2019-01-25 01:47:34 +00:00
Jack Grigg 812a5ac710
Bug fixes 2019-01-25 01:47:25 +00:00
Daira Hopwood be04f70d5b Resolve a TODO.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-01-23 08:20:17 +00:00
Daira Hopwood f825dfe042 Resolve an ambiguity concerning fees.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-01-23 08:19:54 +00:00
Daira Hopwood b69910c141 Address review comments.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2019-01-23 00:20:51 +00:00
Jack Grigg 79e4f07586
Initial draft of the Split Founders' Reward ZIP 2019-01-05 01:47:34 +00:00
Daira Hopwood 232234ec86 Additional formatting improvements for ZIP 308.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-12-17 16:53:12 +00:00
Daira Hopwood 7a66cf8d4e Formatting improvements for ZIP 308.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-12-17 16:48:16 +00:00
Daira Hopwood 5a6d585a9d Completed draft (with open questions) of ZIP 308.
Co-authored-by: Eirik Ogilvie-Wigley <eirik@z.cash>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-12-17 16:25:43 +00:00
Daira Hopwood fb1d0e6f41 WIP: Sprout->Sapling migration ZIP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-27 16:23:06 +00:00
Daira Hopwood 9515d73aac Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-14 02:05:26 +00:00
Daira Hopwood 680af418cf Fill in another constraint cost.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-14 02:02:17 +00:00
Daira Hopwood af17ba2485 Adjust the notation used for scalar multiplication in Appendix A to allow bit sequences as scalars.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-14 02:01:59 +00:00
Daira Hopwood 9aba6af281 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-14 02:01:01 +00:00
Daira Hopwood 538d1f1eb0 Add a description of the Sapling output circuit.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-14 01:05:39 +00:00
Daira Hopwood 79b3d81e42 Complete the description of the Sapling spend circuit.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-13 23:15:54 +00:00
Daira Hopwood 5531006f08 Fix or complete various calculations of constraint costs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-13 23:11:53 +00:00
Daira Hopwood 7419c0a366 Describe 2-bit window lookup with conditional negation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-13 23:09:34 +00:00
Daira Hopwood 39b498fed9 Remove a todo.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-13 22:07:18 +00:00
Daira Hopwood 0835c3837e Modify the description of fixed-base scalar multiplication to match sapling-crypto.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-13 22:06:36 +00:00
Daira Hopwood 2f868aca8d Add LEBStoIP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-11-13 22:00:41 +00:00
Daira Hopwood c7d08a269c ZIP 205 formatting fixes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-30 20:43:30 +00:00
Daira Hopwood e4a74b9d0e
Merge pull request #191 from daira/zip-0205
Add ZIP 205.
2018-10-29 01:13:22 +00:00
Daira Hopwood ede1215566 Add ZIP 205.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-28 07:43:31 +00:00
Daira Hopwood 35478ad138
Merge pull request #189 from zcash/bitcartel-patch-1
Update ZIP 243 with test vector for transparent tx
2018-10-25 18:28:08 +01:00
Daira Hopwood 43e83effb4 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-24 16:18:39 +01:00
Daira Hopwood e24f7cede5 Clarify the description of the Merkle path check in Appendix A.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-24 16:14:28 +01:00
Daira Hopwood 066d424d3a Correct the input to H⊛ used to derive the nonce r in RedDSA.Sign, from T || M to T || _vk_ || M.
This matches the sapling-crypto implementation; the spec was unintentionally changed in 2018.0-beta-20.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-24 16:14:28 +01:00
bitcartel 9ed3c3d455
Update ZIP 243 with test vector for transparent tx 2018-10-15 21:14:25 -07:00
Daira Hopwood f6f47a0ecd
Merge pull request #157 from str4d/zip-0032
[ZIP 32] Shielded Hierarchical Deterministic Wallets
2018-10-05 22:07:39 +01:00
Daira Hopwood 34c6a5c0d6 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 16:47:28 +01:00
Daira Hopwood c04c0542e8 Cosmetics (pagination in Appendix A).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 16:44:31 +01:00
Daira Hopwood bb52ce246c Clarify notation in the proof of A.3.3.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 15:44:11 +01:00
Daira Hopwood 223b8db3a7 Minor tweak to the statement of Theorem A.3.4 to make the contradiction clearer.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 11:22:49 +01:00
Daira Hopwood da7c6fe190 Correct the statement and proof of Theorem A.3.2.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 11:21:02 +01:00
Daira Hopwood 25b64382e4 Clarify the notes concerning domain separation of prefixes for MerkleCRH^Sapling and NoteCommit^Sapling.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 11:00:45 +01:00
Daira Hopwood 2a7002a010 Add the QED-it report to the acknowledgements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 10:45:19 +01:00
Daira Hopwood bc48ebe898 Improved cross-referencing in Pedersen hash section.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 10:43:48 +01:00
Daira Hopwood 74c39f073d Correct a use of \GroupJ that should have been \MontCurve.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 10:34:56 +01:00
Daira Hopwood 691922ebd1 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 10:27:34 +01:00
Daira Hopwood dc81e21c2b Correct uses of LEOS2IP_l in RedDSAVerify and RedDSABatchVerify to ensure l is a multiple of 8.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 10:27:34 +01:00
Daira Hopwood 5524822ed5 Correct some uses of r_J that should have been r_S or q.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 10:27:34 +01:00
Daira Hopwood dc41de37f3 Avoid clashing notation. Refer to the Montgomery form of Jubjub as \mathbb{M}.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-10-01 10:27:34 +01:00
Jack Grigg 975a2aaa64
Formatting 2018-09-20 11:05:25 +01:00
Ariel cb1e663836
Improve explanation of diversifier sequence choice 2018-09-20 12:11:13 +03:00
Jack Grigg 888681c0b0
Update references to Sapling protocol spec 2018-09-18 11:42:29 +01:00
Jack Grigg 606abd14e2
Be explicit about supported range for the Sapling key path 2018-09-18 11:40:19 +01:00
Jack Grigg 44e9c03d45
dk_i -> dk in "Diversifier derivation" section 2018-09-18 11:39:52 +01:00
Jack Grigg 1f7b5120f1
Clarify that dk is not part of the standard Sapling derivation 2018-09-18 11:38:54 +01:00
Jack Grigg a414e4e7d3
Pull in definition of hardened notation 2018-09-18 11:37:55 +01:00
Jack Grigg 55e3cd177e
Clarify wording about default payment addresses 2018-09-18 11:25:12 +01:00
Noah Vesely ace2fbe622
Add missing 'can' 2018-09-10 16:19:53 -07:00
Daira Hopwood 88e255b63f Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-09-02 09:06:22 +01:00
Daira Hopwood 3ecbe6b903 The rest for beta-30 (sorry, I have a flight to catch).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-09-02 09:06:22 +01:00
Daira Hopwood b909f2a482 Add dates to Change History.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-09-02 09:06:22 +01:00
Daira Hopwood a1f90a56cf Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-09-02 09:06:22 +01:00
Daira Hopwood bfc9ba5b21 Add security argument about DiversifyHash.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-09-02 09:06:22 +01:00
Daira Hopwood 5fd898adea Makefile fixes and improvements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-09-02 09:06:22 +01:00
Daira Hopwood 5361fc591e Cosmetics (pagination in Appendix A).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-09-02 09:06:22 +01:00
Daira Hopwood 2cf4dfacef Correct the description of the N-ary AND optimization (not used in Sapling):
a run of N-1 one bits in c yields an N-ary AND.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-09-02 09:06:22 +01:00
Daira Hopwood 2eec56d936 Add specification for seed fingerprints. 2018-09-01 18:39:41 +01:00
Daira Hopwood 08b8427e91 Don't use 'X' to abbreviate 'extended', since it is ambiguous with 'expanded'. 2018-09-01 18:39:08 +01:00
Daira Hopwood 2aee30ca10 Use the same notation for r_J as the spec. 2018-09-01 18:36:39 +01:00
bitcartel 37da8b64e4
Merge pull request #171 from str4d/zip-243-updates
ZIP 243 updates
2018-08-28 23:04:04 -07:00
Jack Grigg b4abd7fb9b
Fix bugs in ZIP 243 reference implementation
Closes #170.
2018-08-23 15:34:00 +01:00
Jack Grigg 111d0a5cd7
ZIP 243 test vectors 2018-08-23 15:32:38 +01:00
Daira Hopwood 58a12371d1 Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-08-15 15:42:35 +01:00
Daira Hopwood 3049a53843 Remove a resolved TODO.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-08-15 15:40:35 +01:00
Daira Hopwood 4d1cb63baf Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-08-15 15:38:15 +01:00
Daira Hopwood 8364aff29c Change the description of BLAKE2s to correct the constraint count and to describe batched equality checks performed by the sapling-crypto implementation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-08-15 15:07:23 +01:00
Daira Hopwood ad0479ac77 Finish the description of range checks in Appendix A.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-08-15 14:52:50 +01:00
Daira Hopwood bc6a430edc Regenerate PDFs.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-08-14 10:45:52 +01:00
Daira Hopwood 813a8891d1 Rename EncodeFVKParts to EncodeXFVKParts, since its input includes dk which is only part of an extended full viewing key.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 14:48:33 +01:00
Daira Hopwood 511c2eb1e0 Fix a link.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood eb60b41f20 Seeds for Sprout master keys must also be at least 32 bytes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 5cdc69196a Factor out Sprout a_sk encoding/decoding into helper functions.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 3018efc0f3 Correct the encoding of a_sk,par for Sprout child derivation.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 777d82a26f Factor out the encoding of extended {spending key, full viewing key} parts and make it more precise.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 6f966489b8 Correct the derivation of a Sapling child full viewing key's nk, and define the bases G and H.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 1b04d74cde Remove unintended addition of a reference to the non-existant (yet) ZIP 173.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 6e9a79604c Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 42506f08bd Define DiversifyHash.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood ebecd8c1ff Clarify the encoding of a_sk in a Sprout extended spending key. Also exclude lead bytes, and swap ASK and c for consistency with Sapling formats and BIP 32.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 5881d3c211 Define depth, parent tag, and i for master keys.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 7002be59fa Clarify the interpretation of I_L in Sprout key derivation.
This also fixes a cut-and-paste error (a child chain code is c_i, not c_m).

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood ba56f26b4d Explain that some diversifiers are invalid, and correct the definition of default diversifier.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 5788c120e7 Rename s_m to sk_m.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 633436cff6 Specify that the seed MUST be at least 32 bytes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood d65629f7a1 Clarify the relation to existing use of BIPs 32 & 44.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 0034331888 Add MUST NOT to Terminology.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 918ea38834 Fix a cut-and-paste error.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood b9e6ed7e1a Another formatting improvement.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 3e884f9579 Fix formatting.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 52eac8c2c1 Put human-readable parts in monospace.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 0fc7c704a7 Add specifications of key fingerprints, tags, and encodings.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 6f85acb9b1 Specify the range of j when generating diversifiers.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood b3c051eb4f Say that ZIP 32 does not supplant the use of BIPs 32 & 44 for transparent addresses.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 8a49de84f6 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood de065cf344 Update another reference to the Sapling spec version.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood ff5affbc77 Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood f94b9a4c67 Define r_J.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 1b3ea422fe Reference version 2018.0-beta-21 or later of the Sapling protocol spec.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Daira Hopwood 3f2815838e Cosmetic improvements.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
Jack Grigg da683d31b9 Remove hardening from example public-key HD path
Hardened derivation is undefined for an extended FVK
2018-07-25 00:32:43 +01:00
Daira Hopwood 9596aedaa0 ZIP 32: use FF1-AES256 as the PRP.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2018-07-25 00:32:43 +01:00
str4d a01dbbbcbc Note that ZIP 32 is consistently little-endian 2018-07-25 00:32:43 +01:00
str4d f07b6d2613 Define how to derive diversifiers from Sapling extended keys 2018-07-25 00:32:43 +01:00
str4d efd68a4474 Define I2LEOSP_l(k) and use it to encode the child key indices
Note that this means they are encoded in little-endian order, which is the
opposite of BIP 32.
2018-07-25 00:32:43 +01:00
str4d aa36706f38 Fix usage of LEOS2IP in definition of ToScalar 2018-07-25 00:32:43 +01:00
str4d c73733ae13 Define a diversifier key dk 2018-07-25 00:32:43 +01:00
str4d 4ed0316834 Use byte sequences for constant single-byte inputs to PRF_expand 2018-07-25 00:32:43 +01:00
str4d a5309ed60e Address Daira's comments 2018-07-25 00:32:43 +01:00
str4d 9a87098e0c ZIP 32: Shielded Hierarchical Deterministic Wallets 2018-07-25 00:32:43 +01:00
Jack Grigg 22338aa775
ZIP 143: Update test vectors to match generator output 2018-07-06 15:08:14 +01:00
Jack Grigg 868b619a2f
ZIP 143: rST bugfixes 2018-07-06 14:41:53 +01:00
Jay Graber 7e29b5d22f Add specification for empty memo field (first byte 0xF6 2017-02-15 22:24:54 -08:00
Jay Graber 6e25e6bb09 Rename file 2017-02-13 16:45:20 -08:00
Jay Graber fdddcfde7b Add zip for standardizing memo field format 2017-02-08 13:05:06 -08:00
228 changed files with 58334 additions and 5957 deletions

View File

@ -0,0 +1 @@
../../../Dockerfile

View File

@ -0,0 +1,7 @@
name: Render Zcash Protocol Specification
description: GitHub Action to compile Zcash Protocol Specification LaTeX documents
author: Deirdre Connolly
runs:
using: docker
# Runs `make all` or something like it
image: Dockerfile

10
.github/dependabot.yml vendored Normal file
View File

@ -0,0 +1,10 @@
version: 2
updates:
- package-ecosystem: github-actions
directory: "/"
schedule:
interval: daily
timezone: America/New_York
open-pull-requests-limit: 10
labels:
- "A-CI"

19
.github/workflows/render.yml vendored Normal file
View File

@ -0,0 +1,19 @@
name: Render pdfs
on: workflow_dispatch
jobs:
render:
runs-on: ubuntu-latest
steps:
- name: Set up Git repository
uses: actions/checkout@v3.0.2
- name: Compile Zcash Protocol Specification
uses: ./.github/actions/render-protocol-pdf
- uses: EndBug/add-and-commit@v9.0.0
with:
add: '**/*.pdf'
default_author: github_actions

12
.gitignore vendored
View File

@ -3,6 +3,7 @@
*.log
*.bbl
*.blg
*.brf
*.out
*.toc
*.synctex.gz
@ -10,11 +11,22 @@
*.fls
*.bcf
*.run.xml
*.dvi
# Temporary files
.emacs.desktop
.~lock.*
*.swp
*.save
*.save.*
.Makefile.uptodate
.zipfilelist.*
protocol/aux/
protocol/html/
protocol/saplinghtml/
protocol/heartwood.pdf
protocol/protocol.ver
*~

1
CNAME Normal file
View File

@ -0,0 +1 @@
zips.z.cash

15
COPYING.html Normal file
View File

@ -0,0 +1,15 @@
<!DOCTYPE html>
<html>
<head>
<title>COPYING</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<p>Copyright (c) 2016-2020 The Zcash Core developers</p>
<p>Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:</p>
<p>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.</p>
<p>THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</p>
</section>
</body>
</html>

View File

@ -1,4 +1,4 @@
Copyright (c) 2016 The Zcash Core developers
Copyright (c) 2016-2020 The Zcash Core developers
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal

23
Dockerfile Normal file
View File

@ -0,0 +1,23 @@
FROM debian:latest
RUN apt-get update \
&& apt-get install -y \
gawk \
perl \
sed \
git \
python3 \
python3-pip \
pandoc \
biber \
latexmk \
texlive \
texlive-science \
texlive-fonts-extra \
texlive-plain-generic \
texlive-bibtex-extra
RUN pip3 install rst2html5
WORKDIR "/zips"
ENTRYPOINT ["make", "all"]

59
Makefile Normal file
View File

@ -0,0 +1,59 @@
# Dependencies:
# sudo apt-get install python3-pip pandoc perl sed
# sudo pip3 install rst2html5
.PHONY: all all-zips release protocol discard
all-zips: .Makefile.uptodate
find . -name 'zip-*.rst' -o -name 'zip-*.md' |sort >.zipfilelist.new
diff .zipfilelist.current .zipfilelist.new || cp -f .zipfilelist.new .zipfilelist.current
rm -f .zipfilelist.new
$(MAKE) README.rst
$(MAKE) index.html $(addsuffix .html,$(filter-out README,$(basename $(sort $(wildcard *.rst) $(wildcard *.md)))))
all: all-zips protocol
release:
$(MAKE) -C protocol release
protocol:
$(MAKE) -C protocol
discard:
git checkout -- '*.html' 'protocol/*.pdf'
.Makefile.uptodate: Makefile
$(MAKE) clean
touch .Makefile.uptodate
define PROCESSRST
$(eval TITLE := $(shell echo '$(basename $<)' | sed -E 's|zip-0{0,3}|ZIP |;s|draft-|Draft |')$(shell grep -E '^(\.\.)?\s*Title: ' $< |sed -E 's|.*Title||'))
rst2html5 -v --title="$(TITLE)" $< >$@
./edithtml.sh --rst $@
endef
define PROCESSMD
$(eval TITLE := $(shell echo '$(basename $<)' | sed -E 's|zip-0{0,3}|ZIP |;s|draft-|Draft |')$(shell grep -E '^(\.\.)?\s*Title: ' $< |sed -E 's|.*Title||'))
pandoc --from=markdown --to=html $< --output=$@
./edithtml.sh --md $@ "${TITLE}"
endef
index.html: README.rst edithtml.sh
$(PROCESSRST)
%.html: %.rst edithtml.sh
$(PROCESSRST)
%.html: %.md edithtml.sh
$(PROCESSMD)
README.rst: .zipfilelist.current makeindex.sh README.template $(sort $(wildcard zip-*.rst) $(wildcard zip-*.md))
./makeindex.sh | cat README.template - >README.rst
.PHONY: linkcheck
linkcheck: all-zips
$(MAKE) -C protocol all-specs
./links_and_dests.py --check $(filter-out $(wildcard draft-*.html),$(wildcard *.html)) protocol/protocol.pdf protocol/canopy.pdf protocol/heartwood.pdf protocol/blossom.pdf protocol/sapling.pdf
.PHONY: clean
clean:
rm -f .zipfilelist.* README.rst index.html $(addsuffix .html,$(basename $(sort $(wildcard *.rst) $(wildcard *.md))))

View File

@ -1,14 +0,0 @@
zips
====
Specifications and Zcash Improvement Proposals for the
[Zcash cryptocurrency](https://z.cash/).
Participation in the Zcash project is subject to a
[Code of Conduct](https://github.com/zcash/zcash/blob/master/code_of_conduct.md).
License
-------
The contents of this repository are released under the terms of the MIT license.
See [COPYING](COPYING) for more information or see http://opensource.org/licenses/MIT.

160
README.rst Normal file
View File

@ -0,0 +1,160 @@
.. Title: Specifications and Zcash Improvement Proposals
What are ZIPs?
--------------
Zcash Improvement Proposals (ZIPs) are the way to:
* propose new features for the `Zcash cryptocurrency <https://z.cash/>`__ and their rationale,
* specify the implementation details of the feature,
* collect community input on the proposal, and
* document design decisions.
Contributing
------------
The authors of a ZIP are responsible for building consensus within the community
and documenting / addressing dissenting opinions.
Anyone can write a ZIP! We encourage community contributions and decentralization
of work on the Zcash protocol. If youd like to bounce ideas off people before formally
writing a ZIP, we encourage it! Visit the `ZcashCommunity Discord chat <https://discord.gg/kdjfvps>`__
to talk about your idea.
Participation in the Zcash project is subject to a `Code of
Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`__.
The Zcash protocol is documented in its `Protocol Specification <protocol/protocol.pdf>`__.
To start contributing, first read `ZIP 0 <zip-0000.rst>`__ which documents the ZIP process.
Then clone `this repo <https://github.com/zcash/zips>`__ from GitHub, and start adding
your draft ZIP, formatted either as reStructuredText or as Markdown.
For example, if using reStructuredText, use a filename matching ``draft-*.rst``.
Use ``make`` to check that you are using correct
`reStructuredText <https://docutils.sourceforge.io/rst.html>`__ or
`Markdown <https://pandoc.org/MANUAL.html#pandocs-markdown>`__ syntax,
and double-check the generated ``draft-*.html`` file before filing a Pull Request.
NU5 ZIPs
--------
This is the list of ZIPs relevant to the NU5 Upgrade, which `activated on 31st May 2022 <https://z.cash/upgrade/nu5/>`__:
- `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`__ (updated)
- `ZIP 203: Transaction Expiry <zip-0203.rst>`__ (updated)
- `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <zip-0209.rst>`__ (updated)
- `ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <zip-0212.rst>`__ (updated)
- `ZIP 213: Shielded Coinbase <zip-0213.rst>`__ (updated)
- `ZIP 216: Require Canonical Jubjub Point Encodings <zip-0216.rst>`__
- `ZIP 221: FlyClient - Consensus-Layer Changes <zip-0221.rst>`__ (updated)
- `ZIP 224: Orchard Shielded Protocol <zip-0224.rst>`__
- `ZIP 225: Version 5 Transaction Format <zip-0225.rst>`__
- `ZIP 239: Relay of Version 5 Transactions <zip-0239.rst>`__
- `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.rst>`__
- `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`__
- `ZIP 316: Unified Addresses and Unified Viewing Keys <zip-0316.rst>`__
- `ZIP 401: Addressing Mempool Denial-of-Service <zip-0401.rst>`__ (clarified)
License
-------
Unless otherwise stated in this repositorys individual files, the
contents of this repository are released under the terms of the MIT
license. See `COPYING <COPYING.rst>`__ for more information or see
https://opensource.org/licenses/MIT .
Index of ZIPs
-------------
.. raw:: html
<embed><table>
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
<tr> <td>0</td> <td class="left"><a href="zip-0000.rst">ZIP Process</a></td> <td>Active</td>
<tr> <td><span class="reserved">1</span></td> <td class="left"><a class="reserved" href="zip-0001.rst">Network Upgrade Policy and Scheduling</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">2</span></td> <td class="left"><a class="reserved" href="zip-0002.rst">Design Considerations for Network Upgrades</a></td> <td>Reserved</td>
<tr> <td>32</td> <td class="left"><a href="zip-0032.rst">Shielded Hierarchical Deterministic Wallets</a></td> <td>Final</td>
<tr> <td><span class="reserved">76</span></td> <td class="left"><a class="reserved" href="zip-0076.rst">Transaction Signature Validation before Overwinter</a></td> <td>Reserved</td>
<tr> <td>143</td> <td class="left"><a href="zip-0143.rst">Transaction Signature Validation for Overwinter</a></td> <td>Final</td>
<tr> <td>155</td> <td class="left"><a href="zip-0155.rst">addrv2 message</a></td> <td>Proposed</td>
<tr> <td>173</td> <td class="left"><a href="zip-0173.rst">Bech32 Format</a></td> <td>Final</td>
<tr> <td>200</td> <td class="left"><a href="zip-0200.rst">Network Upgrade Mechanism</a></td> <td>Final</td>
<tr> <td>201</td> <td class="left"><a href="zip-0201.rst">Network Peer Management for Overwinter</a></td> <td>Final</td>
<tr> <td>202</td> <td class="left"><a href="zip-0202.rst">Version 3 Transaction Format for Overwinter</a></td> <td>Final</td>
<tr> <td>203</td> <td class="left"><a href="zip-0203.rst">Transaction Expiry</a></td> <td>Final</td>
<tr> <td><span class="reserved">204</span></td> <td class="left"><a class="reserved" href="zip-0204.rst">Zcash P2P Network Protocol</a></td> <td>Reserved</td>
<tr> <td>205</td> <td class="left"><a href="zip-0205.rst">Deployment of the Sapling Network Upgrade</a></td> <td>Final</td>
<tr> <td>206</td> <td class="left"><a href="zip-0206.rst">Deployment of the Blossom Network Upgrade</a></td> <td>Final</td>
<tr> <td>207</td> <td class="left"><a href="zip-0207.rst">Funding Streams</a></td> <td>Final</td>
<tr> <td>208</td> <td class="left"><a href="zip-0208.rst">Shorter Block Target Spacing</a></td> <td>Final</td>
<tr> <td>209</td> <td class="left"><a href="zip-0209.rst">Prohibit Negative Shielded Chain Value Pool Balances</a></td> <td>Final</td>
<tr> <td><strike>210</strike></td> <td class="left"><strike><a href="zip-0210.rst">Sapling Anchor Deduplication within Transactions</a></strike></td> <td>Withdrawn</td>
<tr> <td>211</td> <td class="left"><a href="zip-0211.rst">Disabling Addition of New Value to the Sprout Chain Value Pool</a></td> <td>Final</td>
<tr> <td>212</td> <td class="left"><a href="zip-0212.rst">Allow Recipient to Derive Ephemeral Secret from Note Plaintext</a></td> <td>Final</td>
<tr> <td>213</td> <td class="left"><a href="zip-0213.rst">Shielded Coinbase</a></td> <td>Final</td>
<tr> <td>214</td> <td class="left"><a href="zip-0214.rst">Consensus rules for a Zcash Development Fund</a></td> <td>Final</td>
<tr> <td>215</td> <td class="left"><a href="zip-0215.rst">Explicitly Defining and Modifying Ed25519 Validation Rules</a></td> <td>Final</td>
<tr> <td>216</td> <td class="left"><a href="zip-0216.rst">Require Canonical Jubjub Point Encodings</a></td> <td>Final</td>
<tr> <td><span class="reserved">217</span></td> <td class="left"><a class="reserved" href="zip-0217.rst">Aggregate Signatures</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">219</span></td> <td class="left"><a class="reserved" href="zip-0219.rst">Disabling Addition of New Value to the Sapling Chain Value Pool</a></td> <td>Reserved</td>
<tr> <td><strike>220</strike></td> <td class="left"><strike><a href="zip-0220.rst">Zcash Shielded Assets</a></strike></td> <td>Withdrawn</td>
<tr> <td>221</td> <td class="left"><a href="zip-0221.rst">FlyClient - Consensus-Layer Changes</a></td> <td>Final</td>
<tr> <td>222</td> <td class="left"><a href="zip-0222.rst">Transparent Zcash Extensions</a></td> <td>Draft</td>
<tr> <td>224</td> <td class="left"><a href="zip-0224.rst">Orchard Shielded Protocol</a></td> <td>Final</td>
<tr> <td>225</td> <td class="left"><a href="zip-0225.rst">Version 5 Transaction Format</a></td> <td>Final</td>
<tr> <td><span class="reserved">226</span></td> <td class="left"><a class="reserved" href="zip-0226.rst">Zcash Shielded Assets - Transfers and Burns</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">227</span></td> <td class="left"><a class="reserved" href="zip-0227.rst">Zcash Shielded Assets - Issuance</a></td> <td>Reserved</td>
<tr> <td>239</td> <td class="left"><a href="zip-0239.rst">Relay of Version 5 Transactions</a></td> <td>Final</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243.rst">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
<tr> <td>244</td> <td class="left"><a href="zip-0244.rst">Transaction Identifier Non-Malleability</a></td> <td>Final</td>
<tr> <td>245</td> <td class="left"><a href="zip-0245.rst">Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions</a></td> <td>Draft</td>
<tr> <td>250</td> <td class="left"><a href="zip-0250.rst">Deployment of the Heartwood Network Upgrade</a></td> <td>Final</td>
<tr> <td>251</td> <td class="left"><a href="zip-0251.rst">Deployment of the Canopy Network Upgrade</a></td> <td>Final</td>
<tr> <td>252</td> <td class="left"><a href="zip-0252.rst">Deployment of the NU5 Network Upgrade</a></td> <td>Final</td>
<tr> <td>300</td> <td class="left"><a href="zip-0300.rst">Cross-chain Atomic Transactions</a></td> <td>Proposed</td>
<tr> <td>301</td> <td class="left"><a href="zip-0301.rst">Zcash Stratum Protocol</a></td> <td>Final</td>
<tr> <td>302</td> <td class="left"><a href="zip-0302.rst">Standardized Memo Field Format</a></td> <td>Draft</td>
<tr> <td><span class="reserved">303</span></td> <td class="left"><a class="reserved" href="zip-0303.rst">Sprout Payment Disclosure</a></td> <td>Reserved</td>
<tr> <td>304</td> <td class="left"><a href="zip-0304.rst">Sapling Address Signatures</a></td> <td>Draft</td>
<tr> <td><span class="reserved">305</span></td> <td class="left"><a class="reserved" href="zip-0305.rst">Best Practices for Hardware Wallets supporting Sapling</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">306</span></td> <td class="left"><a class="reserved" href="zip-0306.rst">Security Considerations for Anchor Selection</a></td> <td>Reserved</td>
<tr> <td>307</td> <td class="left"><a href="zip-0307.rst">Light Client Protocol for Payment Detection</a></td> <td>Draft</td>
<tr> <td>308</td> <td class="left"><a href="zip-0308.rst">Sprout to Sapling Migration</a></td> <td>Final</td>
<tr> <td><span class="reserved">309</span></td> <td class="left"><a class="reserved" href="zip-0309.rst">Blind Off-chain Lightweight Transactions (BOLT)</a></td> <td>Reserved</td>
<tr> <td>310</td> <td class="left"><a href="zip-0310.rst">Security Properties of Sapling Viewing Keys</a></td> <td>Draft</td>
<tr> <td><span class="reserved">311</span></td> <td class="left"><a class="reserved" href="zip-0311.rst">Sapling Payment Disclosure</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">312</span></td> <td class="left"><a class="reserved" href="zip-0312.rst">Shielded Multisignatures using FROST</a></td> <td>Reserved</td>
<tr> <td>313</td> <td class="left"><a href="zip-0313.rst">Reduce Conventional Transaction Fee to 1000 zatoshis</a></td> <td>Active</td>
<tr> <td><span class="reserved">314</span></td> <td class="left"><a class="reserved" href="zip-0314.rst">Privacy upgrades to the Zcash light client protocol</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">315</span></td> <td class="left"><a class="reserved" href="zip-0315.rst">Best Practices for Wallet Handling of Multiple Pools</a></td> <td>Reserved</td>
<tr> <td>316</td> <td class="left"><a href="zip-0316.rst">Unified Addresses and Unified Viewing Keys</a></td> <td>Final</td>
<tr> <td>321</td> <td class="left"><a href="zip-0321.rst">Payment Request URIs</a></td> <td>Proposed</td>
<tr> <td><span class="reserved">322</span></td> <td class="left"><a class="reserved" href="zip-0322.rst">Generic Signed Message Format</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">323</span></td> <td class="left"><a class="reserved" href="zip-0323.rst">Specification of getblocktemplate for Zcash</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339.rst">Wallet Recovery Words</a></td> <td>Reserved</td>
<tr> <td>400</td> <td class="left"><a href="zip-0400.rst">Wallet.dat format</a></td> <td>Draft</td>
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing Mempool Denial-of-Service</a></td> <td>Final</td>
<tr> <td><span class="reserved">402</span></td> <td class="left"><a class="reserved" href="zip-0402.rst">New Wallet Database Format</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">403</span></td> <td class="left"><a class="reserved" href="zip-0403.rst">Verification Behaviour of zcashd</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416.rst">Support for Unified Addresses in zcashd</a></td> <td>Reserved</td>
<tr> <td><strike>1001</strike></td> <td class="left"><strike><a href="zip-1001.rst">Keep the Block Distribution as Initially Defined — 90% to Miners</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1002</strike></td> <td class="left"><strike><a href="zip-1002.rst">Opt-in Donation Feature</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1003</strike></td> <td class="left"><strike><a href="zip-1003.rst">20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1004</strike></td> <td class="left"><strike><a href="zip-1004.rst">Miner-Directed Dev Fund</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1005</strike></td> <td class="left"><strike><a href="zip-1005.rst">Zcash Community Funding System</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1006</strike></td> <td class="left"><strike><a href="zip-1006.rst">Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1007</strike></td> <td class="left"><strike><a href="zip-1007.rst">Enforce Development Fund Commitments with a Legal Charter</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1008</strike></td> <td class="left"><strike><a href="zip-1008.rst">Fund ECC for Two More Years</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1009</strike></td> <td class="left"><strike><a href="zip-1009.rst">Five-Entity Strategic Council</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1010</strike></td> <td class="left"><strike><a href="zip-1010.rst">Compromise Dev Fund Proposal With Diverse Funding Streams</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1011</strike></td> <td class="left"><strike><a href="zip-1011.rst">Decentralize the Dev Fee</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1012</strike></td> <td class="left"><strike><a href="zip-1012.rst">Dev Fund to ECC + ZF + Major Grants</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1013</strike></td> <td class="left"><strike><a href="zip-1013.rst">Keep It Simple, Zcashers: 10% to ECC, 10% to ZF</a></strike></td> <td>Obsolete</td>
<tr> <td>1014</td> <td class="left"><a href="zip-1014.rst">Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td> <td>Active</td>
<tr> <td>guide</td> <td class="left"><a href="zip-guide.rst">{Something Short and To the Point}</a></td> <td>Draft</td>
</table></embed>

69
README.template Normal file
View File

@ -0,0 +1,69 @@
.. Title: Specifications and Zcash Improvement Proposals
What are ZIPs?
--------------
Zcash Improvement Proposals (ZIPs) are the way to:
* propose new features for the `Zcash cryptocurrency <https://z.cash/>`__ and their rationale,
* specify the implementation details of the feature,
* collect community input on the proposal, and
* document design decisions.
Contributing
------------
The authors of a ZIP are responsible for building consensus within the community
and documenting / addressing dissenting opinions.
Anyone can write a ZIP! We encourage community contributions and decentralization
of work on the Zcash protocol. If youd like to bounce ideas off people before formally
writing a ZIP, we encourage it! Visit the `ZcashCommunity Discord chat <https://discord.gg/kdjfvps>`__
to talk about your idea.
Participation in the Zcash project is subject to a `Code of
Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`__.
The Zcash protocol is documented in its `Protocol Specification <protocol/protocol.pdf>`__.
To start contributing, first read `ZIP 0 <zip-0000.rst>`__ which documents the ZIP process.
Then clone `this repo <https://github.com/zcash/zips>`__ from GitHub, and start adding
your draft ZIP, formatted either as reStructuredText or as Markdown.
For example, if using reStructuredText, use a filename matching ``draft-*.rst``.
Use ``make`` to check that you are using correct
`reStructuredText <https://docutils.sourceforge.io/rst.html>`__ or
`Markdown <https://pandoc.org/MANUAL.html#pandocs-markdown>`__ syntax,
and double-check the generated ``draft-*.html`` file before filing a Pull Request.
NU5 ZIPs
--------
This is the list of ZIPs relevant to the NU5 Upgrade, which `activated on 31st May 2022 <https://z.cash/upgrade/nu5/>`__:
- `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`__ (updated)
- `ZIP 203: Transaction Expiry <zip-0203.rst>`__ (updated)
- `ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances <zip-0209.rst>`__ (updated)
- `ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <zip-0212.rst>`__ (updated)
- `ZIP 213: Shielded Coinbase <zip-0213.rst>`__ (updated)
- `ZIP 216: Require Canonical Jubjub Point Encodings <zip-0216.rst>`__
- `ZIP 221: FlyClient - Consensus-Layer Changes <zip-0221.rst>`__ (updated)
- `ZIP 224: Orchard Shielded Protocol <zip-0224.rst>`__
- `ZIP 225: Version 5 Transaction Format <zip-0225.rst>`__
- `ZIP 239: Relay of Version 5 Transactions <zip-0239.rst>`__
- `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.rst>`__
- `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`__
- `ZIP 316: Unified Addresses and Unified Viewing Keys <zip-0316.rst>`__
- `ZIP 401: Addressing Mempool Denial-of-Service <zip-0401.rst>`__ (clarified)
License
-------
Unless otherwise stated in this repositorys individual files, the
contents of this repository are released under the terms of the MIT
license. See `COPYING <COPYING.rst>`__ for more information or see
https://opensource.org/licenses/MIT .

3
_config.yml Normal file
View File

@ -0,0 +1,3 @@
theme: jekyll-theme-tactile
url: "https://zips.z.cash"
markdown: GFM

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

View File

@ -0,0 +1,6 @@
<https://commons.wikimedia.org/wiki/File:Chain_link_icon.svg>
(c) Mun May Tee-Galloway <https://commons.wikimedia.org/wiki/User:MGalloway_(WMF)>
This file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license.
The image was rotated, changed from black to blue, and converted to PNG.

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.0 KiB

View File

@ -0,0 +1,59 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="24"
height="24"
version="1.1"
viewBox="0 0 24 24"
id="svg867"
sodipodi:docname="Chain_link_icon.svg"
inkscape:version="0.92.4 (5da689c313, 2019-01-14)">
<defs
id="defs871" />
<sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="2055"
inkscape:window-height="1409"
id="namedview869"
showgrid="false"
inkscape:zoom="67.875"
inkscape:cx="12.618785"
inkscape:cy="12"
inkscape:window-x="1611"
inkscape:window-y="94"
inkscape:window-maximized="0"
inkscape:current-layer="svg867" />
<metadata
id="metadata863">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<path
d="m 19.69017,15.294217 c -0.03449,-2.099683 -1.958927,-3.568298 -3.383399,-5.045063 0.0033,0.199971 0.108205,0.498283 0.113147,0.798247 0.0082,0.499927 -0.08355,1.001514 -0.275302,1.504736 0.813065,0.78676 1.72611,1.571867 1.745817,2.771687 0.0099,0.599914 -0.278604,1.30478 -0.670333,1.811291 -0.983415,1.016296 -2.583239,1.042603 -3.599535,0.0592 l -2.642427,-2.556933 c -0.406518,-0.393366 -0.719635,-1.188325 -0.729521,-1.788274 -0.02302,-1.399811 0.865337,-2.114499 1.956992,-2.632533 L 10.884393,8.9380967 C 9.3977837,9.7626206 8.3176231,10.980582 8.3472099,12.780342 c 0.019729,1.199842 0.5377421,2.291476 1.3491637,2.978263 l 2.6424274,2.556934 c 0.914681,0.885087 2.024408,1.466936 3.324212,1.445528 2.196435,-0.236184 4.063292,-2.267133 4.027101,-4.466807 z M 7.5208098,11.193398 6.606129,10.308312 C 6.1996034,9.9149385 5.8864942,9.1199867 5.8766079,8.5200385 5.8667434,7.9201253 6.155212,7.2152587 6.5469407,6.7087476 7.5303551,5.6924515 9.2301515,5.6645014 10.146476,6.6495597 l 2.642427,2.556933 c 0.406519,0.3933659 0.719635,1.1883253 0.729522,1.7882733 0.02302,1.399812 -0.965316,2.116137 -1.956992,2.632534 l 1.321212,1.278467 C 14.369262,14.081249 15.449416,12.863281 15.419829,11.06352 15.4001,9.8636796 14.882088,8.7720451 14.070665,8.0852572 L 11.428238,5.528324 C 9.7004916,3.8564778 7.00084,3.9008687 5.4291065,5.6269689 3.8556574,7.2530283 3.8016512,10.054367 5.5261077,11.526129 L 7.4570845,13.39463 C 7.3521665,13.096317 7.347234,12.796362 7.3422954,12.496397 7.3340785,11.99647 7.3274984,11.596514 7.520921,11.193256 Z"
id="path865"
inkscape:connector-curvature="0"
inkscape:export-filename="/home/daira/zips/assets/images/section-anchor.png"
inkscape:export-xdpi="450"
inkscape:export-ydpi="450"
style="fill:#0097c1;fill-opacity:1" />
</svg>

After

Width:  |  Height:  |  Size: 3.2 KiB

370
css/style.css Normal file
View File

@ -0,0 +1,370 @@
@media (prefers-color-scheme: light) {
body {
background: #ffffff;
color: #212529;
}
span.reserved {
color: #606060;
}
a, a:visited {
color: #0097c1;
}
a:hover, a.reserved:hover {
color: #00556c;
}
a.reserved, a.reserved:visited {
color: #606060;
}
#index-of-zips table tr:hover {
background-color: #eff1f2;
}
}
@media (prefers-color-scheme: dark) {
body {
background: #111111;
color: #eeeeee;
}
img {
background: #bbbbbb;
}
img.section-anchor {
background: #111111;
}
span.reserved {
color: #a0a0a0;
}
a, a:visited {
color: #00b7e1;
}
a:hover, a.reserved:hover {
color: #00e2f5;
}
a.reserved, a.reserved:visited {
color: #a0a0a0;
}
#index-of-zips table tr:hover {
background-color: #303030;
}
}
@font-face {
font-family: robotolight;
src: url('../assets/fonts/Roboto-Light-webfont.woff') format('woff');
font-weight: 100;
font-style: normal;
}
@font-face {
font-family: robotoregular;
src: url('../assets/fonts/Roboto-Regular-webfont.woff') format('woff');
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: robotomedium;
src: url('../assets/fonts/Roboto-Medium-webfont.woff') format('woff');
font-weight: normal;
font-style: normal;
}
body, body > section {
margin: 0 auto;
padding: 1.5rem 0 3rem;
}
body {
font-family: 'robotoregular',Arial,Helvetica Neue,Helvetica,sans-serif;
line-height: 1.5;
max-width: 1140px;
font-size: 16px;
}
body > section {
max-width: 83.33333%;
}
h1, h2, h3, h4, h5, h6, h7, h8 {
margin: 1.875rem 0 1rem;
}
h1, h2, h3, h4 {
font-family: 'robotolight',Arial,Helvetica Neue,Helvetica,sans-serif;
line-height: 1.3;
font-weight: 100;
}
h5, h6, h7, h8 {
font-family: 'robotomedium',Arial,Helvetica Neue,Helvetica,sans-serif;
line-height: 1.3;
font-weight: 125;
}
h1 {
font-size: 2.5rem;
}
h2 {
font-size: 2.125rem;
}
h3 {
font-size: 1.85rem;
}
h3 code {
font-size: 1.5rem;
}
h4 {
font-size: 1.5rem;
}
h4 code {
font-size: 1.35rem;
}
h5 {
font-size: 1.3rem;
}
h6 {
font-size: 1.3rem;
bottom-padding: 2rem;
}
h7 {
font-size: 1.25rem;
bottom-padding: 2rem;
}
h8 {
font-size: 1.2rem;
bottom-padding: 2rem;
}
blockquote {
margin: 0 1rem 1rem 1rem;
padding: 0;
overflow-x: auto;
}
p, ul, ol, li, table {
margin-top: 0;
}
p {
margin-bottom: 1rem;
}
li {
margin-bottom: 0.2rem;
}
li ul {
margin-top: 0.625rem;
}
ul, ol, table {
margin-bottom: calc( 0.5rem + 0.5ex );
}
p, ul, ol, dl, table {
font-size: 1.125rem;
line-height: 1.625;
}
pre {
display: block;
overflow-x: auto;
overflow-y: hidden;
border: 1px solid #e6e7e8;
padding: 0.625rem;
font-size: 0.9375rem;
}
span.math {
transform: scale(1, 1.03);
-moz-transform: scale(1, 1.03);
-ms-transform: scale(1, 1.03);
-webkit-transform: scale(1, 1.03);
-o-transform: scale(1, 1.03);
font-size: 0.97rem;
}
div.math {
display: block;
overflow-x: auto;
overflow-y: hidden;
margin: 0 1rem 1rem 1rem;
text-align: center;
padding: 0;
font-size: 0.75rem;
}
a, a:visited {
text-decoration: none;
}
a:hover, a.reserved:hover {
text-decoration: underline;
}
a.reserved, a.reserved:visited {
text-decoration: none;
}
span.section-anchor {
opacity: 0;
}
span.section-anchor:hover {
opacity: 1;
}
span.section-heading:hover + span {
opacity: 1;
}
a.footnote_reference::before {
content: "[";
}
a.footnote_reference::after {
content: "]";
}
strong, b {
font-family: 'robotomedium',Arial,Helvetica Neue,Helvetica,sans-serif;
font-weight: normal;
}
hr {
border-top: 1px solid #e6e7e8;
margin: 1.875rem 0;
}
table {
border-collapse: collapse;
border: 0 none transparent;
}
th, td {
border: 1px solid #212529;
}
th, td {
padding-left: 0.7rem;
padding-right: 0.75rem;
padding-top: 0.4rem;
padding-bottom: 0.4rem;
vertical-align: top;
}
td:first-child {
text-align: center;
}
#index-of-zips table td:first-child + td {
padding: 0;
}
#index-of-zips table a {
display: block;
padding-left: 0.7rem;
padding-right: 0.75rem;
padding-top: 0.4rem;
padding-bottom: 0.4rem;
}
#references table, #references th, #references td {
border: 0 none transparent;
font-size: 1.125rem;
}
#references table {
margin-bottom: 0;
}
#references th::before {
content: "[";
}
#references th::after {
content: "]";
}
@media (max-width: 576px) {
table:not(.footnote) {
display: block;
}
pre, div.math {
font-size: 0.5rem;
}
table {
font-size: 0.6rem;
}
}
@media (min-width: 576px) {
body > section {
max-width: initial;
width: 510px;
}
pre, div.math {
font-size: 0.5rem;
}
table {
font-size: 0.6rem;
}
}
@media (min-width: 768px) {
body > section {
width: 690px;
}
pre, div.math {
font-size: 0.55rem;
}
table {
font-size: 0.7rem;
}
}
@media (min-width: 992px) {
body > section {
width: 770px;
}
pre, div.math {
font-size: 0.6rem;
}
table {
font-size: 0.8rem;
}
}
@media (min-width: 1200px) {
body > section {
max-width: initial;
width: 920px;
}
pre, div.math {
font-size: 0.68rem;
}
table {
font-size: 0.85rem;
}
}
@media (min-width: 1390px) {
body > section {
max-width: initial;
width: 1200px;
}
pre, div.math {
font-size: 0.75rem;
}
table {
font-size: 1rem;
}
}

View File

@ -1,453 +0,0 @@
<pre>
ZIP: 0
Title: ZIP Purpose and Guidelines
Author: Daira Hopwood
Status: Active
Category: Process
Created: 2011-08-19
</pre>
==Terminology==
The following ... RFC 2119.
==What is a ZIP?==
ZIP stands for Zcash Improvement Proposal. A ZIP is a design document providing
information to the Zcash community, or describing a new feature for Zcash or its
processes or environment. The ZIP should provide a concise technical specification
of the feature and a rationale for the feature.
We intend ZIPs to be the primary mechanisms for proposing new features, for
collecting community input on an issue, and for documenting the design decisions
that have gone into Zcash. The ZIP authors are responsible for building consensus
within the community and documenting dissenting opinions.
ZIPs go through a sequence of versions as described under `ZIP Versioning`_.
ZIP Categories
==============
There are three kinds of ZIP:
* A Standards Track ZIP describes any change that affects most or all Zcash
implementations, such as a change to the network protocol, a change in block
or transaction validity rules, or any change or addition that affects the
interoperability of applications using Zcash. In particular, ZIPs that
propose changes to consensus MUST be Standards Track.
* An Informational ZIP describes a Zcash design issue, or provides general
guidelines or information to the Zcash community, but does not propose a
new feature. Informational ZIPs do not necessarily represent a Zcash
community consensus or recommendation, so users and implementors are free
to ignore Informational ZIPs or follow their advice.
* A Process ZIP describes a process surrounding Zcash, or proposes a change
to (or an event in) a process. Examples include procedures, guidelines,
changes to the decision-making process, and changes to the tools or
environment used in Zcash development. All Process ZIPs, and only
Process ZIPs, have numbers less than 100.
ZIP Work Flow
=============
The ZIP process begins with a new idea for Zcash. ZIPs do not replace the
`Zcash issue tracker`_; typically, an idea will first have been proposed as an issue on that
tracker, and will be discussed there. Only when and if an idea has progressed to the point
where it is useful to propose a more formal specification, will a ZIP be written.
.. _`Zcash issue tracker`: https://github.com/zcash/zcash/issues
Each potential ZIP must have one or more *authors* -- people who write the ZIP using the
style and format described below, shepherd the discussions in the appropriate forums, and
attempt to build community consensus around the idea. The authors of a ZIP are authorized
to make ... The `ZIP Editors`_
Vetting an idea publicly before going as far as writing a ZIP is meant to save both the
potential authors and the wider community time. The Zcash issue tracker contains many ideas
for changing Zcash that have been rejected for various reasons. Searching this tracker and
asking the Zcash community first if an idea is original helps prevent too much time being
spent on something that is guaranteed to be rejected based on prior discussions. It also
helps to make sure the idea is applicable to the entire community and not just the authors.
Just because an idea sounds good to the authors does not mean it will work for most people
in most areas where Zcash is used.
Small enhancements or patches often don't require a ZIP. These should typically be
injected into the relevant Zcash development work flow with a pull request to the
`Zcash issue tracker`_.
A ZIP should be a clear and complete description of the proposed enhancement.
Technical aesthetics and security auditability are important considerations.
ZIPs need not, and generally SHOULD NOT, propose an implementation. (Note that this differs
from common practice for Bitcoin Improvement Proposals.) They SHOULD, however, discuss
non-trivial implementation considerations whenever appropriate.
The original form of a ZIP is written in (any regional variation of) English, but
translations are encouraged and MAY be placed alongside the original by the ZIP Editor.
Versioning
==========
ZIPs are strictly versioned. The versioning scheme starts with "Draft 1", "Draft 2",
etc., for how ever many drafts are needed. When and if the document is considered by
its authors and the `ZIP Editor`_ to be stable, it becomes "Version 1". Any particular
ZIP might not reach this stage. Subsequent revisions, if any, are called "Version 2",
etc. for how ever many revisions are needed.
A ZIP also has a "Change history", separate from the document itself, giving a brief
summary of the changes made in each version. See `Structure of the ZIPs Repository`_
for detail on how the versions are represented.
The source files for a ZIP are maintained under revision control in the `ZIPs
Repository`_, but the revision history of that repository MAY contain intermediate
commits that do not correspond to document versions.
ZIP Editors
===========
The ZIP Editors are tasked with managing the process of accepting ZIPs, maintaining
the ZIPs Repository, assigning ZIP numbers, and performing minor editing tasks on the
content and metadata of ZIPs. Any major editing SHOULD instead be performed by the
author(s) of a ZIP.
There is presently a single ZIP Editor, Daira Hopwood (but this document still
uses "ZIP Editors" for generality). If there is more than one ZIP Editor at a
given time, they make decisions by informal consensus.
A Process ZIP describing procedures for selecting new ZIP Editors as and when that
becomes necessary SHOULD be submitted before January 1st, 2017.
The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP for
any of the following reasons:
* it violates the `Zcash Code of Conduct`_;
* it appears too unfocussed or broad;
* it duplicates effort in other ZIPs without sufficient technical justification
(however, alternative proposals to address similar or overlapping problems
are not excluded for this reason);
* it has manifest security flaws (including being unrealistically dependent
on user vigilance to avoid security weaknesses);
* it disregards compatibility with the existing Zcash blockchain or ecosystem;
* it is manifestly unimplementable;
* it includes buggy code, pseudocode, or algorithms;
* it manifestly violates common expectations of a significant portion of the
Zcash community;
* it updates a Draft ZIP to Released when there is significant community
opposition to its content (however, Draft ZIPs explicitly may describe
proposals to which there is, or could be expected, significant community
opposition);
* in the case of a Released ZIP, the update makes a substantive change to
which there is significant community opposition;
* it is dependent on a patent that could potentially be an obstacle to
adoption of the ZIP;
* it includes commercial advertising;
* it disregards formatting rules;
* it makes non-editorial edits to previous entries in a ZIP's Change history;
* an update to an existing ZIP extends or changes its scope to an extent
that would be better handled as a separate ZIP;
* a new ZIP has been proposed for a category that does not reflect its content,
or an update would change a ZIP to an inappropriate category;
* it updates a Released ZIP to Draft when the specification is already
implemented and has been in common use;
* it violates any specific "MUST" or "MUST NOT" rule in this document;
* the expressed political views of an author of the document are inimical
to the `Zcash Code of Conduct`_ (except in the case of an update removing
that author);
* it is not authorized by the stated ZIP Authors;
* it removes an author without their consent (unless the reason for removal
is directly related to a breach of the Code of Conduct by that author);
* it is spam.
.. _`Zcash Contributor Code of Conduct`: https://github.com/zcash/zcash/blob/master/code_of_conduct.md
The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal or update
that does not violate any of these criteria. If they refuse a proposal or update,
they MUST give an explanation of which of the criteria were violated, with the
exception that spam may be deleted without an explanation.
Note that it is not the primary responsibility of the ZIP Editors to review
proposals for security, correctness, or implementability.
Please send all ZIP-related communications either by email to <zips@z.cash>, or by
opening an issue on the `ZIPs issue tracker`_. However if a communication concerns
a potential security vulnerability that could affect Zcash users, the
`Coordinated Security Disclosure Procedure`_ SHOULD be followed.
.. _`ZIPs issue tracker`: https://github.com/zcash/zips/issues
Authors of proposed ZIPs MUST NOT self-assign ZIP numbers. Proposals and updates
SHOULD be made as pull requests to the ZIPs Repository. A proposal for a new ZIP
MUST indicate whether it is intended to be Standards Track, Informational, or
Process. It is also possible to update an Informational ZIP to be Standards Track
or vice-versa, with the approval of the ZIP Editors. It is not possible to change
a Process ZIP to another category of ZIP, or vice versa. Each ZIP MUST be initially
proposed as a Draft.
A ZIP author may at any time withdraw their authorship on any or all versions
of a ZIP (even if this results in there being no authors for a given version).
Withdrawal of authorship is recorded in the ZIP metadata. An author who has
changed their name, formally or informally, can also ask for their name to be
updated on the ZIP metadata; the result will not include their previous name
unless they ask for it to. (As a technical caveat, the previous name may still
be visible in previous git revisions of the `ZIPs Repository`_ that remain
publically accessible, although it may be possible to fix that by a force-push.)
Relation to the Zcash Protocol Specification
============================================
The `Zcash Protocol Specification`_ describes aspects of the
The canonical description of Zcash consensus and security requirements is the
protocol specification. It is the responsibility of the ZIP Editors and the
authors of the protocol specification to maintain consistency between the
specification and ZIPs that overlap its scope.
The protocol specification SHOULD explicitly reference ZIPs that describe
proposals that are incorporated into it. Duplication between the protocol
specification and such ZIPs is inevitable and acceptable.
To minimize the risk of unintended discrepancies, a ZIP that proposes to change
consensus behaviour SHOULD express its proposal in terms of specific text to be
added or changed in the specification (in addition to motivation, history,
alternative approaches that were not adopted, etc., which may not be appropriate
for the specification).
It is highly recommended that a single ZIP contain a single key proposal or new
idea. The more focussed the ZIP, the more successful it is likely to be. If in
doubt, split your ZIP into several well-focussed ones.
Both initial proposals and updates to ZIPs SHOULD be submitted by an author of
the document as a pull request to the `ZIPs repository`_.
A ZIP can also be assigned status "Deferred". The ZIP author or editor can assign
the ZIP this status when no progress is being made on the ZIP. Once a ZIP is
deferred, the ZIP editor can re-assign it to draft status.
A ZIP can also be "Rejected". Perhaps after all is said and done it was not a good
idea. It is still important to have a record of this fact.
The possible paths of the status of ZIPs are as follows:
<img src=ZIP-0001/process.png></img>
Some Informational and Process ZIPs may also have a status of "Active" if they are
never meant to be completed. E.g. ZIP 1 (this ZIP).
==What belongs in a successful ZIP?==
Each ZIP should have the following parts:
* Preamble -- RFC 822 style headers containing meta-data about the ZIP, including
the ZIP number, a short descriptive title (limited to a maximum of 44 characters),
the names, and optionally the contact info for each author, etc.
* Abstract -- a short description of the issue being addressed.
* Copyright -- Each ZIP MUST be licensed under the MIT License, unless the
ZIP Editor makes an explicit exception to resolve a license incompatibility
with a work from which the ZIP is derived. In the latter case the license
MUST be explicitly stated in the ZIP metadata and MUST satisfy the
`Open Source Definition`_ (interpreted to apply to documentation).
.. _`Open Source Definition`: https://opensource.org/osd-annotated
* Specification -- The technical specification should describe the syntax and
semantics of any new feature. The specification should be detailed enough to allow
competing, interoperable implementations in principle (whether or not multiple
implementations exist).
* Motivation -- The motivation is critical for ZIPs that want to change the Zcash
protocol. It should clearly explain why the existing protocol specification is
inadequate to address the problem that the ZIP solves. ZIP submissions without
sufficient motivation may be rejected outright.
* Rationale -- The rationale fleshes out the specification by describing what
motivated the design and why particular design decisions were made. It should
describe alternate designs that were considered and related work.
* The rationale should provide evidence of consensus within the community and
discuss important objections or concerns raised during discussion.
* Backwards Compatibility -- All ZIPs that introduce backwards incompatibilities
MUST include a section describing these incompatibilities and their severity. The
ZIP MUST explain how the author proposes to deal with these incompatibilities.
Formatting Rules
================
The metadata of a ZIP MUST be represented as a reStructuredText file.
This file includes:
* a Change history ...
* the current authors.
Each Change history entry includes:
* a description of what was changed (this can be just "initial draft" or
similar in the case of the first draft).
* a link to the main reStructuredText or LaTeX source file for that
version.
* a link to a rendered PDF file for that version.
* the new authors, if this is the first draft or the authors have changed.
ZIPs can be represented in either `reStructuredText`_ or `LaTeX`_ format.
Images and diagrams can be included ..., provided that a rendering to
a PNG image is included. SVG is a preferred source format.
The ZIP Editor MAY accept other formats. Formats that depend on proprietary
software are strongly discouraged.
Rules specific to reStructuredText
----------------------------------
The source for the `rst` file MUST be readable in an editor window set to
90 columns, except possibly where prevented by reStructuredText technical
limitations (such as avoiding wrapping of URLs).
The document MAY include images in .png format.
Rules specific to LaTeX
-----------------------
The ZIP directory MUST contain a ``Makefile``, the default target of
which produces a PDF file.
The README.rst file MUST include instructions to build the PDF (including
build dependencies for at least Debian-like systems).
The typographical conventions used by a LaTeX-formatted ZIP SHOULD be
consistent, as far as possible, with those used in the `Zcash protocol specification`_.
It is desirable, but not strictly necessary, that the macros used in
the protocol specification also be used in LaTeX-formatted ZIPs. This
facilitates editing accepted proposals into the main specification.
===ZIP Header Preamble===
Each ZIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
<pre>
ZIP: <ZIP number>
Title: <ZIP title>
Author: <list of authors' real names and optionally, email addrs>
* Discussions-To: <email address>
Status: <Draft | Active | Accepted | Deferred | Rejected |
Withdrawn | Final | Superseded>
Type: <Standards Track | Informational | Process>
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
* Post-History: <dates of postings to Zcash mailing list>
* Replaces: <ZIP number>
* Superseded-By: <ZIP number>
* Resolution: <url>
</pre>
The Author header lists the names, and optionally the email addresses of all the authors/owners of the ZIP. The format of the Author header value must be
Random J. User <address@dom.ain>
if the email address is included, and just
Random J. User
if the address is not given.
If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.
Note: The Resolution header is required for Standards Track ZIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the ZIP is made.
While a ZIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the ZIP is being discussed. No Discussions-To header is necessary if the ZIP is being discussed privately with the author, or on the bitcoin email mailing lists.
The Type header specifies the type of ZIP: Standards Track, Informational, or Process.
The Created header records the date that the ZIP was assigned a number, while Post-History is used to record the dates of when new versions of the ZIP are posted to Zcash mailing lists. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.
ZIPs may have a Requires header, indicating the ZIP numbers that this ZIP depends on.
ZIPs may also have a Superseded-By header indicating that a ZIP has been rendered obsolete by a later document; the value is the number of the ZIP that replaces the current document. The newer ZIP must have a Replaces header containing the number of the ZIP that it rendered obsolete.
===Auxiliary Files===
ZIPs may include auxiliary files such as diagrams. Image files should be included in a subdirectory for that ZIP. Auxiliary files must be named ZIP-XXXX-Y.ext, where "XXXX" is the ZIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png").
==Transferring ZIP Ownership==
It occasionally becomes necessary to transfer ownership of ZIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred ZIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the ZIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the ZIP. We try to build consensus around a ZIP, but if that's not possible, you can always submit a competing ZIP.
If you are interested in assuming ownership of a ZIP, send a message asking to take over, addressed to both the original author and the ZIP editor. If the original author doesn't respond to email in a timely manner, the ZIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
==ZIP Editors==
The current ZIP editor is Luke Dashjr who can be contacted at [[mailto:luke_ZIPeditor@dashjr.org|luke_ZIPeditor@dashjr.org]].
==ZIP Editor Responsibilities & Workflow==
The ZIP editor subscribes to the Zcash development mailing list. All ZIP-related
correspondence should be sent (or CC'd) to luke_ZIPeditor@dashjr.org.
For each new ZIP that comes in an editor does the following:
* Read the ZIP to check if it is ready: sound and complete. The ideas must make technical
sense, even if they don't seem likely to be accepted.
* The title should accurately describe the content.
* Edit the ZIP for language (spelling, grammar, sentence structure, etc.),
markup, code style (examples should match ZIP 8 & 7).
If the ZIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
Once the ZIP is ready for the repository it should be submitted as a "pull request" to the [https://github.com/Zcash/ZIPs Zcash/ZIPs] repository on GitHub where it may get further feedback.
The ZIP Editors will:
* Assign a ZIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141) in the pull request comments.
* Merge the pull request when the author is ready (allowing some time for further peer review).
* List the ZIP in [[README.mediawiki]]
* Send email back to the ZIP author with next steps (post to Zcash-dev mailing list).
The ZIP editors are intended to fulfill administrative and editorial responsibilities. The ZIP editors monitor ZIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
==History==
This document is derived heavily from Bitcoin's BIP 1, authored by Amir Taaki,
which in turn was derived from Python's PEP-0001. In many places text was simply
copied and modified. The authors of PEP-0001 (Barry Warsaw, Jeremy Hylton, and
David Goodger) and BIP 1 (Amir Taaki) are not responsible for any use of their
text or ideas in the Zcash Improvement Process. The `I2P Proposal Process`_
and the RFC Process also influenced this document.
Please direct all comments to the ZIP Editors by email to <zips@z.cash> or by
filing an issue in the `ZIPs issue tracker`_.
Change history (move this to metadata)
==============
Draft 1
-------
Initial version based mainly on BIP 1. Changes include:
* Obvious renamings.
* Changes of forum, e.g. Zcash development uses GitHub repositories
and issue tracking to a greater extent than Bitcoin, and does not
rely on mailing lists.
* We use "ZIP Editors" even though that is currently only one person.
Similarly a given ZIP may have more than one author, and authors
have equal status.
* The list of potential reasons for rejection of a ZIP is expanded
from the corresponding reasons for a BIP, and more precisely defined.

41
edithtml.sh Executable file
View File

@ -0,0 +1,41 @@
#!/bin/sh
if ! ( ( [ "x$1" = "x--rst" ] && [ $# -eq 2 ] ) || ( [ "x$1" = "x--md" ] && [ $# -eq 3 ] ) ); then
echo "Usage: edithtml.sh --rst <htmlfile>"
echo " or: edithtml.sh --md <htmlfile> <title>"
exit
fi
if ! [ -f "$2" ]; then
echo File not found: "$2"
exit
fi
if [ "x$1" = "x--rst" ]; then
sed -i.sedbak 's|</head>|<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>|' $2
sed -i.sedbak 's|http://cdn.mathjax.org/mathjax/latest/MathJax.js|https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js|' $2
else
cat - "$2" >"$2".prefix <<EOF
<!DOCTYPE html>
<html>
<head>
<title>$3</title>
<meta charset="utf-8" />
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css">
</head>
<body>
EOF
cat "$2.prefix" - >"$2" <<EOF
</body>
</html>
EOF
rm -f "$2".prefix
fi
sed -i.sedbak 's|<a \(class=[^ ]* \)*href="\([^":]*\)\.rst\(\#[^"]*\)*">|<a \1href="\2\3">|g' "$2"
sed -i.sedbak 's|&lt;\(https:[^&]*\)&gt;|\&lt;<a href="\1">\1</a>\&gt;|g' "$2"
perl -i.sedbak -p0e 's|<section id="([^"]*)">\s*.?\s*<h([1-9])>([^<]*(?:<code>[^<]*</code>[^<]*)?)</h([1-9])>|<section id="\1"><h\2><span class="section-heading">\3</span><span class="section-anchor"> <a rel="bookmark" href="#\1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h\4>|g' "$2"
rm -f *.sedbak

137
index.html Normal file
View File

@ -0,0 +1,137 @@
<!DOCTYPE html>
<html>
<head>
<title>README: Specifications and Zcash Improvement Proposals</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<!-- Title: Specifications and Zcash Improvement Proposals -->
<section id="what-are-zips"><h2><span class="section-heading">What are ZIPs?</span><span class="section-anchor"> <a rel="bookmark" href="#what-are-zips"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Zcash Improvement Proposals (ZIPs) are the way to:</p>
<ul>
<li>propose new features for the <a href="https://z.cash/">Zcash cryptocurrency</a> and their rationale,</li>
<li>specify the implementation details of the feature,</li>
<li>collect community input on the proposal, and</li>
<li>document design decisions.</li>
</ul>
</section>
<section id="contributing"><h2><span class="section-heading">Contributing</span><span class="section-anchor"> <a rel="bookmark" href="#contributing"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The authors of a ZIP are responsible for building consensus within the community and documenting / addressing dissenting opinions.</p>
<p>Anyone can write a ZIP! We encourage community contributions and decentralization of work on the Zcash protocol. If youd like to bounce ideas off people before formally writing a ZIP, we encourage it! Visit the <a href="https://discord.gg/kdjfvps">ZcashCommunity Discord chat</a> to talk about your idea.</p>
<p>Participation in the Zcash project is subject to a <a href="https://github.com/zcash/zcash/blob/master/code_of_conduct.md">Code of Conduct</a>.</p>
<p>The Zcash protocol is documented in its <a href="protocol/protocol.pdf">Protocol Specification</a>.</p>
<p>To start contributing, first read <a href="zip-0000">ZIP 0</a> which documents the ZIP process. Then clone <a href="https://github.com/zcash/zips">this repo</a> from GitHub, and start adding your draft ZIP, formatted either as reStructuredText or as Markdown.</p>
<p>For example, if using reStructuredText, use a filename matching <code>draft-*.rst</code>. Use <code>make</code> to check that you are using correct <a href="https://docutils.sourceforge.io/rst.html">reStructuredText</a> or <a href="https://pandoc.org/MANUAL.html#pandocs-markdown">Markdown</a> syntax, and double-check the generated <code>draft-*.html</code> file before filing a Pull Request.</p>
</section>
<section id="nu5-zips"><h2><span class="section-heading">NU5 ZIPs</span><span class="section-anchor"> <a rel="bookmark" href="#nu5-zips"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This is the list of ZIPs relevant to the NU5 Upgrade, which <a href="https://z.cash/upgrade/nu5/">activated on 31st May 2022</a>:</p>
<ul>
<li><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a> (updated)</li>
<li><a href="zip-0203">ZIP 203: Transaction Expiry</a> (updated)</li>
<li><a href="zip-0209">ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances</a> (updated)</li>
<li><a href="zip-0212">ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext</a> (updated)</li>
<li><a href="zip-0213">ZIP 213: Shielded Coinbase</a> (updated)</li>
<li><a href="zip-0216">ZIP 216: Require Canonical Jubjub Point Encodings</a></li>
<li><a href="zip-0221">ZIP 221: FlyClient - Consensus-Layer Changes</a> (updated)</li>
<li><a href="zip-0224">ZIP 224: Orchard Shielded Protocol</a></li>
<li><a href="zip-0225">ZIP 225: Version 5 Transaction Format</a></li>
<li><a href="zip-0239">ZIP 239: Relay of Version 5 Transactions</a></li>
<li><a href="zip-0244">ZIP 244: Transaction Identifier Non-Malleability</a></li>
<li><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></li>
<li><a href="zip-0316">ZIP 316: Unified Addresses and Unified Viewing Keys</a></li>
<li><a href="zip-0401">ZIP 401: Addressing Mempool Denial-of-Service</a> (clarified)</li>
</ul>
</section>
<section id="license"><h2><span class="section-heading">License</span><span class="section-anchor"> <a rel="bookmark" href="#license"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Unless otherwise stated in this repositorys individual files, the contents of this repository are released under the terms of the MIT license. See <a href="COPYING">COPYING</a> for more information or see <a href="https://opensource.org/licenses/MIT">https://opensource.org/licenses/MIT</a> .</p>
</section>
<section id="index-of-zips"><h2><span class="section-heading">Index of ZIPs</span><span class="section-anchor"> <a rel="bookmark" href="#index-of-zips"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<embed><table>
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
<tr> <td>0</td> <td class="left"><a href="zip-0000">ZIP Process</a></td> <td>Active</td>
<tr> <td><span class="reserved">1</span></td> <td class="left"><a class="reserved" href="zip-0001">Network Upgrade Policy and Scheduling</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">2</span></td> <td class="left"><a class="reserved" href="zip-0002">Design Considerations for Network Upgrades</a></td> <td>Reserved</td>
<tr> <td>32</td> <td class="left"><a href="zip-0032">Shielded Hierarchical Deterministic Wallets</a></td> <td>Final</td>
<tr> <td><span class="reserved">76</span></td> <td class="left"><a class="reserved" href="zip-0076">Transaction Signature Validation before Overwinter</a></td> <td>Reserved</td>
<tr> <td>143</td> <td class="left"><a href="zip-0143">Transaction Signature Validation for Overwinter</a></td> <td>Final</td>
<tr> <td>155</td> <td class="left"><a href="zip-0155">addrv2 message</a></td> <td>Proposed</td>
<tr> <td>173</td> <td class="left"><a href="zip-0173">Bech32 Format</a></td> <td>Final</td>
<tr> <td>200</td> <td class="left"><a href="zip-0200">Network Upgrade Mechanism</a></td> <td>Final</td>
<tr> <td>201</td> <td class="left"><a href="zip-0201">Network Peer Management for Overwinter</a></td> <td>Final</td>
<tr> <td>202</td> <td class="left"><a href="zip-0202">Version 3 Transaction Format for Overwinter</a></td> <td>Final</td>
<tr> <td>203</td> <td class="left"><a href="zip-0203">Transaction Expiry</a></td> <td>Final</td>
<tr> <td><span class="reserved">204</span></td> <td class="left"><a class="reserved" href="zip-0204">Zcash P2P Network Protocol</a></td> <td>Reserved</td>
<tr> <td>205</td> <td class="left"><a href="zip-0205">Deployment of the Sapling Network Upgrade</a></td> <td>Final</td>
<tr> <td>206</td> <td class="left"><a href="zip-0206">Deployment of the Blossom Network Upgrade</a></td> <td>Final</td>
<tr> <td>207</td> <td class="left"><a href="zip-0207">Funding Streams</a></td> <td>Final</td>
<tr> <td>208</td> <td class="left"><a href="zip-0208">Shorter Block Target Spacing</a></td> <td>Final</td>
<tr> <td>209</td> <td class="left"><a href="zip-0209">Prohibit Negative Shielded Chain Value Pool Balances</a></td> <td>Final</td>
<tr> <td><strike>210</strike></td> <td class="left"><strike><a href="zip-0210">Sapling Anchor Deduplication within Transactions</a></strike></td> <td>Withdrawn</td>
<tr> <td>211</td> <td class="left"><a href="zip-0211">Disabling Addition of New Value to the Sprout Chain Value Pool</a></td> <td>Final</td>
<tr> <td>212</td> <td class="left"><a href="zip-0212">Allow Recipient to Derive Ephemeral Secret from Note Plaintext</a></td> <td>Final</td>
<tr> <td>213</td> <td class="left"><a href="zip-0213">Shielded Coinbase</a></td> <td>Final</td>
<tr> <td>214</td> <td class="left"><a href="zip-0214">Consensus rules for a Zcash Development Fund</a></td> <td>Final</td>
<tr> <td>215</td> <td class="left"><a href="zip-0215">Explicitly Defining and Modifying Ed25519 Validation Rules</a></td> <td>Final</td>
<tr> <td>216</td> <td class="left"><a href="zip-0216">Require Canonical Jubjub Point Encodings</a></td> <td>Final</td>
<tr> <td><span class="reserved">217</span></td> <td class="left"><a class="reserved" href="zip-0217">Aggregate Signatures</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">219</span></td> <td class="left"><a class="reserved" href="zip-0219">Disabling Addition of New Value to the Sapling Chain Value Pool</a></td> <td>Reserved</td>
<tr> <td><strike>220</strike></td> <td class="left"><strike><a href="zip-0220">Zcash Shielded Assets</a></strike></td> <td>Withdrawn</td>
<tr> <td>221</td> <td class="left"><a href="zip-0221">FlyClient - Consensus-Layer Changes</a></td> <td>Final</td>
<tr> <td>222</td> <td class="left"><a href="zip-0222">Transparent Zcash Extensions</a></td> <td>Draft</td>
<tr> <td>224</td> <td class="left"><a href="zip-0224">Orchard Shielded Protocol</a></td> <td>Final</td>
<tr> <td>225</td> <td class="left"><a href="zip-0225">Version 5 Transaction Format</a></td> <td>Final</td>
<tr> <td><span class="reserved">226</span></td> <td class="left"><a class="reserved" href="zip-0226">Zcash Shielded Assets - Transfers and Burns</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">227</span></td> <td class="left"><a class="reserved" href="zip-0227">Zcash Shielded Assets - Issuance</a></td> <td>Reserved</td>
<tr> <td>239</td> <td class="left"><a href="zip-0239">Relay of Version 5 Transactions</a></td> <td>Final</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
<tr> <td>244</td> <td class="left"><a href="zip-0244">Transaction Identifier Non-Malleability</a></td> <td>Final</td>
<tr> <td>245</td> <td class="left"><a href="zip-0245">Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions</a></td> <td>Draft</td>
<tr> <td>250</td> <td class="left"><a href="zip-0250">Deployment of the Heartwood Network Upgrade</a></td> <td>Final</td>
<tr> <td>251</td> <td class="left"><a href="zip-0251">Deployment of the Canopy Network Upgrade</a></td> <td>Final</td>
<tr> <td>252</td> <td class="left"><a href="zip-0252">Deployment of the NU5 Network Upgrade</a></td> <td>Final</td>
<tr> <td>300</td> <td class="left"><a href="zip-0300">Cross-chain Atomic Transactions</a></td> <td>Proposed</td>
<tr> <td>301</td> <td class="left"><a href="zip-0301">Zcash Stratum Protocol</a></td> <td>Final</td>
<tr> <td>302</td> <td class="left"><a href="zip-0302">Standardized Memo Field Format</a></td> <td>Draft</td>
<tr> <td><span class="reserved">303</span></td> <td class="left"><a class="reserved" href="zip-0303">Sprout Payment Disclosure</a></td> <td>Reserved</td>
<tr> <td>304</td> <td class="left"><a href="zip-0304">Sapling Address Signatures</a></td> <td>Draft</td>
<tr> <td><span class="reserved">305</span></td> <td class="left"><a class="reserved" href="zip-0305">Best Practices for Hardware Wallets supporting Sapling</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">306</span></td> <td class="left"><a class="reserved" href="zip-0306">Security Considerations for Anchor Selection</a></td> <td>Reserved</td>
<tr> <td>307</td> <td class="left"><a href="zip-0307">Light Client Protocol for Payment Detection</a></td> <td>Draft</td>
<tr> <td>308</td> <td class="left"><a href="zip-0308">Sprout to Sapling Migration</a></td> <td>Final</td>
<tr> <td><span class="reserved">309</span></td> <td class="left"><a class="reserved" href="zip-0309">Blind Off-chain Lightweight Transactions (BOLT)</a></td> <td>Reserved</td>
<tr> <td>310</td> <td class="left"><a href="zip-0310">Security Properties of Sapling Viewing Keys</a></td> <td>Draft</td>
<tr> <td><span class="reserved">311</span></td> <td class="left"><a class="reserved" href="zip-0311">Sapling Payment Disclosure</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">312</span></td> <td class="left"><a class="reserved" href="zip-0312">Shielded Multisignatures using FROST</a></td> <td>Reserved</td>
<tr> <td>313</td> <td class="left"><a href="zip-0313">Reduce Conventional Transaction Fee to 1000 zatoshis</a></td> <td>Active</td>
<tr> <td><span class="reserved">314</span></td> <td class="left"><a class="reserved" href="zip-0314">Privacy upgrades to the Zcash light client protocol</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">315</span></td> <td class="left"><a class="reserved" href="zip-0315">Best Practices for Wallet Handling of Multiple Pools</a></td> <td>Reserved</td>
<tr> <td>316</td> <td class="left"><a href="zip-0316">Unified Addresses and Unified Viewing Keys</a></td> <td>Final</td>
<tr> <td>321</td> <td class="left"><a href="zip-0321">Payment Request URIs</a></td> <td>Proposed</td>
<tr> <td><span class="reserved">322</span></td> <td class="left"><a class="reserved" href="zip-0322">Generic Signed Message Format</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">323</span></td> <td class="left"><a class="reserved" href="zip-0323">Specification of getblocktemplate for Zcash</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339">Wallet Recovery Words</a></td> <td>Reserved</td>
<tr> <td>400</td> <td class="left"><a href="zip-0400">Wallet.dat format</a></td> <td>Draft</td>
<tr> <td>401</td> <td class="left"><a href="zip-0401">Addressing Mempool Denial-of-Service</a></td> <td>Final</td>
<tr> <td><span class="reserved">402</span></td> <td class="left"><a class="reserved" href="zip-0402">New Wallet Database Format</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">403</span></td> <td class="left"><a class="reserved" href="zip-0403">Verification Behaviour of zcashd</a></td> <td>Reserved</td>
<tr> <td><span class="reserved">416</span></td> <td class="left"><a class="reserved" href="zip-0416">Support for Unified Addresses in zcashd</a></td> <td>Reserved</td>
<tr> <td><strike>1001</strike></td> <td class="left"><strike><a href="zip-1001">Keep the Block Distribution as Initially Defined — 90% to Miners</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1002</strike></td> <td class="left"><strike><a href="zip-1002">Opt-in Donation Feature</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1003</strike></td> <td class="left"><strike><a href="zip-1003">20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1004</strike></td> <td class="left"><strike><a href="zip-1004">Miner-Directed Dev Fund</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1005</strike></td> <td class="left"><strike><a href="zip-1005">Zcash Community Funding System</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1006</strike></td> <td class="left"><strike><a href="zip-1006">Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1007</strike></td> <td class="left"><strike><a href="zip-1007">Enforce Development Fund Commitments with a Legal Charter</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1008</strike></td> <td class="left"><strike><a href="zip-1008">Fund ECC for Two More Years</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1009</strike></td> <td class="left"><strike><a href="zip-1009">Five-Entity Strategic Council</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1010</strike></td> <td class="left"><strike><a href="zip-1010">Compromise Dev Fund Proposal With Diverse Funding Streams</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1011</strike></td> <td class="left"><strike><a href="zip-1011">Decentralize the Dev Fee</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1012</strike></td> <td class="left"><strike><a href="zip-1012">Dev Fund to ECC + ZF + Major Grants</a></strike></td> <td>Obsolete</td>
<tr> <td><strike>1013</strike></td> <td class="left"><strike><a href="zip-1013">Keep It Simple, Zcashers: 10% to ECC, 10% to ZF</a></strike></td> <td>Obsolete</td>
<tr> <td>1014</td> <td class="left"><a href="zip-1014">Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td> <td>Active</td>
<tr> <td>guide</td> <td class="left"><a href="zip-guide">{Something Short and To the Point}</a></td> <td>Draft</td>
</table></embed></section>
</section>
</body>
</html>

224
links_and_dests.py Executable file
View File

@ -0,0 +1,224 @@
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from urllib.request import build_opener, HTTPCookieProcessor, HTTPSHandler, Request
from urllib.error import URLError, HTTPError
from os.path import relpath
from collections import deque
import sys
from time import sleep
import ssl
from io import BytesIO
try:
from bs4 import BeautifulSoup
import html5lib
import certifi
except ImportError:
print("Please install the BeautifulSoup, html5lib, and certifi libraries using `pip install bs4 html5lib certifi`.\n")
raise
if [int(v) for v in certifi.__version__.split('.')] < [2021, 5, 30]:
print("Please upgrade certifi using `pip install --upgrade certifi`.\n")
sys.exit(1)
def get_links_and_destinations_from_pdf(f):
try:
from PyPDF2 import PdfFileReader
except ImportError:
print("Please install the PyPDF2 library using `pip install PyPDF2`.\n")
raise
# Based on <https://stackoverflow.com/a/5978161/393146>
pdf = PdfFileReader(f)
links = set()
for pg in range(pdf.getNumPages()):
obj = pdf.getPage(pg).getObject()
for annotation in obj.get('/Annots', []):
uri = annotation.getObject().get('/A', {}).get('/URI', None)
if uri is not None and uri not in links:
links.add(uri)
dests = pdf.getNamedDestinations().keys()
return (links, dests)
def get_links_and_destinations_from_html(f):
links = set()
internal = set()
dests = set()
soup = BeautifulSoup(f.read(), "html5lib")
for link in soup.find_all('a'):
if link.has_attr('href'):
url = link['href']
(internal if url.startswith('#') else links).add(url)
if link.has_attr('name'):
dests.add(link['name'])
for link in soup.find_all(id=True):
dests.add(link['id'])
# GitHub's rendering of .mediawiki files puts 'id="user-content-<ANCHOR>"' in the source
# and dynamically creates a corresponding link #<ANCHOR>.
if link['id'].startswith("user-content-"):
dests.add(link['id'][13:])
internal.difference_update(['#' + d for d in dests]) # ignore internal links satisfied by a dest
links.update(internal)
return (links, dests)
def main(args):
if len(args) < 2:
print("Usage: ./links_and_dests.py [--check] [--print-dests] <file.pdf|html|xhtml>")
return 1
check = '--check' in args[1:]
print_dests = '--print-dests' in args[1:]
paths = [arg for arg in args[1:] if not arg.startswith('--')]
all_links = {} # url -> pdf_paths
all_dests = {} # url -> dests
errors = deque()
print("Reading files...")
for path in paths:
print(path, end=" ")
sys.stdout.flush()
with open(path, 'rb') as f:
if path.endswith(".html") or path.endswith(".xhtml"):
(links, dests) = get_links_and_destinations_from_html(f)
elif path.endswith(".pdf"):
(links, dests) = get_links_and_destinations_from_pdf(f)
else:
errors.append("Unrecognized file type: " + path)
continue
path = relpath(path)
for l in links:
refs = all_links.get(l, None)
if refs is None:
all_links[l] = refs = deque()
refs.append(path)
all_dests["https://zips.z.cash/" + path] = dests
if path.endswith(".html"):
all_dests["https://zips.z.cash/" + path[:-5]] = dests
print("\n")
print("Links:")
last_url = None
content = None
content_type = None
dests = None
for (l, p) in sorted(all_links.items()):
print(l, end=" ")
sys.stdout.flush()
what = "%s (occurs in %s)" % (l, " and ".join(p)) if len(paths) > 1 else l
status = ""
if ":" not in l:
l = "https://zips.z.cash/" + l
if l.startswith("mailto:"):
status = "(not checked)"
elif l.startswith("https:") or l.startswith("HTTP:"): # use uppercase HTTP: for links with no https: equivalent
(url, _, fragment) = l.partition("#")
if url in all_dests:
if fragment and fragment not in all_dests[url]:
errors.append("Missing link target: " + what)
status = ""
else:
status = ""
elif check:
# If url == last_url, there is no need to refetch content. This is an optimization when
# checking URLs with the same site but different fragments (which will be sorted together).
if url != last_url:
headers = {"User-Agent": "Mozilla/5.0"}
https_handler = HTTPSHandler(context=ssl.create_default_context(cafile=certifi.where()))
# Some DOI links (i.e. to https://doi.org/) redirect to link.springer.com
# in a way that requires cookies (booo!). We allow this for DOI links,
# but for all other links we simulate a client that never sets cookies.
if l.startswith("https://doi.org/"):
opener = build_opener(HTTPCookieProcessor(), https_handler)
else:
opener = build_opener(https_handler)
for retry in range(2):
try:
response = opener.open(Request(url=l, headers=headers))
content_type = response.info().get_content_type()
content = response.read()
last_url = url
except URLError as e:
if retry == 0 and isinstance(e, HTTPError) and e.code == 429:
try:
delay = int(e.headers['Retry-After'], 10) + 1
except Exception:
delay = 60
print("(waiting %ds due to rate limiting)" % (delay,), end=" ")
sys.stdout.flush()
sleep(delay)
continue
errors.append("Could not open link: %s due to %r" % (what, e))
status = ""
content_type = None
content = None
last_url = None
dests = None
break
if content is not None:
if fragment:
if dests is None:
if content_type in ('text/html', 'application/xhtml+xml'):
(_, dests) = get_links_and_destinations_from_html(BytesIO(content))
elif content_type == 'application/pdf':
(_, dests) = get_links_and_destinations_from_pdf(BytesIO(content))
if dests is None:
print("(link target not checked)", end=" ")
status = ""
elif fragment not in dests:
errors.append("Missing link target: " + what)
status = ""
else:
status = ""
else:
status = ""
else:
errors.append("Insecure or unrecognized protocol in link: " + what)
status = ""
print(status)
if print_dests:
for (path, dests) in all_dests.items():
if path + ".html" not in all_dests: # avoid duplication
print("\nDestinations for %s:" % (path,))
for d in dests:
print(d)
if errors:
print("\nErrors:")
for e in errors:
print(e)
return 0
if __name__ == '__main__':
sys.exit(main(sys.argv))

23
makeindex.sh Executable file
View File

@ -0,0 +1,23 @@
#!/bin/sh
cat <<EndOfHeader
Index of ZIPs
-------------
.. raw:: html
<embed><table>
<tr> <th>ZIP</th> <th>Title</th> <th>Status</th> </tr>
EndOfHeader
for zipfile in zip-*.rst; do
echo Adding $zipfile to index. >/dev/stderr
if grep -E '^\s*Status:\s*Reserved' $zipfile >/dev/null; then
echo " <tr> <td><span class=\"reserved\">`basename $zipfile .rst | sed -E 's@zip-0{0,3}@@'`</span></td> <td class=\"left\"><a class=\"reserved\" href=\"`echo $zipfile`\">`grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'`</a></td> <td>`grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`</td>"
elif grep -E '^\s*Status:\s*(Withdrawn|Rejected|Obsolete)' $zipfile >/dev/null; then
echo " <tr> <td><strike>`basename $zipfile .rst | sed -E 's@zip-0{0,3}@@'`</strike></td> <td class=\"left\"><strike><a href=\"`echo $zipfile`\">`grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'`</a></strike></td> <td>`grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`</td>"
else
echo " <tr> <td>`basename $zipfile .rst | sed -E 's@zip-0{0,3}@@'`</td> <td class=\"left\"><a href=\"`echo $zipfile`\">`grep '^\s*Title:' $zipfile | sed -E 's@\s*Title:\s*@@'`</a></td> <td>`grep '^\s*Status:' $zipfile | sed -E 's@\s*Status:\s*@@'`</td>"
fi
done
echo " </table></embed>"

View File

@ -1,113 +1,185 @@
LATEXMK=latexmk --halt-on-error -bibtex -pdf
LATEX=pdflatex --halt-on-error
SHELL=/bin/bash -eo pipefail
sprout.pdf: protocol.tex zcash.bib incremental_merkle.pdf key_components.pdf
$(MAKE) pdf
# Experimental; options are pdflatex, lualatex, or xelatex.
# On Debian, LuaLaTeX needs the texlive-luatex package, and XeLaTeX needs the texlive-xetex package.
# Make sure to read <https://github.com/zcash/zips/issues/249>.
ENGINE=pdflatex
sapling.pdf: protocol.tex zcash.bib incremental_merkle.pdf key_components_sapling.pdf
LATEXMKOPT_pdflatex=
LATEXMKOPT_xelatex=-pdflatex=xelatex -dvi- -ps-
LATEXMKOPT_lualatex=-pdflatex=lualatex -dvi- -ps-
LATEXMK=max_print_line=10000 latexmk $(LATEXMKOPT_$(ENGINE)) --halt-on-error --file-line-error -bibtex -pdf -logfilewarnings- -e '$$max_repeat=8'
LATEX=$(ENGINE) --halt-on-error --file-line-error
NOCRUFT?=|perl -pe 's|[{\<\(]\/[^ ]* ?||g;s|^.* has been referenced but does not exist.*||g;s|^\n||g'
# Use EXTRAOPT=-pvc for "continuous preview" mode. For example, "make auxblossom EXTRAOPT=-pvc".
# In this case the updated .pdf will be in the aux/ directory.
.PHONY: all all-specs release discard
all: .Makefile.uptodate
$(MAKE) nu5 canopy heartwood blossom sapling
all-specs: .Makefile.uptodate
$(MAKE) nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf
release:
ifeq ($(shell git tag --points-at HEAD |wc -l),0)
echo "Set a tag at HEAD first."
else
$(eval TAG := $(shell git tag --points-at HEAD))
if [[ "$(shell git rev-parse --abbrev-ref HEAD)" != "main" ]]; then echo "Not on main."; exit 1; fi
$(MAKE) clean all
git add *.pdf
git commit -m "Regenerate PDFs." *.pdf
git tag "v$(TAG)"
git push --tags origin HEAD:main
endif
discard:
git checkout -- '*.pdf'
.Makefile.uptodate: Makefile
$(MAKE) clean
touch .Makefile.uptodate
sapling.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
$(MAKE) sapling
.PHONY: auxsprout
auxsprout:
printf '\\renewcommand{\\docversion}{Version %s [\\SproutSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/sprout.* aux/protocol.*
$(LATEXMK) -jobname=sprout -auxdir=aux -outdir=aux protocol
blossom.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
$(MAKE) blossom
.PHONY: sprout
sprout:
$(MAKE) auxsprout
mv -f aux/sprout.pdf .
heartwood.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
$(MAKE) heartwood
.PHONY: pvcsprout
pvcsprout:
printf '\\renewcommand{\\docversion}{Version %s [\\SproutSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/sprout.* aux/protocol.*
$(LATEXMK) -jobname=sprout -auxdir=aux -pvc protocol
canopy.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
$(MAKE) canopy
nu5.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
$(MAKE) nu5
.PHONY: auxsapling
auxsapling:
printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/sapling.*
$(LATEXMK) -jobname=sapling -auxdir=aux -outdir=aux protocol
$(LATEXMK) -jobname=sapling -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: sapling
sapling:
$(MAKE) auxsapling
mv -f aux/sapling.pdf .
cp -f sapling.pdf protocol.pdf
.PHONY: pvcsapling
pvcsapling:
printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
.PHONY: auxblossom
auxblossom:
printf '\\toggletrue{isblossom}\n\\renewcommand{\\docversion}{Version %s [\\BlossomSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/sapling.*
$(LATEXMK) -jobname=sapling -auxdir=aux -pvc protocol
rm -f aux/blossom.*
$(LATEXMK) -jobname=blossom -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: nolatexmk-sprout
nolatexmk-sprout:
printf '\\renewcommand{\\docversion}{Version %s [\\SproutSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
rm -f sprout.aux sprout.bbl sprout.blg sprout.brf sprout.bcf
$(LATEX) protocol.tex || { touch incremental_merkle.pdf; exit 1; }
biber protocol
$(LATEX) protocol.tex || { touch incremental_merkle.pdf; exit 1; }
$(LATEX) protocol.tex || { touch incremental_merkle.pdf; exit 1; }
$(LATEX) protocol.tex || { touch incremental_merkle.pdf; exit 1; }
.PHONY: blossom
blossom:
$(MAKE) auxblossom
mv -f aux/blossom.pdf .
.PHONY: auxheartwood
auxheartwood:
printf '\\toggletrue{isheartwood}\n\\renewcommand{\\docversion}{Version %s [\\HeartwoodSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/heartwood.*
$(LATEXMK) -jobname=heartwood -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: heartwood
heartwood:
$(MAKE) auxheartwood
mv -f aux/heartwood.pdf .
.PHONY: auxcanopy
auxcanopy:
printf '\\toggletrue{iscanopy}\n\\renewcommand{\\docversion}{Version %s [\\CanopySpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/canopy.*
$(LATEXMK) -jobname=canopy -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: canopy
canopy:
$(MAKE) auxcanopy
mv -f aux/canopy.pdf .
.PHONY: auxnu5
auxnu5:
printf '\\toggletrue{isnufive}\n\\renewcommand{\\docversion}{Version %s [\\NUFiveSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/nu5.*
$(LATEXMK) -jobname=nu5 -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: nu5
nu5:
$(MAKE) auxnu5
mv -f aux/nu5.pdf .
cp -f nu5.pdf protocol.pdf
.PHONY: nolatexmk-sapling
nolatexmk-sapling:
printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
rm -f sapling.aux sapling.bbl sapling.blg sapling.brf sapling.bcf
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.pdf; exit 1; }
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; }
biber sapling
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.pdf; exit 1; }
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.pdf; exit 1; }
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.pdf; exit 1; }
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; }
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; }
sh mymakeindex.sh -o sapling.ind sapling.idx
$(LATEX) -jobname=sapling protocol.tex || { touch incremental_merkle.png; exit 1; }
.PHONY: html
html: sprout.pdf sapling.pdf
# Can't use --split-pages 1 because XHR doesn't work by default on local files in Chrome.
pdf2htmlEX --decompose-ligature 1 --font-size-multiplier 65 --fit-width 1000 --dest-dir html sprout.pdf
pdf2htmlEX --decompose-ligature 1 --font-size-multiplier 65 --fit-width 1000 --dest-dir html sapling.pdf
.PHONY: nolatexmk-blossom
nolatexmk-blossom:
printf '\\toggletrue{isblossom}\n\\renewcommand{\\docversion}{Version %s [\\BlossomSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
rm -f blossom.aux blossom.bbl blossom.blg blossom.brf blossom.bcf
$(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; }
biber blossom
$(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; }
$(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; }
sh mymakeindex.sh -o blossom.ind blossom.idx
$(LATEX) -jobname=blossom protocol.tex || { touch incremental_merkle.png; exit 1; }
cp -f blossom.pdf protocol.pdf
.PHONY: nolatexmk-heartwood
nolatexmk-heartwood:
printf '\\toggletrue{isheartwood}\n\\renewcommand{\\docversion}{Version %s [\\HeartwoodSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
rm -f heartwood.aux heartwood.bbl heartwood.blg heartwood.brf heartwood.bcf
$(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; }
biber heartwood
$(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; }
$(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; }
sh mymakeindex.sh -o heartwood.ind heartwood.idx
$(LATEX) -jobname=heartwood protocol.tex || { touch incremental_merkle.png; exit 1; }
.PHONY: nolatexmk-canopy
nolatexmk-canopy:
printf '\\toggletrue{iscanopy}\n\\renewcommand{\\docversion}{Version %s [\\CanopySpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
rm -f canopy.aux canopy.bbl canopy.blg canopy.brf canopy.bcf
$(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; }
biber canopy
$(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; }
$(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; }
sh mymakeindex.sh -o canopy.ind canopy.idx
$(LATEX) -jobname=canopy protocol.tex || { touch incremental_merkle.png; exit 1; }
.PHONY: nolatexmk-nu5
nolatexmk-nu5:
printf '\\toggletrue{isnufive}\n\\renewcommand{\\docversion}{Version %s [\\NUFiveSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
rm -f nu5.aux nu5.bbl nu5.blg nu5.brf nu5.bcf
$(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; }
biber nu5
$(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; }
$(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; }
sh mymakeindex.sh -o nu5.ind nu5.idx
$(LATEX) -jobname=nu5 protocol.tex || { touch incremental_merkle.png; exit 1; }
.PHONY: clean
clean:
rm -f aux/* html/* protocol.ver \
sprout.dvi sprout.pdf sprout.bbl sprout.blg sprout.brf sprout.toc \
sprout.aux sprout.out sprout.log sprout.bcf sprout.run.xml sprout.fls sprout.fdb_latexmk \
sapling.dvi sapling.pdf sapling.bbl sapling.blg sapling.brf sapling.toc \
sapling.aux sapling.out sapling.log sapling.bcf sapling.run.xml sapling.fls sapling.fdb_latexmk
optimizer-installed.flag:
# Nail down git commits to make backdooring somewhat harder.
git clone https://github.com/pts/sam2p.git
cd sam2p && git reset --hard a2d7819107324faf7b0904fc7074f7dd4a0e16c7 && $(MAKE)
git clone https://github.com/pts/tif22pnm.git
cd tif22pnm && git reset --hard 22217c1a3ea355a899e9c7c79903488ca13d1dfe && $(MAKE)
git clone https://github.com/pts/pdfsizeopt.git
cd pdfsizeopt && git reset --hard 47a03403d70f6975888cee966858bebc51b76463
touch optimizer-installed.flag
.PHONY: clean-optimizer
clean-optimizer:
rm -rf sam2p tif22pnm pdfsizeopt optimizer-installed.flag
.PHONY: optsprout
optsprout: optimizer-installed.flag
$(MAKE) auxsprout
PATH="${PATH}:$(CURDIR)/sam2p:$(CURDIR)/tif22pnm" pdfsizeopt/pdfsizeopt --v=40 --use-image-optimizer=sam2p \
--tmp-dir=aux aux/sprout.pdf sprout.pdf
.PHONY: optsapling
optsapling: optimizer-installed.flag
$(MAKE) auxsapling
PATH="${PATH}:$(CURDIR)/sam2p:$(CURDIR)/tif22pnm" pdfsizeopt/pdfsizeopt --v=40 --use-image-optimizer=sam2p \
--tmp-dir=aux aux/sapling.pdf sapling.pdf
cp -f sapling.pdf protocol.pdf
.PHONY: optimized
optimized: optsprout optsapling
rm -f aux/* html/* protocol.ver protocol.pdf nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf

View File

@ -7,7 +7,7 @@ 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
texlive-generic-recommended texlive-bibtex-extra biber latexmk perl awk
Building
@ -15,54 +15,32 @@ Building
Use:
* ``make pdf`` to make the current protocol specification (``protocol.pdf``);
* ``make sapling`` to make the draft specification for the Overwinter and
Sapling upgrades (``sapling.pdf``).
* ``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``).
By default these use ``latexmk``, which does not work on all systems.
Use ``make nolatexmk-pdf`` or ``make nolatexmk-sapling`` if you run into
problems with ``latexmk``, but that is not the preferred way of building
because it may not run ``pdflatex`` enough times.
``make all`` is equivalent to ``make nufour heartwood blossom sapling sprout``.
There is also support for using the incremental (``-pvc``) mode of
``latexmk`` to automatically rebuild when changes in the source files
are detected: ``make pvcpdf`` or ``make pvcsapling``.
Manual intervention is still needed when there are LaTeX errors.
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.
Optimizing PDF size
-------------------
Alternative TeX engines
-----------------------
Optionally, you can use `Péter Szabó <https://github.com/pts>`_'s
``pdfsizeopt`` program to optimize the size of the resulting PDF files.
Use:
* ``make optpdf`` to make an optimized version of ``protocol.pdf``;
* ``make optsapling`` to make an optimized version of ``sapling.pdf``;
* ``make optimized`` to make both.
This will probably only work on Linux. The first time one of these
targets is run, it will automatically clone and build the necessary
dependencies (pinned by ``git`` hash) from GitHub.
This gives a size saving of about 50% for ``protocol.pdf``, and
40% for ``sapling.pdf``.
Converting to HTML
------------------
To convert to HTML you will first need to install ``pdf2htmlEX``. On Debian:
.. code::
apt-get install pdf2htmlex
Then use ``make html`` (or ``make optimized html``) to convert both PDFs.
The results are placed in the ``html`` directory at ``html/protocol.html``
and ``html/sapling.html``.
See `<https://github.com/zcash/zips/issues/127>`_ for limitations of
this conversion.
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.

BIN
protocol/blossom.pdf Normal file

Binary file not shown.

BIN
protocol/canopy.pdf Normal file

Binary file not shown.

BIN
protocol/heartwood.pdf Normal file

Binary file not shown.

Binary file not shown.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 18 KiB

After

Width:  |  Height:  |  Size: 63 KiB

File diff suppressed because it is too large Load Diff

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 439 KiB

After

Width:  |  Height:  |  Size: 584 KiB

Binary file not shown.

Binary file not shown.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 58 KiB

After

Width:  |  Height:  |  Size: 73 KiB

View File

@ -13,7 +13,7 @@
height="370"
id="svg2"
version="1.1"
inkscape:version="0.92.0 r15299"
inkscape:version="0.92.4 (5da689c313, 2019-01-14)"
sodipodi:docname="key_components.svg"
inkscape:export-filename="/home/davidsarah/zecc/zips/protocol/key_components.png"
inkscape:export-xdpi="179.99957"
@ -26,7 +26,7 @@
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1.979899"
inkscape:cx="256.59392"
inkscape:cx="142.95176"
inkscape:cy="195.56571"
inkscape:document-units="px"
inkscape:current-layer="layer1"
@ -190,7 +190,7 @@
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
@ -343,15 +343,15 @@
</g>
<text
id="text3850-7"
y="784.07965"
x="176.54729"
y="784.58472"
x="123.51428"
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:19.20000076px;line-height:125%;font-family:Serif;-inkscape-font-specification:'Serif Italic';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06666672"
xml:space="preserve"><tspan
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';stroke-width:1.06666672"
y="784.07965"
x="176.54729"
y="784.58472"
x="123.51428"
id="tspan3852-97"
sodipodi:role="line">Payment address</tspan></text>
sodipodi:role="line">Shielded payment address</tspan></text>
<rect
ry="26.666662"
y="936.75397"

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 346 KiB

File diff suppressed because it is too large Load Diff

After

Width:  |  Height:  |  Size: 97 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 181 KiB

After

Width:  |  Height:  |  Size: 223 KiB

View File

@ -13,7 +13,7 @@
height="720"
id="svg2"
version="1.1"
inkscape:version="0.92.0 r15299"
inkscape:version="0.92.4 (5da689c313, 2019-01-14)"
sodipodi:docname="key_components_sapling.svg"
inkscape:export-filename="c:\zcash\key_components_sapling.png"
inkscape:export-xdpi="179.99957"
@ -25,16 +25,16 @@
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="0.98994951"
inkscape:cx="927.70996"
inkscape:cy="254.72974"
inkscape:zoom="1.4"
inkscape:cx="681.16675"
inkscape:cy="396.44845"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="1525"
inkscape:window-height="943"
inkscape:window-x="69"
inkscape:window-y="182"
inkscape:window-width="3150"
inkscape:window-height="1491"
inkscape:window-x="682"
inkscape:window-y="232"
inkscape:window-maximized="0"
inkscape:lockguides="false"
inkscape:snap-global="false" />
@ -531,14 +531,14 @@
id="text3850-8"
y="668.83093"
x="23.203564"
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:19.20000076px;line-height:125%;font-family:Serif;-inkscape-font-specification:'Serif Italic';letter-spacing:0px;word-spacing:0px;fill:#f10090;fill-opacity:1;stroke:none;stroke-width:1.06666672"
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:19.20000076px;line-height:125%;font-family:Serif;-inkscape-font-specification:'Serif Italic';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06666672;"
xml:space="preserve"><tspan
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';fill:#f10090;fill-opacity:1;stroke-width:1.06666672"
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';fill:#000000;fill-opacity:1;stroke-width:1.06666672;"
y="668.83093"
x="23.203564"
id="tspan3852-3"
sodipodi:role="line"> Incoming</tspan><tspan
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';fill:#f10090;fill-opacity:1;stroke-width:1.06666672"
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';fill:#000000;fill-opacity:1;stroke-width:1.06666672;"
y="694.23407"
x="23.203564"
sodipodi:role="line"
@ -617,15 +617,15 @@
</g>
<text
id="text3850-7"
y="512.10144"
x="181.49651"
y="512.354"
x="134.01933"
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:19.20000076px;line-height:125%;font-family:Serif;-inkscape-font-specification:'Serif Italic';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06666672"
xml:space="preserve"><tspan
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';stroke-width:1.06666672"
y="512.10144"
x="181.49651"
y="512.354"
x="134.01933"
id="tspan3852-97"
sodipodi:role="line">Payment address</tspan></text>
sodipodi:role="line">Shielded payment address</tspan></text>
<rect
ry="26.666662"
y="647.65533"
@ -690,27 +690,27 @@
sodipodi:role="line"
style="stroke-width:1.06666672">sk</tspan></text>
<path
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#f10090;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lendh)"
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker6075)"
d="m 289.70585,937.86564 c 13.34726,-19.916 17.58393,-28.45003 24.03935,-46.47757 3.31248,-9.25049 6.23409,-19.55143 7.6985,-38.78777 1.38353,-18.174 0.29483,-34.40533 0.55584,-57.15903 l 0.55822,-102.74298"
id="path4668"
inkscape:connector-curvature="0"
sodipodi:nodetypes="csscc" />
<g
id="g4689"
style="fill:none;fill-opacity:1;stroke:#f10090;stroke-opacity:1"
style="fill:none;fill-opacity:1;stroke:#050003;stroke-opacity:1"
transform="translate(21.565438,-290.93448)">
<path
sodipodi:nodetypes="czzzc"
inkscape:connector-curvature="0"
id="path4670"
d="m 156.2806,930.52347 c -3.22019,0.27418 -4.8062,0.90755 -6.85506,3.96663 -2.04886,3.05908 -2.06364,10.34355 -2.01133,15.3383 0.0523,4.99475 -0.10857,8.93699 -2.51642,11.96863 -2.40782,3.03165 -4.09355,3.97036 -8.40092,3.77013"
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#f10090;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#050003;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
<path
sodipodi:nodetypes="czzzc"
inkscape:connector-curvature="0"
id="path4670-6"
d="m 156.2806,1000.6108 c -3.22019,-0.2741 -4.8062,-0.9075 -6.85506,-3.96658 -2.04886,-3.05908 -2.06364,-10.34355 -2.01133,-15.3383 0.0523,-4.99475 -0.10857,-8.93699 -2.51642,-11.96863 -2.40782,-3.03165 -4.09355,-3.97036 -8.40092,-3.77013"
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#f10090;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#050003;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
</g>
<path
sodipodi:nodetypes="cc"
@ -831,15 +831,15 @@
</g>
<text
id="text3850-7-7"
y="511.16852"
x="800.72668"
y="513.18884"
x="752.23938"
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:19.20000076px;line-height:125%;font-family:Serif;-inkscape-font-specification:'Serif Italic';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06666672"
xml:space="preserve"><tspan
style="font-style:italic;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:23.46666718px;font-family:Quattrocento;-inkscape-font-specification:'Quattrocento Italic';stroke-width:1.06666672"
y="511.16852"
x="800.72668"
id="tspan3852-97-4"
sodipodi:role="line">Payment address</tspan></text>
y="513.18884"
x="752.23938"
sodipodi:role="line"
id="tspan4954">Shielded payment address</tspan></text>
<rect
ry="26.666662"
y="644.01617"

Before

Width:  |  Height:  |  Size: 57 KiB

After

Width:  |  Height:  |  Size: 57 KiB

1
protocol/latexmkrc Normal file
View File

@ -0,0 +1 @@
$makeindex = 'sh mymakeindex.sh -o %D %O %S';

29
protocol/mymakeindex.sh Executable file
View File

@ -0,0 +1,29 @@
#!/bin/sh
set -e
makeindex $*
# We want to change things like:
# \hyperindexformat{\definingstyle}{17},
# \hyperindexformat{\normalstyle}{17},
# to just
# \hyperindexformat{\definingstyle}{17},
#
# and change:
# \hyperindexformat{\definingstyle}{17},
# \hyperindexformat{\normalstyle}{17, 18},
# to
# \hyperindexformat{\definingstyle}{17},
# \hyperindexformat{\normalstyle}{18},
#
# and change:
# \hyperindexformat{\definingstyle}{17},
# \hyperindexformat{\normalstyle}{17--19},
# to
# \hyperindexformat{\definingstyle}{17},
# \hyperindexformat{\normalstyle}{\increment{17}--19},
echo Postprocessing index file "$2"...
perl -i.original -p0e 's/(?s)(\\hyperindexformat[{]\\definingstyle[}][{])(\d+)[}],\s*.\s*\\hyperindexformat[{]\\normalstyle[}][{]\2[}]/\1\2}/sg' "$2"
perl -i -p0e 's/(?s)(\\hyperindexformat[{]\\definingstyle[}][{])(\d+)([}],\s*.\s*\\hyperindexformat[{]\\normalstyle[}][{])\2,\s*([\d,-\s]+[}])/\1\2\3\4/sg' "$2"
perl -i -p0e 's/(?s)(\\hyperindexformat[{]\\definingstyle[}][{])(\d+)([}],\s*.\s*\\hyperindexformat[{]\\normalstyle[}][{])\2--([\d,-\s]+[}])/\1\2\3\\increment{\2}--\4/sg' "$2"
#diff --context=3 "$2.original" "$2"

BIN
protocol/nu5.pdf Normal file

Binary file not shown.

Binary file not shown.

File diff suppressed because it is too large Load Diff

View File

@ -1,2 +0,0 @@
\toggletrue{issapling}
\renewcommand{\docversion}{Version 2018.0-beta-27 [\SaplingSpec]}

Binary file not shown.

Binary file not shown.

File diff suppressed because it is too large Load Diff

7
render-via-docker.sh Executable file
View File

@ -0,0 +1,7 @@
#!/bin/bash
set -efuxo pipefail
TAG='zcash-zips-render'
docker build -t "$TAG" .
docker run -v "$(pwd):/zips" "$TAG"

317
zip-0000.html Normal file
View File

@ -0,0 +1,317 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 0: ZIP Process</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 0
Title: ZIP Process
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Deirdre Connolly &lt;deirdre@zfnd.org&gt;
Original-Authors: Daira Hopwood
Josh Cincinnati
George Tankersley
Credits: Luke Dashjr
Status: Active
Category: Process
Created: 2019-02-16
License: BSD-2-Clause</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", and "REQUIRED" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>A Zcash Improvement Proposal (ZIP) is a design document providing information to the Zcash community, or describing a new feature for Zcash or its processes or environment. The ZIP should provide a concise technical specification of the feature and a rationale for the feature.</p>
<p>We intend ZIPs to be the primary mechanism for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Zcash. The Owner(s) of the ZIP (usually the authors(s)) are responsible for building consensus within the community and documenting dissenting opinions.</p>
<p>Because the ZIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.</p>
<p>This document is based partly on the work done by Luke Dashjr with <a href="https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki">BIP 2</a>.</p>
</section>
<section id="zip-workflow"><h2><span class="section-heading">ZIP Workflow</span><span class="section-anchor"> <a rel="bookmark" href="#zip-workflow"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The ZIP process begins with a new idea for Zcash. Each potential ZIP must have Owners — one or more people who write the ZIP using the style and format described below, shepherd the discussions in the appropriate forums, and attempt to build community consensus around the idea. The ZIP Owners should first attempt to ascertain whether the idea is ZIP-able. Small enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a ZIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker. Additionally, many ideas have been brought forward for changing Zcash that have been rejected for various reasons. The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. After investigating past work, the best way to proceed is by posting about the new idea to the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>.</p>
<p>Vetting an idea publicly before going as far as writing a ZIP is meant to save both the potential Owners and the wider community time. Asking the Zcash community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the Owners. Just because an idea sounds good to the Owners does not mean it will work for most people in most areas where Zcash is used.</p>
<p>Once the Owners have asked the Zcash community as to whether an idea has any chance of acceptance, a draft ZIP should be presented to the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum</a>. This gives the Owners a chance to flesh out the draft ZIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the <a href="https://github.com/zcash/zips">ZIPs git repository</a> as a pull request. This draft must be written in ZIP style as described below, and named with an alias such as <code>zip-zatoshizakamoto-42millionzec</code> until the ZIP Editors have assigned it a ZIP number (Owners MUST NOT self-assign ZIP numbers).</p>
<p>ZIP Owners are responsible for collecting community feedback on both the initial idea and the ZIP before submitting it for review. However, wherever possible, long open-ended discussions on forums should be avoided.</p>
<p>It is highly recommended that a single ZIP contain a single key proposal or new idea. The more focused the ZIP, the more successful it tends to be. If in doubt, split your ZIP into several well-focused ones.</p>
<p>When the ZIP draft is complete, the ZIP Editors will assign the ZIP a number (if that has not already been done) and one or more Categories, and merge the pull request to the ZIPs git repository. The ZIP Editors will not unreasonably reject a ZIP. Reasons for rejecting ZIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or not in keeping with the Zcash philosophy. For a ZIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.</p>
<p>The ZIP Owners may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the Owners as pull requests.</p>
<section id="zip-numbering-conventions"><h3><span class="section-heading">ZIP Numbering Conventions</span><span class="section-anchor"> <a rel="bookmark" href="#zip-numbering-conventions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The ZIP Editors currently use the following conventions when numbering ZIPs:</p>
<ul>
<li>if a ZIP directly corresponds to a BIP (Bitcoin Improvement Proposal), and the number doesn't clash, assign the same number;</li>
<li>if it affects the consensus layer or the core protocol, assign a number in the range 200..299;</li>
<li>if it affects only higher layers but is needed for interoperability between node implementations or other parts of the ecosystem, assign a number in the range 300..399;</li>
<li>if it is specific to an implementation (e.g. zcashd or zebra), assign a number in the range 400..499;</li>
<li>try to number ZIPs that should or will be deployed together consecutively (subject to the above conventions), and in a coherent reading order.</li>
</ul>
<p>These conventions are subject to change by consensus of the ZIP Editors.</p>
</section>
<section id="transferring-zip-ownership"><h3><span class="section-heading">Transferring ZIP Ownership</span><span class="section-anchor"> <a rel="bookmark" href="#transferring-zip-ownership"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>It occasionally becomes necessary to transfer ownership of ZIPs to a new Owner. In general, we'd like to retain the original Owner as a co-Owner of the transferred ZIP, but that's really up to the original Owner. A good reason to transfer ownership is because the original Owner no longer has the time or interest in updating it or following through with the ZIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the ZIP. We try to build consensus around a ZIP, but if that's not possible, you can always submit a competing ZIP.</p>
<p>If you are interested in assuming ownership of a ZIP, send a message asking to take over, addressed to both the original Owner and the ZIP Editors. If the original Owner doesn't respond to email in a timely manner, the ZIP Editors will make a unilateral decision (it's not like such decisions can't be reversed :).</p>
<p>If an author of a ZIP is no longer an Owner, an Original-Authors field SHOULD be added to the ZIP metadata indicating the original authorship, unless the original author(s) request otherwise.</p>
</section>
<section id="zip-editors"><h3><span class="section-heading">ZIP Editors</span><span class="section-anchor"> <a rel="bookmark" href="#zip-editors"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The current ZIP Editors are Daira Hopwood, representing the Electric Coin Company, and Deirdre Connolly, representing the Zcash Foundation. Both can be reached at <a href="mailto:zips@z.cash">zips@z.cash</a> . The current design of the ZIP Process dictates that there are always at least two ZIP Editors: one from the Electric Coin Company and one from the Zcash Foundation. Additional Editors may be selected by consensus among the current Editors.</p>
</section>
<section id="zip-editor-responsibilities-workflow"><h3><span class="section-heading">ZIP Editor Responsibilities &amp; Workflow</span><span class="section-anchor"> <a rel="bookmark" href="#zip-editor-responsibilities-workflow"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The ZIP Editors subscribe to the <a href="https://forum.zcashcommunity.com/">Zcash Community Forum.</a></p>
<p>For each new ZIP that comes in an Editor confirms the following:</p>
<ul>
<li>Read the ZIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.</li>
<li>The title should accurately describe the content.</li>
<li>The ZIP draft must have been sent to the Zcash Community Forum or as a PR to the <a href="https://github.com/zcash/zips">ZIPs git repository</a></li>
<li>Motivation and backward compatibility (when applicable) must be addressed.</li>
<li>The licensing terms are acceptable for ZIPs.</li>
</ul>
<p>If the ZIP isn't ready, the editor will send it back to the Owners for revision, with specific instructions.</p>
<p>Once the ZIP is ready for the repository it SHOULD be submitted as a "pull request" to the <a href="https://github.com/zcash/zips">ZIPs git repository</a> where it may get further feedback. It SHOULD NOT contain a ZIP number unless one had already been assigned by the ZIP Editors. The pull request SHOULD initially be marked as a Draft.</p>
<p>The ZIP Editors will:</p>
<ul>
<li>Assign a ZIP number in the pull request.</li>
<li>Remove Draft status and merge the pull request when it is ready.</li>
</ul>
<p>The ZIP editors monitor ZIP changes and update ZIP headers as appropriate.</p>
<p>The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP for any of the following reasons:</p>
<ul>
<li>it violates the Zcash Code of Conduct <a id="id3" class="footnote_reference" href="#conduct">4</a> ;</li>
<li>it appears too unfocused or broad;</li>
<li>it duplicates effort in other ZIPs without sufficient technical justification (however, alternative proposals to address similar or overlapping problems are not excluded for this reason);</li>
<li>it has manifest security flaws (including being unrealistically dependent on user vigilance to avoid security weaknesses);</li>
<li>it disregards compatibility with the existing Zcash blockchain or ecosystem;</li>
<li>it is manifestly unimplementable;</li>
<li>it includes buggy code, pseudocode, or algorithms;</li>
<li>it manifestly violates common expectations of a significant portion of the Zcash community;</li>
<li>it updates a Draft ZIP to Released when there is significant community opposition to its content (however, Draft ZIPs explicitly may describe proposals to which there is, or could be expected, significant community opposition);</li>
<li>in the case of a Released ZIP, the update makes a substantive change to which there is significant community opposition;</li>
<li>it is dependent on a patent that could potentially be an obstacle to adoption of the ZIP;</li>
<li>it includes commercial advertising or spam;</li>
<li>it disregards formatting rules;</li>
<li>it makes non-editorial edits to previous entries in a ZIP's Change history, if there is one;</li>
<li>an update to an existing ZIP extends or changes its scope to an extent that would be better handled as a separate ZIP;</li>
<li>a new ZIP has been proposed for a category that does not reflect its content, or an update would change a ZIP to an inappropriate category;</li>
<li>it updates a Released ZIP to Draft when the specification is already implemented and has been in common use;</li>
<li>it violates any specific "MUST" or "MUST NOT" rule in this document;</li>
<li>the expressed political views of a Owner of the document are inimical to the Zcash Code of Conduct <a id="id4" class="footnote_reference" href="#conduct">4</a> (except in the case of an update removing that Owner);</li>
<li>it is not authorized by the stated ZIP Owners;</li>
<li>it removes an Owner without their consent (unless the reason for removal is directly related to a breach of the Code of Conduct by that Owner).</li>
</ul>
<p>The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal or update that does not violate any of these criteria. If they refuse a proposal or update, they MUST give an explanation of which of the criteria were violated, with the exception that spam may be deleted without an explanation.</p>
<p>Note that it is not the primary responsibility of the ZIP Editors to review proposals for security, correctness, or implementability.</p>
<p>Please send all ZIP-related communications either by email to &lt;<a href="mailto:zips@z.cash">zips@z.cash</a>&gt;, or by opening an issue on the <a href="https://github.com/zcash/zips/issues">ZIPs issue tracker</a>. All communications should abide by the Zcash Code of Conduct <a id="id5" class="footnote_reference" href="#conduct">4</a> and follow <a href="https://www.gnu.org/philosophy/kind-communication.en.html">the GNU Kind Communication Guidelines</a></p>
</section>
</section>
<section id="zip-format-and-structure"><h2><span class="section-heading">ZIP format and structure</span><span class="section-anchor"> <a rel="bookmark" href="#zip-format-and-structure"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>ZIPs SHOULD be written in reStructuredText <a id="id6" class="footnote_reference" href="#rst">5</a>, Markdown <a id="id7" class="footnote_reference" href="#markdown">6</a>, or LaTeX <a id="id8" class="footnote_reference" href="#latex">7</a>. For ZIPs written in LaTeX, a <code>Makefile</code> MUST be provided to build (at least) a PDF version of the document.</p>
<p>Each ZIP SHOULD have the following parts:</p>
<ul>
<li>Preamble — Headers containing metadata about the ZIP (<a href="#zip-header-preamble">see below</a>). The License field of the preamble indicates the licensing terms, which MUST be acceptable according to <a href="#zip-licensing">the ZIP licensing requirements</a>.</li>
<li>Terminology — Definitions of technical or non-obvious terms used in the document.</li>
<li>Abstract — A short (~200 word) description of the technical issue being addressed.</li>
<li>Motivation — The motivation is critical for ZIPs that want to change the Zcash protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the ZIP solves.</li>
<li>Specification — The technical specification should describe the interface and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Zcash platforms.</li>
<li>Rationale — The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.</li>
<li>Security and privacy considerations — If applicable, security and privacy considerations should be explicitly described, particularly if the ZIP makes explicit trade-offs or assumptions. For guidance on this section consider RFC 3552 <a id="id9" class="footnote_reference" href="#rfc3552">2</a> as a starting point.</li>
<li>Reference implementation — Literal code implementing the ZIP's specification, and/or a link to the reference implementation of the ZIP's specification. The reference implementation MUST be completed before any ZIP is given status “Implemented” or “Final”, but it generally need not be completed before the ZIP is accepted into “Proposed”.</li>
</ul>
<section id="zip-header-preamble"><h3><span class="section-heading">ZIP header preamble</span><span class="section-anchor"> <a rel="bookmark" href="#zip-header-preamble"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Each ZIP MUST begin with a RFC 822-style header preamble. For ZIPs written in reStructuredText, this is represented as <code>::</code> on the first line, followed by a blank line, then the preamble indented by 2 spaces.</p>
<p>The following header fields are REQUIRED:</p>
<pre>ZIP:
Title:
Owners:
Status:
Category:
Created:
License:</pre>
<p>The following additional header fields are OPTIONAL:</p>
<pre>Credits:
Original-Authors:
Discussions-To:
Pull-Request:
Obsoleted by:
Updated by:
Obsoletes:
Updates:</pre>
<p>The Owners header lists the names and email addresses of all the Owners of the ZIP. The format of the Owners header value SHOULD be:</p>
<pre>Random J. User &lt;address@dom.ain&gt;</pre>
<p>If there are multiple Owners, each should be on a separate line.</p>
<p>The "Owners", "Credits", and "Original-Authors" headers always use these plural spellings even there is only one Owner, one person to be credited, or one original author.</p>
<p>While a ZIP is in public discussions (usually during the initial Draft phase), a Discussions-To header will indicate the URL where the ZIP is being discussed. No Discussions-To header is necessary if the ZIP is being discussed privately with the Owner.</p>
<p>The Pull-Request header, if present, gives an URL to a Pull Request for the ZIP.</p>
<p>The Category header specifies the type of ZIP, as described in <a href="#zip-categories">ZIP categories</a>. Multiple categories MAY be specified, separated by " <code>/</code> ".</p>
<p>The Created header records the date that the ZIP was submitted. Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.</p>
<p>For ZIPs written in reStructuredText, URLs in header fields SHOULD be surrounded by <code>&lt;</code> <code>&gt;</code>; this ensures that the link is rendered correctly.</p>
</section>
<section id="auxiliary-files"><h3><span class="section-heading">Auxiliary Files</span><span class="section-anchor"> <a rel="bookmark" href="#auxiliary-files"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>ZIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that ZIP; that is, for any ZIP that requires more than one file, all of the files SHOULD be in a subdirectory named zip-XXXX.</p>
</section>
</section>
<section id="zip-categories"><h2><span class="section-heading">ZIP categories</span><span class="section-anchor"> <a rel="bookmark" href="#zip-categories"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Each ZIP is in one or more of the following categories, as specified in the Category header:</p>
<dl>
<dt>Consensus</dt>
<dd>Rules that affect the consensus protocol followed by all Zcash implementations.</dd>
<dt>Standards</dt>
<dd>Non-consensus changes affecting most or all Zcash implementations, or the interoperability of applications using Zcash.</dd>
<dt>Process</dt>
<dd>A Process ZIP describes a process surrounding Zcash, or proposes a change to (or an event in) a process. They may propose an implementation, but not to Zcash's codebase; they often require community consensus; unlike Informational ZIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Zcash development.</dd>
<dt>Consensus Process</dt>
<dd>A subcategory of Process ZIP that specifies requirements and processes that are to be realized by one or more Consensus ZIPs, and/or by social consensus of the Zcash community.</dd>
<dt>Informational</dt>
<dd>An Informational ZIP describes non-consensus Zcash design issues, or general guidelines or information for the Zcash community. These ZIPs do not not necessarily represent a Zcash community consensus or recommendation, so users and implementors are free to ignore Informational ZIPs or follow their advice.</dd>
<dt>Network</dt>
<dd>Specifications of peer-to-peer networking behaviour.</dd>
<dt>RPC</dt>
<dd>Specifications of the RPC interface provided by zcashd nodes.</dd>
<dt>Wallet</dt>
<dd>Specifications affecting wallets (e.g. non-consensus changes to how transactions, addresses, etc. are constructed or interpreted).</dd>
<dt>Ecosystem</dt>
<dd>Specifications otherwise useful to the Zcash ecosystem.</dd>
</dl>
<p>New categories may be added by consensus among the ZIP Editors.</p>
<p>Consensus and Standards ZIPs SHOULD have a Reference Implementation section, which includes or (more often) links to an implementation.</p>
<p>Consensus ZIPs SHOULD have a Deployment section, describing how and when the consensus change is planned to be deployed (for example, in a particular network upgrade).</p>
</section>
<section id="zip-status-field"><h2><span class="section-heading">ZIP Status Field</span><span class="section-anchor"> <a rel="bookmark" href="#zip-status-field"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>Reserved: The ZIP Editors have reserved this ZIP number, and there MAY be a Pull Request for it, but no ZIP has been published. The ZIP Editors SHOULD publish a stub header so that the reservation appears in the <a href="https://zips.z.cash#index-of-zips">ZIP index</a>.</li>
<li>Draft: All initial ZIP submissions have this status.</li>
<li>Withdrawn: If the Owner decides to remove the ZIP from consideration by the community, they may set the status to Withdrawn.</li>
<li>Active: Typically only used for Process/Informational ZIPs, achieved once rough consensus is reached in PR/forum posts from Draft Process ZIP.</li>
<li>Proposed: Typically the stage after Draft, added to a ZIP after consideration, feedback, and rough consensus from the community. The ZIP Editors must validate this change before it is approved.</li>
<li>Rejected: The status when progress hasn't been made on the ZIP in one year. Can revert back to Draft/Proposed if the Owner resumes work or resolves issues preventing consensus.</li>
<li>Implemented: When a Consensus or Standards ZIP has a working reference implementation but before activation on the Zcash network.</li>
<li>Final: When a Consensus or Standards ZIP is both implemented and activated on the Zcash network.</li>
<li>Obsolete: The status when a ZIP is no longer relevant (typically when superseded by another ZIP).</li>
</ul>
<p>More details on the status workflow are given in the section below.</p>
<section id="specification"><h3><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Owners of a ZIP may decide on their own to change the status between Draft or Withdrawn.</p>
<p>A ZIP may only change status from Draft (or Rejected) to Proposed, when the Owner deems it is complete and there is rough consensus on the forums, validated by both the Electric Coin Company and Zcash Foundation Editors. One Editor will not suffice — there needs to be consensus among the Editors. If it's a Consensus ZIP, a Deployment section MUST be present in order for the ZIP to change status to Proposed. Typically, although not necessarily, this will specify a network upgrade in which the consensus change is to activate.</p>
<p>A Standards ZIP may only change status from Proposed to Implemented once the Owners provide an associated reference implementation, typically in the period after the network upgrade's specification freeze but before the implementation audit. If the Owners miss this deadline, the Editors or Owners MAY choose to update the Deployment section of the ZIP to target another upgrade, at their discretion.</p>
<p>ZIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in one year. Such a ZIP may be changed to Draft status if the Owner provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraphs.</p>
<p>A Consensus or Standards ZIP becomes Final when its associated network upgrade or other protocol change is activated on Zcash's mainnet.</p>
<p>A Process or Informational ZIP may change status from Draft to Active when it achieves rough consensus on the forum or PR. Such a proposal is said to have rough consensus if it has been open to discussion on the forum or GitHub PR for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.</p>
<p>When an Active or Final ZIP is no longer relevant, its status may be changed to Obsolete. This change must also be objectively verifiable and/or discussed. Final ZIPs may be updated; the specification is still in force but modified by another specified ZIP or ZIPs (check the optional Updated-by header).</p>
</section>
</section>
<section id="zip-comments"><h2><span class="section-heading">ZIP Comments</span><span class="section-anchor"> <a rel="bookmark" href="#zip-comments"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Comments from the community on the ZIP should occur on the Zcash Community Forum and the comment fields of the pull requests in any open ZIPs. Editors will use these sources to judge rough consensus.</p>
</section>
<section id="zip-licensing"><h2><span class="section-heading">ZIP Licensing</span><span class="section-anchor"> <a rel="bookmark" href="#zip-licensing"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>New ZIPs may be accepted with the following licenses. Each new ZIP MUST identify at least one acceptable license in its preamble. Each license MUST be referenced by their respective abbreviation given below.</p>
<p>For example, a preamble might include the following License header:</p>
<pre>License: BSD-2-Clause
GNU-All-Permissive</pre>
<p>In this case, the ZIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of <em>either</em> license. In other words, the license list is an "OR choice", not an "AND also" requirement.</p>
<p>It is also possible to license source code differently from the ZIP text. This case SHOULD be indicated in the Reference Implementation section of the ZIP. Again, each license MUST be referenced by its respective abbreviation given below.</p>
<p>Statements of code licenses in ZIPs are only advisory; anyone intending to use the code should look for license statements in the code itself.</p>
<p>ZIPs are not required to be <em>exclusively</em> licensed under approved terms, and MAY also be licensed under unacceptable licenses <em>in addition to</em> at least one acceptable license. In this case, only the acceptable license(s) should be listed in the License header.</p>
<section id="recommended-licenses"><h3><span class="section-heading">Recommended licenses</span><span class="section-anchor"> <a rel="bookmark" href="#recommended-licenses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<ul>
<li>MIT: <a href="https://opensource.org/licenses/MIT">Expat/MIT/X11 license</a></li>
<li>BSD-2-Clause: <a href="https://opensource.org/licenses/BSD-2-Clause">OSI-approved BSD 2-clause license</a></li>
<li>BSD-3-Clause: <a href="https://opensource.org/licenses/BSD-3-Clause">OSI-approved BSD 3-clause license</a></li>
<li>CC0-1.0: <a href="https://creativecommons.org/publicdomain/zero/1.0/">Creative Commons CC0 1.0 Universal</a></li>
<li>GNU-All-Permissive: <a href="https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html">GNU All-Permissive License</a></li>
<li>Apache-2.0: <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache License, version 2.0</a></li>
</ul>
<p>In addition, it is RECOMMENDED that literal code included in the ZIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for zcashd would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the ZIP text.</p>
</section>
<section id="not-recommended-but-acceptable-licenses"><h3><span class="section-heading">Not recommended, but acceptable licenses</span><span class="section-anchor"> <a rel="bookmark" href="#not-recommended-but-acceptable-licenses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<ul>
<li>BSL-1.0: <a href="https://www.boost.org/LICENSE_1_0.txt">Boost Software License, version 1.0</a></li>
<li>CC-BY-4.0: <a href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International</a></li>
<li>CC-BY-SA-4.0: <a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International</a></li>
<li>AGPL-3.0+: <a href="https://www.gnu.org/licenses/agpl-3.0.en.html">GNU Affero General Public License (AGPL), version 3 or newer</a></li>
<li>FDL-1.3: <a href="https://www.gnu.org/licenses/fdl-1.3.en.html">GNU Free Documentation License, version 1.3</a></li>
<li>GPL-2.0+: <a href="https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html">GNU General Public License (GPL), version 2 or newer</a></li>
<li>LGPL-2.1+: <a href="https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html">GNU Lesser General Public License (LGPL), version 2.1 or newer</a></li>
</ul>
</section>
<section id="not-acceptable-licenses"><h3><span class="section-heading">Not acceptable licenses</span><span class="section-anchor"> <a rel="bookmark" href="#not-acceptable-licenses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>All licenses not explicitly included in the above lists are not acceptable terms for a Zcash Improvement Proposal.</p>
</section>
<section id="rationale"><h3><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Bitcoin's BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient?</p>
<ul>
<li>The OPL is generally regarded as obsolete, and not a license suitable for new publications.</li>
<li>The OPL license terms allowed for the author to prevent publication and derived works, which was widely considered inappropriate.</li>
<li>In some jurisdictions, releasing a work to the public domain is not recognised as a legitimate legal action, leaving the ZIP simply copyrighted with no redistribution or modification allowed at all.</li>
</ul>
<p>Why are there software licenses included?</p>
<ul>
<li>Some ZIPs, especially in the Consensus category, may include literal code in the ZIP itself which may not be available under the exact license terms of the ZIP.</li>
<li>Despite this, not all software licenses would be acceptable for content included in ZIPs.</li>
</ul>
</section>
</section>
<section id="see-also"><h2><span class="section-heading">See Also</span><span class="section-anchor"> <a rel="bookmark" href="#see-also"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc7282.html">RFC 7282: On Consensus and Humming in the IETF</a></li>
<li><a href="https://electriccoin.co/blog/the-zcash-network-upgrade-pipeline/">Zcash Network Upgrade Pipeline</a></li>
</ul>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="rfc3552" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc3552.html">RFC 3552: Guidelines for Writing RFC Text on Security Considerations</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="conduct" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://github.com/zcash/zcash/blob/master/code_of_conduct.md">Zcash Code of Conduct</a></td>
</tr>
</tbody>
</table>
<table id="rst" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="https://docutils.sourceforge.io/rst.html">reStructuredText documentation</a></td>
</tr>
</tbody>
</table>
<table id="markdown" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="https://www.markdownguide.org/">The Markdown Guide</a></td>
</tr>
</tbody>
</table>
<table id="latex" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="https://www.latex-project.org/">LaTeX — a document preparation system</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

637
zip-0000.rst Normal file
View File

@ -0,0 +1,637 @@
::
ZIP: 0
Title: ZIP Process
Owners: Daira Hopwood <daira@electriccoin.co>
Deirdre Connolly <deirdre@zfnd.org>
Original-Authors: Daira Hopwood
Josh Cincinnati
George Tankersley
Credits: Luke Dashjr
Status: Active
Category: Process
Created: 2019-02-16
License: BSD-2-Clause
Terminology
===========
The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED",
"OPTIONAL", and "REQUIRED" in this document are to be interpreted as
described in RFC 2119. [#RFC2119]_
The term "network upgrade" in this document is to be interpreted as
described in ZIP 200. [#zip-0200]_
Abstract
========
A Zcash Improvement Proposal (ZIP) is a design document providing
information to the Zcash community, or describing a new feature for
Zcash or its processes or environment. The ZIP should provide a concise
technical specification of the feature and a rationale for the feature.
We intend ZIPs to be the primary mechanism for proposing new features,
for collecting community input on an issue, and for documenting the
design decisions that have gone into Zcash. The Owner(s) of the ZIP
(usually the authors(s)) are responsible for building consensus within
the community and documenting dissenting opinions.
Because the ZIPs are maintained as text files in a versioned repository,
their revision history is the historical record of the feature proposal.
This document is based partly on the work done by Luke Dashjr with
`BIP 2 <https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki>`__.
ZIP Workflow
============
The ZIP process begins with a new idea for Zcash. Each potential ZIP
must have Owners — one or more people who write the ZIP using the style
and format described below, shepherd the discussions in the appropriate
forums, and attempt to build community consensus around the idea. The
ZIP Owners should first attempt to ascertain whether the idea is ZIP-able.
Small enhancements or patches to a particular piece of software often
don't require standardisation between multiple projects; these don't
need a ZIP and should be injected into the relevant project-specific
development workflow with a patch submission to the applicable issue
tracker. Additionally, many ideas have been brought forward for changing
Zcash that have been rejected for various reasons. The first step should
be to search past discussions to see if an idea has been considered
before, and if so, what issues arose in its progression. After
investigating past work, the best way to proceed is by posting about the
new idea to the `Zcash Community Forum <https://forum.zcashcommunity.com/>`__.
Vetting an idea publicly before going as far as writing a ZIP is meant
to save both the potential Owners and the wider community time. Asking
the Zcash community first if an idea is original helps prevent too much
time being spent on something that is guaranteed to be rejected based on
prior discussions (searching the internet does not always do the trick).
It also helps to make sure the idea is applicable to the entire
community and not just the Owners. Just because an idea sounds good to
the Owners does not mean it will work for most people in most areas
where Zcash is used.
Once the Owners have asked the Zcash community as to whether an idea
has any chance of acceptance, a draft ZIP should be presented to the
`Zcash Community Forum <https://forum.zcashcommunity.com/>`__.
This gives the Owners a chance to flesh out the draft ZIP to make it
properly formatted, of high quality, and to address additional concerns
about the proposal. Following a discussion, the proposal should be
submitted to the `ZIPs git repository <https://github.com/zcash/zips>`__
as a pull request. This draft must be written in ZIP style as described
below, and named with an alias such as
``zip-zatoshizakamoto-42millionzec`` until the ZIP Editors have assigned
it a ZIP number (Owners MUST NOT self-assign ZIP numbers).
ZIP Owners are responsible for collecting community feedback on both
the initial idea and the ZIP before submitting it for review. However,
wherever possible, long open-ended discussions on forums should be avoided.
It is highly recommended that a single ZIP contain a single key proposal
or new idea. The more focused the ZIP, the more successful it tends to
be. If in doubt, split your ZIP into several well-focused ones.
When the ZIP draft is complete, the ZIP Editors will assign the ZIP a
number (if that has not already been done) and one or more Categories,
and merge the pull request to the ZIPs git repository. The ZIP Editors
will not unreasonably reject a ZIP. Reasons for rejecting ZIPs include
duplication of effort, disregard for formatting rules, being too
unfocused or too broad, being technically unsound, not providing proper
motivation or not in keeping with the Zcash philosophy. For a ZIP to be
accepted it must meet certain minimum criteria. It must be a clear and
complete description of the proposed enhancement. The enhancement must
represent a net improvement. The proposed implementation, if applicable,
must be solid and must not complicate the protocol unduly.
The ZIP Owners may update the draft as necessary in the git repository.
Updates to drafts should also be submitted by the Owners as pull requests.
ZIP Numbering Conventions
-------------------------
The ZIP Editors currently use the following conventions when numbering
ZIPs:
* if a ZIP directly corresponds to a BIP (Bitcoin Improvement Proposal),
and the number doesn't clash, assign the same number;
* if it affects the consensus layer or the core protocol, assign a
number in the range 200..299;
* if it affects only higher layers but is needed for interoperability
between node implementations or other parts of the ecosystem, assign
a number in the range 300..399;
* if it is specific to an implementation (e.g. zcashd or zebra), assign
a number in the range 400..499;
* try to number ZIPs that should or will be deployed together
consecutively (subject to the above conventions), and in a coherent
reading order.
These conventions are subject to change by consensus of the ZIP Editors.
Transferring ZIP Ownership
--------------------------
It occasionally becomes necessary to transfer ownership of ZIPs to a new
Owner. In general, we'd like to retain the original Owner as a
co-Owner of the transferred ZIP, but that's really up to the original
Owner. A good reason to transfer ownership is because the original
Owner no longer has the time or interest in updating it or following
through with the ZIP process, or has fallen off the face of the 'net
(i.e. is unreachable or not responding to email). A bad reason to
transfer ownership is because you don't agree with the direction of the
ZIP. We try to build consensus around a ZIP, but if that's not possible,
you can always submit a competing ZIP.
If you are interested in assuming ownership of a ZIP, send a message
asking to take over, addressed to both the original Owner and the ZIP
Editors. If the original Owner doesn't respond to email in a timely
manner, the ZIP Editors will make a unilateral decision (it's not like
such decisions can't be reversed :).
If an author of a ZIP is no longer an Owner, an Original-Authors field
SHOULD be added to the ZIP metadata indicating the original authorship,
unless the original author(s) request otherwise.
ZIP Editors
-----------
The current ZIP Editors are Daira Hopwood, representing the Electric Coin
Company, and Deirdre Connolly, representing the Zcash Foundation. Both
can be reached at zips@z.cash . The current design of the ZIP Process
dictates that there are always at least two ZIP Editors: one from the
Electric Coin Company and one from the Zcash Foundation. Additional Editors may
be selected by consensus among the current Editors.
ZIP Editor Responsibilities & Workflow
--------------------------------------
The ZIP Editors subscribe to the `Zcash Community Forum.
<https://forum.zcashcommunity.com/>`__
For each new ZIP that comes in an Editor confirms the following:
* Read the ZIP to check if it is ready: sound and complete. The ideas
must make technical sense, even if they don't seem likely to be
accepted.
* The title should accurately describe the content.
* The ZIP draft must have been sent to the Zcash Community Forum or as
a PR to the `ZIPs git repository <https://github.com/zcash/zips>`__
* Motivation and backward compatibility (when applicable) must be
addressed.
* The licensing terms are acceptable for ZIPs.
If the ZIP isn't ready, the editor will send it back to the Owners for
revision, with specific instructions.
Once the ZIP is ready for the repository it SHOULD be submitted as a
"pull request" to the `ZIPs git repository <https://github.com/zcash/zips>`__
where it may get further feedback. It SHOULD NOT contain a ZIP number
unless one had already been assigned by the ZIP Editors. The pull
request SHOULD initially be marked as a Draft.
The ZIP Editors will:
* Assign a ZIP number in the pull request.
* Remove Draft status and merge the pull request when it is ready.
The ZIP editors monitor ZIP changes and update ZIP headers as
appropriate.
The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP
for any of the following reasons:
* it violates the Zcash Code of Conduct [#conduct]_ ;
* it appears too unfocused or broad;
* it duplicates effort in other ZIPs without sufficient technical justification
(however, alternative proposals to address similar or overlapping problems
are not excluded for this reason);
* it has manifest security flaws (including being unrealistically dependent
on user vigilance to avoid security weaknesses);
* it disregards compatibility with the existing Zcash blockchain or ecosystem;
* it is manifestly unimplementable;
* it includes buggy code, pseudocode, or algorithms;
* it manifestly violates common expectations of a significant portion of the
Zcash community;
* it updates a Draft ZIP to Released when there is significant community
opposition to its content (however, Draft ZIPs explicitly may describe
proposals to which there is, or could be expected, significant community
opposition);
* in the case of a Released ZIP, the update makes a substantive change to
which there is significant community opposition;
* it is dependent on a patent that could potentially be an obstacle to
adoption of the ZIP;
* it includes commercial advertising or spam;
* it disregards formatting rules;
* it makes non-editorial edits to previous entries in a ZIP's Change history,
if there is one;
* an update to an existing ZIP extends or changes its scope to an extent
that would be better handled as a separate ZIP;
* a new ZIP has been proposed for a category that does not reflect its content,
or an update would change a ZIP to an inappropriate category;
* it updates a Released ZIP to Draft when the specification is already
implemented and has been in common use;
* it violates any specific "MUST" or "MUST NOT" rule in this document;
* the expressed political views of a Owner of the document are inimical
to the Zcash Code of Conduct [#conduct]_ (except in the case of an update
removing that Owner);
* it is not authorized by the stated ZIP Owners;
* it removes an Owner without their consent (unless the reason for removal
is directly related to a breach of the Code of Conduct by that Owner).
The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal
or update that does not violate any of these criteria. If they refuse a
proposal or update, they MUST give an explanation of which of the
criteria were violated, with the exception that spam may be deleted
without an explanation.
Note that it is not the primary responsibility of the ZIP Editors to
review proposals for security, correctness, or implementability.
Please send all ZIP-related communications either by email to
<zips@z.cash>, or by opening an issue on the `ZIPs issue
tracker <https://github.com/zcash/zips/issues>`__. All communications
should abide by the Zcash Code of Conduct [#conduct]_
and follow `the GNU Kind Communication
Guidelines <https://www.gnu.org/philosophy/kind-communication.en.html>`__
ZIP format and structure
========================
ZIPs SHOULD be written in reStructuredText [#rst]_, Markdown [#markdown]_,
or LaTeX [#latex]_. For ZIPs written in LaTeX, a ``Makefile`` MUST be
provided to build (at least) a PDF version of the document.
Each ZIP SHOULD have the following parts:
* Preamble — Headers containing metadata about the ZIP (`see
below <#zip-header-preamble>`__).
The License field of the preamble indicates the licensing terms,
which MUST be acceptable according to `the ZIP licensing requirements <#zip-licensing>`__.
* Terminology — Definitions of technical or non-obvious terms used
in the document.
* Abstract — A short (~200 word) description of the technical issue
being addressed.
* Motivation — The motivation is critical for ZIPs that want to change
the Zcash protocol. It should clearly explain why the existing
protocol is inadequate to address the problem that the ZIP solves.
* Specification — The technical specification should describe the
interface and semantics of any new feature. The specification should be
detailed enough to allow competing, interoperable implementations for
any of the current Zcash platforms.
* Rationale — The rationale fleshes out the specification by
describing what motivated the design and why particular design
decisions were made. It should describe alternate designs that were
considered and related work. The rationale should provide evidence of
consensus within the community and discuss important objections or
concerns raised during discussion.
* Security and privacy considerations — If applicable, security
and privacy considerations should be explicitly described, particularly
if the ZIP makes explicit trade-offs or assumptions. For guidance on
this section consider RFC 3552 [#RFC3552]_ as a starting point.
* Reference implementation — Literal code implementing the ZIP's
specification, and/or a link to the reference implementation of
the ZIP's specification. The reference implementation MUST be
completed before any ZIP is given status “Implemented” or “Final”,
but it generally need not be completed before the ZIP is accepted
into “Proposed”.
ZIP header preamble
-------------------
Each ZIP MUST begin with a RFC 822-style header preamble. For ZIPs written
in reStructuredText, this is represented as ``::`` on the first line,
followed by a blank line, then the preamble indented by 2 spaces.
The following header fields are REQUIRED::
ZIP:
Title:
Owners:
Status:
Category:
Created:
License:
The following additional header fields are OPTIONAL::
Credits:
Original-Authors:
Discussions-To:
Pull-Request:
Obsoleted by:
Updated by:
Obsoletes:
Updates:
The Owners header lists the names and email addresses of all the
Owners of the ZIP. The format of the Owners header value SHOULD be::
Random J. User <address@dom.ain>
If there are multiple Owners, each should be on a separate line.
The "Owners", "Credits", and "Original-Authors" headers always use
these plural spellings even there is only one Owner, one person to be
credited, or one original author.
While a ZIP is in public discussions (usually during the initial Draft
phase), a Discussions-To header will indicate the URL where the ZIP is
being discussed. No Discussions-To header is necessary if the ZIP is being
discussed privately with the Owner.
The Pull-Request header, if present, gives an URL to a Pull Request for
the ZIP.
The Category header specifies the type of ZIP, as described in
`ZIP categories`_. Multiple categories MAY be specified, separated by
" ``/`` ".
The Created header records the date that the ZIP was submitted.
Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.
For ZIPs written in reStructuredText, URLs in header fields SHOULD be
surrounded by ``<`` ``>``; this ensures that the link is rendered correctly.
Auxiliary Files
---------------
ZIPs may include auxiliary files such as diagrams. Auxiliary files
should be included in a subdirectory for that ZIP; that is, for any ZIP
that requires more than one file, all of the files SHOULD be in a
subdirectory named zip-XXXX.
ZIP categories
==============
Each ZIP is in one or more of the following categories, as specified
in the Category header:
Consensus
Rules that affect the consensus protocol followed by all Zcash
implementations.
Standards
Non-consensus changes affecting most or all Zcash implementations, or
the interoperability of applications using Zcash.
Process
A Process ZIP describes a process surrounding Zcash, or proposes a
change to (or an event in) a process. They may propose an implementation,
but not to Zcash's codebase; they often require community consensus;
unlike Informational ZIPs, they are more than recommendations, and users
are typically not free to ignore them. Examples include procedures,
guidelines, changes to the decision-making process, and changes to the
tools or environment used in Zcash development.
Consensus Process
A subcategory of Process ZIP that specifies requirements and processes
that are to be realized by one or more Consensus ZIPs, and/or by social
consensus of the Zcash community.
Informational
An Informational ZIP describes non-consensus Zcash design issues, or
general guidelines or information for the Zcash community. These ZIPs
do not not necessarily represent a Zcash community consensus or
recommendation, so users and implementors are free to ignore
Informational ZIPs or follow their advice.
Network
Specifications of peer-to-peer networking behaviour.
RPC
Specifications of the RPC interface provided by zcashd nodes.
Wallet
Specifications affecting wallets (e.g. non-consensus changes to how
transactions, addresses, etc. are constructed or interpreted).
Ecosystem
Specifications otherwise useful to the Zcash ecosystem.
New categories may be added by consensus among the ZIP Editors.
Consensus and Standards ZIPs SHOULD have a Reference Implementation section,
which includes or (more often) links to an implementation.
Consensus ZIPs SHOULD have a Deployment section, describing how and when
the consensus change is planned to be deployed (for example, in a particular
network upgrade).
ZIP Status Field
================
* Reserved: The ZIP Editors have reserved this ZIP number, and there MAY
be a Pull Request for it, but no ZIP has been published. The ZIP Editors
SHOULD publish a stub header so that the reservation appears in the
`ZIP index <https://zips.z.cash#index-of-zips>`__.
* Draft: All initial ZIP submissions have this status.
* Withdrawn: If the Owner decides to remove the ZIP from
consideration by the community, they may set the status to Withdrawn.
* Active: Typically only used for Process/Informational ZIPs, achieved
once rough consensus is reached in PR/forum posts from Draft Process ZIP.
* Proposed: Typically the stage after Draft, added to a ZIP after
consideration, feedback, and rough consensus from the community. The ZIP
Editors must validate this change before it is approved.
* Rejected: The status when progress hasn't been made on the ZIP in one
year. Can revert back to Draft/Proposed if the Owner resumes work
or resolves issues preventing consensus.
* Implemented: When a Consensus or Standards ZIP has a working
reference implementation but before activation on the Zcash network.
* Final: When a Consensus or Standards ZIP is both implemented
and activated on the Zcash network.
* Obsolete: The status when a ZIP is no longer relevant (typically when
superseded by another ZIP).
More details on the status workflow are given in the section below.
Specification
-------------
Owners of a ZIP may decide on their own to change the status between
Draft or Withdrawn.
A ZIP may only change status from Draft (or Rejected) to Proposed, when
the Owner deems it is complete and there is rough consensus on the
forums, validated by both the Electric Coin Company and Zcash Foundation
Editors. One Editor will not suffice — there needs to be consensus
among the Editors. If it's a Consensus ZIP, a Deployment section MUST
be present in order for the ZIP to change status to Proposed. Typically,
although not necessarily, this will specify a network upgrade in which
the consensus change is to activate.
A Standards ZIP may only change status from Proposed to Implemented once
the Owners provide an associated reference implementation, typically in
the period after the network upgrade's specification freeze but before
the implementation audit. If the Owners miss this deadline, the Editors
or Owners MAY choose to update the Deployment section of the ZIP to
target another upgrade, at their discretion.
ZIPs should be changed from Draft or Proposed status, to Rejected
status, upon request by any person, if they have not made progress in
one year. Such a ZIP may be changed to Draft status if the Owner
provides revisions that meaningfully address public criticism of the
proposal, or to Proposed status if it meets the criteria required as
described in the previous paragraphs.
A Consensus or Standards ZIP becomes Final when its associated network
upgrade or other protocol change is activated on Zcash's mainnet.
A Process or Informational ZIP may change status from Draft to Active
when it achieves rough consensus on the forum or PR. Such a proposal is
said to have rough consensus if it has been open to discussion on the
forum or GitHub PR for at least one month, and no person maintains
any unaddressed substantiated objections to it. Addressed or obstructive
objections may be ignored/overruled by general agreement that they have
been sufficiently addressed, but clear reasoning must be given in such
circumstances.
When an Active or Final ZIP is no longer relevant, its status may be
changed to Obsolete. This change must also be objectively verifiable
and/or discussed. Final ZIPs may be updated; the specification is still
in force but modified by another specified ZIP or ZIPs (check the
optional Updated-by header).
ZIP Comments
============
Comments from the community on the ZIP should occur on the Zcash
Community Forum and the comment fields of the pull requests in
any open ZIPs. Editors will use these sources to judge rough consensus.
ZIP Licensing
=============
New ZIPs may be accepted with the following licenses. Each new ZIP MUST
identify at least one acceptable license in its preamble. Each license
MUST be referenced by their respective abbreviation given below.
For example, a preamble might include the following License header::
License: BSD-2-Clause
GNU-All-Permissive
In this case, the ZIP text is fully licensed under both the OSI-approved
BSD 2-clause license as well as the GNU All-Permissive License, and
anyone may modify and redistribute the text provided they comply with
the terms of *either* license. In other words, the license list is an
"OR choice", not an "AND also" requirement.
It is also possible to license source code differently from the ZIP
text. This case SHOULD be indicated in the Reference Implementation
section of the ZIP. Again, each license MUST be referenced by its
respective abbreviation given below.
Statements of code licenses in ZIPs are only advisory; anyone intending
to use the code should look for license statements in the code itself.
ZIPs are not required to be *exclusively* licensed under approved
terms, and MAY also be licensed under unacceptable licenses
*in addition to* at least one acceptable license. In this case, only the
acceptable license(s) should be listed in the License header.
Recommended licenses
--------------------
* MIT: `Expat/MIT/X11 license <https://opensource.org/licenses/MIT>`__
* BSD-2-Clause: `OSI-approved BSD 2-clause
license <https://opensource.org/licenses/BSD-2-Clause>`__
* BSD-3-Clause: `OSI-approved BSD 3-clause
license <https://opensource.org/licenses/BSD-3-Clause>`__
* CC0-1.0: `Creative Commons CC0 1.0
Universal <https://creativecommons.org/publicdomain/zero/1.0/>`__
* GNU-All-Permissive: `GNU All-Permissive
License <https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html>`__
* Apache-2.0: `Apache License, version
2.0 <https://www.apache.org/licenses/LICENSE-2.0>`__
In addition, it is RECOMMENDED that literal code included in the ZIP be
dual-licensed under the same license terms as the project it modifies.
For example, literal code intended for zcashd would ideally be
dual-licensed under the MIT license terms as well as one of the above
with the rest of the ZIP text.
Not recommended, but acceptable licenses
----------------------------------------
* BSL-1.0: `Boost Software License, version
1.0 <https://www.boost.org/LICENSE_1_0.txt>`__
* CC-BY-4.0: `Creative Commons Attribution 4.0
International <https://creativecommons.org/licenses/by/4.0/>`__
* CC-BY-SA-4.0: `Creative Commons Attribution-ShareAlike 4.0
International <https://creativecommons.org/licenses/by-sa/4.0/>`__
* AGPL-3.0+: `GNU Affero General Public License (AGPL), version 3 or
newer <https://www.gnu.org/licenses/agpl-3.0.en.html>`__
* FDL-1.3: `GNU Free Documentation License, version
1.3 <https://www.gnu.org/licenses/fdl-1.3.en.html>`__
* GPL-2.0+: `GNU General Public License (GPL), version 2 or
newer <https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html>`__
* LGPL-2.1+: `GNU Lesser General Public License (LGPL), version 2.1 or
newer <https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html>`__
Not acceptable licenses
-----------------------
All licenses not explicitly included in the above lists are not
acceptable terms for a Zcash Improvement Proposal.
Rationale
---------
Bitcoin's BIP 1 allowed the Open Publication License or releasing into
the public domain; was this insufficient?
* The OPL is generally regarded as obsolete, and not a license suitable
for new publications.
* The OPL license terms allowed for the author to prevent publication
and derived works, which was widely considered inappropriate.
* In some jurisdictions, releasing a work to the public domain is not
recognised as a legitimate legal action, leaving the ZIP simply
copyrighted with no redistribution or modification allowed at all.
Why are there software licenses included?
* Some ZIPs, especially in the Consensus category, may include literal
code in the ZIP itself which may not be available under the exact
license terms of the ZIP.
* Despite this, not all software licenses would be acceptable for
content included in ZIPs.
See Also
========
* `RFC 7282: On Consensus and Humming in the
IETF <https://www.rfc-editor.org/rfc/rfc7282.html>`__
* `Zcash Network Upgrade Pipeline <https://electriccoin.co/blog/the-zcash-network-upgrade-pipeline/>`__
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC3552] `RFC 3552: Guidelines for Writing RFC Text on Security Considerations <https://www.rfc-editor.org/rfc/rfc3552.html>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#conduct] `Zcash Code of Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`_
.. [#rst] `reStructuredText documentation <https://docutils.sourceforge.io/rst.html>`_
.. [#markdown] `The Markdown Guide <https://www.markdownguide.org/>`_
.. [#latex] `LaTeX — a document preparation system <https://www.latex-project.org/>`_

16
zip-0001.html Normal file
View File

@ -0,0 +1,16 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1: Network Upgrade Policy and Scheduling</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 1
Title: Network Upgrade Policy and Scheduling
Status: Reserved
Category: Consensus Process
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/343">https://github.com/zcash/zips/issues/343</a>&gt;</pre>
</section>
</body>
</html>

7
zip-0001.rst Normal file
View File

@ -0,0 +1,7 @@
::
ZIP: 1
Title: Network Upgrade Policy and Scheduling
Status: Reserved
Category: Consensus Process
Discussions-To: <https://github.com/zcash/zips/issues/343>

16
zip-0002.html Normal file
View File

@ -0,0 +1,16 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 2: Design Considerations for Network Upgrades</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 2
Title: Design Considerations for Network Upgrades
Status: Reserved
Category: Informational
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/362">https://github.com/zcash/zips/issues/362</a>&gt;</pre>
</section>
</body>
</html>

7
zip-0002.rst Normal file
View File

@ -0,0 +1,7 @@
::
ZIP: 2
Title: Design Considerations for Network Upgrades
Status: Reserved
Category: Informational
Discussions-To: <https://github.com/zcash/zips/issues/362>

16
zip-0022.html Normal file
View File

@ -0,0 +1,16 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 22: Specification of getblocktemplate for Zcash</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 22
Title: Specification of getblocktemplate for Zcash
Status: Reserved
Category: RPC
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/349">https://github.com/zcash/zips/issues/349</a>&gt;</pre>
</section>
</body>
</html>

Binary file not shown.

After

Width:  |  Height:  |  Size: 186 KiB

File diff suppressed because it is too large Load Diff

After

Width:  |  Height:  |  Size: 83 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 228 KiB

File diff suppressed because it is too large Load Diff

After

Width:  |  Height:  |  Size: 89 KiB

1161
zip-0032.html Normal file

File diff suppressed because it is too large Load Diff

711
zip-0032.rst Normal file
View File

@ -0,0 +1,711 @@
::
ZIP: 32
Title: Shielded Hierarchical Deterministic Wallets
Owners: Jack Grigg <str4d@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Credits: Sean Bowe
Kris Nuttycombe
Ying Tong Lai
Pieter Wuille
Marek Palatinus
Pavol Rusnak
Status: Final
Category: Standards / Wallet
Created: 2018-05-22
License: MIT
:math:`% This ZIP makes heavy use of mathematical markup. If you can see this, you may want to instead view the rendered version at https://zips.z.cash/zip-0032 .`
Terminology
===========
The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119.
[#RFC2119]_
"Jubjub" refers to the elliptic curve defined in [#protocol-jubjub]_.
A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive
descendant keys and addresses of that key.
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash
Protocol Specification [#protocol-networks]_.
Abstract
========
This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32
[#bip-0032]_, to support Zcash's shielded addresses.
The initial parts of the specification define (mostly) equivalent, but independent, systems for deriving a
tree of key components from a single seed, for the following shielded pools (which have different internal
key structures):
- Sapling
- Orchard
Previous versions of this document also defined a similar derivation system for the Sprout shielded pool.
This has been removed since it was never used, and is unlikely to be used given that `zcashd` no longer
generates Sprout addresses (and neither `Zebra` nor the mobile SDKs have ever done so).
The last part shows how to use these trees in the context of existing BIP 44 [#bip-0044]_ wallets.
This specification complements the existing use by some Zcash wallets of BIP 32 and BIP 44 for transparent
Zcash addresses, and is not intended to deprecate that usage (privacy risks of using transparent addresses
notwithstanding).
Motivation
==========
BIP 32 [#bip-0032]_ is the standard mechanism by which wallets for Bitcoin and its derivatives (including
Zcash's transparent addresses [#slip-0044]_) generate keys and addresses deterministically. This has several
advantages over random generation:
- Wallets only need to store a single seed (particularly useful for hardware wallets).
- A one-time backup of the seed (usually stored as a word phrase [#bip-0039]_) can be used to recover funds
from all future addresses.
- Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level
structures.
- Viewing authority or spending authority can be delegated independently for sub-trees without compromising
the master seed.
At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for
hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users
to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with
shielded addresses, it is desirable to have a standard mechanism for deriving them.
Conventions
===========
Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification
[#protocol]_. They are reproduced here for convenience:
- :math:`\mathsf{truncate}_k(S)` means the sequence formed from the first :math:`k` elements of :math:`S`.
- :math:`a\,||\,b` means the concatenation of sequences :math:`a` then :math:`b`.
- :math:`[k] P` means scalar multiplication of the elliptic curve point :math:`P` by the scalar :math:`k`.
- :math:`\mathsf{LEOS2IP}_\ell(S)` is the integer in range :math:`\{ 0\,.\!. 2^\ell - 1 \}` represented in
little-endian order by the byte sequence :math:`S` of length :math:`\ell/8`.
- :math:`\mathsf{I2LEBSP}_\ell(k)` is the sequence of :math:`\ell` bits representing :math:`k` in
little-endian order.
- :math:`\mathsf{LEBS2OSP}_\ell(B)` is defined as follows when :math:`\ell` is a multiple of :math:`8`:
convert each group of 8 bits in :math:`B` to a byte value with the least significant bit first, and
concatenate the resulting bytes in the same order as the groups.
- :math:`\mathsf{repr}_\mathbb{J}(P)` is the representation of the Jubjub elliptic curve point :math:`P`
as a bit sequence, defined in [#protocol-jubjub]_.
- :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)` refers to unkeyed BLAKE2b-256 in sequential mode,
with an output digest length of 32 bytes, 16-byte personalization string :math:`p`, and input :math:`x`.
- :math:`\mathsf{BLAKE2b}\text{-}\mathsf{512}(p, x)` refers to unkeyed BLAKE2b-512 in sequential mode,
with an output digest length of 64 bytes, 16-byte personalization string :math:`p`, and input :math:`x`.
- :math:`\mathsf{PRF^{expand}}(\mathsf{sk}, t) :=`:math:`\mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“Zcash_ExpandSeed”},`:math:`\mathsf{sk}\,||\,t)`
- :math:`r_\mathbb{J}` is the order of the Jubjub large prime subgroup.
- :math:`r_\mathbb{P}` is the order of the Pallas curve.
- :math:`\mathsf{ToScalar^{Sapling}}(x) :=`:math:`\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{J}}`.
- :math:`\mathsf{ToScalar^{Orchard}}(x) :=`:math:`\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{P}}`.
- :math:`\mathsf{DiversifyHash^{Sapling}}(d)` maps a diversifier :math:`d` to a base point on the Jubjub elliptic
curve, or to :math:`\bot` if the diversifier is invalid. It is instantiated in [#protocol-concretediversifyhash]_.
The following algorithm standardized in [#NIST-SP-800-38G]_ is used:
- :math:`\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)` refers to the FF1 encryption algorithm
using AES with a 256-bit :math:`key`, and parameters :math:`radix = 2,`:math:`minlen = 88,`:math:`maxlen = 88`.
It will be used only with the empty string :math:`\texttt{“”}` as the :math:`tweak`. :math:`x` is a
sequence of 88 bits, as is the output.
We also define the following conversion function:
- :math:`\mathsf{I2LEOSP}_\ell(k)` is the byte sequence :math:`S` of length :math:`\ell/8` representing in
little-endian order the integer :math:`k` in range :math:`\{ 0\,.\!. 2^\ell - 1 \}`. It is the reverse
operation of :math:`\mathsf{LEOS2IP}_\ell(S)`.
Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard
specifications), which is the opposite of BIP 32.
We adapt the path notation of BIP 32 [#bip-0032]_ to describe shielded HD paths, using prime marks (:math:`'`) to
indicate hardened derivation (:math:`i' = i + 2^{31}`) as in BIP 44 [#bip-0044]_:
- :math:`\mathsf{CDKfvk}(\mathsf{CDKfvk}(\mathsf{CDKfvk}(m_\mathsf{Sapling}, a), b), c)` is written as :math:`m_\mathsf{Sapling} / a / b / c`.
Specification: Sapling key derivation
=====================================
Sapling extended keys
---------------------
BIP 32 defines a method to derive a number of child keys from a parent key. In order to prevent these from
depending solely on the parent key itself, both the private and public keys are extended with a 32-byte chain
code. We similarly extend Sapling keys with a chain code here. However, the concepts of "private" and "public"
keys in BIP 32 do not map cleanly to Sapling's key components. We take the following approach:
- We derive child Sapling expanded spending keys, rather than Sapling spending keys. This enables us to
implement both hardened and non-hardened derivation modes (the latter being incompatible with Sapling
spending keys).
- We do not derive Sapling public keys directly, as this would prevent the use of diversified addresses.
Instead, we derive Sapling full viewing keys, from which payment addresses can be generated. This maintains
the trust semantics of BIP 32: someone with access to a BIP 32 extended public key is able to view all
transactions involving that address, which a Sapling full viewing key also enables.
We represent a Sapling extended spending key as :math:`(\mathsf{ask, nsk, ovk, dk, c})`, where
:math:`(\mathsf{ask, nsk, ovk})` is the normal Sapling expanded spending key, :math:`\mathsf{dk}` is a
diversifier key, and :math:`\mathsf{c}` is the chain code.
We represent a Sapling extended full viewing key as :math:`(\mathsf{ak, nk, ovk, dk, c})`, where
:math:`(\mathsf{ak, nk, ovk})` is the normal Sapling full viewing key, :math:`\mathsf{dk}` is the same
diversifier key as above, and :math:`\mathsf{c}` is the chain code.
Sapling helper functions
------------------------
Define
* :math:`\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk}) :=`:math:`\mathsf{I2LEOSP}_{256}(\mathsf{ask})`:math:`||\,\mathsf{I2LEOSP}_{256}(\mathsf{nsk})`:math:`||\,\mathsf{ovk}`:math:`||\,\mathsf{dk}`
* :math:`\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=`:math:`\mathsf{LEBS2OS}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))`:math:`||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))`:math:`||\,\mathsf{ovk}`:math:`||\,\mathsf{dk}`
Sapling master key generation
-----------------------------
Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
- Calculate :math:`I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Sapling”}, S)`.
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
- Use :math:`I_L` as the master spending key :math:`\mathsf{sk}_m`, and :math:`I_R` as the master chain code
:math:`\mathsf{c}_m`.
- Calculate :math:`\mathsf{ask}_m`, :math:`\mathsf{nsk}_m`, and :math:`\mathsf{ovk}_m` via the standard
Sapling derivation [#protocol-saplingkeycomponents]_:
- :math:`\mathsf{ask}_m = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))`
- :math:`\mathsf{nsk}_m = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x01}]))`
- :math:`\mathsf{ovk}_m = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x02}]))`.
- Calculate :math:`\mathsf{dk}_m` similarly:
- :math:`\mathsf{dk}_m = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x10}]))`.
- Return :math:`(\mathsf{ask}_m, \mathsf{nsk}_m, \mathsf{ovk}_m, \mathsf{dk}_m, \mathsf{c}_m)` as the
master extended spending key :math:`m_\mathsf{Sapling}`.
Note that the master extended key is invalid if :math:`\mathsf{ask}_m` is :math:`0`, or if the corresponding
:math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
Sapling child key derivation
----------------------------
As in BIP 32, the method for deriving a child extended key, given a parent extended key and an index :math:`i`,
depends on the type of key being derived, and whether this is a hardened or non-hardened derivation.
Deriving a child extended spending key
``````````````````````````````````````
:math:`\mathsf{CDKsk}((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)`:math:`\rightarrow (\mathsf{ask}_i, \mathsf{nsk}_i, \mathsf{ovk}_i, \mathsf{dk}_i, \mathsf{c}_i)`
- Check whether :math:`i \geq 2^{31}` (whether the child is a hardened key).
- If so (hardened child):
let :math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x11}]`:math:`||\,\mathsf{EncodeExtSKParts}(\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})`:math:`||\,\mathsf{I2LEOSP}_{32}(i))`.
- If not (normal child):
let :math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]`:math:`||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})`:math:`||\,\mathsf{I2LEOSP}_{32}(i))`
where :math:`(\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})` is the full viewing key derived from
:math:`(\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})` as described in [#protocol-saplingkeycomponents]_.
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
- Let :math:`I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))`.
- Let :math:`I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))`.
- Return:
- :math:`\mathsf{ask}_i = (I_\mathsf{ask} + \mathsf{ask}_{par}) \pmod{r_\mathbb{J}}`
- :math:`\mathsf{nsk}_i = (I_\mathsf{nsk} + \mathsf{nsk}_{par}) \pmod{r_\mathbb{J}}`
- :math:`\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x15}]`:math:`||\,\mathsf{ovk}_{par}))`
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]`:math:`||\,\mathsf{dk}_{par}))`
- :math:`\mathsf{c}_i = I_R`.
Note that the child extended key is invalid if :math:`\mathsf{ask}_i` is :math:`0`, or if the corresponding
:math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
Deriving a child extended full viewing key
``````````````````````````````````````````
Let :math:`\mathcal{G}^\mathsf{Sapling}` be as defined in [#protocol-concretespendauthsig]_ and
let :math:`\mathcal{H}^\mathsf{Sapling}` be as defined in [#protocol-saplingkeycomponents]_.
:math:`\mathsf{CDKfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)`:math:`\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})`
- Check whether :math:`i \geq 2^{31}` (whether the child is a hardened key).
- If so (hardened child): return failure.
- If not (normal child): let
:math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x12}]`:math:`||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par})`:math:`||\,\mathsf{I2LEOSP}_{32}(i))`.
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
- Let :math:`I_\mathsf{ask} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x13}]))`.
- Let :math:`I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x14}]))`.
- Return:
- :math:`\mathsf{ak}_i = [I_\mathsf{ask}]\,\mathcal{G}^\mathsf{Sapling} + \mathsf{ak}_{par}`
- :math:`\mathsf{nk}_i = [I_\mathsf{nsk}]\,\mathcal{H}^\mathsf{Sapling} + \mathsf{nk}_{par}`
- :math:`\mathsf{ovk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x15}]`:math:`||\,\mathsf{ovk}_{par}))`
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]`:math:`||\,\mathsf{dk}_{par}))`
- :math:`\mathsf{c}_i = I_R`.
Note that the child extended key is invalid if :math:`\mathsf{ak}_i` is the zero point of Jubjub,
or if the corresponding :math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_
is :math:`0`.
Sapling internal key derivation
-------------------------------
The above derivation mechanisms produce external addresses suitable for giving out to senders.
We also want to be able to produce another address derived from a given external address, for
use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that
allows deriving a stream of external and internal addresses in the same hierarchical derivation
tree [#bip-0044]_, for any external full viewing key we only need to be able to derive a single
internal full viewing key that has viewing authority for just internal transfers. We also need
to be able to derive the corresponding internal spending key if we have the external spending
key.
Deriving a Sapling internal spending key
````````````````````````````````````````
Let :math:`(\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk}, \mathsf{dk})` be the external spending key.
- Derive the corresponding :math:`\mathsf{ak}` and :math:`\mathsf{nk}` as specified in [#protocol-saplingkeycomponents]_.
- Let :math:`I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))`.
- Let :math:`I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))`.
- Let :math:`R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])`.
- Let :math:`\mathsf{nsk_{internal}} = (I_\mathsf{nsk} + \mathsf{nsk}) \pmod{r_\mathbb{J}}`.
- Split :math:`R` into two 32-byte sequences, :math:`\mathsf{dk_{internal}}` and :math:`\mathsf{ovk_{internal}}`.
- Return the internal spending key as :math:`(\mathsf{ask}, \mathsf{nsk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})`.
Note that the child extended key is invalid if :math:`\mathsf{ak}` is the zero point of Jubjub,
or if the corresponding :math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_
is :math:`0`.
Deriving a Sapling internal full viewing key
````````````````````````````````````````````
Let :math:`\mathcal{H}^\mathsf{Sapling}` be as defined in [#protocol-saplingkeycomponents]_.
Let :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})` be the external full viewing key.
- Let :math:`I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))`.
- Let :math:`I_\mathsf{nsk} = \mathsf{ToScalar^{Sapling}}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))`.
- Let :math:`R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])`.
- Let :math:`\mathsf{nk_{internal}} = [I_\mathsf{nsk}] \mathcal{H}^\mathsf{Sapling} + \mathsf{nk}`.
- Split :math:`R` into two 32-byte sequences, :math:`\mathsf{dk_{internal}}` and :math:`\mathsf{ovk_{internal}}`.
- Return the internal full viewing key as :math:`(\mathsf{ak}, \mathsf{nk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})`.
This design uses the same technique as non-hardened derivation to obtain a full viewing key
with the same spend authority (the private key corresponding to :math:`\mathsf{ak}`) as the
original, but viewing authority only for internal transfers.
The values of :math:`I`, :math:`I_\mathsf{nsk}`, and :math:`R` are the same between deriving
a full viewing key, and deriving the corresponding spending key. Both of these derivations
are shown in the following diagram:
.. figure:: zip-0032-sapling-internal-key-derivation.png
:width: 900px
:align: center
:figclass: align-center
Diagram of Sapling internal key derivation
(For simplicity, the proof authorizing key is not shown.)
This method of deriving internal keys is applied to external keys that are children of the
Account level. It was implemented in `zcashd` as part of support for ZIP 316 [#zip-0316]_.
Note that the internal extended key is invalid if :math:`\mathsf{ak}` is the zero point of Jubjub,
or if the corresponding :math:`\mathsf{ivk_{internal}}` derived from the internal full viewing key
as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
Sapling diversifier derivation
------------------------------
The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key :math:`\mathsf{dk}`.
To prevent the diversifier leaking how many diversified addresses have already been generated for an account,
we make the sequence of diversifiers pseudorandom and uncorrelated to that of any other account. In order to
reach the maximum possible diversifier range without running into repetitions due to the birthday bound, we
use FF1-AES256 as a Pseudo-Random Permutation as follows:
- Let :math:`j` be the index of the desired diversifier, in the range :math:`0\,.\!. 2^{88} - 1`.
- :math:`d_j = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))`.
A valid diversifier :math:`d_j` is one for which :math:`\mathsf{DiversifyHash^{Sapling}}(d_j) \neq \bot`.
For a given :math:`\mathsf{dk}`, approximately half of the possible values of :math:`j` yield valid
diversifiers.
The default diversifier for a Sapling extended key is defined to be :math:`d_j`, where :math:`j` is the
least nonnegative integer yielding a valid diversifier.
Specification: Orchard key derivation
=====================================
The derivation mechanism for Sapling addresses specified above incurs significant complexity to support
non-hardened derivation. In the several years since Sapling was deployed, we have seen no use cases for
non-hardened derivation appear. With that in mind, we only support hardened key derivation for Orchard.
Orchard extended keys
---------------------
We represent an Orchard extended spending key as :math:`(\mathsf{sk, c}),` where :math:`\mathsf{sk}`
is the normal Orchard spending key (opaque 32 bytes), and :math:`\mathsf{c}` is the chain code.
Orchard master key generation
-----------------------------
Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
- Calculate :math:`I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Orchard”}, S)`.
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
- Use :math:`I_L` as the master spending key :math:`\mathsf{sk}_m`.
- Use :math:`I_R` as the master chain code :math:`\mathsf{c}_m`.
- Return :math:`(\mathsf{sk}_m, \mathsf{c}_m)` as the master extended spending key
:math:`m_\mathsf{Orchard}`.
Orchard child key derivation
----------------------------
:math:`\mathsf{CDKsk}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)`:math:`\rightarrow (\mathsf{sk}_{i}, \mathsf{c}_i)`
- Check whether :math:`i \geq 2^{31}` (whether the child is a hardened key).
- If so (hardened child): let
:math:`I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x81}]\,||\,\mathsf{sk}_{par}\,||\,\mathsf{I2LEOSP}_{32}(i))`.
- If not (normal child): return failure.
- Split :math:`I` into two 32-byte sequences, :math:`I_L` and :math:`I_R`.
- Use :math:`I_L` as the child spending key :math:`\mathsf{sk}_{i}`.
- Use :math:`I_R` as the child chain code :math:`\mathsf{c}_i`.
Note that the resulting child spending key may produce an invalid external FVK, as specified
in [#protocol-orchardkeycomponents]_, with small probability. The corresponding internal FVK
derived as specified in the next section may also be invalid with small probability.
Orchard internal key derivation
-------------------------------
As in the case of Sapling, for a given external address, we want to produce another address
for use by wallets for internal operations such as change and auto-shielding. That is, for
any external full viewing key we need to be able to derive a single internal full viewing
key that has viewing authority for just internal transfers. We also need to be able to
derive the corresponding internal spending key if we have the external spending key.
Let :math:`\mathsf{ask}` be the spend authorizing key if available, and
let :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})` be the corresponding external full
viewing key, obtained as specified in [#protocol-orchardkeycomponents]_.
Define :math:`\mathsf{DeriveInternalFVK^{Orchard}}(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})`
as follows:
- Let :math:`K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})`.
- Let :math:`\mathsf{rivk_{internal}} = \mathsf{ToScalar^{Orchard}}(\mathsf{PRF^{expand}}(K, [\mathtt{0x83}] \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{ak}) \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{nk}))`.
- Return :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk_{internal}})`.
The result of applying :math:`\mathsf{DeriveInternalFVK^{Orchard}}` to the external full viewing
key is the internal full viewing key. The corresponding expanded internal spending key is
:math:`(\mathsf{ask}, \mathsf{nk}, \mathsf{rivk_{internal}})`,
Unlike `Sapling internal key derivation`_, we do not base this internal key derivation
procedure on non-hardened derivation, which is not defined for Orchard. We can obtain the
desired separation of viewing authority by modifying only the :math:`\mathsf{rivk_{internal}}`
field relative to the external full viewing key, which results in different
:math:`\mathsf{dk_{internal}}`, :math:`\mathsf{ivk_{internal}}` and :math:`\mathsf{ovk_{internal}}`
fields being derived, as specified in [#protocol-orchardkeycomponents]_ and shown in the following
diagram:
.. figure:: zip-0032-orchard-internal-key-derivation.png
:width: 720px
:align: center
:figclass: align-center
Diagram of Orchard internal key derivation, also showing derivation from the parent extended spending key
This method of deriving internal keys is applied to external keys that are children of the
Account level. It was implemented in `zcashd` as part of support for ZIP 316 [#zip-0316]_.
Note that the resulting FVK may be invalid, as specified in [#protocol-orchardkeycomponents]_.
Orchard diversifier derivation
------------------------------
As with Sapling, we define a mechanism for deterministically deriving a sequence of diversifiers, without
leaking how many diversified addresses have already been generated for an account. Unlike Sapling, we do so
by deriving a diversifier key directly from the full viewing key, instead of as part of the extended spending
key. This means that the full viewing key provides the capability to determine the position of a diversifier
within the sequence, which matches the capabilities of a Sapling extended full viewing key but simplifies the
key structure.
Given an Orchard extended spending key :math:`(\mathsf{sk}_i, \mathsf{c}_i)`:
- Let :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})` be the Orchard full viewing key for :math:`\mathsf{sk}_i`.
- Let :math:`K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})` and let :math:`B = \mathsf{repr}_{\mathbb{P}}(\mathsf{ak})\,||\,\mathsf{I2LEBSP}_{256}(\mathsf{nk})`.
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(K, [\texttt{0x82}]\,||\,\mathsf{LEBS2OSP}_{512}(B)))`.
- Let :math:`j` be the index of the desired diversifier, in the range :math:`0\,.\!. 2^{88} - 1`.
- :math:`d_{i,j} = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}_i, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))`.
Note that unlike Sapling, all Orchard diversifiers are valid, and thus all possible values of :math:`j` yield
valid diversifiers.
The default diversifier for :math:`(\mathsf{sk}_i, \mathsf{c}_i)` is defined to be :math:`d_{i,0}.`
Specification: Wallet usage
===========================
Existing Zcash-supporting HD wallets all use BIP 44 [#bip-0044]_ to organize their derived keys. In order to
more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have
altered the design where it makes sense to leverage features of shielded addresses.
Key path levels
---------------
Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened
derivation:
- :math:`purpose`: a constant set to :math:`32'` (or :math:`\texttt{0x80000020}`) following the BIP 43
recommendation. It indicates that the subtree of this node is used according to this specification.
- :math:`coin\_type`: a constant identifying the cryptocurrency that this subtree's keys are used with. For
compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44
[#slip-0044]_. Note that in keeping with that document, all cryptocurrency testnets share :math:`coin\_type`
index :math:`1`.
- :math:`account`: numbered from index :math:`0` in sequentially increasing manner. Defined as in
BIP 44 [#bip-0044]_.
Unlike BIP 44, none of the shielded key paths have a :math:`change` path level. The use of change addresses
in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by
segregating external and internal address usage. Shielded addresses are never publicly visible in
transactions, which means that sending change back to the originating address is indistinguishable from
using a change address.
Sapling key path
----------------
Sapling provides a mechanism to allow the efficient creation of diversified payment addresses with the same
spending authority. A group of such addresses shares the same full viewing key and incoming viewing key, and
so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for
relevant transactions.
The above key path levels include an account identifier, which in all user interfaces is represented as a
"bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Sapling
ZIP 32 derivation MUST support the following path for any account in range :math:`\{ 0\,.\!. 2^{31} - 1 \}`:
* :math:`m_\mathsf{Sapling} / purpose' / coin\_type' / account'`.
Furthermore, wallets MUST support generating the default payment address (corresponding to the default
diversifier as defined above) for any account they support. They MAY also support generating a stream of
payment addresses for a given account, if they wish to maintain the user experience of giving a unique
address to each recipient.
Note that a given account can have a maximum of approximately :math:`2^{87}` payment addresses, because each
diversifier has around a 50% chance of being invalid.
If in certain circumstances a wallet needs to derive independent spend authorities within a single account,
they MAY additionally support a non-hardened :math:`address\_index` path level as in [#bip-0044]_:
* :math:`m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index`.
`zcashd` version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase
under account :math:`\mathtt{0x7FFFFFFF}`, using hardened derivation for :math:`address\_index`.
Orchard key path
----------------
Orchard supports diversified addresses with the same spending authority (like Sapling). A group of such
addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable
addresses as needed does not increase the cost of scanning the block chain for relevant transactions.
The above key path levels include an account identifier, which in all user interfaces is represented as a
"bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Orchard
ZIP 32 derivation MUST support the following path for any account in range :math:`\{ 0\,.\!. 2^{31} - 1 \}`:
* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account'`.
Furthermore, wallets MUST support generating the default payment address (corresponding to the default
diversifier for Orchard) for any account they support. They MAY also support generating a stream of
diversified payment addresses for a given account, if they wish to enable users to give a unique address to
each recipient.
Note that a given account can have a maximum of :math:`2^{88}` payment addresses (unlike Sapling, all Orchard
diversifiers are valid).
Specification: Fingerprints and Tags
====================================
Sapling Full Viewing Key Fingerprints and Tags
----------------------------------------------
A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding :math:`\mathit{FVK}` (as specified
in [#protocol-saplingfullviewingkeyencoding]_) is given by:
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})`.
It MAY be used to uniquely identify a particular Sapling full viewing key.
A "Sapling full viewing key tag" is the first 4 bytes of the corresponding Sapling full viewing key
fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to
uniquely identify a particular key.
Orchard Full Viewing Key Fingerprints and Tags
----------------------------------------------
An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding :math:`\mathit{FVK}` (as
specified in [#protocol-orchardfullviewingkeyencoding]_) is given by:
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})`.
It MAY be used to uniquely identify a particular Orchard full viewing key.
An "Orchard full viewing key tag" is the first 4 bytes of the corresponding Orchard full viewing key
fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to
uniquely identify a particular key.
Seed Fingerprints
-----------------
A "seed fingerprint" for the master seed :math:`S` of a hierarchical deterministic wallet is given by:
* :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_HD_Seed_FP”},`:math:`[\mathsf{length}(S)]\,||\,S)`.
It MAY be used to uniquely identify a particular hierarchical deterministic wallet.
No corresponding short tag is defined.
Note: a previous version of this specification did not have the length byte prefixing the seed.
The current specification reflects the implementation in `zcashd`.
Specification: Key Encodings
============================
The following encodings are analogous to the ``xprv`` and ``xpub`` encodings defined
in BIP 32 for transparent keys and addresses. Each key type has a raw representation
and a Bech32 [#bip-0173]_ encoding.
Sapling extended spending keys
------------------------------
A Sapling extended spending key :math:`(\mathsf{ask, nsk, ovk, dk, c})`, at depth :math:`depth`,
with parent full viewing key tag :math:`parent\_fvk\_tag` and child number :math:`i`, is
represented as a byte sequence:
* :math:`\mathsf{I2LEOSP}_{8}(depth)`:math:`||\,parent\_fvk\_tag`:math:`||\,\mathsf{I2LEOSP}_{32}(i)`:math:`||\,\mathsf{c}`:math:`||\,\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk})`.
For the master extended spending key, :math:`depth` is :math:`0`, :math:`parent\_fvk\_tag` is
4 zero bytes, and :math:`i` is :math:`0`.
When encoded as Bech32, the Human-Readable Part is ``secret-extended-key-main``
for the production network, or ``secret-extended-key-test`` for the test network.
Sapling extended full viewing keys
----------------------------------
A Sapling extended full viewing key :math:`(\mathsf{ak, nk, ovk, dk, c})`, at depth :math:`depth`,
with parent full viewing key tag :math:`parent\_fvk\_tag` and child number :math:`i`, is
represented as a byte sequence:
* :math:`\mathsf{I2LEOSP}_{8}(depth)`:math:`||\,parent\_fvk\_tag`:math:`||\,\mathsf{I2LEOSP}_{32}(i)`:math:`||\,\mathsf{c}`:math:`||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk})`.
For the master extended full viewing key, :math:`depth` is :math:`0`, :math:`parent\_fvk\_tag`
is 4 zero bytes, and :math:`i` is :math:`0`.
When encoded as Bech32, the Human-Readable Part is ``zxviews`` for the production
network, or ``zxviewtestsapling`` for the test network.
Orchard extended spending keys
------------------------------
An Orchard extended spending key :math:`(\mathsf{sk, c})`, at depth :math:`depth`, with parent full viewing
key tag :math:`parent\_fvk\_tag` and child number :math:`i`, is represented as a byte sequence:
* :math:`\mathsf{I2LEOSP}_{8}(depth)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{sk}`.
For the master extended spending key, :math:`depth` is :math:`0`, :math:`parent\_fvk\_tag` is
4 zero bytes, and :math:`i` is :math:`0`.
When encoded as Bech32, the Human-Readable Part is ``secret-orchard-extsk-main``
for Mainnet, or ``secret-orchard-extsk-test`` for Testnet.
We define this encoding for completeness, however given that it includes the capability to derive child
spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to
users [#protocol-orchardspendingkeyencoding]_.
Values reserved due to previous specification for Sprout
========================================================
The following values were previously used in the specification of hierarchical derivation
for Sprout, and therefore SHOULD NOT be used in future Zcash-related specifications:
* the :math:`\mathsf{BLAKE2b}\text{-}\mathsf{512}` personalization :math:`\texttt{“ZcashIP32_Sprout”}`,
formerly specified for derivation of the master key of the Sprout tree;
* the :math:`\mathsf{BLAKE2b}\text{-}\mathsf{256}` personalization :math:`\texttt{“Zcash_Sprout_AFP”}`,
formerly specified for generation of Sprout address fingerprints;
* the :math:`\mathsf{PRF^{expand}}` prefix :math:`\texttt{0x80}`, formerly specified for
Sprout child key derivation;
* the Bech32 Human-Readable Parts ``zxsprout`` and ``zxtestsprout``, formerly specified for
Sprout extended spending keys on Mainnet and Testnet respectively.
Test Vectors
============
TBC
Reference Implementation
========================
* https://github.com/zcash-hackworks/zip32
* https://github.com/zcash/librustzcash/pull/29
* https://github.com/zcash/zcash/pull/3447
* https://github.com/zcash/zcash/pull/3492
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#bip-0032] `BIP 32: Hierarchical Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>`_
.. [#bip-0039] `BIP 39: Mnemonic code for generating deterministic keys <https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki>`_
.. [#bip-0043] `BIP 43: Purpose Field for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki>`_
.. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>`_
.. [#slip-0044] `SLIP 44: Registered coin types for BIP-0044 <https://github.com/satoshilabs/slips/blob/master/slip-0044.md>`_
.. [#bip-0173] `BIP 173: Base32 address format for native v0-16 witness outputs <https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki>`_
.. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys <zip-0316.rst>`_
.. [#protocol] `Zcash Protocol Specification, Version 2022.2.19 or later [NU5 proposal] <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2022.2.19. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components <protocol/protocol.pdf#orchardkeycomponents>`_
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2022.2.19. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions <protocol/protocol.pdf#concretediversifyhash>`_
.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2022.2.19. Section 5.4.6.1: Spend Authorization Signature <protocol/protocol.pdf#concretespendauthsig>`_
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2022.2.19. Section 5.4.9.3: Jubjub <protocol/protocol.pdf#jubjub>`_
.. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.2.1: Sprout Payment Addresses <protocol/protocol.pdf#sproutpaymentaddrencoding>`_
.. [#protocol-sproutspendingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.2.3: Sprout Spending Keys <protocol/protocol.pdf#sproutspendingkeyencoding>`_
.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.3: Sapling Full Viewing Keys <protocol/protocol.pdf#saplingfullviewingkeyencoding>`_
.. [#protocol-saplingspendingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.4: Sapling Spending Keys <protocol/protocol.pdf#saplingspendingkeyencoding>`_
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.4: Orchard Raw Full Viewing Keys <protocol/protocol.pdf#orchardfullviewingkeyencoding>`_
.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.5: Orchard Spending Keys <protocol/protocol.pdf#orchardspendingkeyencoding>`_
.. [#NIST-SP-800-38G] `NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption <https://dx.doi.org/10.6028/NIST.SP.800-38G>`_

18
zip-0076.html Normal file
View File

@ -0,0 +1,18 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 76: Transaction Signature Validation before Overwinter</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 76
Title: Transaction Signature Validation before Overwinter
Owners: Jack Grigg &lt;str4d@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Status: Reserved
Category: Consensus
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/130">https://github.com/zcash/zips/issues/130</a>&gt;</pre>
</section>
</body>
</html>

9
zip-0076.rst Normal file
View File

@ -0,0 +1,9 @@
::
ZIP: 76
Title: Transaction Signature Validation before Overwinter
Owners: Jack Grigg <str4d@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Status: Reserved
Category: Consensus
Discussions-To: <https://github.com/zcash/zips/issues/130>

480
zip-0143.html Normal file

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

287
zip-0155.html Normal file
View File

@ -0,0 +1,287 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 155: addrv2 message</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 155
Title: addrv2 message
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Credits: Wladimir J. van der Laan
Zancas Wilcox
Status: Proposed
Category: Network
Created: 2021-08-13
License: BSD-2-Clause
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/542">https://github.com/zcash/zips/issues/542</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/543">https://github.com/zcash/zips/pull/543</a>&gt;</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</a></p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
<p>"P2P network" means the Zcash peer-to-peer network.</p>
<p><code>uint8</code>, <code>uint16</code>, and <code>uint32</code> denote unsigned integer data types of the corresponding length (8, 16, or 32 bits respectively).</p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This document proposes a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current <code>addr</code> message.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Tor v3 onion services are part of the stable release of Tor since version 0.3.2.9. They have various advantages compared to the old v2 onion services, among which better encryption and privacy <a id="id4" class="footnote_reference" href="#tor-rendezvous-v3">9</a>. These services have 256-bit addresses and thus do not fit in the existing <code>addr</code> message (unchanged from Bitcoin <a id="id5" class="footnote_reference" href="#bitcoin-addr-message">7</a>), which encapsulates onion addresses in OnionCat IPv6 addresses.</p>
<p>Other transport-layer protocols such as I2P have always used longer addresses. This change would make it possible to gossip such addresses over the P2P network, so that other peers can connect to them.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The <code>addrv2</code> message is defined as a message where the <code>command</code> field is (NUL-padded) <code>"addrv2"</code>. It is serialized in the standard encoding for P2P messages. Its format is similar to the current <code>addr</code> message format described in <a id="id6" class="footnote_reference" href="#bitcoin-addr-message">7</a>, with the difference that the fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to <a id="id7" class="footnote_reference" href="#bitcoin-compactsize">8</a>.</p>
<p>This means that the message contains a serialized vector of the following structure:</p>
<blockquote>
<table>
<tbody>
<tr>
<td>Bytes</td>
<td>Name</td>
<td>Data Type</td>
<td>Description</td>
</tr>
<tr>
<td>4</td>
<td><code>time</code></td>
<td><code>uint32</code></td>
<td>Time that this node was last seen as connected to the network. A time in Unix epoch time format.</td>
</tr>
<tr>
<td><code>varies</code></td>
<td><code>services</code></td>
<td><code>CompactSize</code></td>
<td>Service bits. A CompactSize-encoded bit field that is 64 bits wide.</td>
</tr>
<tr>
<td>1</td>
<td><code>networkID</code></td>
<td><code>uint8</code></td>
<td>Network identifier. An 8-bit value that specifies which network is addressed.</td>
</tr>
<tr>
<td><code>varies</code></td>
<td><code>sizeAddr</code></td>
<td><code>CompactSize</code></td>
<td>The length in bytes of <code>addr</code>.</td>
</tr>
<tr>
<td><code>sizeAddr</code></td>
<td><code>addr</code></td>
<td><code>uint8[sizeAddr]</code></td>
<td>Network address. The interpretation depends on networkID.</td>
</tr>
<tr>
<td>2</td>
<td><code>port</code></td>
<td><code>uint16</code></td>
<td>Network port. If not relevant for the network this MUST be 0.</td>
</tr>
</tbody>
</table>
</blockquote>
<p>One message can contain up to 1,000 addresses. Clients MUST reject messages with more addresses.</p>
<p>Field <code>addr</code> has a variable length, with a maximum of 512 bytes (4096 bits). Clients MUST reject messages with a longer <code>addr</code> field, irrespective of the network ID.</p>
<p>The list of reserved network IDs is as follows:</p>
<blockquote>
<table>
<tbody>
<tr>
<td>Network ID</td>
<td>Enumeration</td>
<td>Address length (bytes)</td>
<td>Description</td>
</tr>
<tr>
<td><code>0x01</code></td>
<td><code>IPV4</code></td>
<td>4</td>
<td>IPv4 address (globally routed internet)</td>
</tr>
<tr>
<td><code>0x02</code></td>
<td><code>IPV6</code></td>
<td>16</td>
<td>IPv6 address (globally routed internet)</td>
</tr>
<tr>
<td><code>0x04</code></td>
<td><code>TORV3</code></td>
<td>32</td>
<td>Tor v3 onion service address</td>
</tr>
<tr>
<td><code>0x05</code></td>
<td><code>I2P</code></td>
<td>32</td>
<td>I2P overlay network address</td>
</tr>
<tr>
<td><code>0x06</code></td>
<td><code>CJDNS</code></td>
<td>16</td>
<td>Cjdns overlay network address</td>
</tr>
</tbody>
</table>
</blockquote>
<p>Network ID <code>0x03</code> is intentionally not assigned. In BIP 155 <a id="id8" class="footnote_reference" href="#bip-0155">3</a> it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.</p>
<p>Clients SHOULD gossip valid, potentially routable addresses from all known networks, even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to.</p>
<p>Clients MUST NOT gossip addresses from unknown networks, because they have no means to validate those addresses and so can be tricked to gossip invalid addresses.</p>
<p>Clients MUST reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless.</p>
<section id="network-address-encodings"><h3><span class="section-heading">Network address encodings</span><span class="section-anchor"> <a rel="bookmark" href="#network-address-encodings"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The <code>IPV4</code> and <code>IPV6</code> network IDs use addresses encoded in the usual way for binary IPv4 and IPv6 addresses in network byte order (big endian).</p>
<section id="tor-v3-address-encoding"><h4><span class="section-heading">Tor v3 address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#tor-v3-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>According to the spec <a id="id9" class="footnote_reference" href="#tor-rendezvous-v3">9</a>, version 3 <code>.onion</code> addresses are encoded as follows:</p>
<pre>onion_address = base32(PUBKEY || CHECKSUM || VERSION) + ".onion"
CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
<p>where:</p>
<ul>
<li><code>PUBKEY</code> is the 32-byte Ed25519 master pubkey of the onion service;</li>
<li><code>VERSION</code> is a one-byte version field (default value <code>0x03</code>);</li>
<li><code>".onion"</code> and <code>".onion checksum"</code> are constant strings;</li>
<li><code>CHECKSUM</code> is truncated to two bytes before inserting it in <code>onion_address</code>;</li>
<li><code>H()</code> is the SHA3-256 cryptographic hash function. <a id="id10" class="footnote_reference" href="#nist-sha3">10</a></li>
</ul>
<p>Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte <code>PUBKEY</code> part in the <code>addr</code> field. As <code>VERSION</code> will always be 0x03 in the case of v3 addresses, this is enough to reconstruct the onion address.</p>
</section>
<section id="i2p-address-encoding"><h4><span class="section-heading">I2P address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#i2p-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Like Tor, I2P naming uses a base32-encoded address format <a id="id11" class="footnote_reference" href="#i2p-naming">11</a>.</p>
<p>I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by <code>.b32.i2p</code>. The base32 encoding does not include <code>"="</code> padding characters.</p>
<p>I2P addresses MUST be sent with the <code>I2P</code> network ID, with the decoded SHA-256 hash as address field.</p>
</section>
<section id="cjdns-address-encoding"><h4><span class="section-heading">Cjdns address encoding</span><span class="section-anchor"> <a rel="bookmark" href="#cjdns-address-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Cjdns addresses are simply IPv6 addresses in the <code>fc00::/8</code> range <a id="id12" class="footnote_reference" href="#cjdns-whitepaper">12</a>. They MUST be sent with the <code>CJDNS</code> network ID. They are encoded in network byte order (big endian) as for the <code>IPV6</code> network ID.</p>
</section>
</section>
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>TODO: change ${PLACEHOLDER} to a specific peer protocol version.</p>
<p>Support for this specification is signalled by peer protocol version ${PLACEHOLDER} (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet <a id="id13" class="footnote_reference" href="#zip-0252">6</a>.</p>
<p>Nodes that have not negotiated peer protocol version ${PLACEHOLDER} or higher on a given connection, MUST NOT send <code>addrv2</code> messages on that connection.</p>
<p>A node that has negotiated peer protocol version ${PLACEHOLDER} or higher on a given connection, MAY still send <code>addr</code> messages on the connection, and MUST handle received <code>addr</code> messages as it would have done prior to this ZIP.</p>
</section>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP is closely based on BIP 155 <a id="id14" class="footnote_reference" href="#bip-0155">3</a>, with the following changes:</p>
<ul>
<li>Deployment: support for the <code>addrv2</code> message is signalled by advertising a peer protocol version of ${PLACEHOLDER} or higher, not by sending a <code>sendaddrv2</code> message. This is motivated by a desire to avoid an exponential explosion in the space of possible feature configurations in a given peer-to-peer connection. In Zcash, unlike Bitcoin, the space of such configurations is effectively constant no matter how many peer-to-peer protocol changes are made, because nodes that do not support a given peer protocol version will drop off the network over time if they do not support the latest Network Upgrade. The feature configuration for a given connection is also established at version negotiation, and cannot change after that point without reconnecting. Other peer-to-peer protocol changes ported from the Bitcoin peer-to-peer protocol, for example the <code>MSG_WTX</code> inv type defined in ZIP 239 <a id="id15" class="footnote_reference" href="#zip-0239">5</a>, have taken the same approach to signalling.</li>
<li>No Network ID for Tor v2 onion addresses: the Tor network is expected to have removed support for these addresses in the timeframe for deployment of this ZIP.</li>
<li>Clients MUST, rather than SHOULD, reject <code>addrv2</code> messages with more than 1,000 addresses. Making this a consistent requirement promotes interoperability.</li>
<li>Clients MUST NOT, rather than SHOULD NOT, gossip addresses from unknown networks.</li>
<li>Clients MUST, rather than SHOULD, reject messages that contain addresses that have a different length than specified for a known network ID, or a length greater than the 512-byte maximum for an unknown network ID.</li>
</ul>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TBD.</p>
</section>
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP is closely based on BIP 155 <a id="id16" class="footnote_reference" href="#bip-0155">3</a>, written by Wladimir J. van der Laan. Zancas Wilcox ported the implementation for Zcashd.</p>
<p>Acknowledgements for BIP 155:</p>
<ul>
<li>Jonas Schnelli: change <code>services</code> field to <code>CompactSize</code>, to make the message more compact in the likely case instead of always using 8 bytes.</li>
<li>Gregory Maxwell: various suggestions regarding extensibility.</li>
</ul>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="bip-0155" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki">BIP 155: addrv2 message</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0239" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0239">ZIP 239: Relay of Version 5 Transactions</a></td>
</tr>
</tbody>
</table>
<table id="zip-0252" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="bitcoin-addr-message" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="https://en.bitcoin.it/wiki/Protocol_documentation#addr">Protocol documentation: addr. Bitcoin Wiki</a></td>
</tr>
</tbody>
</table>
<table id="bitcoin-compactsize" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer">Variable length integer. Bitcoin Wiki</a></td>
</tr>
</tbody>
</table>
<table id="tor-rendezvous-v3" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt">Tor Rendezvous Specification - Version 3</a></td>
</tr>
</tbody>
</table>
<table id="nist-sha3" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="https://csrc.nist.gov/publications/detail/fips/202/final">NIST FIPS 202 - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</a></td>
</tr>
</tbody>
</table>
<table id="i2p-naming" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="https://geti2p.net/en/docs/naming#base32">I2P: Naming and address book</a></td>
</tr>
</tbody>
</table>
<table id="cjdns-whitepaper" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="https://github.com/cjdelisle/cjdns/blob/f909b960709a4e06730ddd4d221e5df38164dbb6/doc/Whitepaper.md#user-content-pulling-it-all-together">Cjdns whitepaper: Pulling It All Together</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

251
zip-0155.rst Normal file
View File

@ -0,0 +1,251 @@
::
ZIP: 155
Title: addrv2 message
Owners: Daira Hopwood <daira@electriccoin.co>
Credits: Wladimir J. van der Laan
Zancas Wilcox
Status: Proposed
Category: Network
Created: 2021-08-13
License: BSD-2-Clause
Discussions-To: <https://github.com/zcash/zips/issues/542>
Pull-Request: <https://github.com/zcash/zips/pull/543>
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
document are to be interpreted as described in RFC 2119. [#RFC2119]_
The term "network upgrade" in this document is to be interpreted as described in
ZIP 200. [#zip-0200]_
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
"P2P network" means the Zcash peer-to-peer network.
``uint8``, ``uint16``, and ``uint32`` denote unsigned integer data types of the
corresponding length (8, 16, or 32 bits respectively).
Abstract
========
This document proposes a new P2P message to gossip longer node addresses over the
P2P network. This is required to support new-generation onion addresses, I2P, and
potentially other networks that have longer endpoint addresses than fit in the 128
bits of the current ``addr`` message.
Motivation
==========
Tor v3 onion services are part of the stable release of Tor since version 0.3.2.9.
They have various advantages compared to the old v2 onion services, among which better
encryption and privacy [#Tor-rendezvous-v3]_. These services have 256-bit addresses
and thus do not fit in the existing ``addr`` message (unchanged from Bitcoin
[#Bitcoin-addr-message]_), which encapsulates onion addresses in OnionCat IPv6 addresses.
Other transport-layer protocols such as I2P have always used longer addresses. This
change would make it possible to gossip such addresses over the P2P network, so that
other peers can connect to them.
Specification
=============
The ``addrv2`` message is defined as a message where the ``command`` field is
(NUL-padded) ``"addrv2"``. It is serialized in the standard encoding for P2P messages.
Its format is similar to the current ``addr`` message format described in
[#Bitcoin-addr-message]_, with the difference that the fixed 16-byte IP address is
replaced by a network ID and a variable-length address, and the services format
has been changed to [#Bitcoin-CompactSize]_.
This means that the message contains a serialized vector of the following structure:
+--------------+-----------------+---------------------+----------------------------------------------------------------+
| Bytes | Name | Data Type | Description |
+--------------+-----------------+---------------------+----------------------------------------------------------------+
| 4 | ``time`` | ``uint32`` | Time that this node was last seen as connected to the network. |
| | | | A time in Unix epoch time format. |
+--------------+-----------------+---------------------+----------------------------------------------------------------+
| ``varies`` | ``services`` | ``CompactSize`` | Service bits. A CompactSize-encoded bit field that is 64 bits |
| | | | wide. |
+--------------+-----------------+---------------------+----------------------------------------------------------------+
| 1 | ``networkID`` | ``uint8`` | Network identifier. An 8-bit value that specifies which |
| | | | network is addressed. |
+--------------+-----------------+---------------------+----------------------------------------------------------------+
| ``varies`` | ``sizeAddr`` | ``CompactSize`` | The length in bytes of ``addr``. |
+--------------+-----------------+---------------------+----------------------------------------------------------------+
| ``sizeAddr`` | ``addr`` | ``uint8[sizeAddr]`` | Network address. The interpretation depends on networkID. |
+--------------+-----------------+---------------------+----------------------------------------------------------------+
| 2 | ``port`` | ``uint16`` | Network port. If not relevant for the network this MUST be 0. |
+--------------+-----------------+---------------------+----------------------------------------------------------------+
One message can contain up to 1,000 addresses. Clients MUST reject messages with
more addresses.
Field ``addr`` has a variable length, with a maximum of 512 bytes (4096 bits). Clients
MUST reject messages with a longer ``addr`` field, irrespective of the network ID.
The list of reserved network IDs is as follows:
+------------+-------------+------------------------+-----------------------------------------+
| Network ID | Enumeration | Address length (bytes) | Description |
+------------+-------------+------------------------+-----------------------------------------+
| ``0x01`` | ``IPV4`` | 4 | IPv4 address (globally routed internet) |
+------------+-------------+------------------------+-----------------------------------------+
| ``0x02`` | ``IPV6`` | 16 | IPv6 address (globally routed internet) |
+------------+-------------+------------------------+-----------------------------------------+
| ``0x04`` | ``TORV3`` | 32 | Tor v3 onion service address |
+------------+-------------+------------------------+-----------------------------------------+
| ``0x05`` | ``I2P`` | 32 | I2P overlay network address |
+------------+-------------+------------------------+-----------------------------------------+
| ``0x06`` | ``CJDNS`` | 16 | Cjdns overlay network address |
+------------+-------------+------------------------+-----------------------------------------+
Network ID ``0x03`` is intentionally not assigned. In BIP 155 [#bip-0155]_ it was
assigned to Tor v2 onion addresses, but those addresses are no longer supported
by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.
Clients SHOULD gossip valid, potentially routable addresses from all known
networks, even if they are currently not connected to some of them. That could
help multi-homed nodes and make it more difficult for an observer to tell which
networks a node is connected to.
Clients MUST NOT gossip addresses from unknown networks, because they have no means
to validate those addresses and so can be tricked to gossip invalid addresses.
Clients MUST reject messages that contain addresses that have a different length
than specified in this table for a specific network ID, as these are meaningless.
Network address encodings
-------------------------
The ``IPV4`` and ``IPV6`` network IDs use addresses encoded in the usual way for
binary IPv4 and IPv6 addresses in network byte order (big endian).
Tor v3 address encoding
'''''''''''''''''''''''
According to the spec [#Tor-rendezvous-v3]_, version 3 ``.onion`` addresses are
encoded as follows::
onion_address = base32(PUBKEY || CHECKSUM || VERSION) + ".onion"
CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes
where:
* ``PUBKEY`` is the 32-byte Ed25519 master pubkey of the onion service;
* ``VERSION`` is a one-byte version field (default value ``0x03``);
* ``".onion"`` and ``".onion checksum"`` are constant strings;
* ``CHECKSUM`` is truncated to two bytes before inserting it in ``onion_address``;
* ``H()`` is the SHA3-256 cryptographic hash function. [#NIST-SHA3]_
Tor v3 addresses MUST be sent with the ``TORV3`` network ID, with the 32-byte
``PUBKEY`` part in the ``addr`` field. As ``VERSION`` will always be 0x03 in the
case of v3 addresses, this is enough to reconstruct the onion address.
I2P address encoding
''''''''''''''''''''
Like Tor, I2P naming uses a base32-encoded address format [#I2P-naming]_.
I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by
``.b32.i2p``. The base32 encoding does not include ``"="`` padding characters.
I2P addresses MUST be sent with the ``I2P`` network ID, with the decoded SHA-256 hash
as address field.
Cjdns address encoding
''''''''''''''''''''''
Cjdns addresses are simply IPv6 addresses in the ``fc00::/8`` range
[#Cjdns-whitepaper]_. They MUST be sent with the ``CJDNS`` network ID.
They are encoded in network byte order (big endian) as for the ``IPV6`` network ID.
Deployment
----------
TODO: change ${PLACEHOLDER} to a specific peer protocol version.
Support for this specification is signalled by peer protocol version ${PLACEHOLDER}
(on both Testnet and Mainnet). Note that this is the same peer protocol version that
signals support for NU5 on Mainnet [#zip-0252]_.
Nodes that have not negotiated peer protocol version ${PLACEHOLDER} or higher on a
given connection, MUST NOT send ``addrv2`` messages on that connection.
A node that has negotiated peer protocol version ${PLACEHOLDER} or higher on a given
connection, MAY still send ``addr`` messages on the connection, and MUST handle
received ``addr`` messages as it would have done prior to this ZIP.
Rationale
=========
This ZIP is closely based on BIP 155 [#bip-0155]_, with the following changes:
* Deployment: support for the ``addrv2`` message is signalled by advertising a
peer protocol version of ${PLACEHOLDER} or higher, not by sending a ``sendaddrv2``
message. This is motivated by a desire to avoid an exponential explosion in the
space of possible feature configurations in a given peer-to-peer connection. In
Zcash, unlike Bitcoin, the space of such configurations is effectively constant no
matter how many peer-to-peer protocol changes are made, because nodes that do not
support a given peer protocol version will drop off the network over time if they do
not support the latest Network Upgrade. The feature configuration for a given
connection is also established at version negotiation, and cannot change after that
point without reconnecting. Other peer-to-peer protocol changes ported from the
Bitcoin peer-to-peer protocol, for example the ``MSG_WTX`` inv type defined in
ZIP 239 [#zip-0239]_, have taken the same approach to signalling.
* No Network ID for Tor v2 onion addresses: the Tor network is expected to have
removed support for these addresses in the timeframe for deployment of this ZIP.
* Clients MUST, rather than SHOULD, reject ``addrv2`` messages with more than 1,000
addresses. Making this a consistent requirement promotes interoperability.
* Clients MUST NOT, rather than SHOULD NOT, gossip addresses from unknown networks.
* Clients MUST, rather than SHOULD, reject messages that contain addresses that have
a different length than specified for a known network ID, or a length greater
than the 512-byte maximum for an unknown network ID.
Reference implementation
========================
TBD.
Acknowledgements
================
This ZIP is closely based on BIP 155 [#bip-0155]_, written by Wladimir J.
van der Laan. Zancas Wilcox ported the implementation for Zcashd.
Acknowledgements for BIP 155:
* Jonas Schnelli: change ``services`` field to ``CompactSize``, to make the message
more compact in the likely case instead of always using 8 bytes.
* Gregory Maxwell: various suggestions regarding extensibility.
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#bip-0155] `BIP 155: addrv2 message <https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0239] `ZIP 239: Relay of Version 5 Transactions <zip-0239.rst>`_
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`_
.. [#Bitcoin-addr-message] `Protocol documentation: addr. Bitcoin Wiki <https://en.bitcoin.it/wiki/Protocol_documentation#addr>`_
.. [#Bitcoin-CompactSize] `Variable length integer. Bitcoin Wiki <https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer>`_
.. [#Tor-rendezvous-v3] `Tor Rendezvous Specification - Version 3 <https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt>`_
.. [#NIST-SHA3] `NIST FIPS 202 - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions <https://csrc.nist.gov/publications/detail/fips/202/final>`_
.. [#I2P-naming] `I2P: Naming and address book <https://geti2p.net/en/docs/naming#base32>`_
.. [#Cjdns-whitepaper] `Cjdns whitepaper: Pulling It All Together <https://github.com/cjdelisle/cjdns/blob/f909b960709a4e06730ddd4d221e5df38164dbb6/doc/Whitepaper.md#user-content-pulling-it-all-together>`_

412
zip-0173.html Normal file
View File

@ -0,0 +1,412 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 173: Bech32 Format</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 173
Title: Bech32 Format
Author: Daira Hopwood &lt;daira@electriccoin.co&gt;
Credits: Pieter Wuille &lt;pieter.wuille@gmail.com&gt;
Greg Maxwell &lt;greg@xiph.org&gt;
Rusty Russell
Mark Friedenbach
Status: Final
Category: Standards / Wallet
Created: 2018-06-13
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</a></p>
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205. <a id="id3" class="footnote_reference" href="#zip-0205">5</a></p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This document proposes a checksummed base32 format, "Bech32", and a standard for Sapling addresses and keys using it.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Since launch, Zcash has relied on Base58 addresses with a truncated double-SHA256 checksum, inherited from Bitcoin. They were part of the original Bitcoin software and their scope was extended in BIP 13 <a id="id4" class="footnote_reference" href="#bip-0013">6</a> for P2SH (Pay-to-Script-Hash) addresses. However, both the character set and the checksum algorithm have limitations:</p>
<ul>
<li>Base58 needs a lot of space in QR codes, as it cannot use the ''alphanumeric mode''.</li>
<li>The mixed case in Base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud.</li>
<li>The double-SHA256 checksum is slow and has no error-detection guarantees.</li>
<li>Most of the research on error-detecting codes only applies to character-set sizes that are a <a href="https://en.wikipedia.org/wiki/Prime_power">prime power</a>, which 58 is not.</li>
<li>Base58 decoding is complicated and relatively slow.</li>
</ul>
<p>To address these issues, Bitcoin adopted a new encoding called Bech32 <a id="id5" class="footnote_reference" href="#bip-0173">7</a>, for use with address types added by its Segregated Witness proposal. Zcash does not implement Segregated Witness, but it reuses Bech32 with address and key types introduced by the Sapling network upgrade <a id="id6" class="footnote_reference" href="#zip-0205">5</a>.</p>
<p>Since the description of Bech32 in <a id="id7" class="footnote_reference" href="#bip-0173">7</a> is partially entangled with Segregated Witness address formats, we have found it clearer to write this ZIP to specify Bech32 separately. This specification should be read in conjunction with section 5.6 ("Encodings of Addresses and Keys") of the Zcash Sapling protocol specification <a id="id8" class="footnote_reference" href="#protocol">2</a>, and with ZIP 32 which specifies additional key types for support of shielded hierarchical deterministic wallets <a id="id9" class="footnote_reference" href="#zip-0032">3</a>.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>We describe the general checksummed base32 format called ''Bech32''. Its use for Sapling payment addresses and keys is defined in the Sapling protocol specification <a id="id10" class="footnote_reference" href="#protocol">2</a>.</p>
<p>A Bech32 string consists of:</p>
<ul>
<li>The <em>human-readable part</em>, which is intended to convey the type of data, or anything else that is relevant to the reader. This part MUST contain 1 to 83 US-ASCII characters, with each character having a value in the range [33-126]. HRP validity may be further restricted by specific applications.</li>
<li>The <em>separator</em>, which is always "1". In case "1" is allowed inside the human-readable part, the last one in the string is the separator.</li>
<li>The <em>data part</em>, which is at least 6 characters long and only consists of alphanumeric characters excluding "1", "b", "i", and "o".</li>
</ul>
<table>
<thead>
<tr>
<th></th>
<th>0</th>
<th>1</th>
<th>2</th>
<th>3</th>
<th>4</th>
<th>5</th>
<th>6</th>
<th>7</th>
</tr>
</thead>
<tbody>
<tr>
<td>+0</td>
<td>q</td>
<td>p</td>
<td>z</td>
<td>r</td>
<td>y</td>
<td>9</td>
<td>x</td>
<td>8</td>
</tr>
<tr>
<td>+8</td>
<td>g</td>
<td>f</td>
<td>2</td>
<td>t</td>
<td>v</td>
<td>d</td>
<td>w</td>
<td>0</td>
</tr>
<tr>
<td>+16</td>
<td>s</td>
<td>3</td>
<td>j</td>
<td>n</td>
<td>5</td>
<td>4</td>
<td>k</td>
<td>h</td>
</tr>
<tr>
<td>+24</td>
<td>c</td>
<td>e</td>
<td>6</td>
<td>m</td>
<td>u</td>
<td>a</td>
<td>7</td>
<td>l</td>
</tr>
</tbody>
</table>
<section id="checksum"><h3><span class="section-heading">Checksum</span><span class="section-anchor"> <a rel="bookmark" href="#checksum"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The last six characters of the data part form a checksum and contain no information. Valid strings MUST pass the criteria for validity specified by the Python3 code snippet below. The checksum is defined so that the function <code>bech32_verify_checksum</code> returns true when its arguments are:</p>
<ul>
<li><code>hrp</code>: the human-readable part as a string;</li>
<li><code>data</code>: the data part as a list of integers representing the characters after conversion using the table above.</li>
</ul>
<pre>def bech32_polymod(values):
GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]
chk = 1
for v in values:
b = (chk &gt;&gt; 25)
chk = (chk &amp; 0x1ffffff) &lt;&lt; 5 ^ v
for i in range(5):
chk ^= GEN[i] if ((b &gt;&gt; i) &amp; 1) else 0
return chk
def bech32_hrp_expand(s):
return [ord(x) &gt;&gt; 5 for x in s] + [0] + [ord(x) &amp; 31 for x in s]
def bech32_verify_checksum(hrp, data):
return bech32_polymod(bech32_hrp_expand(hrp) + data) == 1</pre>
<p>This implements a <a href="https://en.wikipedia.org/wiki/BCH_code">BCH code</a>; in the case where the encoded string is at most 90 characters, this code guarantees detection of <em>any error affecting at most 4 characters</em> and has less than a 1 in 10<sup>9</sup> chance of failing to detect more errors. More details about the properties can be found in the Checksum Design section. The human-readable part is processed by first feeding the higher 3 bits of each character's US-ASCII value into the checksum calculation followed by a zero and then the lower 5 bits of each US-ASCII value.</p>
<p>To construct a valid checksum given the human-readable part and (non-checksum) values of the data-part characters, the code below can be used:</p>
<pre>def bech32_create_checksum(hrp, data):
values = bech32_hrp_expand(hrp) + data
polymod = bech32_polymod(values + [0,0,0,0,0,0]) ^ 1
return [(polymod &gt;&gt; 5 * (5 - i)) &amp; 31 for i in range(6)]</pre>
<section id="error-correction"><h4><span class="section-heading">Error correction</span><span class="section-anchor"> <a rel="bookmark" href="#error-correction"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>One of the properties of these BCH codes is that they can be used for error correction. An unfortunate side effect of error correction is that it erodes error detection: correction changes invalid inputs into valid inputs, but if more than a few errors were made then the valid input may not be the correct input. Use of an incorrect but valid input can cause funds to be lost irrecoverably. Because of this, implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the string an error might be found, without suggesting the correction to make.</p>
</section>
<section id="uppercase-lowercase"><h4><span class="section-heading">Uppercase/lowercase</span><span class="section-anchor"> <a rel="bookmark" href="#uppercase-lowercase"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The lowercase form is used when determining a character's value for checksum purposes.</p>
<p>Encoders MUST always output an all-lowercase Bech32 string. If an uppercase version of the encoding result is desired (e.g. for presentation purposes, or QR code use), then an uppercasing procedure can be performed external to the encoding process.</p>
<p>Decoders MUST NOT accept strings where some characters are uppercase and some are lowercase (such strings are referred to as mixed-case strings).</p>
<p>For presentation, lowercase is usually preferable, but inside QR codes uppercase SHOULD be used, as those permit the use of <a href="https://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding">alphanumeric mode</a>, which is 45% more compact than the <a href="https://www.thonky.com/qr-code-tutorial/byte-mode-encoding">byte mode</a> that would otherwise be used.</p>
</section>
<section id="encoding"><h4><span class="section-heading">Encoding</span><span class="section-anchor"> <a rel="bookmark" href="#encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<ul>
<li>Start with the bits of the raw encoding of the appropriate address or key type, most significant bit per byte first.</li>
<li>Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.</li>
<li>Translate those bits, most significant bit first, to characters using the table above.</li>
</ul>
</section>
<section id="decoding"><h4><span class="section-heading">Decoding</span><span class="section-anchor"> <a rel="bookmark" href="#decoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Software interpreting a Bech32-encoded address MUST first verify that the human-readable part matches that of a specified address type, and similarly for keys.</p>
<p>If this check passes, convert the rest of the data to bytes:</p>
<ul>
<li>Translate the values using the table above to 5 bits, most significant bit first.</li>
<li>Re-arrange those bits into groups of 8 bits. Any incomplete group at the end MUST be 4 bits or fewer, MUST be all zeroes, and is discarded.</li>
<li>The resulting groups are interpreted as the raw encoding of the appropriate address or key type, with the most significant bit first in each byte.</li>
</ul>
<p>Decoders SHOULD enforce known-length restrictions on address and key types.</p>
<p>For example, <a id="id11" class="footnote_reference" href="#protocol">2</a> specifies that the length of the raw encoding of a Sapling payment address is 43 bytes (88 + 256 bits). This results in a Bech32-encoded Sapling payment address being 78 characters long.</p>
</section>
</section>
</section>
<section id="compatibility"><h2><span class="section-heading">Compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Only software supporting the Sapling network upgrade is able to use these addresses.</p>
<p>There is no effect on support for transparent addresses and keys, or for Sprout z-addresses and keys; these will continue to be encoded using Base58Check, and MUST NOT be encoded using Bech32.</p>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="why-use-base32-at-all"><h3><span class="section-heading">Why use base32 at all?</span><span class="section-anchor"> <a rel="bookmark" href="#why-use-base32-at-all"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The lack of mixed case makes it more efficient to read out loud or to put into QR codes. It does come with a 15% length increase. However, the length of a Bech32-encoded Sapling payment address remains below 80 characters, which reduces the likelihood of line splitting in terminals or email. Thus, cutting-and-pasting of addresses is still reliable.</p>
</section>
<section id="why-call-it-bech32"><h3><span class="section-heading">Why call it Bech32?</span><span class="section-anchor"> <a rel="bookmark" href="#why-call-it-bech32"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>"Bech" contains the characters BCH (the error detection algorithm used) and sounds a bit like "base". The term Bech32 is established for Bitcoin and there was no reason to use a different name for it in Zcash Sapling.</p>
</section>
<section id="why-not-support-bech32-encoding-of-sprout-or-transparent-addresses"><h3><span class="section-heading">Why not support Bech32 encoding of Sprout or transparent addresses?</span><span class="section-anchor"> <a rel="bookmark" href="#why-not-support-bech32-encoding-of-sprout-or-transparent-addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>This was not considered to be sufficiently well-motivated given the compatibility issues that would arise from having two formats for these address types, with pre-Sapling software not supporting the new format.</p>
</section>
<section id="why-include-a-separator-in-addresses"><h3><span class="section-heading">Why include a separator in addresses?</span><span class="section-anchor"> <a rel="bookmark" href="#why-include-a-separator-in-addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>That way the human-readable part is unambiguously separated from the data part, avoiding potential collisions with other human-readable parts that share a prefix. It also allows us to avoid having character-set restrictions on the human-readable part. The separator is ''1'' because using a non-alphanumeric character would complicate copy-pasting of addresses (with no double-click selection in several applications). Therefore an alphanumeric character outside the normal character set was chosen.</p>
</section>
<section id="why-not-use-an-existing-base32-character-set"><h3><span class="section-heading">Why not use an existing base32 character set?</span><span class="section-anchor"> <a rel="bookmark" href="#why-not-use-an-existing-base32-character-set"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Existing character sets for base-32 encodings include <a href="https://www.rfc-editor.org/rfc/rfc3548.html">RFC 3548</a> and <a href="https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt">z-base-32</a>. The set used for Bech32 was chosen to minimize ambiguity according to <a href="https://hissa.nist.gov/~black/GTLD/">this</a> visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.</p>
</section>
<section id="why-are-the-high-bits-of-the-human-readable-part-processed-first"><h3><span class="section-heading">Why are the high bits of the human-readable part processed first?</span><span class="section-anchor"> <a rel="bookmark" href="#why-are-the-high-bits-of-the-human-readable-part-processed-first"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>This design choice had a rationale for Bitcoin Segregated Witness addresses (see <a id="id12" class="footnote_reference" href="#bip-0173">7</a>) that does not apply to Zcash Sapling addresses. It is retained for compatibility with Bech32 encoders/decoders written for Bitcoin.</p>
</section>
</section>
<section id="reference-implementations"><h2><span class="section-heading">Reference implementations</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>The encoder/decoder used by <code>zcashd</code>:
<ul>
<li><a href="https://github.com/zcash/zcash/blob/master/src/bech32.cpp">In C++</a></li>
</ul>
</li>
<li>Encoders and decoders written for Bitcoin:
<ul>
<li><a href="https://github.com/sipa/bech32/tree/master/ref/c">For C</a></li>
<li><a href="https://github.com/sipa/bech32/tree/master/ref/c++">For C++</a></li>
<li><a href="https://github.com/sipa/bech32/tree/master/ref/javascript">For Javascript</a></li>
<li><a href="https://github.com/sipa/bech32/tree/master/ref/go">For Go</a></li>
<li><a href="https://github.com/sipa/bech32/tree/master/ref/python">For Python</a></li>
<li><a href="https://github.com/sipa/bech32/tree/master/ref/haskell">For Haskell</a></li>
<li><a href="https://github.com/sipa/bech32/tree/master/ref/ruby">For Ruby</a></li>
<li><a href="https://github.com/sipa/bech32/tree/master/ref/rust">For Rust</a></li>
</ul>
</li>
<li>Fancy decoder written for Bitcoin that localizes errors:
<ul>
<li><a href="https://github.com/sipa/bech32/tree/master/ecc/javascript">Fancy decoder for Javascript</a> (<a href="HTTP://bitcoin.sipa.be/bech32/demo/demo.html">demo website</a>)</li>
</ul>
</li>
</ul>
<p>Note that the encoders written for Bitcoin may make assumptions specific to Segregated Witness address formats that do not apply to Zcash. Only the Python one has been tested with Zcash at the time of writing.</p>
</section>
<section id="examples"><h2><span class="section-heading">Examples</span><span class="section-anchor"> <a rel="bookmark" href="#examples"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TODO: add valid Sapling payment addresses and keys, and their corresponding raw encodings.</p>
</section>
<section id="test-vectors"><h2><span class="section-heading">Test vectors</span><span class="section-anchor"> <a rel="bookmark" href="#test-vectors"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The following strings are valid Bech32:</p>
<ul>
<li><code>A12UEL5L</code></li>
<li><code>a12uel5l</code></li>
<li><code>an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs</code></li>
<li><code>abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw</code></li>
<li><code>11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j</code></li>
<li><code>split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w</code></li>
<li><code>?1ezyfcl</code></li>
</ul>
<p>The following strings are not valid Bech32 (with reason for invalidity):</p>
<ul>
<li>0x20 + <code>1nwldj5</code>: HRP character out of range</li>
<li>0x7F + <code>1axkwrx</code>: HRP character out of range</li>
<li>0x80 + <code>1eym55h</code>: HRP character out of range</li>
<li><code>pzry9x0s0muk</code>: No separator character</li>
<li><code>1pzry9x0s0muk</code>: Empty HRP</li>
<li><code>x1b4n0q5v</code>: Invalid data character</li>
<li><code>li1dgmt3</code>: Too short checksum</li>
<li><code>de1lg7wt</code> + 0xFF: Invalid character in checksum</li>
<li><code>A1G7SGD8</code>: checksum calculated with uppercase form of HRP</li>
<li><code>10a06t8</code>: empty HRP</li>
<li><code>1qzzfhee</code>: empty HRP</li>
<li><code>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5</code>: Invalid checksum</li>
<li><code>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sL5k7</code>: Mixed case</li>
<li><code>bc1zw508d6qejxtdg4y5r3zarvaryvqyzf3du</code>: Zero padding of more than 4 bits</li>
<li><code>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3pjxtptv</code>: Non-zero padding in 8-to-5 conversion</li>
</ul>
</section>
<section id="checksum-design"><h2><span class="section-heading">Checksum design</span><span class="section-anchor"> <a rel="bookmark" href="#checksum-design"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="design-choices"><h3><span class="section-heading">Design choices</span><span class="section-anchor"> <a rel="bookmark" href="#design-choices"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>BCH codes can be constructed over any prime-power alphabet and can be chosen to have a good trade-off between size and error-detection capabilities. Unlike <a href="https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction">Reed-Solomon codes</a>, they are not restricted in length to one less than the alphabet size. While they also support efficient error correction, the implementation of just error detection is very simple.</p>
<p>We pick 6 checksum characters as a trade-off between length of the addresses and the error-detection capabilities, as 6 characters is the lowest number sufficient for a random failure chance below 1 per billion. For the length of data we're most interested in protecting (up to 77 bytes excluding the separator, for a Sapling payment address), BCH codes can be constructed that guarantee detecting up to 4 errors. Longer data is also supported with slightly weaker error detection.</p>
<section id="selected-properties"><h4><span class="section-heading">Selected properties</span><span class="section-anchor"> <a rel="bookmark" href="#selected-properties"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Many of these codes perform badly when dealing with more errors than they are designed to detect, but not all. For that reason, we consider codes that are designed to detect only 3 errors as well as 4 errors, and analyse how well they perform in practice.</p>
<p>The specific code chosen here is the result of:</p>
<ul>
<li>Starting with an exhaustive list of 159605 BCH codes designed to detect 3 or 4 errors up to length 93, 151, 165, 341, 1023, and 1057.</li>
<li>From those, requiring the detection of 4 errors up to length 71, resulting in 28825 remaining codes.</li>
<li>From those, choosing the codes with the best worst-case window for 5-character errors, resulting in 310 remaining codes.</li>
<li>From those, picking the code with the lowest chance for not detecting small numbers of ''bit'' errors.</li>
</ul>
<p>As a naive search would require over 6.5 * 10<sup>19</sup> checksum evaluations, a collision-search approach was used for analysis. The code can be found <a href="https://github.com/sipa/ezbase32/">here</a>.</p>
</section>
<section id="properties"><h4><span class="section-heading">Properties</span><span class="section-anchor"> <a rel="bookmark" href="#properties"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The following table summarizes the chances for detection failure (as multiples of 1 in 10<sup>9</sup>).</p>
<table>
<tbody>
<tr>
<td colspan="2">Window length</td>
<td colspan="6">Number of wrong characters</td>
</tr>
<tr>
<td>Length</td>
<td>Description</td>
<td>≤4</td>
<td>5</td>
<td>6</td>
<td>7</td>
<td>8</td>
<td>≥9</td>
</tr>
<tr>
<td>8</td>
<td>Longest detecting 6 errors</td>
<td colspan="3">0</td>
<td>1.127</td>
<td>0.909</td>
<td>n/a</td>
</tr>
<tr>
<td>18</td>
<td>Longest detecting 5 errors</td>
<td colspan="2">0</td>
<td>0.965</td>
<td>0.929</td>
<td>0.932</td>
<td>0.931</td>
</tr>
<tr>
<td>19</td>
<td>Worst case for 6 errors</td>
<td>0</td>
<td>0.093</td>
<td>0.972</td>
<td>0.928</td>
<td colspan="2">0.931</td>
</tr>
<tr>
<td>39</td>
<td>Length ≤ 39 characters</td>
<td>0</td>
<td>0.756</td>
<td>0.935</td>
<td>0.932</td>
<td colspan="2">0.931</td>
</tr>
<tr>
<td>59</td>
<td>Length ≤ 59 characters</td>
<td>0</td>
<td>0.805</td>
<td>0.933</td>
<td colspan="3">0.931</td>
</tr>
<tr>
<td>71</td>
<td>Length ≤ 71 characters</td>
<td>0</td>
<td>0.830</td>
<td>0.934</td>
<td colspan="3">0.931</td>
</tr>
<tr>
<td>89</td>
<td>Longest detecting 4 errors</td>
<td>0</td>
<td>0.867</td>
<td>0.933</td>
<td colspan="3">0.931</td>
</tr>
</tbody>
</table>
<p>TODO: fill in table for a Sapling payment address, and check the following paragraph.</p>
<p>This means that when 5 changed characters occur randomly distributed in the 77 characters (excluding the separator) of a Sapling payment address, there is a chance of at most 0.867 per billion that it will go undetected. When those 5 changes occur randomly within a 19-character window, that chance goes down to 0.093 per billion. As the number of errors goes up, the chance converges towards 1 in 2<sup>30</sup> = 0.931 per billion.</p>
<p>The chosen code performs reasonably well up to 1023 characters, but is best for lengths up to 89 characters (excluding the separator). Since the search for suitable codes was based on the requirements for Bitcoin P2WPKH and P2WSH addresses, it is not quite optimal for the address lengths used by Sapling, but the advantages of compatibility with existing Bitcoin libraries were considered to outweigh this consideration.</p>
</section>
</section>
</section>
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This document is closely based on BIP 173 written by Pieter Wuille and Greg Maxwell, which was inspired by the <a href="https://rusty.ozlabs.org/?p=578">address proposal</a> by Rusty Russell and the <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html">base32</a> proposal by Mark Friedenbach. BIP 173 also had input from Luke Dashjr, Johnson Lau, Eric Lombrozo, Peter Todd, and various other reviewers.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
<table id="zip-0032" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0205" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="bip-0013" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki">BIP 13: Address Format for pay-to-script-hash</a></td>
</tr>
</tbody>
</table>
<table id="bip-0173" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki">BIP 173: Base32 address format for native v0-16 witness outputs</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

470
zip-0173.rst Normal file
View File

@ -0,0 +1,470 @@
::
ZIP: 173
Title: Bech32 Format
Author: Daira Hopwood <daira@electriccoin.co>
Credits: Pieter Wuille <pieter.wuille@gmail.com>
Greg Maxwell <greg@xiph.org>
Rusty Russell
Mark Friedenbach
Status: Final
Category: Standards / Wallet
Created: 2018-06-13
License: MIT
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are
to be interpreted as described in RFC 2119. [#RFC2119]_
The term "network upgrade" in this document is to be interpreted as described in
ZIP 200. [#zip-0200]_
The term "Sapling" in this document is to be interpreted as described in ZIP 205.
[#zip-0205]_
Abstract
========
This document proposes a checksummed base32 format, "Bech32", and a standard for
Sapling addresses and keys using it.
Motivation
==========
Since launch, Zcash has relied on Base58 addresses with a truncated double-SHA256
checksum, inherited from Bitcoin. They were part of the original Bitcoin software
and their scope was extended in BIP 13 [#bip-0013]_ for P2SH (Pay-to-Script-Hash)
addresses. However, both the character set and the checksum algorithm have
limitations:
* Base58 needs a lot of space in QR codes, as it cannot use the
''alphanumeric mode''.
* The mixed case in Base58 makes it inconvenient to reliably write down, type on
mobile keyboards, or read out loud.
* The double-SHA256 checksum is slow and has no error-detection guarantees.
* Most of the research on error-detecting codes only applies to character-set
sizes that are a `prime power <https://en.wikipedia.org/wiki/Prime_power>`_,
which 58 is not.
* Base58 decoding is complicated and relatively slow.
To address these issues, Bitcoin adopted a new encoding called Bech32 [#bip-0173]_,
for use with address types added by its Segregated Witness proposal. Zcash does
not implement Segregated Witness, but it reuses Bech32 with address and key types
introduced by the Sapling network upgrade [#zip-0205]_.
Since the description of Bech32 in [#bip-0173]_ is partially entangled with
Segregated Witness address formats, we have found it clearer to write this ZIP to
specify Bech32 separately. This specification should be read in conjunction with
section 5.6 ("Encodings of Addresses and Keys") of the Zcash Sapling protocol
specification [#protocol]_, and with ZIP 32 which specifies additional key types
for support of shielded hierarchical deterministic wallets [#zip-0032]_.
Specification
=============
We describe the general checksummed base32 format called ''Bech32''. Its use for
Sapling payment addresses and keys is defined in the Sapling protocol specification
[#protocol]_.
A Bech32 string consists of:
* The *human-readable part*, which is intended to convey the type of data, or
anything else that is relevant to the reader. This part MUST contain 1 to 83
US-ASCII characters, with each character having a value in the range [33-126].
HRP validity may be further restricted by specific applications.
* The *separator*, which is always "1". In case "1" is allowed inside the
human-readable part, the last one in the string is the separator.
* The *data part*, which is at least 6 characters long and only consists of
alphanumeric characters excluding "1", "b", "i", and "o".
+-----+---+---+---+---+---+---+---+---+
| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+=====+===+===+===+===+===+===+===+===+
| +0 | q | p | z | r | y | 9 | x | 8 |
+-----+---+---+---+---+---+---+---+---+
| +8 | g | f | 2 | t | v | d | w | 0 |
+-----+---+---+---+---+---+---+---+---+
| +16 | s | 3 | j | n | 5 | 4 | k | h |
+-----+---+---+---+---+---+---+---+---+
| +24 | c | e | 6 | m | u | a | 7 | l |
+-----+---+---+---+---+---+---+---+---+
Checksum
--------
The last six characters of the data part form a checksum and contain no information.
Valid strings MUST pass the criteria for validity specified by the Python3 code
snippet below. The checksum is defined so that the function ``bech32_verify_checksum``
returns true when its arguments are:
* ``hrp``: the human-readable part as a string;
* ``data``: the data part as a list of integers representing the characters after
conversion using the table above.
::
def bech32_polymod(values):
GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]
chk = 1
for v in values:
b = (chk >> 25)
chk = (chk & 0x1ffffff) << 5 ^ v
for i in range(5):
chk ^= GEN[i] if ((b >> i) & 1) else 0
return chk
def bech32_hrp_expand(s):
return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s]
def bech32_verify_checksum(hrp, data):
return bech32_polymod(bech32_hrp_expand(hrp) + data) == 1
This implements a `BCH code <https://en.wikipedia.org/wiki/BCH_code>`_;
in the case where the encoded string is at most 90 characters, this code
guarantees detection of *any error affecting at most 4 characters* and has
less than a 1 in 10\ :sup:`9` chance of failing to detect more errors.
More details about the properties can be found in the Checksum Design section.
The human-readable part is processed by first feeding the higher 3 bits of each
character's US-ASCII value into the checksum calculation followed by a zero
and then the lower 5 bits of each US-ASCII value.
To construct a valid checksum given the human-readable part and (non-checksum)
values of the data-part characters, the code below can be used:
::
def bech32_create_checksum(hrp, data):
values = bech32_hrp_expand(hrp) + data
polymod = bech32_polymod(values + [0,0,0,0,0,0]) ^ 1
return [(polymod >> 5 * (5 - i)) & 31 for i in range(6)]
Error correction
''''''''''''''''
One of the properties of these BCH codes is that they can be used for error
correction. An unfortunate side effect of error correction is that it erodes
error detection: correction changes invalid inputs into valid inputs, but if
more than a few errors were made then the valid input may not be the correct
input. Use of an incorrect but valid input can cause funds to be lost
irrecoverably. Because of this, implementations SHOULD NOT implement correction
beyond potentially suggesting to the user where in the string an error might be
found, without suggesting the correction to make.
Uppercase/lowercase
'''''''''''''''''''
The lowercase form is used when determining a character's value for checksum
purposes.
Encoders MUST always output an all-lowercase Bech32 string. If an uppercase
version of the encoding result is desired (e.g. for presentation purposes, or
QR code use), then an uppercasing procedure can be performed external to the
encoding process.
Decoders MUST NOT accept strings where some characters are uppercase and some
are lowercase (such strings are referred to as mixed-case strings).
For presentation, lowercase is usually preferable, but inside QR codes
uppercase SHOULD be used, as those permit the use of `alphanumeric mode
<https://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding>`_,
which is 45% more compact than the `byte mode
<https://www.thonky.com/qr-code-tutorial/byte-mode-encoding>`_ that would
otherwise be used.
Encoding
''''''''
* Start with the bits of the raw encoding of the appropriate address or key
type, most significant bit per byte first.
* Re-arrange those bits into groups of 5, and pad with zeroes at the end if
needed.
* Translate those bits, most significant bit first, to characters using the
table above.
Decoding
''''''''
Software interpreting a Bech32-encoded address MUST first verify that the
human-readable part matches that of a specified address type, and similarly
for keys.
If this check passes, convert the rest of the data to bytes:
* Translate the values using the table above to 5 bits, most significant bit
first.
* Re-arrange those bits into groups of 8 bits. Any incomplete group at the
end MUST be 4 bits or fewer, MUST be all zeroes, and is discarded.
* The resulting groups are interpreted as the raw encoding of the appropriate
address or key type, with the most significant bit first in each byte.
Decoders SHOULD enforce known-length restrictions on address and key types.
For example, [#protocol]_ specifies that the length of the raw encoding of a
Sapling payment address is 43 bytes (88 + 256 bits). This results in a
Bech32-encoded Sapling payment address being 78 characters long.
Compatibility
=============
Only software supporting the Sapling network upgrade is able to use these
addresses.
There is no effect on support for transparent addresses and keys, or for Sprout
z-addresses and keys; these will continue to be encoded using Base58Check, and
MUST NOT be encoded using Bech32.
Rationale
=========
Why use base32 at all?
----------------------
The lack of mixed case makes it more efficient to read out loud or to put into
QR codes. It does come with a 15% length increase. However, the length of a
Bech32-encoded Sapling payment address remains below 80 characters, which
reduces the likelihood of line splitting in terminals or email. Thus,
cutting-and-pasting of addresses is still reliable.
Why call it Bech32?
-------------------
"Bech" contains the characters BCH (the error detection algorithm used) and
sounds a bit like "base". The term Bech32 is established for Bitcoin and there
was no reason to use a different name for it in Zcash Sapling.
Why not support Bech32 encoding of Sprout or transparent addresses?
-------------------------------------------------------------------
This was not considered to be sufficiently well-motivated given the
compatibility issues that would arise from having two formats for these
address types, with pre-Sapling software not supporting the new format.
Why include a separator in addresses?
-------------------------------------
That way the human-readable part is unambiguously separated from the data part,
avoiding potential collisions with other human-readable parts that share a
prefix. It also allows us to avoid having character-set restrictions on the
human-readable part. The separator is ''1'' because using a non-alphanumeric
character would complicate copy-pasting of addresses (with no double-click
selection in several applications). Therefore an alphanumeric character outside
the normal character set was chosen.
Why not use an existing base32 character set?
---------------------------------------------
Existing character sets for base-32 encodings include
`RFC 3548 <https://www.rfc-editor.org/rfc/rfc3548.html>`_ and
`z-base-32 <https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt>`_.
The set used for Bech32 was chosen to minimize ambiguity according to
`this <https://hissa.nist.gov/~black/GTLD/>`_ visual similarity data, and the
ordering is chosen to minimize the number of pairs of similar characters
(according to the same data) that differ in more than 1 bit. As the checksum is
chosen to maximize detection capabilities for low numbers of bit errors, this
choice improves its performance under some error models.
Why are the high bits of the human-readable part processed first?
-----------------------------------------------------------------
This design choice had a rationale for Bitcoin Segregated Witness addresses
(see [#bip-0173]_) that does not apply to Zcash Sapling addresses. It is
retained for compatibility with Bech32 encoders/decoders written for Bitcoin.
Reference implementations
=========================
* The encoder/decoder used by ``zcashd``:
* `In C++ <https://github.com/zcash/zcash/blob/master/src/bech32.cpp>`_
* Encoders and decoders written for Bitcoin:
* `For C <https://github.com/sipa/bech32/tree/master/ref/c>`_
* `For C++ <https://github.com/sipa/bech32/tree/master/ref/c++>`_
* `For Javascript <https://github.com/sipa/bech32/tree/master/ref/javascript>`_
* `For Go <https://github.com/sipa/bech32/tree/master/ref/go>`_
* `For Python <https://github.com/sipa/bech32/tree/master/ref/python>`_
* `For Haskell <https://github.com/sipa/bech32/tree/master/ref/haskell>`_
* `For Ruby <https://github.com/sipa/bech32/tree/master/ref/ruby>`_
* `For Rust <https://github.com/sipa/bech32/tree/master/ref/rust>`_
* Fancy decoder written for Bitcoin that localizes errors:
* `Fancy decoder for Javascript <https://github.com/sipa/bech32/tree/master/ecc/javascript>`_
(`demo website <HTTP://bitcoin.sipa.be/bech32/demo/demo.html>`_)
Note that the encoders written for Bitcoin may make assumptions specific to
Segregated Witness address formats that do not apply to Zcash. Only the Python
one has been tested with Zcash at the time of writing.
Examples
========
TODO: add valid Sapling payment addresses and keys, and their corresponding raw encodings.
Test vectors
============
The following strings are valid Bech32:
* ``A12UEL5L``
* ``a12uel5l``
* ``an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs``
* ``abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw``
* ``11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j``
* ``split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w``
* ``?1ezyfcl``
The following strings are not valid Bech32 (with reason for invalidity):
* 0x20 + ``1nwldj5``: HRP character out of range
* 0x7F + ``1axkwrx``: HRP character out of range
* 0x80 + ``1eym55h``: HRP character out of range
* ``pzry9x0s0muk``: No separator character
* ``1pzry9x0s0muk``: Empty HRP
* ``x1b4n0q5v``: Invalid data character
* ``li1dgmt3``: Too short checksum
* ``de1lg7wt`` + 0xFF: Invalid character in checksum
* ``A1G7SGD8``: checksum calculated with uppercase form of HRP
* ``10a06t8``: empty HRP
* ``1qzzfhee``: empty HRP
* ``bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5``: Invalid checksum
* ``tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sL5k7``: Mixed case
* ``bc1zw508d6qejxtdg4y5r3zarvaryvqyzf3du``: Zero padding of more than 4 bits
* ``tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3pjxtptv``: Non-zero padding in 8-to-5 conversion
Checksum design
===============
Design choices
--------------
BCH codes can be constructed over any prime-power alphabet and can be chosen to
have a good trade-off between size and error-detection capabilities. Unlike
`Reed-Solomon codes <https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction>`_,
they are not restricted in length to one less than the alphabet size. While they
also support efficient error correction, the implementation of just error detection
is very simple.
We pick 6 checksum characters as a trade-off between length of the addresses and
the error-detection capabilities, as 6 characters is the lowest number sufficient
for a random failure chance below 1 per billion. For the length of data we're
most interested in protecting (up to 77 bytes excluding the separator, for a
Sapling payment address), BCH codes can be constructed that guarantee detecting
up to 4 errors. Longer data is also supported with slightly weaker error detection.
Selected properties
'''''''''''''''''''
Many of these codes perform badly when dealing with more errors than they are
designed to detect, but not all. For that reason, we consider codes that are
designed to detect only 3 errors as well as 4 errors, and analyse how well they
perform in practice.
The specific code chosen here is the result of:
* Starting with an exhaustive list of 159605 BCH codes designed to detect 3 or 4
errors up to length 93, 151, 165, 341, 1023, and 1057.
* From those, requiring the detection of 4 errors up to length 71, resulting in
28825 remaining codes.
* From those, choosing the codes with the best worst-case window for 5-character
errors, resulting in 310 remaining codes.
* From those, picking the code with the lowest chance for not detecting small
numbers of ''bit'' errors.
As a naive search would require over 6.5 \* 10\ :sup:`19` checksum evaluations,
a collision-search approach was used for analysis. The code can be found
`here <https://github.com/sipa/ezbase32/>`_.
Properties
''''''''''
The following table summarizes the chances for detection failure (as multiples of
1 in 10\ :sup:`9`).
+-------------------------------------+-----------------------------------------------+
| Window length | Number of wrong characters |
+--------+----------------------------+-------+-------+-------+-------+-------+-------+
| Length | Description | ≤4 | 5 | 6 | 7 | 8 | ≥9 |
+--------+----------------------------+-------+-------+-------+-------+-------+-------+
| 8 | Longest detecting 6 errors | 0 | 1.127 | 0.909 | n/a |
+--------+----------------------------+---------------+-------+-------+-------+-------+
| 18 | Longest detecting 5 errors | 0 | 0.965 | 0.929 | 0.932 | 0.931 |
+--------+----------------------------+-------+-------+-------+-------+-------+-------+
| 19 | Worst case for 6 errors | 0 | 0.093 | 0.972 | 0.928 | 0.931 |
+--------+----------------------------+-------+-------+-------+-------+---------------+
| 39 | Length ≤ 39 characters | 0 | 0.756 | 0.935 | 0.932 | 0.931 |
+--------+----------------------------+-------+-------+-------+-------+---------------+
| 59 | Length ≤ 59 characters | 0 | 0.805 | 0.933 | 0.931 |
+--------+----------------------------+-------+-------+-------+-----------------------+
| 71 | Length ≤ 71 characters | 0 | 0.830 | 0.934 | 0.931 |
+--------+----------------------------+-------+-------+-------+-----------------------+
| 89 | Longest detecting 4 errors | 0 | 0.867 | 0.933 | 0.931 |
+--------+----------------------------+-------+-------+-------+-----------------------+
TODO: fill in table for a Sapling payment address, and check the following paragraph.
This means that when 5 changed characters occur randomly distributed in the 77
characters (excluding the separator) of a Sapling payment address, there is a chance
of at most 0.867 per billion that it will go undetected. When those 5 changes occur
randomly within a 19-character window, that chance goes down to 0.093 per billion.
As the number of errors goes up, the chance converges towards 1 in 2\ :sup:`30` =
0.931 per billion.
The chosen code performs reasonably well up to 1023 characters, but is best for
lengths up to 89 characters (excluding the separator). Since the search for suitable
codes was based on the requirements for Bitcoin P2WPKH and P2WSH addresses, it is
not quite optimal for the address lengths used by Sapling, but the advantages of
compatibility with existing Bitcoin libraries were considered to outweigh this
consideration.
Acknowledgements
================
This document is closely based on BIP 173 written by Pieter Wuille and Greg Maxwell,
which was inspired by the `address proposal <https://rusty.ozlabs.org/?p=578>`_ by
Rusty Russell and the `base32
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html>`_
proposal by Mark Friedenbach. BIP 173 also had input from Luke Dashjr, Johnson Lau,
Eric Lombrozo, Peter Todd, and various other reviewers.
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#bip-0013] `BIP 13: Address Format for pay-to-script-hash <https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki>`_
.. [#bip-0173] `BIP 173: Base32 address format for native v0-16 witness outputs <https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki>`_

176
zip-0200.html Normal file
View File

@ -0,0 +1,176 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 200: Network Upgrade Mechanism</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 200
Title: Network Upgrade Mechanism
Owners: Jack Grigg &lt;str4d@electriccoin.co&gt;
Status: Final
Category: Consensus
Created: 2018-01-08
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Block chain</dt>
<dd>A sequence of blocks starting at the genesis block, where the header of each block refers to the previous block in the sequence.</dd>
<dt>Consensus rule set</dt>
<dd>A set of validation rules that determine which block chains are considered valid.</dd>
<dt>Consensus rule change</dt>
<dd>A change in the consensus rule set of the network, such that nodes that do not recognize the new rules will follow a different block chain.</dd>
<dt>Consensus branch</dt>
<dd>A block chain with a common consensus rule set, where the first block in the chain is either the genesis block, or the child of a parent block created under an older set of consensus rules (i.e. the parent block is a member of a different consensus branch). By definition, every block belongs to at most one consensus branch.</dd>
<dt>Network upgrade</dt>
<dd>An intentional consensus rule change undertaken by the community in order to improve the network.</dd>
</dl>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a mechanism for coordinating upgrades of the Zcash network, in order to remove ambiguity about when network upgrades will activate, provide defined periods in which users should upgrade their local software, and minimize the risks to both the upgrading network and any users opting out of the changes.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Zcash is a <em>consensual currency</em>: nobody is ever going to force someone to use a specific software implementation or a specific consensus branch of Zcash. <a id="id2" class="footnote_reference" href="#consensual-currency">2</a> As such, different sub-communities will always have the freedom to choose different variants or branches which offer different design trade-offs.</p>
<p>The current Zcash software includes an <em>End-of-Service halt</em> feature, causing nodes running a particular version to automatically shut down approximately 16 weeks after that version was released (specifically, at the block height <code>DEPRECATION_HEIGHT</code> defined in the source code for that version). This was implemented for several reasons: <a id="id3" class="footnote_reference" href="#release-lifecycle">3</a></p>
<ul>
<li>It gives the same systemic advantage of removing old software as auto-upgrade behavior.</li>
<li>It requires users to individually choose one of the following options:
<ul>
<li>Upgrade to a more recent software release from the main network.</li>
<li>Upgrade to an alternative release.</li>
<li>Modify their node in order to keep running the older software.</li>
</ul>
</li>
</ul>
<p>Developers can rely on this cadence for coordinating network upgrades. Once the last pre-upgrade software version has been deprecated, they can reasonably assume that all node operators on the network either support the upgraded rules, or have explicitly chosen not to follow them.</p>
<p>However, this behaviour is not sufficient for performing network upgrades. A globally-understood on-chain activation mechanism is necessary so that nodes can unambiguously know at what point the changes from an upgrade come into effect (and can enforce consensus rule changes, for example).</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The following constants are defined for every network upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd>
<p>A globally-unique non-zero 32-bit identifier.</p>
<p>Implementations MAY use a value of zero in consensus branch ID fields to indicate the absence of any upgrade (i.e. that the Sprout consensus rules apply).</p>
</dd>
<dt>ACTIVATION_HEIGHT</dt>
<dd>
<p>The non-zero block height at which the network upgrade rules will come into effect, and be enforced as part of the block chain consensus.</p>
<p>For removal of ambiguity, the block at height <code>ACTIVATION_HEIGHT - 1</code> is subject to the pre-upgrade consensus rules, and would be the last common block in the event of a persistent pre-upgrade consensus branch.</p>
<p>It MUST be greater than the value of <code>DEPRECATION_HEIGHT</code> in the last software version that will not contain support for the network upgrade. It SHOULD be chosen to be reached approximately three months after the first software version containing support for the network upgrade is released, for the following reason:</p>
<ul>
<li>As of the time of writing (the 1.0.15 release), the release cycle is six weeks long, and nodes undergo End-of-Service halt 16 weeks after release. Thus, if version <code>X</code> contains support for a network upgrade, version <code>X-1</code> will be deprecated 10 weeks after the release of version <code>X</code>, which is about 2.3 months. A three-month window provides ample time for users to upgrade their nodes after End-of-Service halt, and re-integrate into the network prior to activation of the network upgrade.</li>
</ul>
</dd>
</dl>
<p>The relationship between <code>CONSENSUS_BRANCH_ID</code> and <code>ACTIVATION_HEIGHT</code> is many-to-one: it is possible for many distinct consensus branches to descend from the same parent block (and thus have the same <code>ACTIVATION_HEIGHT</code>), but a specific consensus branch can only have one parent block. Concretely, this means that if the <code>ACTIVATION_HEIGHT</code> of a network upgrade is changed for any reason (e.g. security vulnerabilities or consensus bugs are discovered), the <code>CONSENSUS_BRANCH_ID</code> MUST also be changed.</p>
<section id="activation-mechanism"><h3><span class="section-heading">Activation mechanism</span><span class="section-anchor"> <a rel="bookmark" href="#activation-mechanism"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The Zcash block chain is broken into "epochs" of block height intervals <code>[ACTIVATION_HEIGHT_N, ACTIVATION_HEIGHT_{N+1})</code> (i.e. including <code>ACTIVATION_HEIGHT_N</code> and excluding <code>ACTIVATION_HEIGHT_{N+1}</code>), on which consensus rule sets are defined.</p>
<p>When a consensus rule depends on activation of a particular upgrade, its implementation (and that of any network behavior or surrounding code that depends on it) MUST be gated by a block height check. For example:</p>
<pre data-language="cpp"><span class="k">if</span> <span class="p">(</span><span class="n">CurrentEpoch</span><span class="p">(</span><span class="n">chainActive</span><span class="p">.</span><span class="n">Height</span><span class="p">(),</span> <span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">())</span> <span class="o">==</span> <span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">)</span> <span class="p">{</span>
<span class="c1">// Overwinter-specific logic</span>
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
<span class="c1">// Non-Overwinter logic</span>
<span class="p">}</span>
<span class="c1">// ...</span>
<span class="k">if</span> <span class="p">(</span><span class="n">NetworkUpgradeActive</span><span class="p">(</span><span class="n">pindex</span><span class="o">-&gt;</span><span class="n">nHeight</span><span class="p">,</span> <span class="n">Params</span><span class="p">().</span><span class="n">GetConsensus</span><span class="p">(),</span> <span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_OVERWINTER</span><span class="p">))</span> <span class="p">{</span>
<span class="c1">// Overwinter consensus rules applied to block</span>
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
<span class="c1">// Pre-Overwinter consensus rules applied to block</span>
<span class="p">}</span></pre>
<section id="block-validation"><h4><span class="section-heading">Block validation</span><span class="section-anchor"> <a rel="bookmark" href="#block-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be validated under the consensus rules corresponding to the expected consensus branch ID for that height.</p>
<p>Incoming blocks with unknown heights (because at least one block header in their parent chain is unknown) MAY be cached, so that they can be reconsidered in the future after all their parents have been received.</p>
</section>
<section id="chain-reorganization"><h4><span class="section-heading">Chain reorganization</span><span class="section-anchor"> <a rel="bookmark" href="#chain-reorganization"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>It is possible for a reorganization to occur that rolls back from after the activation height, to before that height. This can be handled in the same way as any regular chain orphaning or reorganization, as long as the new chain is valid.</p>
</section>
<section id="post-activation-upgrading"><h4><span class="section-heading">Post-activation upgrading</span><span class="section-anchor"> <a rel="bookmark" href="#post-activation-upgrading"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>If a user does not upgrade their node to a compatible software version before <code>ACTIVATION_HEIGHT</code> is reached, and the node continues running (which could normally only occur if the End-of-Service halt were bypassed), then the node will follow any pre-upgrade consensus branch that persists. In this case it may download blocks that are incompatible with the post-upgrade consensus branch. If the user subsequently upgrades their node to a compatible software version, the node will consider these blocks to be invalid, and if there are a significant number of invalid blocks it SHOULD shut down and alert the user of the issue.</p>
</section>
</section>
<section id="memory-pool"><h3><span class="section-heading">Memory pool</span><span class="section-anchor"> <a rel="bookmark" href="#memory-pool"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>While the current chain tip height is below <code>ACTIVATION_HEIGHT</code>, nodes SHOULD NOT accept transactions that will only be valid on the post-upgrade consensus branch.</p>
<p>When the current chain tip height reaches <code>ACTIVATION_HEIGHT</code>, the node's local transaction memory pool SHOULD be cleared of transactions that will never be valid on the post-upgrade consensus branch.</p>
</section>
<section id="two-way-replay-protection"><h3><span class="section-heading">Two-way replay protection</span><span class="section-anchor"> <a rel="bookmark" href="#two-way-replay-protection"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the most significant bit of the transaction version is set to 1. <a id="id4" class="footnote_reference" href="#zip-0202">6</a> From the perspective of old nodes, the transactions will have a negative version number, which is invalid under the old consensus rules. Enforcing this rule trivially makes old transactions invalid on the Overwinter consensus branch.</p>
<p>After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures committing to a specific <code>CONSENSUS_BRANCH_ID</code>. <a id="id5" class="footnote_reference" href="#zip-0143">4</a></p>
</section>
<section id="wipe-out-protection"><h3><span class="section-heading">Wipe-out protection</span><span class="section-anchor"> <a rel="bookmark" href="#wipe-out-protection"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from <code>ACTIVATION_HEIGHT</code>. The chain from that height will not reorganize to a pre-upgrade consensus branch if any block in that consensus branch would violate the new consensus rules.</p>
<p>Care must be taken, however, to account for possible edge cases where the old and new consensus rules do not differ. For example, if the non-upgraded chain only contained empty blocks from <code>ACTIVATION_HEIGHT</code>, and the coinbase transactions were valid under both the old and new consensus rules, a wipe-out could occur. The Overwinter network upgrade is not susceptible to this because all previous transaction versions will become invalid, meaning that the coinbase transactions must use the newer transaction version. More generally, this issue could be addressed in a future network upgrade by modifying the block header to include a commitment to the <code>CONSENSUS_BRANCH_ID</code>.</p>
</section>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Overwinter network upgrade. <a id="id6" class="footnote_reference" href="#zip-0201">5</a></p>
</section>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p><a href="https://github.com/zcash/zcash/pull/2898">https://github.com/zcash/zcash/pull/2898</a></p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="consensual-currency" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://electriccoin.co/blog/consensual-currency/">Consensual Currency. Electric Coin Company blog</a></td>
</tr>
</tbody>
</table>
<table id="release-lifecycle" class="footnote">
<tbody>
<tr>
<th>3</th>
<td>
<ul>
<li><a href="https://electriccoin.co/blog/release-cycle-and-lifetimes/">Release Cycle and Lifetimes. Electric Coin Company blog</a></li>
<li><a href="https://electriccoin.co/blog/release-cycle-update/">Release Cycle Update. Electric Coin Company blog</a></li>
</ul>
</td>
</tr>
</tbody>
</table>
<table id="zip-0143" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0143">ZIP 143: Transaction Signature Validation for Overwinter</a></td>
</tr>
</tbody>
</table>
<table id="zip-0201" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
</tr>
</tbody>
</table>
<table id="zip-0202" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="zip-0202">ZIP 202: Version 3 Transaction Format for Overwinter</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

View File

@ -2,7 +2,8 @@
ZIP: 200
Title: Network Upgrade Mechanism
Author: Jack Grigg <jack@z.cash>
Owners: Jack Grigg <str4d@electriccoin.co>
Status: Final
Category: Consensus
Created: 2018-01-08
License: MIT
@ -27,10 +28,11 @@ Consensus rule change
A change in the consensus rule set of the network, such that nodes that do not recognize the new rules will
follow a different block chain.
Branch
Consensus branch
A block chain with a common consensus rule set, where the first block in the chain is either the genesis
block, or the child of a parent block created under an older set of consensus rules (i.e. the parent block
is a member of a different branch). By definition, every block belongs to at most one branch.
is a member of a different consensus branch). By definition, every block belongs to at most one consensus
branch.
Network upgrade
An intentional consensus rule change undertaken by the community in order to improve the network.
@ -48,10 +50,11 @@ Motivation
==========
Zcash is a *consensual currency*: nobody is ever going to force someone to use a specific software
implementation or a specific branch of Zcash. [#consensual-currency]_ As such, different sub-communities will
always have the freedom to choose different variants or branches which offer different design trade-offs.
implementation or a specific consensus branch of Zcash. [#consensual-currency]_ As such, different
sub-communities will always have the freedom to choose different variants or branches which offer different
design trade-offs.
The current Zcash software includes an *auto-senescence* feature, causing nodes running a particular version
The current Zcash software includes an *End-of-Service halt* feature, causing nodes running a particular version
to automatically shut down approximately 16 weeks after that version was released (specifically, at the block
height ``DEPRECATION_HEIGHT`` defined in the source code for that version). This was implemented for several
reasons: [#release-lifecycle]_
@ -80,34 +83,35 @@ Specification
The following constants are defined for every network upgrade:
BRANCH_ID
CONSENSUS_BRANCH_ID
A globally-unique non-zero 32-bit identifier.
Implementations MAY use a value of zero in branch ID fields to indicate the absence of any upgrade (i.e.
that the Sprout consensus rules apply).
Implementations MAY use a value of zero in consensus branch ID fields to indicate the absence of any
upgrade (i.e. that the Sprout consensus rules apply).
ACTIVATION_HEIGHT
The non-zero block height at which the network upgrade rules will come into effect, and be enforced as part
of the block chain consensus.
For removal of ambiguity, the block at height ``ACTIVATION_HEIGHT - 1`` is subject to the pre-upgrade
consensus rules, and would be the last common block in the event of a persistent pre-upgrade branch.
consensus rules, and would be the last common block in the event of a persistent pre-upgrade consensus
branch.
It MUST be greater than the value of ``DEPRECATION_HEIGHT`` in the last software version that will not
contain support for the network upgrade. It SHOULD be chosen to be reached approximately three months after
the first software version containing support for the network upgrade is released, for the following reason:
- As of the time of writing (the 1.0.15 release), the release cycle is six weeks long, and nodes undergo
auto-senescence 16 weeks after release. Thus, if version ``X`` contains support for a network upgrade,
End-of-Service halt 16 weeks after release. Thus, if version ``X`` contains support for a network upgrade,
version ``X-1`` will be deprecated 10 weeks after the release of version ``X``, which is about 2.3 months.
A three-month window provides ample time for users to upgrade their nodes after auto-senescence, and
A three-month window provides ample time for users to upgrade their nodes after End-of-Service halt, and
re-integrate into the network prior to activation of the network upgrade.
The relationship between ``BRANCH_ID`` and ``ACTIVATION_HEIGHT`` is many-to-one: it is possible for many
distinct branches to descend from the same parent block (and thus have the same ``ACTIVATION_HEIGHT``), but a
specific branch can only have one parent block. Concretely, this means that if the ``ACTIVATION_HEIGHT`` of a
network upgrade is changed for any reason (e.g. security vulnerabilities or consensus bugs are discovered),
the ``BRANCH_ID`` MUST also be changed.
The relationship between ``CONSENSUS_BRANCH_ID`` and ``ACTIVATION_HEIGHT`` is many-to-one: it is possible
for many distinct consensus branches to descend from the same parent block (and thus have the same
``ACTIVATION_HEIGHT``), but a specific consensus branch can only have one parent block. Concretely, this
means that if the ``ACTIVATION_HEIGHT`` of a network upgrade is changed for any reason (e.g. security
vulnerabilities or consensus bugs are discovered), the ``CONSENSUS_BRANCH_ID`` MUST also be changed.
Activation mechanism
--------------------
@ -139,7 +143,7 @@ network behavior or surrounding code that depends on it) MUST be gated by a bloc
Block validation
````````````````
Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be
validated under the consensus rules corresponding to the expected branch ID for that height.
validated under the consensus rules corresponding to the expected consensus branch ID for that height.
Incoming blocks with unknown heights (because at least one block header in their parent chain is unknown)
MAY be cached, so that they can be reconsidered in the future after all their parents have been received.
@ -147,25 +151,26 @@ MAY be cached, so that they can be reconsidered in the future after all their pa
Chain reorganization
````````````````````
It is possible for a reorganization to occur that rolls back from after the activation height, to before that
height. This can handled in the same way as any regular chain orphaning or reorganization, as long as the new
chain is valid.
height. This can be handled in the same way as any regular chain orphaning or reorganization, as long as the
new chain is valid.
Post-activation upgrading
`````````````````````````
If a user does not upgrade their node to a compatible software version before ``ACTIVATION_HEIGHT`` is
reached, their node will follow any pre-upgrade branch that persists, and may download blocks that are
incompatible with the post-upgrade branch. If the user subsequently upgrades their node to a compatible
software version, the node will consider these blocks to be invalid, and if there are a significant number of
invalid blocks it SHOULD shut down and alert the user of the issue.
reached, and the node continues running (which could normally only occur if the End-of-Service halt were
bypassed), then the node will follow any pre-upgrade consensus branch that persists. In this case it may
download blocks that are incompatible with the post-upgrade consensus branch. If the user subsequently
upgrades their node to a compatible software version, the node will consider these blocks to be invalid,
and if there are a significant number of invalid blocks it SHOULD shut down and alert the user of the issue.
Memory pool
-----------
While the current chain tip height is below ``ACTIVATION_HEIGHT``, nodes SHOULD NOT accept transactions that
will only be valid on the post-upgrade branch.
will only be valid on the post-upgrade consensus branch.
When the current chain tip height reaches ``ACTIVATION_HEIGHT``, the node's local transaction memory pool
SHOULD be cleared of transactions that will never be valid on the post-upgrade branch.
SHOULD be cleared of transactions that will never be valid on the post-upgrade consensus branch.
Two-way replay protection
-------------------------
@ -173,17 +178,17 @@ Two-way replay protection
Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the
most significant bit of the transaction version is set to 1. [#zip-0202]_ From the perspective of old nodes,
the transactions will have a negative version number, which is invalid under the old consensus rules.
Enforcing this rule trivially makes old transactions invalid on the Overwinter branch.
Enforcing this rule trivially makes old transactions invalid on the Overwinter consensus branch.
After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures
committing to a specific ``BRANCH_ID``. [#zip-0143]_
committing to a specific ``CONSENSUS_BRANCH_ID``. [#zip-0143]_
Wipe-out protection
-------------------
Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from
``ACTIVATION_HEIGHT``. The chain from that height will not reorganize to a pre-upgrade branch if any block in
that branch would violate the new consensus rules.
``ACTIVATION_HEIGHT``. The chain from that height will not reorganize to a pre-upgrade consensus branch if
any block in that consensus branch would violate the new consensus rules.
Care must be taken, however, to account for possible edge cases where the old and new consensus rules do not
differ. For example, if the non-upgraded chain only contained empty blocks from ``ACTIVATION_HEIGHT``, and the
@ -191,7 +196,7 @@ coinbase transactions were valid under both the old and new consensus rules, a w
Overwinter network upgrade is not susceptible to this because all previous transaction versions will become
invalid, meaning that the coinbase transactions must use the newer transaction version. More generally, this
issue could be addressed in a future network upgrade by modifying the block header to include a commitment to
the ``BRANCH_ID``.
the ``CONSENSUS_BRANCH_ID``.
Deployment
@ -206,7 +211,7 @@ Backward compatibility
This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this
mechanism requires that all network participants upgrade their software to a compatible version within the
upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade
branch that persists.
consensus branch that persists.
Reference Implementation
@ -218,11 +223,11 @@ https://github.com/zcash/zcash/pull/2898
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#consensual-currency] https://z.cash/blog/consensual-currency.html
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#consensual-currency] `Consensual Currency. Electric Coin Company blog <https://electriccoin.co/blog/consensual-currency/>`_
.. [#release-lifecycle]
- https://z.cash/blog/release-cycle-and-lifetimes.html
- https://z.cash/blog/release-cycle-update.html
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
- `Release Cycle and Lifetimes. Electric Coin Company blog <https://electriccoin.co/blog/release-cycle-and-lifetimes/>`_
- `Release Cycle Update. Electric Coin Company blog <https://electriccoin.co/blog/release-cycle-update/>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <zip-0202.rst>`_

271
zip-0201.html Normal file
View File

@ -0,0 +1,271 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 201: Network Peer Management for Overwinter</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 201
Title: Network Peer Management for Overwinter
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: Simon Liu
Status: Final
Category: Network
Created: 2018-01-15
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Overwinter</dt>
<dd>Code-name for the first Zcash network upgrade, also known as Network Upgrade Zero.</dd>
</dl>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Mechanism <a id="id3" class="footnote_reference" href="#zip-0200">3</a>.</p>
<p>Related to:</p>
<ul>
<li>Transaction Signature Validation for Overwinter <a id="id4" class="footnote_reference" href="#zip-0143">2</a>.</li>
<li>Version 3 Transaction Format for Overwinter <a id="id5" class="footnote_reference" href="#zip-0202">4</a>.</li>
<li>Transaction Expiry <a id="id6" class="footnote_reference" href="#zip-0203">5</a>.</li>
</ul>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>With scheduled network upgrades, at the activation height, nodes on each consensus branch should disconnect from nodes on other consensus branches and only accept new incoming connections from nodes on the same consensus branch.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>When a new inbound connection is received or an outbound connection created, a CNode object is instantiated with the version field set to INIT_PROTO_VERSION which has a value of 209. This value is not transmitted across the network, but for legacy reasons and technical debt beyond the scope of this ZIP, this value will not be changed.</p>
<p>Once the two nodes have connected and started the handshake to negotiate the protocol version, the version field of CNode will be updated. The handshake <a id="id7" class="footnote_reference" href="#bitcoin-version-handshake">8</a> involves "version" and "verack" messages being exchanged.:</p>
<pre>L -&gt; R: Send version message with the local peer's version
R -&gt; L: Send version message back
R -&gt; L: Send verack message
R: Sets version to the minimum of the 2 versions
L -&gt; R: Send verack message after receiving version message from R
L: Sets version to the minimum of the 2 versions</pre>
<p>To send a version message, the node will invoke <code>PushVersion()</code>:</p>
<pre>void CNode::PushVersion() {
...
PushMessage("version", PROTOCOL_VERSION, nLocalServices, nTime, addrYou, addrMe, ...);
...
}</pre>
<p>where <code>PROTOCOL_VERSION</code> is the highest protocol version supported by the node.</p>
<section id="rejecting-pre-overwinter-connections"><h3><span class="section-heading">Rejecting Pre-Overwinter Connections</span><span class="section-anchor"> <a rel="bookmark" href="#rejecting-pre-overwinter-connections"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Currently, nodes will reject connections from peers with an advertised protocol version lower than the other node's minimum supported protocol version.</p>
<p>This value is defined as:</p>
<pre>//! disconnect from peers older than this proto version
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
<p>With rejection implemented as:</p>
<pre>if (pfrom-&gt;nVersion &lt; MIN_PEER_PROTO_VERSION)
{
// disconnect from old peers running protocol version we don't support.</pre>
<p>Activation of Overwinter will take place first on testnet, and if successful, followed by mainnet.</p>
<p>To prepare for testnet activation, Overwinter nodes will contain the following constants:</p>
<pre>static const int PROTOCOL_VERSION = 170003;
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
<p>Nodes running protocol version 170003 have a testnet activation height set, but do not have a mainnet activation height set.</p>
<p>On testnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is &lt;= 170002.</p>
<p>These constants allow pre-Overwinter nodes that support protocol version 170002, and Overwinter nodes (which support both protocol versions 170002 and 170003 before Overwinter activation) to remain connected until the activation.</p>
<p>To prepare for mainnet activation, Overwinter nodes will contain the following constants:</p>
<pre>static const int PROTOCOL_VERSION = 170005;
static const int MIN_PEER_PROTO_VERSION = 170002;</pre>
<p>On mainnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is &lt;= 170004. (Nodes running protocol version 170003 or 170004 do not have a mainnet activation height set. The intermediate protocol version 170004 is used to indicate support for the <code>NODE_BLOOM</code> service bit defined in <a id="id8" class="footnote_reference" href="#bip-0111">6</a>.)</p>
<p>These constants allow pre-Overwinter nodes that support protocol versions 170002 to 170004 inclusive, and Overwinter nodes (which support protocol versions 170002 to 170005 inclusive before Overwinter activation) to remain connected until the activation.</p>
<p>As these constants cannot be changed at run-time, once Overwinter activates on testnet or mainnet, Overwinter nodes should take steps to:</p>
<ul>
<li>reject new connections from pre-Overwinter nodes;</li>
<li>disconnect any existing connections to pre-Overwinter nodes.</li>
</ul>
</section>
<section id="network-coalescence"><h3><span class="section-heading">Network Coalescence</span><span class="section-anchor"> <a rel="bookmark" href="#network-coalescence"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Prior to the activation of Overwinter, nodes running a pre-Overwinter protocol version (e.g. 170002) and the Overwinter protocol version (170003 for testnet; 170005 for mainnet) remain connected with the same consensus rules, but it is desirable for nodes supporting Overwinter to connect preferentially to other nodes supporting Overwinter.</p>
<p>This is intended to help the network partition smoothly, since nodes should already be connected to (a majority of) peers running the same protocol version. Otherwise an Overwinter node may find their connections to Sprout nodes dropped suddenly at the activation height, potentially leaving them isolated and susceptible to eclipse attacks. <a id="id9" class="footnote_reference" href="#eclipse-attack">9</a></p>
<p>To assist network coalescence before the activation height, we update the eviction process to place a higher priority on evicting Sprout nodes.</p>
<p>Currently, an eviction process takes place when new inbound connections arrive, but the node has already connected to the maximum number of inbound peers:</p>
<pre>if (nInbound &gt;= nMaxInbound)
{
if (!AttemptToEvictConnection(whitelisted)) {
// No connection to evict, disconnect the new connection
LogPrint("net", "failed to find an eviction candidate - connection dropped (full)\n");
CloseSocket(hSocket);
return;
}
}</pre>
<p>We update this process by adding behaviour so that the set of eviction candidates will prefer pre-Overwinter nodes, when the chain tip is in a period N blocks before the activation block height, where N is defined as:</p>
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
<p>The eviction candidates can be modified as so:</p>
<pre>static bool AttemptToEvictConnection(bool fPreferNewConnection) {
...
// Protect connections with certain characteristics
...
// Check version of eviction candidates...
// If we are connected to any pre-Overwinter nodes, keep them in the eviction set and remove any Overwinter nodes
// If we are only connected to Overwinter nodes, continue with existing behaviour.
if (nActivationHeight &gt; 0 &amp;&amp;
height &lt; nActivationHeight &amp;&amp;
height &gt;= nActivationHeight - NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD)
{
// Find any nodes which don't support Overwinter protocol version
BOOST_FOREACH(const CNodeRef &amp;node, vEvictionCandidates) {
if (node-&gt;nVersion &lt; params.vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion) {
vTmpEvictionCandidates.push_back(node);
}
}
// Prioritize these nodes by replacing eviction set with them
if (vTmpEvictionCandidates.size() &gt; 0) {
vEvictionCandidates = vTmpEvictionCandidates;
}
}</pre>
<p>The existing method of disconnecting a candidate remains:</p>
<blockquote>
<p>vEvictionCandidates[0]-&gt;fDisconnect = true;</p>
</blockquote>
<p>The existing eviction process will classify and divide eviction candidates into buckets called netgroups. If a netgroup only has one peer, it will not be evicted. This means at least one pre-Overwinter node will remain connected upto the activation block height, barring any network issues or a high ban score.</p>
</section>
<section id="disconnecting-existing-connections"><h3><span class="section-heading">Disconnecting Existing Connections</span><span class="section-anchor"> <a rel="bookmark" href="#disconnecting-existing-connections"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>At the activation block height, an Overwinter node may still remain connected to pre-Overwinter nodes. Currently, when connecting, a node can only perform the networking handshake once, where it sends the version message before any other messages are processed. To disconnect existing pre-Overwinter connections, <code>ProcessMessage</code> is modified so that once Overwinter activates, if necessary, the protocol version of an existing peer is validated when inbound messages arrive.</p>
<p>Example code:</p>
<pre>bool static ProcessMessage(CNode* pfrom, string strCommand, CDataStream&amp; vRecv, int64_t nTimeReceived)
...
else if (pfrom-&gt;nVersion == 0)
{
// Must have a version message before anything else
Misbehaving(pfrom-&gt;GetId(), 1);
return false;
}
else if (strCommand == "verack")
{
...
}
// Disconnect existing peer connection when:
// 1. The version message has been received
// 2. Overwinter is active
// 3. Peer version is pre-Overwinter
else if (NetworkUpgradeActive(GetHeight(), chainparams.GetConsensus(), Consensus::UPGRADE_OVERWINTER)
&amp;&amp; (pfrom-&gt;nVersion &lt; chainparams.GetConsensus().vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion))
{
LogPrintf("peer=%d using obsolete version %i; disconnecting\n", pfrom-&gt;id, pfrom-&gt;nVersion);
pfrom-&gt;PushMessage("reject", strCommand, REJECT_OBSOLETE,
strprintf("Version must be %d or greater",
chainparams.GetConsensus().vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion));
pfrom-&gt;fDisconnect = true;
return false;
}</pre>
</section>
</section>
<section id="deployment-of-overwinter"><h2><span class="section-heading">Deployment of Overwinter</span><span class="section-anchor"> <a rel="bookmark" href="#deployment-of-overwinter"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Overwinter network upgrade defines the following network upgrade constants <a id="id10" class="footnote_reference" href="#zip-0200">3</a>:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0x5ba81b19</code></dd>
<dt>ACTIVATION_HEIGHT</dt>
<dd>
<p>Testnet: 207500</p>
<p>Mainnet: 347500</p>
</dd>
</dl>
<p>The following ZIPs are deployed by Overwinter:</p>
<ul>
<li>ZIP 200 <a id="id11" class="footnote_reference" href="#zip-0200">3</a></li>
<li>ZIP 201 (this ZIP)</li>
<li>ZIP 202 <a id="id12" class="footnote_reference" href="#zip-0202">4</a></li>
<li>ZIP 203 <a id="id13" class="footnote_reference" href="#zip-0203">5</a></li>
<li>ZIP 143 <a id="id14" class="footnote_reference" href="#zip-0143">2</a></li>
</ul>
</section>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Prior to the network upgrade activating, Overwinter and pre-Overwinter nodes are compatible and can connect to each other. However, Overwinter nodes will have a preference for connecting to other Overwinter nodes, so pre-Overwinter nodes will gradually be disconnected in the run up to activation.</p>
<p>Once the network upgrades, even though pre-Overwinter nodes can still accept the numerically larger protocol version used by Overwinter as being valid, Overwinter nodes will always disconnect peers using lower protocol versions.</p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p><a href="https://github.com/zcash/zcash/pull/2919">https://github.com/zcash/zcash/pull/2919</a></p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zip-0143" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="zip-0143">ZIP 143: Transaction Signature Validation for Overwinter</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0202" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0202">ZIP 202: Version 3 Transaction Format for Overwinter</a></td>
</tr>
</tbody>
</table>
<table id="zip-0203" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0203">ZIP 203: Transaction Expiry</a></td>
</tr>
</tbody>
</table>
<table id="bip-0111" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki">BIP 111: NODE_BLOOM service bit</a></td>
</tr>
</tbody>
</table>
<table id="bitcoin-verson" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="https://en.bitcoin.it/wiki/Protocol_documentation#version">https://en.bitcoin.it/wiki/Protocol_documentation#version</a></td>
</tr>
</tbody>
</table>
<table id="bitcoin-version-handshake" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="https://en.bitcoin.it/wiki/Version_Handshake">https://en.bitcoin.it/wiki/Version_Handshake</a></td>
</tr>
</tbody>
</table>
<table id="eclipse-attack" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="https://eprint.iacr.org/2015/263">Eclipse Attacks on Bitcoins Peer-to-Peer Network</a></td>
</tr>
</tbody>
</table>
<table id="partition-discussion" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="https://github.com/zcash/zcash/issues/2775">Partition nodes with old protocol version from network in advance of hard fork</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

View File

@ -2,17 +2,22 @@
ZIP: 201
Title: Network Peer Management for Overwinter
Author: Simon Liu <simon@z.cash>
Owners: Daira Hopwood <daira@electriccoin.co>
Original-Authors: Simon Liu
Status: Final
Category: Network
Created: 2018-01-15
License: MIT
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described
in RFC 2119. [#RFC2119]_
The terms "branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. [#zip-0200]_
The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in
ZIP 200. [#zip-0200]_
The terms below are to be interpreted as follows:
@ -23,18 +28,21 @@ Overwinter
Abstract
========
This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Activation Mechanism [#zip-0200]_.
This proposal defines an upgrade to the network handshake and peer management required for network upgrades
following the Network Upgrade Mechanism [#zip-0200]_.
Related to:
- Transaction Signature Verification for Overwinter [#zip-0143]_.
- Transaction Signature Validation for Overwinter [#zip-0143]_.
- Version 3 Transaction Format for Overwinter [#zip-0202]_.
- Transaction Expiry [#zip-0203]_.
Motivation
==========
With scheduled network upgrades, at the activation height, nodes on each branch should disconnect from nodes on other branches and only accept new incoming connections from nodes on the same branch.
With scheduled network upgrades, at the activation height, nodes on each consensus branch should disconnect
from nodes on other consensus branches and only accept new incoming connections from nodes on the same
consensus branch.
Specification
=============
@ -206,7 +214,7 @@ Deployment of Overwinter
The Overwinter network upgrade defines the following network upgrade constants [#zip-0200]_:
BRANCH_ID
CONSENSUS_BRANCH_ID
``0x5ba81b19``
ACTIVATION_HEIGHT
@ -240,11 +248,11 @@ https://github.com/zcash/zcash/pull/2919
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/blob/master/zip-0203.rst>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <zip-0202.rst>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
.. [#bip-0111] `BIP 111: NODE_BLOOM service bit <https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki>`_
.. [#bitcoin-verson] https://en.bitcoin.it/wiki/Protocol_documentation#version
.. [#bitcoin-version-handshake] https://en.bitcoin.it/wiki/Version_Handshake

377
zip-0202.html Normal file
View File

@ -0,0 +1,377 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 202: Version 3 Transaction Format for Overwinter</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 202
Title: Version 3 Transaction Format for Overwinter
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: Simon Liu
Status: Final
Category: Consensus
Created: 2018-01-10
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms "consensus branch", "network upgrade", and "consensus rule change" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
<p>The term "Overwinter" in this document is to be interpreted as described in ZIP 201. <a id="id3" class="footnote_reference" href="#zip-0201">4</a></p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a new transaction format required for Network Upgrade Mechanism <a id="id4" class="footnote_reference" href="#zip-0200">3</a> and Transaction Expiry <a id="id5" class="footnote_reference" href="#zip-0203">5</a>.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Zcash launched with support for upstream Bitcoin version 1 transactions and defined a new version 2 transaction format which added fields required for shielded transactions.</p>
<table>
<thead>
<tr>
<th>Version</th>
<th>Field</th>
<th>Description</th>
<th>Type</th>
</tr>
</thead>
<tbody>
<tr>
<td>&gt;= 1</td>
<td><code>version</code></td>
<td>positive value</td>
<td><code>int32</code></td>
</tr>
<tr>
<td>&gt;= 1</td>
<td><code>tx_in_count</code></td>
<td>variable-length integer</td>
<td><code>compactSize</code></td>
</tr>
<tr>
<td>&gt;= 1</td>
<td><code>tx_in</code></td>
<td>list of inputs</td>
<td><code>vector</code></td>
</tr>
<tr>
<td>&gt;= 1</td>
<td><code>tx_out_count</code></td>
<td>variable-length integer</td>
<td><code>compactSize</code></td>
</tr>
<tr>
<td>&gt;= 1</td>
<td><code>tx_out</code></td>
<td>list of outputs</td>
<td><code>vector</code></td>
</tr>
<tr>
<td>&gt;= 1</td>
<td><code>lock_time</code></td>
<td>block height or timestamp</td>
<td><code>uint32</code></td>
</tr>
<tr>
<td>&gt;= 2</td>
<td><code>nJoinSplit</code></td>
<td>variable-length integer</td>
<td><code>compactSize</code></td>
</tr>
<tr>
<td>&gt;= 2</td>
<td><code>vJoinSplit</code></td>
<td>list of joinsplits</td>
<td><code>vector</code></td>
</tr>
<tr>
<td>&gt;= 2</td>
<td><code>joinSplitPubKey</code></td>
<td>joinsplit_sig public key</td>
<td>32 bytes</td>
</tr>
<tr>
<td>&gt;= 2</td>
<td><code>joinSplitSig</code></td>
<td>signature</td>
<td>64 bytes</td>
</tr>
</tbody>
</table>
<p>A new transaction format is required to:</p>
<ul>
<li>support safe network upgrades as specified in Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">3</a>;</li>
<li>provide replay protection between pre-Overwinter and Overwinter consensus branches during upgrades;</li>
<li>provide replay protection between different consensus branches post-Overwinter;</li>
<li>enable a consensus branch to support multiple transaction version formats;</li>
<li>ensure transaction formats are parsed uniquely across parallel consensus branches;</li>
<li>support transaction expiry <a id="id7" class="footnote_reference" href="#zip-0203">5</a>.</li>
</ul>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="transaction-format-version-3"><h3><span class="section-heading">Transaction format version 3</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-format-version-3"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A new version 3 transaction format will be introduced for Overwinter.</p>
<p>The version 3 format differs from the version 2 format in the following ways:</p>
<ul>
<li>header (first four bytes, little-endian encoded)
<ul>
<li><code>fOverwintered</code> flag : bit 31, must be set</li>
<li><code>nVersion</code> : bits 30-0, positive integer</li>
</ul>
</li>
<li><code>nVersionGroupId</code></li>
<li><code>nExpiryHeight</code></li>
</ul>
<table>
<thead>
<tr>
<th>Version</th>
<th>Field</th>
<th>Description</th>
<th>Type</th>
</tr>
</thead>
<tbody>
<tr>
<td>&gt;= 3</td>
<td>header</td>
<td>
<p>contains:</p>
<ul>
<li><code>fOverwintered</code> flag (bit 31, always set)</li>
<li><code>nVersion</code> (bits 30-0)</li>
</ul>
</td>
<td><code>uint32</code></td>
</tr>
<tr>
<td>&gt;= 3</td>
<td><code>nVersionGroupId</code></td>
<td>version group ID (not zero)</td>
<td><code>uint32</code></td>
</tr>
<tr>
<td>&gt;= 1</td>
<td><code>tx_in_count</code></td>
<td>variable-length integer</td>
<td><code>compactSize</code></td>
</tr>
<tr>
<td>&gt;= 1</td>
<td><code>tx_in</code></td>
<td>list of inputs</td>
<td><code>vector</code></td>
</tr>
<tr>
<td>&gt;= 1</td>
<td><code>tx_out_count</code></td>
<td>variable-length integer</td>
<td><code>compactSize</code></td>
</tr>
<tr>
<td>&gt;= 1</td>
<td><code>tx_out</code></td>
<td>list of outputs</td>
<td><code>vector</code></td>
</tr>
<tr>
<td>&gt;= 1</td>
<td><code>lock_time</code></td>
<td>block height or timestamp</td>
<td><code>uint32</code></td>
</tr>
<tr>
<td>&gt;= 3</td>
<td><code>expiryHeight</code></td>
<td>block height</td>
<td><code>uint32</code></td>
</tr>
<tr>
<td>&gt;= 2</td>
<td><code>nJoinSplit</code></td>
<td>variable-length integer</td>
<td><code>compactSize</code></td>
</tr>
<tr>
<td>&gt;= 2</td>
<td><code>vJoinSplit</code></td>
<td>list of joinsplits</td>
<td><code>vector</code></td>
</tr>
<tr>
<td>&gt;= 2</td>
<td><code>joinSplitPubKey</code></td>
<td>joinsplit_sig public key</td>
<td>32 bytes</td>
</tr>
<tr>
<td>&gt;= 2</td>
<td><code>joinSplitSig</code></td>
<td>signature</td>
<td>64 bytes</td>
</tr>
</tbody>
</table>
</section>
<section id="header-field"><h3><span class="section-heading">Header Field</span><span class="section-anchor"> <a rel="bookmark" href="#header-field"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The first four bytes of pre-Overwinter and Overwinter transactions are little-endian encoded.</p>
<p>Version 1 transaction (txid <a href="https://blockchair.com/zcash/transaction/5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061">5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061</a>)</p>
<ul>
<li>begins with little-endian byte sequence [0x01, 0x00, 0x00, 0x00];</li>
<li>deserialized as 32-bit signed integer with decimal value of 1.</li>
</ul>
<p>Version 2 transaction (txid <a href="https://blockchair.com/zcash/transaction/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b">4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b</a>)</p>
<ul>
<li>begins with little-endian byte sequence [0x02, 0x00, 0x00, 0x00];</li>
<li>deserialized as 32-bit signed integer with decimal value of 2.</li>
</ul>
<p>Transaction parsers for versions of Zcash prior to Overwinter, and for most other Bitcoin forks, require the transaction version number to be positive.</p>
<p>With the version 3 transaction format, the first four bytes of a serialized transaction, the 32-bit header, are made up of two fields as shown in the table above:</p>
<ul>
<li>1-bit <code>fOverwintered</code> flag, must be set;</li>
<li>31-bit unsigned int for the version.</li>
</ul>
<p>Pre-Overwinter parsers will deserialize these four bytes as a 32-bit signed integer. With two's complement integers, the most significant bit indicates whether an integer is positive or negative. With the Overwinter flag set, the transaction version will be negative, resulting in pre-Overwinter parsers rejecting the transaction as invalid. This provides transaction replay protection between pre-Overwinter and Overwinter software.</p>
<p>Consider the following example of a serialized version 3 transaction.</p>
<p>Pre-Overwinter parser:</p>
<ul>
<li>data begins with little-endian byte sequence: [0x03, 0x00, 0x00, 0x80];</li>
<li>deserialized as 32-bit signed integer.
<ul>
<li>with hexadecimal value of 0x80000003 (most significant bit is set);</li>
<li>decimal value of -2147483645.</li>
</ul>
</li>
</ul>
<p>Legacy parsers will expect the version to be a positive value, such as 1 or 2, and will thus reject the Overwinter transaction as invalid.</p>
<p>Overwinter parser:</p>
<ul>
<li>data begins with little-endian byte sequence: [0x03, 0x00, 0x00, 0x80];</li>
<li>deserialized as 32-bit unsigned integer
<ul>
<li>with binary value of 0b10000000000000000000000000000011;</li>
</ul>
</li>
<li>the 32-bits are decomposed into two fields:
<ul>
<li><code>fOverwintered</code> flag (bit 31) as a boolean, expected to be set;</li>
<li>version (bits 30 - bit 0) as an unsigned integer, expected to have a decimal value of 3.</li>
</ul>
</li>
</ul>
<p>Overwinter parsers will accept the transaction as valid as the most significant bit of the header has been set. By masking off (unsetting) the most significant bit, the parser can retrieve the transaction version number:</p>
<pre>0x80000003 &amp; 0x7FFFFFFF = 0x00000003 = 3</pre>
</section>
<section id="version-group-id"><h3><span class="section-heading">Version Group ID</span><span class="section-anchor"> <a rel="bookmark" href="#version-group-id"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The version group ID is a non-zero, random and unique identifier, of type <code>uint32</code>, assigned to a transaction format version, or a group of soft-forking transaction format versions. The version group ID helps nodes disambiguate between consensus branches using the same version number.</p>
<p>That is, it prevents a client on one branch of the network from attempting to parse transactions intended for another consensus branch, in the situation where the transactions share the same format version number but are actually specified differently. For example, Zcash and a clone of Zcash might both define their own custom v3 transaction formats, but each will have its own unique version group ID, so that they can reject v3 transactions with unknown version group IDs.</p>
<p>The combination of transaction version and version group ID, <code>nVersion || nVersionGroupId</code>, uniquely defines the transaction format, thus enabling parsers to reject transactions from outside the client's chain which cannot be parsed.</p>
<p>By convention, it is expected that when introducing a new transaction version requiring a network upgrade, a new unique version group ID will be assigned to that transaction version.</p>
<p>However, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group ID MAY be re-used.</p>
</section>
<section id="expiry-height"><h3><span class="section-heading">Expiry Height</span><span class="section-anchor"> <a rel="bookmark" href="#expiry-height"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The expiry height field, as defined in the Transaction Expiry ZIP <a id="id8" class="footnote_reference" href="#zip-0203">5</a>, stores the block height after which a transaction can no longer be mined.</p>
</section>
<section id="transaction-validation"><h3><span class="section-heading">Transaction Validation</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A valid Overwinter transaction intended for Zcash MUST have:</p>
<ul>
<li>version number 3; and</li>
<li>version group ID 0x03C48270; and</li>
<li><code>fOverwintered</code> flag set.</li>
</ul>
<p>Overwinter validators MUST reject transactions for violating consensus rules if:</p>
<ul>
<li>the <code>fOverwintered</code> flag is not set; or</li>
<li>the version group ID is unknown; or</li>
<li>the version number is unknown.</li>
</ul>
<p>Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id9" class="footnote_reference" href="#zip-0143">2</a>.</p>
</section>
</section>
<section id="implementation"><h2><span class="section-heading">Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The comments and code samples in this section apply to the reference C++ implementation of Zcash. Other implementations may vary.</p>
<section id="transaction-version"><h3><span class="section-heading">Transaction Version</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-version"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Transaction version remains a positive value. The main Zcash chain will follow convention and continue to order transaction versions in an ascending order.</p>
<p>Tests can continue to check for the existence of forwards-compatible transaction fields by checking the transaction version using comparison operators:</p>
<pre>if (tx.nVersion &gt;= 2) {
for (int js = 0; js &lt; joinsplits; js++) {
...
}
}</pre>
<p>When (de)serializing v3 transactions, the version group ID must also be checked in case the transaction is intended for a consensus branch which has a different format for its version 3 transaction:</p>
<pre>if (tx.nVersion == 3 &amp;&amp; tx.nVersionGroupId == OVERWINTER_VERSION_GROUP_ID) {
auto expiryHeight = tx.nExpiryHeight;
}</pre>
<p>Tests can continue to set the version to zero as an error condition:</p>
<pre>mtx.nVersion = 0</pre>
</section>
<section id="overwinter-validation"><h3><span class="section-heading">Overwinter Validation</span><span class="section-anchor"> <a rel="bookmark" href="#overwinter-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>To test if the format of an Overwinter transaction is v3 or not:</p>
<pre>if (tx.fOverwintered &amp;&amp; tx.nVersion == 3) {
// Valid v3 format transaction
}</pre>
<p>This only tests that the format of the transaction matches the v3 specification described above.</p>
<p>To test if the format of an Overwinter transaction is both v3 and the transaction itself is intended for the client's chain:</p>
<pre>if (tx.fOverwintered &amp;&amp;
tx.nVersionGroupId == OVERWINTER_VERSION_GROUP_ID) &amp;&amp;
tx.nVersion == 3) {
// Valid v3 format transaction intended for this client's chain
}</pre>
<p>It is expected that this test involving <code>nVersionGroupId</code> is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system.</p>
<p>However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.</p>
<p>Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id10" class="footnote_reference" href="#zip-0143">2</a>.</p>
</section>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in <a id="id11" class="footnote_reference" href="#zip-0201">4</a>.</p>
</section>
<section id="backwards-compatibility"><h2><span class="section-heading">Backwards compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backwards-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change" <a id="id12" class="footnote_reference" href="#zip-0200">3</a> between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.</p>
<p>Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group IDs.</p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p><a href="https://github.com/zcash/zcash/pull/2925">https://github.com/zcash/zcash/pull/2925</a></p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zip-0143" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="zip-0143">ZIP 143: Transaction Signature Validation for Overwinter</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0201" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0201">ZIP 201: Network Handshaking for Overwinter</a></td>
</tr>
</tbody>
</table>
<table id="zip-0203" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0203">ZIP 203: Transaction Expiry</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

View File

@ -2,24 +2,31 @@
ZIP: 202
Title: Version 3 Transaction Format for Overwinter
Author: Simon Liu <simon@z.cash>
Owners: Daira Hopwood <daira@electriccoin.co>
Original-Authors: Simon Liu
Status: Final
Category: Consensus
Created: 2018-01-10
License: MIT
Terminology
===========
The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in
RFC 2119. [#RFC2119]_
The terms "branch", "network upgrade", and "consensus rule change" in this document are to be interpreted as described in ZIP 200. [#zip-0200]_
The terms "consensus branch", "network upgrade", and "consensus rule change" in this document are
to be interpreted as described in ZIP 200. [#zip-0200]_
The term "Overwinter" in this document is to be interpreted as described in ZIP 201. [#zip-0201]_
Abstract
========
This proposal defines a new transaction format required for Network Upgrade Activation Mechanism [#zip-0200]_ and Transaction Expiry [#zip-0203]_.
This proposal defines a new transaction format required for Network Upgrade Mechanism [#zip-0200]_ and Transaction Expiry [#zip-0203]_.
Motivation
==========
@ -41,16 +48,16 @@ Version Field Description Type
>= 2 ``joinSplitSig`` signature 64 bytes
======== ====================== =========================== ===============
A new transaction format is required to:
* support safe network upgrades as specified in Network Upgrade Activation Mechanism [#zip-0200]_;
* provide replay protection between pre-Overwinter and Overwinter branches during upgrades;
* provide replay protection between different branches post-Overwinter;
* enable a branch to support multiple transaction version formats;
* ensure transaction formats are parsed uniquely across parallel branches;
* support safe network upgrades as specified in Network Upgrade Mechanism [#zip-0200]_;
* provide replay protection between pre-Overwinter and Overwinter consensus branches during upgrades;
* provide replay protection between different consensus branches post-Overwinter;
* enable a consensus branch to support multiple transaction version formats;
* ensure transaction formats are parsed uniquely across parallel consensus branches;
* support transaction expiry [#zip-0203]_.
Specification
=============
@ -76,7 +83,7 @@ Version Field Description Type
- ``fOverwintered`` flag
(bit 31, always set)
- ``nVersion`` (bits 30-0)
>= 3 ``nVersionGroupId`` version group id (not zero) ``uint32``
>= 3 ``nVersionGroupId`` version group ID (not zero) ``uint32``
>= 1 ``tx_in_count`` variable-length integer ``compactSize``
>= 1 ``tx_in`` list of inputs ``vector``
>= 1 ``tx_out_count`` variable-length integer ``compactSize``
@ -95,12 +102,12 @@ Header Field
The first four bytes of pre-Overwinter and Overwinter transactions are little-endian encoded.
Version 1 transaction (txid 5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061 https://zcash.blockexplorer.com/tx/5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061)
Version 1 transaction (txid `5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061 <https://blockchair.com/zcash/transaction/5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22dd4ca183ae061>`_)
* begins with little-endian byte sequence [0x01, 0x00, 0x00, 0x00];
* deserialized as 32-bit signed integer with decimal value of 1.
Version 2 transaction (txid 4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b https://zcash.blockexplorer.com/tx/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b)
Version 2 transaction (txid `4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b <https://blockchair.com/zcash/transaction/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b>`_)
* begins with little-endian byte sequence [0x02, 0x00, 0x00, 0x00];
* deserialized as 32-bit signed integer with decimal value of 2.
@ -141,18 +148,29 @@ Overwinter parsers will accept the transaction as valid as the most significant
0x80000003 & 0x7FFFFFFF = 0x00000003 = 3
Version Group Id
Version Group ID
----------------
The version group id is a non-zero, random and unique identifier, of type ``uint32``, assigned to a transaction format version, or a group of soft-forking transaction format versions. The version group id helps nodes disambiguate between branches using the same version number.
The version group ID is a non-zero, random and unique identifier, of type ``uint32``, assigned
to a transaction format version, or a group of soft-forking transaction format versions. The
version group ID helps nodes disambiguate between consensus branches using the same version number.
That is, it prevents a client on one branch of the network from attempting to parse transactions intended for another branch, in the situation where the transactions share the same format version number but are actually specified differently. For example, Zcash and a clone of Zcash might both define their own custom v3 transaction formats, but each will have its own unique version group id, so that they can reject v3 transactions with unknown version group ids.
That is, it prevents a client on one branch of the network from attempting to parse transactions
intended for another consensus branch, in the situation where the transactions share the same
format version number but are actually specified differently. For example, Zcash and a clone of
Zcash might both define their own custom v3 transaction formats, but each will have its own
unique version group ID, so that they can reject v3 transactions with unknown version group IDs.
The combination of transaction version and version group id, ``nVersion || nVersionGroupId``, uniquely defines the transaction format, thus enabling parsers to reject transactions from outside the client's chain which cannot be parsed.
The combination of transaction version and version group ID, ``nVersion || nVersionGroupId``,
uniquely defines the transaction format, thus enabling parsers to reject transactions from outside
the client's chain which cannot be parsed.
By convention, it is expected that when introducing a new transaction version requiring a network upgrade, a new unique version group id will be assigned to that transaction version.
By convention, it is expected that when introducing a new transaction version requiring a network
upgrade, a new unique version group ID will be assigned to that transaction version.
However, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group id MAY be re-used.
However, if a new transaction version can be correctly parsed according to the format of a
preceding version (that is, it only restricts the format, or defines fields that were previously
reserved and which old parsers can safely ignore), then the same version group ID MAY be re-used.
Expiry Height
-------------
@ -160,21 +178,22 @@ Expiry Height
The expiry height field, as defined in the Transaction Expiry ZIP [#zip-0203]_, stores the block height after which a transaction can no longer be mined.
Transaction Validation
======================
----------------------
A valid Overwinter transaction intended for Zcash MUST have:
- version number 3; and
- version group id 0x03C48270 [#versiongroupid]_; and
- version group ID 0x03C48270; and
- ``fOverwintered`` flag set.
Overwinter validators MUST reject transactions for violating consensus rules if:
- the ``fOverwintered`` flag is not set; or
- the version group id is unknown; or
- the version group ID is unknown; or
- the version number is unknown.
Validation of version 3 transactions MUST use the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP [#zip-0143]_.
Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP [#zip-0143]_.
Implementation
==============
@ -194,7 +213,9 @@ Tests can continue to check for the existence of forwards-compatible transaction
}
}
When (de)serializing v3 transactions, the version group id must also be checked in case the transaction is intended for a branch which has a different format for its version 3 transaction::
When (de)serializing v3 transactions, the version group ID must also be checked in case the
transaction is intended for a consensus branch which has a different format for its version 3
transaction::
if (tx.nVersion == 3 && tx.nVersionGroupId == OVERWINTER_VERSION_GROUP_ID) {
auto expiryHeight = tx.nExpiryHeight;
@ -226,21 +247,29 @@ To test if the format of an Overwinter transaction is both v3 and the transactio
It is expected that this test involving ``nVersionGroupId`` is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system.
However, it's possible that a clone of Zcash is using the same version group id and passes the conditional.
However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.
Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP [#zip-0143]_.
Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP [#zip-0143]_.
Deployment
==========
This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in [#zip-0201]_.
Backwards compatibility
=======================
This proposal intentionally creates what is known as a "bilateral consensus rule change" [#zip-0200]_ between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.
This proposal intentionally creates what is known as a "bilateral consensus rule change"
[#zip-0200]_ between pre-Overwinter software and Overwinter-compatible software. Use of
this new transaction format requires that all network participants upgrade their software
to a compatible version within the upgrade window. Pre-Overwinter software will treat
Overwinter transactions as invalid.
Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group ids.
Once Overwinter has activated, Overwinter-compatible software will reject version 1 and
version 2 transactions, and will only accept transactions based upon supported transaction
version numbers and recognized version group IDs.
Reference Implementation
@ -248,12 +277,12 @@ Reference Implementation
https://github.com/zcash/zcash/pull/2925
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Handshaking for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/blob/master/zip-0203.rst>`_
.. [#versiongroupid] `OVERWINTER_VERSION_GROUP_ID <https://github.com/zcash/zcash/pull/2925/files#diff-5cb8d9decaa15620a8f98b0c6c44da9bR311>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Handshaking for Overwinter <zip-0201.rst>`_
.. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_

114
zip-0203.html Normal file
View File

@ -0,0 +1,114 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 203: Transaction Expiry</title>
<meta charset="utf-8" />
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 203
Title: Transaction Expiry
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: Jay Graber
Status: Final
Category: Consensus
Created: 2018-01-09
License: MIT</pre>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This is a Standards ZIP describing a new consensus rule to set an expiration time after which a transaction cannot be mined. If it is not mined within that time, the transaction will be removed from nodes' mempools.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Transactions that have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing a transaction to set a block height after which it cannot be mined would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent.</p>
<p>Advantages include optimizing mempool performance by removing transactions that will not be mined, and potentially simplifying bidirectional payment channels by reducing the need to store and compress revocations for past states, since transactions not committed to the chain could expire and become invalid after a period of time.</p>
<p>If the expiry is at block height
<span class="math">\(N\)</span>
, then the transaction must be included in block
<span class="math">\(N\)</span>
or earlier. Block
<span class="math">\(N+1\)</span>
will be too late, and the transaction will be removed from the mempool.</p>
<p>The new consensus rule will enforce that the transaction will not be considered valid if included in block of height greater than
<span class="math">\(N\)</span>
, and blocks that include expired transactions will not be considered valid.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Transactions will have a new field, <code>nExpiryHeight</code>, which will set the block height after which transactions will be removed from the mempool if they have not been mined.</p>
<p>The data type for <code>nExpiryHeight</code> will be <code>uint32_t</code>. <code>nExpiryHeight</code> will never be a UNIX timestamp, unlike <code>nLockTime</code> values, and thus the maximum expiry height will be 499999999 (but see the exception for coinbase transactions described in <a href="#changes-for-nu5">Changes for NU5</a>).</p>
<p>Note: a previous version of this ZIP incorrectly specified an interaction between <code>nExpiryHeight</code> and <code>nLockTime</code> that was never implemented.</p>
<p>For the example below, the last block that the transaction below could possibly be included in is 3539. After that, it will be removed from the mempool.</p>
<pre>"txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f",
"version": 3,
"locktime": 2089,
"expiryheight": 3539,</pre>
<p>Default: 20 blocks from the current height, or about 50 minutes at 2.5-minute target block spacing. A configuration option can be used to set the user's default.</p>
<p>Minimum: No minimum</p>
<p>Maximum: 499999999, which is about 1185 years from now at 75 seconds/block.</p>
<p>No limit: To set no limit on transactions (so that they do not expire), <code>nExpiryHeight</code> should be set to 0.</p>
<p>Coinbase: <code>nExpiryHeight</code> on coinbase transactions is ignored, and is set to 0 by convention.</p>
<p>Every time a transaction expires and should be removed from the mempool, so should all of its dependent transactions.</p>
<section id="changes-for-blossom"><h3><span class="section-heading">Changes for Blossom</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-blossom"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>On Blossom activation <a id="id1" class="footnote_reference" href="#zip-0206">2</a>, the default changes to 40 blocks from the current height, which still represents about 50 minutes at the revised 75-second target block spacing.</p>
</section>
<section id="changes-for-nu5"><h3><span class="section-heading">Changes for NU5</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-nu5"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As mentioned above, <code>nExpiryHeight</code> is ignored for coinbase transactions. However, from NU5 activation <a id="id2" class="footnote_reference" href="#zip-0252">3</a>, the <code>nExpiryHeight</code> field of a coinbase transaction MUST be set equal to the block height. Also, for coinbase transactions only, the bound of 499999999 on <code>nExpiryHeight</code> is removed. The motivation is to ensure that transaction IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencoding">4</a>.</p>
</section>
<section id="wallet-behavior-and-ui"><h3><span class="section-heading">Wallet behavior and UI</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-behavior-and-ui"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>With the addition of this feature, zero-confirmation transactions with an expiration block height set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash.</p>
<p>Wallet should notify the user of expired transactions that must be re-sent.</p>
</section>
<section id="rpc"><h3><span class="section-heading">RPC</span><span class="section-anchor"> <a rel="bookmark" href="#rpc"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>For Overwinter, transaction expiry will be set to a default that can be overridden by a flag <cite>txexpirydelta</cite> set in the config file.</p>
<p><code>-txexpirydelta=</code> set the number of blocks after which a transaction that has not been mined will become invalid</p>
<p>To view: <cite>listtransactions</cite> has a new filter attribute, showing expired transactions only:</p>
<pre>listtransactions "*" 10 0 "expired"</pre>
<p>WalletTxToJSON shows a boolean expired true/false.</p>
</section>
<section id="config"><h3><span class="section-heading">Config</span><span class="section-anchor"> <a rel="bookmark" href="#config"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The default will be user-configurable with the option <cite>txexpirydelta</cite>.</p>
<p><cite>--txexpirydelta=100</cite></p>
</section>
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>This feature will be deployed with Overwinter. The activation blockheight proposal is in <a id="id4" class="footnote_reference" href="#zip-0201">1</a>.</p>
</section>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p><a href="https://github.com/zcash/zcash/pull/2874">https://github.com/zcash/zcash/pull/2874</a></p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="zip-0201" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
</tr>
</tbody>
</table>
<table id="zip-0206" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="zip-0206">ZIP 206: Deployment of the Blossom Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zip-0252" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencoding" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

View File

@ -2,85 +2,137 @@
ZIP: 203
Title: Transaction Expiry
Author: Jay Graber <jay@z.cash>
Owners: Daira Hopwood <daira@electriccoin.co>
Original-Authors: Jay Graber
Status: Final
Category: Consensus
Created: 2018-01-09
License: MIT
Abstract
===========
========
This is a Standards ZIP describing a new consensus rule to set an expiration time after
which a transaction cannot be mined. If it is not mined within that time, the transaction
will be removed from nodes' mempools.
This is a Standards ZIP describing a new consensus rule to set an expiration time after which a transaction cannot be mined. If it is not mined within that time, the transaction will be removed from nodes' mempools.
Motivation
===========
==========
Transactions that have insufficient fees are often not mined. This indeterminism is a source of confusion for users and wallets. Allowing a transaction to set a block height after which it cannot be mined would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent.
Transactions that have insufficient fees are often not mined. This indeterminism is a
source of confusion for users and wallets. Allowing a transaction to set a block height
after which it cannot be mined would provide certainty around how long a transaction has
to confirm before it is rejected by the network and must be re-sent.
Advantages include optimizing mempool performance by removing transactions that will not be mined, and potentially simplifying bidirectional payment channels by reducing the need to store and compress revocations for past states, since transactions not committed to the chain could expire and become invalid after a period of time.
Advantages include optimizing mempool performance by removing transactions that will not
be mined, and potentially simplifying bidirectional payment channels by reducing the need
to store and compress revocations for past states, since transactions not committed to the
chain could expire and become invalid after a period of time.
If the expiry is at block height N, then the transaction must be included in block N or earlier. Block N+1 will be too late, and the transaction will be removed from the mempool.
If the expiry is at block height :math:`N`, then the transaction must be included in block
:math:`N` or earlier. Block :math:`N+1` will be too late, and the transaction will be
removed from the mempool.
The new consensus rule will enforce that the transaction will not be considered valid if
included in block of height greater than :math:`N`, and blocks that include expired
transactions will not be considered valid.
The new consensus rule will enforce that the transaction will not be considered valid if included in block of height greater than N, and blocks that include expired transactions will not be considered valid.
Specification
===============
=============
Transactions will have a new field, ``nExpiryHeight``, which will set the block height after which transactions will be removed from the mempool if they have not been mined.
Transactions will have a new field, ``nExpiryHeight``, which will set the block height
after which transactions will be removed from the mempool if they have not been mined.
The data type for ``nExpiryHeight`` will be ``uint32_t``. If used in combination with ``nLockTime``, both ``nLockTime`` and ``nExpiryHeight`` must be block heights. ``nExpiryHeight`` will never be a UNIX timestamp, unlike ``nLockTime`` values, and thus the maximum expiry height will be 499999999.
The data type for ``nExpiryHeight`` will be ``uint32_t``. ``nExpiryHeight`` will never
be a UNIX timestamp, unlike ``nLockTime`` values, and thus the maximum expiry height
will be 499999999 (but see the exception for coinbase transactions described in
`Changes for NU5`_).
For the example below, the last block that the transaction below could possibly be included in is 3539. After that, it will be removed from the mempool.
Note: a previous version of this ZIP incorrectly specified an interaction between
``nExpiryHeight`` and ``nLockTime`` that was never implemented.
```
"txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f",
"version": 3,
"locktime": 2089,
"expiryheight": 3539,
```
For the example below, the last block that the transaction below could possibly be
included in is 3539. After that, it will be removed from the mempool.
::
"txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f",
"version": 3,
"locktime": 2089,
"expiryheight": 3539,
Default: 20 blocks from the current height, or about 50 minutes at 2.5-minute target
block spacing. A configuration option can be used to set the user's default.
Default: 20 blocks, or about 1 hour assuming 2.5 minute block times. A configuration option can be used to set the user's default.
Minimum: No minimum
Maximum: 499999999, about 380 years
No limit: To set no limit on transactions (so that they do not expire), ``nExpiryHeight`` should be set to 0.
Coinbase: ``nExpiryHeight`` on coinbase transactions is ignored, and is set to 0 by convention.
Every time a transaction expires and should be removed from the mempool, so should all of its dependent transactions.
Maximum: 499999999, which is about 1185 years from now at 75 seconds/block.
No limit: To set no limit on transactions (so that they do not expire), ``nExpiryHeight``
should be set to 0.
Coinbase: ``nExpiryHeight`` on coinbase transactions is ignored, and is set to 0 by
convention.
Every time a transaction expires and should be removed from the mempool, so should all
of its dependent transactions.
Changes for Blossom
-------------------
On Blossom activation [#zip-0206]_, the default changes to 40 blocks from the current
height, which still represents about 50 minutes at the revised 75-second target block
spacing.
Changes for NU5
---------------
As mentioned above, ``nExpiryHeight`` is ignored for coinbase transactions. However, from
NU5 activation [#zip-0252]_, the ``nExpiryHeight`` field of a coinbase transaction MUST
be set equal to the block height. Also, for coinbase transactions only, the bound of
499999999 on ``nExpiryHeight`` is removed. The motivation is to ensure that transaction
IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol
specification [#protocol-txnencoding]_.
Wallet behavior and UI
-----------------------
----------------------
With the addition of this feature, zero-confirmation transactions with an expiration block height set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash.
With the addition of this feature, zero-confirmation transactions with an expiration block
height set will have even less guarantee of inclusion. This means that UIs and services
must never rely on zero-confirmation transactions in Zcash.
Wallet should notify the user of expired transactions that must be re-sent.
Wallet should notify the user of expired transactions that must be re-sent.
RPC
-----
---
To make changes to the sendtoaddress and z_sendmany commands backwards compatible for future changes, keyword arguments should be accepted by the RPC interface.
For Overwinter, transaction expiry will be set to a default that can be overridden by a
flag `txexpirydelta` set in the config file.
For Overwinter, tx expiry will be set to a default that can be overridden by a flag `txexpirydelta` set in the config file.
``-txexpirydelta=`` set the number of blocks after which a transaction that has not been
mined will become invalid
-txexpirydelta= set the number of blocks after which a transaction that has not been mined will become invalid
To view: `listtransactions` has a new filter attribute, showing expired transactions only::
To view:
listtransactions has a new filter attribute, showing expired transactions only:
listtransactions "*" 10 0 "expired"
WalletTxToJSON shows a boolean expired true/false.
Config
-------
------
The default will be user-configurable with the option `txexpirydelta`.
`--txexpirydelta=100`
Deployment
------------
----------
This feature will be deployed with Overwinter. The activation blockheight proposal is in [#zip-0201]_.
This feature will be deployed with Overwinter. The activation blockheight proposal is in
[#zip-0201]_.
Reference Implementation
@ -92,4 +144,7 @@ https://github.com/zcash/zcash/pull/2874
References
==========
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`_
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_

16
zip-0204.html Normal file
View File

@ -0,0 +1,16 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 204: Zcash P2P Network Protocol</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 204
Title: Zcash P2P Network Protocol
Status: Reserved
Category: Network
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/352">https://github.com/zcash/zips/issues/352</a>&gt;</pre>
</section>
</body>
</html>

7
zip-0204.rst Normal file
View File

@ -0,0 +1,7 @@
::
ZIP: 204
Title: Zcash P2P Network Protocol
Status: Reserved
Category: Network
Discussions-To: <https://github.com/zcash/zips/issues/352>

152
zip-0205.html Normal file
View File

@ -0,0 +1,152 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 205: Deployment of the Sapling Network Upgrade</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 205
Title: Deployment of the Sapling Network Upgrade
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Credits: Simon Liu
Status: Final
Category: Consensus / Network
Created: 2018-10-08
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">7</a></p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Sapling</dt>
<dd>Code-name for the second Zcash network upgrade, also known as Network Upgrade 1.</dd>
</dl>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines the deployment of the Sapling network upgrade. In addition, it describes a hard fork that occurred on Testnet to allow "minimum-difficulty" blocks.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="sapling-deployment"><h3><span class="section-heading">Sapling deployment</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The primary sources of information about Sapling consensus protocol changes are:</p>
<ul>
<li>The Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol">2</a>.</li>
<li>Transaction Signature Validation for Sapling <a id="id5" class="footnote_reference" href="#zip-0243">9</a>.</li>
<li>Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">7</a>.</li>
</ul>
<p>The network handshake and peer management mechanisms defined in <a id="id7" class="footnote_reference" href="#zip-0201">8</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="id8" class="footnote_reference" href="#zip-0200">7</a> are defined for the Sapling upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0x76b809bb</code></dd>
<dt>ACTIVATION_HEIGHT (Sapling)</dt>
<dd>
<p>Testnet: 280000</p>
<p>Mainnet: 419200</p>
</dd>
</dl>
<p>On Testnet, Sapling had activated prior to this height, but that consensus branch was rolled back. A subsequent hard fork occurred on Testnet, changing the difficulty algorithm to accept "minimum-difficulty" blocks under certain conditions starting at block height 299188.</p>
<p>On both Mainnet and Testnet, Sapling-compatible nodes MUST advertise protocol version 170007 or later. The minimum peer protocol version that Sapling-compatible nodes will connect to, remains 170002.</p>
<p>Pre-Sapling nodes are defined as nodes advertising a protocol version less than 170007.</p>
<p>Approximately three days (defined in terms of block height) before the Sapling activation height, Sapling-compatible nodes will change the behaviour of their peer connection logic in order to prefer pre-Sapling peers for eviction from the set of peer connections.</p>
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
<p>The implementation is similar to that for Overwinter which was described in <a id="id9" class="footnote_reference" href="#zip-0201">8</a>.</p>
<p>Once Sapling activates on Testnet or Mainnet, Sapling nodes SHOULD take steps to:</p>
<ul>
<li>reject new connections from pre-Sapling nodes;</li>
<li>disconnect any existing connections to pre-Sapling nodes.</li>
</ul>
</section>
<section id="change-to-difficulty-adjustment-on-testnet"><h3><span class="section-heading">Change to difficulty adjustment on Testnet</span><span class="section-anchor"> <a rel="bookmark" href="#change-to-difficulty-adjustment-on-testnet"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Section 7.6.3 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-diffadjustment">5</a> describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the <code>nTime</code> and <code>nBits</code> fields of preceding blocks.</p>
<p>This algorithm changed on Testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is greater than 15 minutes after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id11" class="footnote_reference" href="#protocol-constants">4</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="id12" class="footnote_reference" href="#protocol-nbits">6</a>.</p>
<p>Note: a previous revision of this ZIP incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
<p>This change does not affect Mainnet.</p>
</section>
</section>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Prior to the network upgrade activating, Sapling and pre-Sapling nodes are compatible and can connect to each other. However, Sapling nodes will have a preference for connecting to other Sapling nodes, so pre-Sapling nodes will gradually be disconnected in the run up to activation.</p>
<p>Once the network upgrades, even though pre-Sapling nodes can still accept the numerically larger protocol version used by Sapling as being valid, Sapling nodes will always disconnect peers using lower protocol versions.</p>
</section>
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Support for Sapling consensus rules was implemented in zcashd version 2.0.0. The majority of support for RPC calls and persistence of Sapling z-addresses was implemented in version 2.0.1. Both of these versions advertise protocol version 170007.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-constants" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants</a></td>
</tr>
</tbody>
</table>
<table id="protocol-diffadjustment" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment</a></td>
</tr>
</tbody>
</table>
<table id="protocol-nbits" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf#nbits">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0201" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
</tr>
</tbody>
</table>
<table id="zip-0243" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="zip-0243">ZIP 243: Transaction Signature Validation for Sapling</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

154
zip-0205.rst Normal file
View File

@ -0,0 +1,154 @@
::
ZIP: 205
Title: Deployment of the Sapling Network Upgrade
Owners: Daira Hopwood <daira@electriccoin.co>
Credits: Simon Liu
Status: Final
Category: Consensus / Network
Created: 2018-10-08
License: MIT
Terminology
===========
The key words "MUST" and "SHOULD" in this document are to be interpreted as
described in RFC 2119. [#RFC2119]_
The terms "consensus branch" and "network upgrade" in this document are to be
interpreted as described in ZIP 200. [#zip-0200]_
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
The terms below are to be interpreted as follows:
Sapling
Code-name for the second Zcash network upgrade, also known as Network Upgrade 1.
Abstract
========
This proposal defines the deployment of the Sapling network upgrade. In addition,
it describes a hard fork that occurred on Testnet to allow "minimum-difficulty"
blocks.
Specification
=============
Sapling deployment
------------------
The primary sources of information about Sapling consensus protocol changes are:
- The Zcash Protocol Specification [#protocol]_.
- Transaction Signature Validation for Sapling [#zip-0243]_.
- Network Upgrade Mechanism [#zip-0200]_.
The network handshake and peer management mechanisms defined in [#zip-0201]_ also
apply to this upgrade.
The following network upgrade constants [#zip-0200]_ are defined for the Sapling
upgrade:
CONSENSUS_BRANCH_ID
``0x76b809bb``
ACTIVATION_HEIGHT (Sapling)
Testnet: 280000
Mainnet: 419200
On Testnet, Sapling had activated prior to this height, but that consensus branch
was rolled back. A subsequent hard fork occurred on Testnet, changing the
difficulty algorithm to accept "minimum-difficulty" blocks under certain
conditions starting at block height 299188.
On both Mainnet and Testnet, Sapling-compatible nodes MUST advertise protocol
version 170007 or later. The minimum peer protocol version that Sapling-compatible
nodes will connect to, remains 170002.
Pre-Sapling nodes are defined as nodes advertising a protocol version less than
170007.
Approximately three days (defined in terms of block height) before the Sapling
activation height, Sapling-compatible nodes will change the behaviour of their peer
connection logic in order to prefer pre-Sapling peers for eviction from the set of
peer connections.
::
/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
The implementation is similar to that for Overwinter which was described in
[#zip-0201]_.
Once Sapling activates on Testnet or Mainnet, Sapling nodes SHOULD take steps to:
- reject new connections from pre-Sapling nodes;
- disconnect any existing connections to pre-Sapling nodes.
Change to difficulty adjustment on Testnet
------------------------------------------
Section 7.6.3 of the Zcash Protocol Specification [#protocol-diffadjustment]_
describes the algorithm used to adjust the difficulty of a block (defined in terms
of a "target threshold") based on the ``nTime`` and ``nBits`` fields of preceding
blocks.
This algorithm changed on Testnet, starting from block 299188, to allow
"minimum-difficulty" blocks. If the block time of a block from this height onward
is greater than 15 minutes after that of the preceding block, then the block is a
minimum-difficulty block. In that case its ``nBits`` field MUST be set to
ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3
of the Zcash Protocol Specification [#protocol-constants]_, and ToCompact is as
defined in section 7.7.4 of that specification [#protocol-nbits]_.
Note: a previous revision of this ZIP incorrectly said that only the target
threshold of minimum-difficulty blocks is affected. In fact the ``nBits`` field
is modified as well, and this affects difficulty adjustment for subsequent blocks.
This change does not affect Mainnet.
Backward compatibility
======================
Prior to the network upgrade activating, Sapling and pre-Sapling nodes are
compatible and can connect to each other. However, Sapling nodes will have a
preference for connecting to other Sapling nodes, so pre-Sapling nodes will
gradually be disconnected in the run up to activation.
Once the network upgrades, even though pre-Sapling nodes can still accept the
numerically larger protocol version used by Sapling as being valid, Sapling nodes
will always disconnect peers using lower protocol versions.
Support in zcashd
=================
Support for Sapling consensus rules was implemented in zcashd version 2.0.0.
The majority of support for RPC calls and persistence of Sapling z-addresses
was implemented in version 2.0.1. Both of these versions advertise protocol
version 170007.
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
.. [#protocol-nbits] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion <protocol/protocol.pdf#nbits>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling <zip-0243.rst>`_

117
zip-0206.html Normal file
View File

@ -0,0 +1,117 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 206: Deployment of the Blossom Network Upgrade</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 206
Title: Deployment of the Blossom Network Upgrade
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Credits: Simon Liu
Status: Final
Category: Consensus / Network
Created: 2019-07-29
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Blossom</dt>
<dd>Code-name for the third Zcash network upgrade, also known as Network Upgrade 2.</dd>
<dt>Testnet</dt>
<dd>The Zcash test network, as defined in <a id="id3" class="footnote_reference" href="#protocol">2</a>.</dd>
<dt>Mainnet</dt>
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
</dl>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines the deployment of the Blossom network upgrade.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="blossom-deployment"><h3><span class="section-heading">Blossom deployment</span><span class="section-anchor"> <a rel="bookmark" href="#blossom-deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The primary sources of information about Blossom consensus protocol changes are:</p>
<ul>
<li>The Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol">2</a>.</li>
<li>Shorter Block Target Spacing <a id="id6" class="footnote_reference" href="#zip-0208">5</a>.</li>
<li>Network Upgrade Mechanism <a id="id7" class="footnote_reference" href="#zip-0200">3</a>.</li>
</ul>
<p>The network handshake and peer management mechanisms defined in <a id="id8" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="id9" class="footnote_reference" href="#zip-0200">3</a> are defined for the Blossom upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0x2BB40E60</code></dd>
<dt>ACTIVATION_HEIGHT (Blossom)</dt>
<dd>
<p>Testnet: 584000</p>
<p>Mainnet: 653600</p>
</dd>
</dl>
<p>Nodes compatible with Blossom activation on testnet MUST advertise protocol version 170008 or later. Nodes compatible with Blossom activation on mainnet MUST advertise protocol version 170009 or later. The minimum peer protocol version that Blossom-compatible nodes will connect to is 170002.</p>
<p>Pre-Blossom testnet nodes are defined as nodes on testnet advertising a protocol version less than 170008. Pre-Blossom mainnet nodes are defined as nodes on mainnet advertising a protocol version less than 170009.</p>
<p>For each network (testnet and mainnet), approximately three days (defined in terms of block height) before the corresponding Blossom activation height, nodes compatible with Blossom activation on that network will change the behaviour of their peer connection logic in order to prefer pre-Blossom peers on that network for eviction from the set of peer connections:</p>
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pre>
<p>The implementation is similar to that for Overwinter which was described in <a id="id10" class="footnote_reference" href="#zip-0201">4</a>.</p>
<p>Once Blossom activates on testnet or mainnet, Blossom nodes SHOULD take steps to:</p>
<ul>
<li>reject new connections from pre-Blossom nodes on that network;</li>
<li>disconnect any existing connections to pre-Blossom nodes on that network.</li>
</ul>
</section>
</section>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Prior to the network upgrade activating on each network, Blossom and pre-Blossom nodes are compatible and can connect to each other. However, Blossom nodes will have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will gradually be disconnected in the run up to activation.</p>
<p>Once the network upgrades, even though pre-Blossom nodes can still accept the numerically larger protocol version used by Blossom as being valid, Blossom nodes will always disconnect peers using lower protocol versions.</p>
<p>Unlike Overwinter and Sapling, Blossom does not define a new transaction version. Blossom transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in <a id="id11" class="footnote_reference" href="#protocol">2</a> section 7.1. This does not imply that transactions are valid across the Blossom activation, since signatures MUST use the appropriate consensus branch ID.</p>
</section>
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Support for Blossom on testnet is implemented in <code>zcashd</code> version 2.0.7, which advertises protocol version 170008. Support for Blossom on mainnet is implemented in <code>zcashd</code> version 2.1.0, which advertises protocol version 170009.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0201" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
</tr>
</tbody>
</table>
<table id="zip-0208" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

128
zip-0206.rst Normal file
View File

@ -0,0 +1,128 @@
::
ZIP: 206
Title: Deployment of the Blossom Network Upgrade
Owners: Daira Hopwood <daira@electriccoin.co>
Credits: Simon Liu
Status: Final
Category: Consensus / Network
Created: 2019-07-29
License: MIT
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
interpreted as described in RFC 2119. [#RFC2119]_
The term "network upgrade" in this document is to be interpreted as described in
ZIP 200. [#zip-0200]_
The terms below are to be interpreted as follows:
Blossom
Code-name for the third Zcash network upgrade, also known as Network Upgrade 2.
Testnet
The Zcash test network, as defined in [#protocol]_.
Mainnet
The Zcash production network, as defined in [#protocol]_.
Abstract
========
This proposal defines the deployment of the Blossom network upgrade.
Specification
=============
Blossom deployment
------------------
The primary sources of information about Blossom consensus protocol changes are:
- The Zcash Protocol Specification [#protocol]_.
- Shorter Block Target Spacing [#zip-0208]_.
- Network Upgrade Mechanism [#zip-0200]_.
The network handshake and peer management mechanisms defined in [#zip-0201]_ also
apply to this upgrade.
The following network upgrade constants [#zip-0200]_ are defined for the Blossom
upgrade:
CONSENSUS_BRANCH_ID
``0x2BB40E60``
ACTIVATION_HEIGHT (Blossom)
Testnet: 584000
Mainnet: 653600
Nodes compatible with Blossom activation on testnet MUST advertise protocol version
170008 or later. Nodes compatible with Blossom activation on mainnet MUST advertise
protocol version 170009 or later. The minimum peer protocol version that
Blossom-compatible nodes will connect to is 170002.
Pre-Blossom testnet nodes are defined as nodes on testnet advertising a protocol
version less than 170008. Pre-Blossom mainnet nodes are defined as nodes on mainnet
advertising a protocol version less than 170009.
For each network (testnet and mainnet), approximately three days (defined in terms of
block height) before the corresponding Blossom activation height, nodes compatible
with Blossom activation on that network will change the behaviour of their peer
connection logic in order to prefer pre-Blossom peers on that network for eviction
from the set of peer connections::
/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
The implementation is similar to that for Overwinter which was described in
[#zip-0201]_.
Once Blossom activates on testnet or mainnet, Blossom nodes SHOULD take steps to:
- reject new connections from pre-Blossom nodes on that network;
- disconnect any existing connections to pre-Blossom nodes on that network.
Backward compatibility
======================
Prior to the network upgrade activating on each network, Blossom and pre-Blossom
nodes are compatible and can connect to each other. However, Blossom nodes will
have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will
gradually be disconnected in the run up to activation.
Once the network upgrades, even though pre-Blossom nodes can still accept the
numerically larger protocol version used by Blossom as being valid, Blossom nodes
will always disconnect peers using lower protocol versions.
Unlike Overwinter and Sapling, Blossom does not define a new transaction version.
Blossom transactions are therefore in the same v4 format as Sapling transactions,
and use the same version group ID, i.e. 0x892F2085 as defined in [#protocol]_
section 7.1. This does not imply that transactions are valid across the Blossom
activation, since signatures MUST use the appropriate consensus branch ID.
Support in zcashd
=================
Support for Blossom on testnet is implemented in ``zcashd`` version 2.0.7, which
advertises protocol version 170008. Support for Blossom on mainnet is implemented
in ``zcashd`` version 2.1.0, which advertises protocol version 170009.
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_

357
zip-0207.html Normal file
View File

@ -0,0 +1,357 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 207: Funding Streams</title>
<meta charset="utf-8" />
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 207
Title: Funding Streams
Owners: Jack Grigg &lt;str4d@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Status: Final
Category: Consensus
Created: 2019-01-04
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol-subsidyconcepts">3</a> <a id="id3" class="footnote_reference" href="#protocol-subsidies">7</a></p>
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id4" class="footnote_reference" href="#zip-0200">10</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Canopy</dt>
<dd>Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</dd>
<dt>Testnet</dt>
<dd>The Zcash test network, as defined in the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#protocol-networks">4</a></dd>
<dt>Mainnet</dt>
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#protocol-networks">4</a></dd>
</dl>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.</p>
<p>This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 <a id="id7" class="footnote_reference" href="#zip-0214">14</a>. It should be read in conjunction with ZIP 1014 <a id="id8" class="footnote_reference" href="#zip-1014">16</a>, which describes the high-level requirements for that fund.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Motivation for the Zcash Development Fund is considered in ZIP 1014 <a id="id9" class="footnote_reference" href="#zip-1014">16</a>.</p>
<p>This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.</p>
</section>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="id10" class="footnote_reference" href="#zip-0214">14</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (BP, ZF, and MG) defined in ZIP 1014 <a id="id11" class="footnote_reference" href="#zip-1014">16</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
<p>As for the original Founders' Reward, a mechanism is provided to allow addresses for a given funding stream to be changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="definitions"><h3><span class="section-heading">Definitions</span><span class="section-anchor"> <a rel="bookmark" href="#definitions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>We use the following constants and functions defined in <a id="id12" class="footnote_reference" href="#protocol-constants">5</a>, <a id="id13" class="footnote_reference" href="#protocol-diffadjustment">6</a>, <a id="id14" class="footnote_reference" href="#protocol-subsidies">7</a>, and <a id="id15" class="footnote_reference" href="#protocol-foundersreward">8</a>:</p>
<ul>
<li>
<span class="math">\(\mathsf{BlossomActivationHeight}\)</span>
</li>
<li>
<span class="math">\(\mathsf{PostBlossomHalvingInterval}\)</span>
</li>
<li>
<span class="math">\(\mathsf{Halving}(\mathsf{height})\)</span>
</li>
<li>
<span class="math">\(\mathsf{BlockSubsidy}(\mathsf{height})\)</span>
</li>
<li>
<span class="math">\(\mathsf{RedeemScriptHash}(\mathsf{height})\)</span>
.</li>
</ul>
<p>We also define the following function:</p>
<ul>
<li>
<span class="math">\(\mathsf{HeightForHalving}(\mathsf{halving})\)</span>
: Smallest
<span class="math">\(\mathsf{height}\)</span>
such that
<span class="math">\(\mathsf{Halving}(\mathsf{height}) = \mathsf{halving}\)</span>
</li>
</ul>
</section>
<section id="funding-streams"><h3><span class="section-heading">Funding streams</span><span class="section-anchor"> <a rel="bookmark" href="#funding-streams"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).</p>
<p>By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. <a id="id16" class="footnote_reference" href="#zip-0208">11</a></p>
<p>The value of a funding stream at a given block height is defined as:</p>
<div class="math">\(\mathsf{FundingStream[FUND].Value}(\mathsf{height}) =
\mathsf{floor}\left(
\frac{\mathsf{BlockSubsidy}(\mathsf{height}) \,\cdot\, \mathsf{FundingStream[FUND].ValueNumerator}}{\mathsf{FundingStream[FUND].ValueDenominator}}
\right)\)</div>
<p>An active funding stream at a given block height is defined as a funding stream for which the block height is less than its end height, but not less than its start height.</p>
<p>Each funding stream has an associated sequence of recipient addresses, each of which MUST be either a transparent P2SH address or a Sapling address.</p>
<p>Each address is used for at most 1/48th of a halving interval, creating a roughly-monthly sequence of funding periods. The address to be used for a given block height is defined as follows:</p>
<div class="math">\(\begin{eqnarray*}
\mathsf{AddressChangeInterval} &amp;=&amp; \mathsf{PostBlossomHalvingInterval} / 48 \\
\mathsf{AddressPeriod}(\mathsf{height}) &amp;=&amp;
\mathsf{floor}\left(
{\small\frac{\mathsf{height} + \mathsf{PostBlossomHalvingInterval} - \mathsf{HeightForHalving}(1)}{\mathsf{AddressChangeInterval}}}
\right) \\
\mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height}) &amp;=&amp;
\mathsf{AddressPeriod}(\mathsf{height}) - \\&amp;&amp;\hspace{2em} \mathsf{AddressPeriod}(\mathsf{FundingStream[FUND].StartHeight}) \\
\mathsf{FundingStream[FUND].Address}(\mathsf{height}) &amp;=&amp; \mathsf{FundingStream[FUND].Addresses[} \\&amp;&amp;\hspace{2em} \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height})\mathsf{]}
\end{eqnarray*}\)</div>
<p>This has the property that all active funding streams change the address they are using on the same block height schedule, aligned to the height of the first halving so that 48 funding periods fit cleanly within a halving interval. This can be leveraged to simplify implementations, by batching the necessary outputs for each funding period.</p>
<p>Below is a visual representation of how stream addresses align with funding periods:</p>
<blockquote>
<table>
<thead>
<tr>
<th>Example height</th>
<th>Stream A</th>
<th>Stream B</th>
<th>Stream C</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>AddressChangeInterval - 2</code></td>
<td>A0</td>
<td></td>
<td></td>
</tr>
<tr>
<td><code>AddressChangeInterval - 1</code></td>
<td>A0</td>
<td></td>
<td></td>
</tr>
<tr>
<td><code>AddressChangeInterval</code></td>
<td>A1</td>
<td>B0</td>
<td>C0</td>
</tr>
<tr>
<td><code>AddressChangeInterval + 1</code></td>
<td>A1</td>
<td>B0</td>
<td>C0</td>
</tr>
<tr>
<td>...</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td><code>2*AddressChangeInterval - 2</code></td>
<td>A1</td>
<td>B0</td>
<td>C0</td>
</tr>
<tr>
<td><code>2*AddressChangeInterval - 1</code></td>
<td>A1</td>
<td>B0</td>
<td>C0</td>
</tr>
<tr>
<td><code>2*AddressChangeInterval</code></td>
<td>A2</td>
<td></td>
<td>C1</td>
</tr>
<tr>
<td><code>2*AddressChangeInterval + 1</code></td>
<td>A2</td>
<td></td>
<td>C1</td>
</tr>
<tr>
<td>...</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td><code>PostBlossomHalvingInterval - 2</code></td>
<td>A2</td>
<td></td>
<td>C1</td>
</tr>
<tr>
<td><code>PostBlossomHalvingInterval - 1</code></td>
<td>A2</td>
<td></td>
<td>C1</td>
</tr>
<tr>
<td><code>PostBlossomHalvingInterval</code></td>
<td></td>
<td></td>
<td>C2</td>
</tr>
<tr>
<td><code>PostBlossomHalvingInterval + 1</code></td>
<td></td>
<td></td>
<td>C2</td>
</tr>
</tbody>
</table>
</blockquote>
<p>On Mainnet, Canopy is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to Canopy activation.</p>
</section>
<section id="consensus-rules"><h3><span class="section-heading">Consensus rules</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rules"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="id17" class="footnote_reference" href="#protocol-foundersreward">8</a></p>
<p>Once the Canopy network upgrade activates:</p>
<ul>
<li>The existing consensus rule for payment of the Founders' Reward <a id="id18" class="footnote_reference" href="#protocol-foundersreward">8</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
<li>The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.</li>
<li>The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form <code>OP_HASH160 RedeemScriptHash(height) OP_EQUAL</code> as the <code>scriptPubKey</code>.</li>
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id19" class="footnote_reference" href="#zip-0213">13</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
<span class="math">\(\mathbf{0x02}\)</span>
, as specified in <a id="id20" class="footnote_reference" href="#zip-0212">12</a>.</li>
</ul>
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="id21" class="footnote_reference" href="#zip-0214">14</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id22" class="footnote_reference" href="#zip-0000">9</a></p>
</section>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal is intended to be deployed with Canopy. <a id="id23" class="footnote_reference" href="#zip-0251">15</a></p>
</section>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li><a href="https://github.com/zcash/zcash/pull/4560">https://github.com/zcash/zcash/pull/4560</a></li>
<li><a href="https://github.com/zcash/zcash/pull/4675">https://github.com/zcash/zcash/pull/4675</a></li>
<li><a href="https://github.com/zcash/zcash/pull/4830">https://github.com/zcash/zcash/pull/4830</a></li>
</ul>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-subsidyconcepts" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy and Founders' Reward</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-constants" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants</a></td>
</tr>
</tbody>
</table>
<table id="protocol-diffadjustment" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment</a></td>
</tr>
</tbody>
</table>
<table id="protocol-subsidies" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/protocol.pdf#subsidies">Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward</a></td>
</tr>
</tbody>
</table>
<table id="protocol-foundersreward" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/protocol.pdf#foundersreward">Zcash Protocol Specification, Version 2021.2.16. Section 7.9: Payment of Founders' Reward</a></td>
</tr>
</tbody>
</table>
<table id="zip-0000" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="zip-0000">ZIP 0: ZIP Process</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0208" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
</tr>
</tbody>
</table>
<table id="zip-0212" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="zip-0212">ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td>
</tr>
</tbody>
</table>
<table id="zip-0213" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="zip-0213">ZIP 213: Shielded Coinbase</a></td>
</tr>
</tbody>
</table>
<table id="zip-0214" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="zip-0214">ZIP 214: Consensus rules for a Zcash Development Fund</a></td>
</tr>
</tbody>
</table>
<table id="zip-0251" class="footnote">
<tbody>
<tr>
<th>15</th>
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zip-1014" class="footnote">
<tbody>
<tr>
<th>16</th>
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

251
zip-0207.rst Normal file
View File

@ -0,0 +1,251 @@
::
ZIP: 207
Title: Funding Streams
Owners: Jack Grigg <str4d@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Status: Final
Category: Consensus
Created: 2019-01-04
License: MIT
Terminology
===========
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are
to be interpreted as described in RFC 2119. [#RFC2119]_
The terms "block subsidy" and "halving" in this document are to be interpreted
as described in sections 3.9 and 7.7 of the Zcash Protocol Specification.
[#protocol-subsidyconcepts]_ [#protocol-subsidies]_
The terms "consensus branch" and "network upgrade" in this document are to be
interpreted as described in ZIP 200. [#zip-0200]_
The terms below are to be interpreted as follows:
Canopy
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
Testnet
The Zcash test network, as defined in the Zcash Protocol Specification. [#protocol-networks]_
Mainnet
The Zcash production network, as defined in the Zcash Protocol Specification. [#protocol-networks]_
Abstract
========
This proposal specifies a mechanism to support funding streams, distributed
from a portion of the block subsidy for a specified range of block heights.
This is intended as a means of implementing the Zcash Development Fund,
using the funding stream definitions specified in ZIP 214 [#zip-0214]_. It
should be read in conjunction with ZIP 1014 [#zip-1014]_, which describes
the high-level requirements for that fund.
Motivation
==========
Motivation for the Zcash Development Fund is considered in ZIP 1014 [#zip-1014]_.
This ZIP 207 was originally proposed for the Blossom network upgrade, as a
means of splitting the original Founders' Reward into several streams. It was
then withdrawn when such splitting was judged to be unnecessary at the consensus
level. Since the capabilities of the funding stream mechanism match the
requirements for the Zcash Development Fund, the ZIP is being reintroduced
for that purpose in order to reuse specification, analysis, and implementation
effort.
Requirements
============
The primary requirement of this ZIP is to provide a mechanism for specifying
the funding streams that are used in ZIP 214 [#zip-0214]_ to implement the Zcash
Development Fund. It should be sufficiently expressive to handle both the main
three "slices" (BP, ZF, and MG) defined in ZIP 1014 [#zip-1014]_, and also
(with additional funding stream definitions) the "direct grant option" described
in that ZIP.
As for the original Founders' Reward, a mechanism is provided to allow addresses
for a given funding stream to be changed on a roughly-monthly basis, so that keys
that are not yet needed may be kept off-line as a security measure.
Specification
=============
Definitions
-----------
We use the following constants and functions defined in [#protocol-constants]_,
[#protocol-diffadjustment]_, [#protocol-subsidies]_, and [#protocol-foundersreward]_:
- :math:`\mathsf{BlossomActivationHeight}`
- :math:`\mathsf{PostBlossomHalvingInterval}`
- :math:`\mathsf{Halving}(\mathsf{height})`
- :math:`\mathsf{BlockSubsidy}(\mathsf{height})`
- :math:`\mathsf{RedeemScriptHash}(\mathsf{height})`.
We also define the following function:
- :math:`\mathsf{HeightForHalving}(\mathsf{halving})`: Smallest :math:`\mathsf{height}` such that
:math:`\mathsf{Halving}(\mathsf{height}) = \mathsf{halving}`
Funding streams
---------------
A funding stream is defined by a block subsidy fraction (represented as a
numerator and a denominator), a start height (inclusive), and an end height
(exclusive).
By defining the issuance as a proportion of the total block subsidy, rather
than absolute zatoshis, this ZIP dovetails with any changes to both block
target spacing and issuance-per-block rates. Such a change occurred at the
Blossom network upgrade, for example. [#zip-0208]_
The value of a funding stream at a given block height is defined as:
.. math::
\mathsf{FundingStream[FUND].Value}(\mathsf{height}) =
\mathsf{floor}\left(
\frac{\mathsf{BlockSubsidy}(\mathsf{height}) \,\cdot\, \mathsf{FundingStream[FUND].ValueNumerator}}{\mathsf{FundingStream[FUND].ValueDenominator}}
\right)
An active funding stream at a given block height is defined as a funding
stream for which the block height is less than its end height, but not less
than its start height.
Each funding stream has an associated sequence of recipient addresses,
each of which MUST be either a transparent P2SH address or a Sapling address.
Each address is used for at most 1/48th of a halving interval, creating a
roughly-monthly sequence of funding periods. The address to be used for a
given block height is defined as follows:
.. math::
\begin{eqnarray*}
\mathsf{AddressChangeInterval} &=& \mathsf{PostBlossomHalvingInterval} / 48 \\
\mathsf{AddressPeriod}(\mathsf{height}) &=&
\mathsf{floor}\left(
{\small\frac{\mathsf{height} + \mathsf{PostBlossomHalvingInterval} - \mathsf{HeightForHalving}(1)}{\mathsf{AddressChangeInterval}}}
\right) \\
\mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height}) &=&
\mathsf{AddressPeriod}(\mathsf{height}) - \\&&\hspace{2em} \mathsf{AddressPeriod}(\mathsf{FundingStream[FUND].StartHeight}) \\
\mathsf{FundingStream[FUND].Address}(\mathsf{height}) &=& \mathsf{FundingStream[FUND].Addresses[} \\&&\hspace{2em} \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height})\mathsf{]}
\end{eqnarray*}
This has the property that all active funding streams change the address they
are using on the same block height schedule, aligned to the height of the
first halving so that 48 funding periods fit cleanly within a halving
interval. This can be leveraged to simplify implementations, by batching the
necessary outputs for each funding period.
Below is a visual representation of how stream addresses align with funding
periods:
================================== ======== ======== ========
Example height Stream A Stream B Stream C
================================== ======== ======== ========
``AddressChangeInterval - 2`` A0
``AddressChangeInterval - 1`` A0
``AddressChangeInterval`` A1 B0 C0
``AddressChangeInterval + 1`` A1 B0 C0
\...
``2*AddressChangeInterval - 2`` A1 B0 C0
``2*AddressChangeInterval - 1`` A1 B0 C0
``2*AddressChangeInterval`` A2 C1
``2*AddressChangeInterval + 1`` A2 C1
\...
``PostBlossomHalvingInterval - 2`` A2 C1
``PostBlossomHalvingInterval - 1`` A2 C1
``PostBlossomHalvingInterval`` C2
``PostBlossomHalvingInterval + 1`` C2
================================== ======== ======== ========
On Mainnet, Canopy is planned to activate exactly at the point when the Founders'
Reward expires, at block height 1046400. On Testnet, there will be a shortened
Founders' Reward address period prior to Canopy activation.
Consensus rules
---------------
Prior to activation of the Canopy network upgrade, the existing consensus rule
for payment of the original Founders' Reward is enforced. [#protocol-foundersreward]_
Once the Canopy network upgrade activates:
- The existing consensus rule for payment of the Founders' Reward [#protocol-foundersreward]_
is no longer active.
(This would be the case under the preexisting consensus rules for Mainnet, but
not for Testnet.)
- The coinbase transaction in each block MUST contain at least one output per
active funding stream that pays the stream's value in the prescribed way to
the stream's recipient address for the block's height.
- The "prescribed way" to pay a transparent P2SH address is to use a standard
P2SH script of the form ``OP_HASH160 RedeemScriptHash(height) OP_EQUAL`` as
the ``scriptPubKey``.
- The "prescribed way" to pay a Sapling address is as defined in [#zip-0213]_.
That is, all Sapling outputs in coinbase transactions (including, but not
limited to, outputs for funding streams) MUST have valid note commitments
when recovered using a 32-byte array of zeroes as the outgoing viewing key.
In this case the note plaintext lead byte MUST be :math:`\mathbf{0x02}`, as
specified in [#zip-0212]_.
For the funding stream definitions to be activated at Canopy, see ZIP 214. [#zip-0214]_
Funding stream definitions can be added, changed, or deleted in ZIPs associated
with subsequent network upgrades, subject to the ZIP process. [#zip-0000]_
Deployment
==========
This proposal is intended to be deployed with Canopy. [#zip-0251]_
Backward compatibility
======================
This proposal intentionally creates what is known as a "bilateral consensus
rule change". Use of this mechanism requires that all network participants
upgrade their software to a compatible version within the upgrade window.
Older software will treat post-upgrade blocks as invalid, and will follow any
pre-upgrade consensus branch that persists.
Reference Implementation
========================
* https://github.com/zcash/zcash/pull/4560
* https://github.com/zcash/zcash/pull/4675
* https://github.com/zcash/zcash/pull/4830
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidyconcepts>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward <protocol/protocol.pdf#subsidies>`_
.. [#protocol-foundersreward] `Zcash Protocol Specification, Version 2021.2.16. Section 7.9: Payment of Founders' Reward <protocol/protocol.pdf#foundersreward>`_
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_
.. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund <zip-0214.rst>`_
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_
.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_

313
zip-0208.html Normal file
View File

@ -0,0 +1,313 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 208: Shorter Block Target Spacing</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 208
Title: Shorter Block Target Spacing
Owner: Daira Hopwood &lt;daira@electriccoin.co&gt;
Original-Authors: Daira Hopwood
Simon Liu
Status: Final
Category: Consensus
Created: 2019-01-10
License: MIT
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://github.com/zcash/zips/pull/237</a>&gt;</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST" and "SHOULD" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms "block chain", "consensus rule change", "consensus branch", and "network upgrade" are to be interpreted as defined in <a id="id2" class="footnote_reference" href="#zip-0200">9</a>.</p>
<p>The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given consensus branch. It is normally measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-diffadjustment">6</a>.)</p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol-networks">4</a>.</p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade <a id="id5" class="footnote_reference" href="#zip-0206">11</a>.</p>
<p>The emission schedule of mined ZEC will be approximately the same in terms of time, but this requires the emission per block to be adjusted to take account of the changed block target spacing.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The motivations for decreasing the block target spacing are:</p>
<ul>
<li>Reduced latency for considering transactions to be sufficiently confirmed;</li>
<li>Greater throughput of transactions in unit time.</li>
</ul>
<p>The latter goal could alternatively be achieved by increasing the block size limit, but that would not also achieve the former goal.</p>
<p>Note that, for a given security requirement (in terms of the expected cost distribution of a rollback attack), the number of confirmations needed increases more slowly than the decrease in block time, and so, up to a point, decreasing the block target spacing can provide a better trade-off between latency and security. This argument assumes that the validation and propagation time for a block remain small compared to the block target spacing. See <a id="id6" class="footnote_reference" href="#slowfastblocks">13</a> for further analysis in various attack models.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The changes described in this section are to be made in the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol">3</a>, relative to the pre-Blossom specification in [#preblossom-protocol].</p>
<section id="consensus-changes"><h3><span class="section-heading">Consensus changes</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-changes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval, and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain their values from <a id="id8" class="footnote_reference" href="#preblossom-protocol">2</a> of 840000 (blocks) and 150 (seconds) respectively.</p>
<p>In section 2 (Notation), add BlossomActivationHeight and PostBlossomPoWTargetSpacing to the list of integer constants.</p>
<p>In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.</p>
<p>For a given network (production or test), define BlossomActivationHeight as the height at which Blossom activates on that network, as specified in <a id="id9" class="footnote_reference" href="#zip-0206">11</a>.</p>
<p>In section 7.6.3 (Difficulty adjustment) [later moved to section 7.7.3], make the following changes:</p>
<p>Define IsBlossomActivated(<em>height</em>) to return true if <em>height</em> ≥ BlossomActivationHeight, otherwise false.</p>
<p>This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.</p>
<p>Define:</p>
<ul>
<li>BlossomPoWTargetSpacingRatio := PreBlossomPoWTargetSpacing / PostBlossomPoWTargetSpacing</li>
<li>PostBlossomHalvingInterval := floor(PreBlossomHalvingInterval · BlossomPoWTargetSpacingRatio).</li>
</ul>
<p>In the same section, redefine PoWTargetSpacing as a function taking a <em>height</em> parameter, as follows:</p>
<ul>
<li>PoWTargetSpacing(<em>height</em>) :=
<ul>
<li>PreBlossomPoWTargetSpacing, if not IsBlossomActivated(<em>height</em>)</li>
<li>PostBlossomPoWTargetSpacing, otherwise.</li>
</ul>
</li>
</ul>
<p>Also redefine AveragingWindowTimespan, MinActualTimespan, MaxActualTimespan, ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows:</p>
<ul>
<li>add a <em>height</em> parameter to each of these functions that does not already have one;</li>
<li>ensure that each reference to any of these values, or to PoWTargetSpacing, are replaced with a function call passing the <em>height</em> parameter.</li>
</ul>
<p>In section 7.7 (Calculation of Block Subsidy and Founders Reward) [later moved to section 7.8], redefine the Halving and BlockSubsidy functions as follows:</p>
<ul>
<li>Halving(<em>height</em>) :=
<ul>
<li>floor((<em>height</em> - SlowStartShift) / PreBlossomHalvingInterval), if not IsBlossomActivated(<em>height</em>)</li>
<li>floor((BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (<em>height</em> - BlossomActivationHeight) / PostBlossomHalvingInterval), otherwise</li>
</ul>
</li>
<li>BlockSubsidy(<em>height</em>) :=
<ul>
<li>SlowStartRate · <em>height</em>, if <em>height</em> &lt; SlowStartInterval / 2</li>
<li>SlowStartRate · (<em>height</em> + 1), if SlowStartInterval / 2 ≤ <em>height</em> and <em>height</em> &lt; SlowStartInterval</li>
<li>floor(MaxBlockSubsidy / 2<sup>Halving(*height*)</sup>), if SlowStartInterval ≤ <em>height</em> and not IsBlossomActivated(<em>height</em>)</li>
<li>floor(MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2<sup>Halving(*height*)</sup>)), otherwise</li>
</ul>
</li>
</ul>
<p>Note: BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTargetSpacing are chosen so that:</p>
<ul>
<li>(BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (<em>height</em> - BlossomActivationHeight) / PostBlossomHalvingInterval) is exactly 1 for some integer <em>height</em>.</li>
<li>MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2<sup>Halving(*height*)</sup>) is an integer for the next few periods.</li>
</ul>
<p>In section 7.8 (Payment of Founders Reward) [later moved to section 7.9], define:</p>
<ul>
<li>FounderAddressAdjustedHeight(<em>height</em>) :=
<ul>
<li><em>height</em>, if not IsBlossomActivated(<em>height</em>)</li>
<li>BlossomActivationHeight + floor((<em>height</em> - BlossomActivationHeight) / BlossomPoWTargetSpacingRatio), otherwise</li>
</ul>
</li>
</ul>
<p>and in the definition of FounderAddressIndex, replace the use of <em>height</em> with FounderAddressAdjustedHeight(<em>height</em>).</p>
<p>Also define:</p>
<ul>
<li>FoundersRewardLastBlockHeight := max({ <em>height</em> ⦂ N | Halving(<em>height</em>) &lt; 1 })</li>
</ul>
<p>Replace the first note in that section with:</p>
<ul>
<li>No Founders Reward is required to be paid for <em>height</em> &gt; FoundersRewardLastBlockHeight (i.e. after the first halving), or for <em>height</em> = 0 (i.e. the genesis block).</li>
</ul>
<p>and in the second note, replace SlowStartShift + PreBlossomHalvingInterval - 1 with FoundersRewardLastBlockHeight.</p>
</section>
<section id="effect-on-difficulty-adjustment"><h3><span class="section-heading">Effect on difficulty adjustment</span><span class="section-anchor"> <a rel="bookmark" href="#effect-on-difficulty-adjustment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The difficulty adjustment parameters PoWAveragingWindow and PoWMedianBlockSpan refer to numbers of blocks, but do <em>not</em> change at Blossom activation. This is because the amount of damping/averaging required is expected to be roughly the same, in terms of the number of blocks, after the change in block target spacing.</p>
<p>The change in the effective value of PoWTargetSpacing will cause the block spacing to adjust to the new target, at the normal rate for a difficulty adjustment. The results of simulations are consistent with this expected behaviour.</p>
<p>Note that the change in AveragingWindowTimespan(height) takes effect immediately when calculating the target difficulty starting from the block at the Blossom activation height, even though the difficulty of the preceding PoWAveragingWindow blocks will have been adjusted using the pre-Blossom target spacing. Therefore it is likely that the difficulty adjustment for the first few blocks after activation will be limited by PoWMaxAdjustDown. This is not anticipated to cause any problem.</p>
<section id="minimum-difficulty-blocks-on-testnet"><h4><span class="section-heading">Minimum difficulty blocks on Testnet</span><span class="section-anchor"> <a rel="bookmark" href="#minimum-difficulty-blocks-on-testnet"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>On Testnet from block height 299188 onward, the difficulty adjustment algorithm <a id="id10" class="footnote_reference" href="#protocol-diffadjustment">6</a> allows minimum-difficulty blocks, as described in <a id="id11" class="footnote_reference" href="#zip-0205">10</a>, when the block time is greater than a given threshold. This specification changes this threshold to be proportional to the block target spacing.</p>
<p>That is, if the block time of a block at height <em>height</em> ≥ 299188 is greater than 6 · PoWTargetSpacing(<em>height</em>) seconds after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id12" class="footnote_reference" href="#protocol-constants">5</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="id13" class="footnote_reference" href="#protocol-nbits">7</a>.</p>
<p>Note: a previous revision of this ZIP (and <a id="id14" class="footnote_reference" href="#zip-0205">10</a>) incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
<p>This change does not affect Mainnet.</p>
</section>
</section>
<section id="non-consensus-node-behaviour"><h3><span class="section-heading">Non-consensus node behaviour</span><span class="section-anchor"> <a rel="bookmark" href="#non-consensus-node-behaviour"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="end-of-service-halt"><h4><span class="section-heading">End-of-Service halt</span><span class="section-anchor"> <a rel="bookmark" href="#end-of-service-halt"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p><cite>zcashd</cite> implements an "End-of-Service halt" behaviour that halts the node at a block height that corresponds approximately to a given time after release. This interval SHOULD be adjusted in releases where the End-of-Service halt time will follow Blossom activation.</p>
</section>
<section id="default-expiry-delta"><h4><span class="section-heading">Default expiry delta</span><span class="section-anchor"> <a rel="bookmark" href="#default-expiry-delta"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>When not overridden by the <code>-txexpirydelta</code> option, <cite>zcashd</cite> RPC calls that create transactions use a default value for the number of blocks after which a transaction will expire. The default in recent versions of <cite>zcashd</cite> is 20 blocks, which at the pre-Blossom block target spacing corresponds to roughly 50 minutes.</p>
<p>This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after Blossom activation, to maintain the approximate expiry time of 50 minutes.</p>
<p>If the <code>-txexpirydelta</code> option is set, then the set value SHOULD be used both before and after Blossom activation.</p>
</section>
<section id="sprout-to-sapling-migration"><h4><span class="section-heading">Sprout to Sapling migration</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-to-sapling-migration"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>ZIP 308 <a id="id15" class="footnote_reference" href="#zip-0308">12</a> defines a procedure for migrating funds from Sprout to Sapling z-addresses. In that procedure, migration transactions are sent every 500 blocks, which corresponded to roughly 20.83 hours before Blossom.</p>
<p>The 500-block constant has not been changed. Therefore, migration transactions are now sent roughly every 10.42 hours after Blossom activation. This has been noted in the ZIP, and a table showing the expected time to complete migration has been updated accordingly.</p>
</section>
<section id="fingerprinting-mitigation"><h4><span class="section-heading">Fingerprinting mitigation</span><span class="section-anchor"> <a rel="bookmark" href="#fingerprinting-mitigation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A "fingerprinting attack" is a network analysis technique in which nodes are identified across network sessions, for example using information about which blocks they request or send.</p>
<p><cite>zcashd</cite> inherits from Bitcoin Core the following behaviour, described in a comment in <code>main.cpp</code>, intended as a fingerprinting mitigation:</p>
<pre>// To prevent fingerprinting attacks, only send blocks outside of the active
// chain if they are valid, and no more than a month older (both in time, and in
// best equivalent proof of work) than the best header chain we know about.</pre>
<p>We make no assertion about the significance of fingerprinting for Zcash, and (despite the word "prevent" in the above comment) no claim about the effectiveness of this mitigation.</p>
<p>In any case, to estimate the "best equivalent proof of work" of a given block chain (measured in units of time), we take the total work of the chain as defined in section 7.7.5 of the Zcash Protocol Specification <a id="id16" class="footnote_reference" href="#protocol-workdef">8</a>, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.</p>
<p>It is not a requirement of the Zcash protocol that this fingerprinting mitigation is used; however, if it is used, then it SHOULD use the target block spacing at the same block height that is used for the current work estimate.</p>
</section>
<section id="monitoring-for-quicker-or-slower-than-expected-blocks"><h4><span class="section-heading">Monitoring for quicker- or slower-than-expected blocks</span><span class="section-anchor"> <a rel="bookmark" href="#monitoring-for-quicker-or-slower-than-expected-blocks"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p><cite>zcashd</cite> previously did this monitoring every 150 seconds; it is now done every 60 seconds.</p>
</section>
<section id="block-timeout"><h4><span class="section-heading">Block timeout</span><span class="section-anchor"> <a rel="bookmark" href="#block-timeout"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The timeout for a requested block is calculated as the target block time, multiplied by 2 + (the number of queued validated headers)/2.</p>
</section>
<section id="latency-optimization-when-requesting-blocks"><h4><span class="section-heading">Latency optimization when requesting blocks</span><span class="section-anchor"> <a rel="bookmark" href="#latency-optimization-when-requesting-blocks"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>When <cite>zcashd</cite> sees an announced block that chains from headers that it does not already have, it will first ask for the headers, and then the block itself. A latency optimization is performed only if the chain is "nearly synced":</p>
<pre>// First request the headers preceding the announced block. In the normal fully-synced
// case where a new block is announced that succeeds the current tip (no reorganization),
// there are no such headers.
// Secondly, and only when we are close to being synced, we request the announced block directly,
// to avoid an extra round-trip. Note that we must *first* ask for the headers, so by the
// time the block arrives, the header chain leading up to it is already validated. Not
// doing this will result in the received block being rejected as an orphan in case it is
// not a direct successor.</pre>
<p>The heuristic for "nearly synced" is that the timestamp of the block at the active tip is no more than 20 block times before the current "adjusted time". In <cite>zcashd</cite> this calculation uses the block target spacing as of the best known header. Around Blossom activation when the block target spacing changes, this could cause the heuristic to be based on the pre-Blossom block target spacing until the node has synced headers past the activation block, but this is not anticipated to cause any problem.</p>
</section>
<section id="response-to-getblocks-message-when-pruning"><h4><span class="section-heading">Response to getblocks message when pruning</span><span class="section-anchor"> <a rel="bookmark" href="#response-to-getblocks-message-when-pruning"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>If pruning is enabled, when <cite>zcashd</cite> responds to an "getblocks" peer-to-peer message, it will only include blocks that it has on disk, and is likely to still have on disk an hour after responding to the message:</p>
<pre>// If pruning, don't inv blocks unless we have on disk and are likely to still have
// for some reasonable time window (1 hour) that block relay might require.</pre>
<p>For each block, when estimating whether it will still be on disk after an hour, we take MIN_BLOCKS_TO_KEEP = 288 blocks, minus approximately the number of blocks expected in one hour at the target block spacing as of that block. Around Blossom activation, this might underestimate the number of blocks in the next hour, but given the value of MIN_BLOCKS_TO_KEEP, this is not anticipated to cause any problem.</p>
</section>
<section id="estimation-of-fully-synced-chain-height"><h4><span class="section-heading">Estimation of fully synced chain height</span><span class="section-anchor"> <a rel="bookmark" href="#estimation-of-fully-synced-chain-height"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p><cite>zcashd</cite> uses the <code>EstimateNetHeight</code> function to estimate the approximate height of the fully synced chain, so that the progress of block download can be displayed to the node operator. This function has been rewritten, simplified, and changed to take account of cases where the time period that needs to be estimated crosses Blossom activation.</p>
</section>
<section id="other-block-related-constants"><h4><span class="section-heading">Other block-related constants</span><span class="section-anchor"> <a rel="bookmark" href="#other-block-related-constants"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The following constants, measured in number of blocks, were reviewed and a decision was made not to change them:</p>
<pre>/** The number of blocks within expiry height when a tx is considered to be expiring soon */
TX_EXPIRING_SOON_THRESHOLD = 3
/** Maximum reorg length we will accept before we shut down and alert the user. */
MAX_REORG_LENGTH = COINBASE_MATURITY - 1;
static const int COINBASE_MATURITY = 100;
/** Number of blocks that can be requested at any given time from a single peer. */
static const int MAX_BLOCKS_IN_TRANSIT_PER_PEER = 16;
static const unsigned int BLOCK_DOWNLOAD_WINDOW = 1024;
/** Block files containing a block-height within MIN_BLOCKS_TO_KEEP of chainActive.Tip() will not be pruned. */
static const unsigned int MIN_BLOCKS_TO_KEEP = 288;
/**
* The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks).
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
*/
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
</section>
</section>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Blossom network upgrade. <a id="id17" class="footnote_reference" href="#zip-0206">11</a></p>
</section>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p><a href="https://github.com/zcash/zcash/pull/4025">https://github.com/zcash/zcash/pull/4025</a></p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="preblossom-protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf">Zcash Protocol Specification, Version 2018.0-beta-37 (exactly)</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-constants" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants</a></td>
</tr>
</tbody>
</table>
<table id="protocol-diffadjustment" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment</a></td>
</tr>
</tbody>
</table>
<table id="protocol-nbits" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/protocol.pdf#nbits">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion</a></td>
</tr>
</tbody>
</table>
<table id="protocol-workdef" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/protocol.pdf#workdef">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0205" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zip-0206" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="zip-0206">ZIP 206: Deployment of the Blossom Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zip-0308" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="zip-0308">ZIP 308: Sprout to Sapling Migration</a></td>
</tr>
</tbody>
</table>
<table id="slowfastblocks" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/">On Slow and Fast Block Times</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

409
zip-0208.rst Normal file
View File

@ -0,0 +1,409 @@
::
ZIP: 208
Title: Shorter Block Target Spacing
Owner: Daira Hopwood <daira@electriccoin.co>
Original-Authors: Daira Hopwood
Simon Liu
Status: Final
Category: Consensus
Created: 2019-01-10
License: MIT
Pull-Request: <https://github.com/zcash/zips/pull/237>
Terminology
===========
The key words "MUST" and "SHOULD" in this document are to be interpreted as
described in RFC 2119. [#RFC2119]_
The terms "block chain", "consensus rule change", "consensus branch", and
"network upgrade" are to be interpreted as defined in [#zip-0200]_.
The term "block target spacing" means the time interval between blocks targeted
by the difficulty adjustment algorithm in a given consensus branch. It is normally
measured in seconds. (This is also sometimes called the "target block time",
but "block target spacing" is the term used in the Zcash Protocol Specification
[#protocol-diffadjustment]_.)
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
Abstract
========
This proposal specifies a change in the block target spacing, to take effect in
the Blossom network upgrade [#zip-0206]_.
The emission schedule of mined ZEC will be approximately the same in terms of
time, but this requires the emission per block to be adjusted to take account
of the changed block target spacing.
Motivation
==========
The motivations for decreasing the block target spacing are:
- Reduced latency for considering transactions to be sufficiently confirmed;
- Greater throughput of transactions in unit time.
The latter goal could alternatively be achieved by increasing the block size
limit, but that would not also achieve the former goal.
Note that, for a given security requirement (in terms of the expected cost
distribution of a rollback attack), the number of confirmations needed
increases more slowly than the decrease in block time, and so, up to a point,
decreasing the block target spacing can provide a better trade-off between
latency and security. This argument assumes that the validation and
propagation time for a block remain small compared to the block target spacing.
See [#slowfastblocks]_ for further analysis in various attack models.
Specification
=============
The changes described in this section are to be made in the Zcash Protocol Specification
[#protocol]_, relative to the pre-Blossom specification in [#preblossom-protocol].
Consensus changes
-----------------
Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval,
and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain
their values from [#preblossom-protocol]_ of 840000 (blocks) and 150 (seconds)
respectively.
In section 2 (Notation), add BlossomActivationHeight and PostBlossomPoWTargetSpacing
to the list of integer constants.
In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.
For a given network (production or test), define BlossomActivationHeight as the
height at which Blossom activates on that network, as specified in [#zip-0206]_.
In section 7.6.3 (Difficulty adjustment) [later moved to section 7.7.3], make the
following changes:
Define IsBlossomActivated(*height*) to return true if *height* ≥ BlossomActivationHeight,
otherwise false.
This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.
Define:
- BlossomPoWTargetSpacingRatio := PreBlossomPoWTargetSpacing / PostBlossomPoWTargetSpacing
- PostBlossomHalvingInterval := floor(PreBlossomHalvingInterval · BlossomPoWTargetSpacingRatio).
In the same section, redefine PoWTargetSpacing as a function taking a *height*
parameter, as follows:
- PoWTargetSpacing(*height*) :=
- PreBlossomPoWTargetSpacing, if not IsBlossomActivated(*height*)
- PostBlossomPoWTargetSpacing, otherwise.
Also redefine AveragingWindowTimespan, MinActualTimespan, MaxActualTimespan,
ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows:
- add a *height* parameter to each of these functions that does not already
have one;
- ensure that each reference to any of these values, or to PoWTargetSpacing,
are replaced with a function call passing the *height* parameter.
In section 7.7 (Calculation of Block Subsidy and Founders Reward) [later moved
to section 7.8], redefine the Halving and BlockSubsidy functions as follows:
- Halving(*height*) :=
- floor((*height* - SlowStartShift) / PreBlossomHalvingInterval), if not IsBlossomActivated(*height*)
- floor((BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (*height* - BlossomActivationHeight) / PostBlossomHalvingInterval), otherwise
- BlockSubsidy(*height*) :=
- SlowStartRate · *height*, if *height* < SlowStartInterval / 2
- SlowStartRate · (*height* + 1), if SlowStartInterval / 2 ≤ *height* and *height* < SlowStartInterval
- floor(MaxBlockSubsidy / 2\ :sup:`Halving(*height*)`\ ), if SlowStartInterval ≤ *height* and not IsBlossomActivated(*height*)
- floor(MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ )), otherwise
Note: BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTargetSpacing are chosen so that:
- (BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (*height* - BlossomActivationHeight) / PostBlossomHalvingInterval)
is exactly 1 for some integer *height*.
- MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ )
is an integer for the next few periods.
In section 7.8 (Payment of Founders Reward) [later moved to section 7.9], define:
- FounderAddressAdjustedHeight(*height*) :=
- *height*, if not IsBlossomActivated(*height*)
- BlossomActivationHeight + floor((*height* - BlossomActivationHeight) / BlossomPoWTargetSpacingRatio), otherwise
and in the definition of FounderAddressIndex, replace the use of *height* with FounderAddressAdjustedHeight(*height*).
Also define:
- FoundersRewardLastBlockHeight := max({ *height* ⦂ N | Halving(*height*) < 1 })
Replace the first note in that section with:
- No Founders Reward is required to be paid for *height* > FoundersRewardLastBlockHeight
(i.e. after the first halving), or for *height* = 0 (i.e. the genesis block).
and in the second note, replace SlowStartShift + PreBlossomHalvingInterval - 1 with
FoundersRewardLastBlockHeight.
Effect on difficulty adjustment
-------------------------------
The difficulty adjustment parameters PoWAveragingWindow and PoWMedianBlockSpan
refer to numbers of blocks, but do *not* change at Blossom activation. This is
because the amount of damping/averaging required is expected to be roughly the
same, in terms of the number of blocks, after the change in block target
spacing.
The change in the effective value of PoWTargetSpacing will cause the block
spacing to adjust to the new target, at the normal rate for a difficulty
adjustment. The results of simulations are consistent with this expected
behaviour.
Note that the change in AveragingWindowTimespan(height) takes effect
immediately when calculating the target difficulty starting from the block at
the Blossom activation height, even though the difficulty of the preceding
PoWAveragingWindow blocks will have been adjusted using the pre-Blossom target
spacing. Therefore it is likely that the difficulty adjustment for the first
few blocks after activation will be limited by PoWMaxAdjustDown. This is not
anticipated to cause any problem.
Minimum difficulty blocks on Testnet
''''''''''''''''''''''''''''''''''''
On Testnet from block height 299188 onward, the difficulty adjustment algorithm
[#protocol-diffadjustment]_ allows minimum-difficulty blocks, as described in
[#zip-0205]_, when the block time is greater than a given threshold. This
specification changes this threshold to be proportional to the block target
spacing.
That is, if the block time of a block at height *height* ≥ 299188 is greater than
6 · PoWTargetSpacing(*height*) seconds after that of the preceding block,
then the block is a minimum-difficulty block. In that case its ``nBits`` field
MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet
in section 5.3 of the Zcash Protocol Specification [#protocol-constants]_, and
ToCompact is as defined in section 7.7.4 of that specification [#protocol-nbits]_.
Note: a previous revision of this ZIP (and [#zip-0205]_) incorrectly said that
only the target threshold of minimum-difficulty blocks is affected. In fact
the ``nBits`` field is modified as well, and this affects difficulty adjustment
for subsequent blocks.
This change does not affect Mainnet.
Non-consensus node behaviour
----------------------------
End-of-Service halt
'''''''''''''''''''
`zcashd` implements an "End-of-Service halt" behaviour that halts the node at a
block height that corresponds approximately to a given time after release. This
interval SHOULD be adjusted in releases where the End-of-Service halt time will
follow Blossom activation.
Default expiry delta
''''''''''''''''''''
When not overridden by the ``-txexpirydelta`` option, `zcashd` RPC calls that
create transactions use a default value for the number of blocks after which a
transaction will expire. The default in recent versions of `zcashd` is
20 blocks, which at the pre-Blossom block target spacing corresponds to roughly
50 minutes.
This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after
Blossom activation, to maintain the approximate expiry time of 50 minutes.
If the ``-txexpirydelta`` option is set, then the set value SHOULD be used both
before and after Blossom activation.
Sprout to Sapling migration
'''''''''''''''''''''''''''
ZIP 308 [#zip-0308]_ defines a procedure for migrating funds from Sprout to
Sapling z-addresses. In that procedure, migration transactions are sent every
500 blocks, which corresponded to roughly 20.83 hours before Blossom.
The 500-block constant has not been changed. Therefore, migration transactions
are now sent roughly every 10.42 hours after Blossom activation. This has been
noted in the ZIP, and a table showing the expected time to complete migration
has been updated accordingly.
Fingerprinting mitigation
'''''''''''''''''''''''''
A "fingerprinting attack" is a network analysis technique in which nodes are
identified across network sessions, for example using information about which
blocks they request or send.
`zcashd` inherits from Bitcoin Core the following behaviour, described in a
comment in ``main.cpp``, intended as a fingerprinting mitigation::
// To prevent fingerprinting attacks, only send blocks outside of the active
// chain if they are valid, and no more than a month older (both in time, and in
// best equivalent proof of work) than the best header chain we know about.
We make no assertion about the significance of fingerprinting for Zcash,
and (despite the word "prevent" in the above comment) no claim about the
effectiveness of this mitigation.
In any case, to estimate the "best equivalent proof of work" of a given block
chain (measured in units of time), we take the total work of the chain as
defined in section 7.7.5 of the Zcash Protocol Specification [#protocol-workdef]_,
divide by the work of the block at the active tip, and multiply by the target
block spacing of that block.
It is not a requirement of the Zcash protocol that this fingerprinting
mitigation is used; however, if it is used, then it SHOULD use the target
block spacing at the same block height that is used for the current work
estimate.
Monitoring for quicker- or slower-than-expected blocks
''''''''''''''''''''''''''''''''''''''''''''''''''''''
`zcashd` previously did this monitoring every 150 seconds; it is now done
every 60 seconds.
Block timeout
'''''''''''''
The timeout for a requested block is calculated as the target block time,
multiplied by 2 + (the number of queued validated headers)/2.
Latency optimization when requesting blocks
'''''''''''''''''''''''''''''''''''''''''''
When `zcashd` sees an announced block that chains from headers that it does
not already have, it will first ask for the headers, and then the block itself.
A latency optimization is performed only if the chain is "nearly synced"::
// First request the headers preceding the announced block. In the normal fully-synced
// case where a new block is announced that succeeds the current tip (no reorganization),
// there are no such headers.
// Secondly, and only when we are close to being synced, we request the announced block directly,
// to avoid an extra round-trip. Note that we must *first* ask for the headers, so by the
// time the block arrives, the header chain leading up to it is already validated. Not
// doing this will result in the received block being rejected as an orphan in case it is
// not a direct successor.
The heuristic for "nearly synced" is that the timestamp of the block at the active tip
is no more than 20 block times before the current "adjusted time". In `zcashd` this
calculation uses the block target spacing as of the best known header. Around Blossom
activation when the block target spacing changes, this could cause the heuristic to be
based on the pre-Blossom block target spacing until the node has synced headers past the
activation block, but this is not anticipated to cause any problem.
Response to getblocks message when pruning
''''''''''''''''''''''''''''''''''''''''''
If pruning is enabled, when `zcashd` responds to an "getblocks" peer-to-peer message,
it will only include blocks that it has on disk, and is likely to still have on disk
an hour after responding to the message::
// If pruning, don't inv blocks unless we have on disk and are likely to still have
// for some reasonable time window (1 hour) that block relay might require.
For each block, when estimating whether it will still be on disk after an hour, we
take MIN_BLOCKS_TO_KEEP = 288 blocks, minus approximately the number of blocks expected
in one hour at the target block spacing as of that block. Around Blossom activation,
this might underestimate the number of blocks in the next hour, but given the value
of MIN_BLOCKS_TO_KEEP, this is not anticipated to cause any problem.
Estimation of fully synced chain height
'''''''''''''''''''''''''''''''''''''''
`zcashd` uses the ``EstimateNetHeight`` function to estimate the approximate height
of the fully synced chain, so that the progress of block download can be displayed to
the node operator. This function has been rewritten, simplified, and changed to take
account of cases where the time period that needs to be estimated crosses Blossom
activation.
Other block-related constants
'''''''''''''''''''''''''''''
The following constants, measured in number of blocks, were reviewed and a
decision was made not to change them::
/** The number of blocks within expiry height when a tx is considered to be expiring soon */
TX_EXPIRING_SOON_THRESHOLD = 3
/** Maximum reorg length we will accept before we shut down and alert the user. */
MAX_REORG_LENGTH = COINBASE_MATURITY - 1;
static const int COINBASE_MATURITY = 100;
/** Number of blocks that can be requested at any given time from a single peer. */
static const int MAX_BLOCKS_IN_TRANSIT_PER_PEER = 16;
static const unsigned int BLOCK_DOWNLOAD_WINDOW = 1024;
/** Block files containing a block-height within MIN_BLOCKS_TO_KEEP of chainActive.Tip() will not be pruned. */
static const unsigned int MIN_BLOCKS_TO_KEEP = 288;
/**
* The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks).
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
*/
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;
Deployment
==========
This proposal will be deployed with the Blossom network upgrade. [#zip-0206]_
Backward compatibility
======================
This proposal intentionally creates what is known as a "bilateral consensus
rule change". Use of this mechanism requires that all network participants
upgrade their software to a compatible version within the upgrade window.
Older software will treat post-upgrade blocks as invalid, and will follow any
pre-upgrade consensus branch that persists.
Reference Implementation
========================
https://github.com/zcash/zcash/pull/4025
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#preblossom-protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) <https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
.. [#protocol-nbits] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion <protocol/protocol.pdf#nbits>`_
.. [#protocol-workdef] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work <protocol/protocol.pdf#workdef>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_
.. [#zip-0308] `ZIP 308: Sprout to Sapling Migration <zip-0308.rst>`_
.. [#slowfastblocks] `On Slow and Fast Block Times <https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/>`_

77
zip-0209.html Normal file
View File

@ -0,0 +1,77 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 209
Title: Prohibit Negative Shielded Chain Value Pool Balances
Owners: Sean Bowe &lt;sean@electriccoin.co&gt;
Daira Hopwood &lt;daira@electriccoin.co&gt;
Status: Final
Category: Consensus
Created: 2019-02-25
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "block chain" and "network upgrade" are to be interpreted as defined in <a id="id2" class="footnote_reference" href="#zip-0200">3</a>.</p>
<p>The "Sprout chain value pool balance" for a given block chain is the sum of all <code>vpub_old</code> fields for transactions in the block chain, minus the sum of all <code>vpub_new</code> fields for transactions in the block chain.</p>
<p>The "Sapling chain value pool balance" for a given block chain is the negation of the sum of all <code>valueBalanceSapling</code> fields for transactions in the block chain.</p>
<p>The "Orchard chain value pool balance" for a given block chain is the negation of the sum of all <code>valueBalanceOrchard</code> fields for transactions in the block chain. (Before NU5 has activated, the Orchard chain value pool balance is zero.)</p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines how the consensus rules are altered such that blocks that produce negative shielded chain value pool balances are prohibited.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>It is possible for nodes to monitor the total value of notes that are shielded to, or unshielded from, each of the Sprout, Sapling, and Orchard value pools. If the total value that is unshielded exceeds the total value that was shielded for a given pool, a balance violation has occurred in the corresponding shielded transaction protocol.</p>
<p>It would be preferable for the network to reject blocks that result in the aforementioned balance violation. However, nodes do not currently react to such an event. Remediation may therefore require chain rollbacks and other disruption.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>If any of the "Sprout chain value pool balance", "Sapling chain value pool balance", or "Orchard chain value pool balance" would become negative in the block chain created as a result of accepting a block, then all nodes MUST reject the block as invalid.</p>
<p>Nodes MAY relay transactions even if one or more of them cannot be mined due to the aforementioned restriction.</p>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 <a id="id4" class="footnote_reference" href="#zip-0200">3</a> and there is no mechanism by which the network will synchronize to enforce this rule. Rather, all nodes SHOULD begin enforcing this consensus rule upon acceptance of this proposal.</p>
<p>There is a risk that before all nodes on the network begin enforcing this consensus rule that block(s) will be produced that violate it, potentially leading to network fragmentation. This is considered sufficiently unlikely that the benefits of enforcing this consensus rule sooner are overwhelming.</p>
<p>This specification was deployed in zcashd v2.0.4 for Testnet, and in zcashd v2.0.5 for Mainnet. The application to the Orchard chain value pool balance will be deployed from NU5 activation <a id="id5" class="footnote_reference" href="#zip-0252">4</a>.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 or later. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0252" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

89
zip-0209.rst Normal file
View File

@ -0,0 +1,89 @@
::
ZIP: 209
Title: Prohibit Negative Shielded Chain Value Pool Balances
Owners: Sean Bowe <sean@electriccoin.co>
Daira Hopwood <daira@electriccoin.co>
Status: Final
Category: Consensus
Created: 2019-02-25
License: MIT
Terminology
===========
The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in
RFC 2119. [#RFC2119]_
The term "block chain" and "network upgrade" are to be interpreted as defined in [#zip-0200]_.
The "Sprout chain value pool balance" for a given block chain is the sum of all ``vpub_old``
fields for transactions in the block chain, minus the sum of all ``vpub_new`` fields for
transactions in the block chain.
The "Sapling chain value pool balance" for a given block chain is the negation of the sum of all
``valueBalanceSapling`` fields for transactions in the block chain.
The "Orchard chain value pool balance" for a given block chain is the negation of the sum of all
``valueBalanceOrchard`` fields for transactions in the block chain. (Before NU5 has activated,
the Orchard chain value pool balance is zero.)
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the
Zcash Protocol Specification [#protocol-networks]_.
Abstract
========
This proposal defines how the consensus rules are altered such that blocks that produce negative
shielded chain value pool balances are prohibited.
Motivation
==========
It is possible for nodes to monitor the total value of notes that are shielded to, or unshielded from,
each of the Sprout, Sapling, and Orchard value pools. If the total value that is unshielded exceeds the
total value that was shielded for a given pool, a balance violation has occurred in the corresponding
shielded transaction protocol.
It would be preferable for the network to reject blocks that result in the aforementioned balance violation.
However, nodes do not currently react to such an event. Remediation may therefore require chain rollbacks
and other disruption.
Specification
=============
If any of the "Sprout chain value pool balance", "Sapling chain value pool balance", or
"Orchard chain value pool balance" would become negative in the block chain created as a result of
accepting a block, then all nodes MUST reject the block as invalid.
Nodes MAY relay transactions even if one or more of them cannot be mined due to the aforementioned
restriction.
Deployment
==========
This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 [#zip-0200]_
and there is no mechanism by which the network will synchronize to enforce this rule. Rather, all
nodes SHOULD begin enforcing this consensus rule upon acceptance of this proposal.
There is a risk that before all nodes on the network begin enforcing this consensus rule that block(s)
will be produced that violate it, potentially leading to network fragmentation. This is considered
sufficiently unlikely that the benefits of enforcing this consensus rule sooner are overwhelming.
This specification was deployed in zcashd v2.0.4 for Testnet, and in zcashd v2.0.5 for Mainnet.
The application to the Orchard chain value pool balance will be deployed from NU5 activation
[#zip-0252]_.
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 or later. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`_

96
zip-0210.html Normal file
View File

@ -0,0 +1,96 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 210: Sapling Anchor Deduplication within Transactions</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 210
Title: Sapling Anchor Deduplication within Transactions
Owners: Jack Grigg &lt;str4d@electriccoin.co&gt;
Status: Withdrawn
Category: Consensus
Created: 2019-03-27
License: MIT</pre>
<section id="status"><h2><span class="section-heading">Status</span><span class="section-anchor"> <a rel="bookmark" href="#status"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP has been withdrawn because a similar change has been incorporated into the ZIP 225 proposal for a version 5 transaction format. <a id="id1" class="footnote_reference" href="#zip-0225">5</a></p>
</section>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id2" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id3" class="footnote_reference" href="#zip-0200">3</a>.</p>
<p>The term "Sapling" in this document is to be interpreted as described in ZIP 205 <a id="id4" class="footnote_reference" href="#zip-0205">4</a>.</p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a modification to the transaction format whereby a single Sapling anchor is used for all Sapling spends. This change removes a potential implementation fingerprint, and reduces the size of Sapling transactions within the block chain.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Sapling network upgrade <a id="id5" class="footnote_reference" href="#zip-0205">4</a> introduced new shielded inputs (spends) and outputs. Each spend proves the existence of the note being spent by including the anchor of a Merkle tree that contains the note's commitment, and proving in zero knowledge the existence of a path from the commitment to the anchor (a witness). Valid anchors correspond to the state of the Sapling commitment tree after each block in the chain.</p>
<p>The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. However, the Sapling v4 transaction format <a id="id6" class="footnote_reference" href="#protocol-txnencoding">2</a> includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.</p>
<p>Modifying the transaction format to have a single Sapling anchor field, instead of one field per Sapling spend, removes the ability (within the new transaction format version) to create transactions with this fingerprint. It also reduces the size of the transaction, costing 32 bytes per transaction instead of 32 bytes per spend.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>A new transaction format is defined, identical to the Sapling v4 transaction format except for two changes:</p>
<ul>
<li>The <code>anchor</code> field in <code>SpendDescription</code> is removed.</li>
<li>A new field <code>saplingAnchor</code> is placed between <code>vShieldedOutput</code> and <code>vJoinSplit</code>, if and only if <code>vShieldedSpend</code> is not empty.</li>
</ul>
<p>Consensus rules that previously applied to individual <code>anchor</code> entries MUST be applied to <code>saplingAnchor</code>.</p>
<p>TODO: If this is the only ZIP updating the transaction format in a NU, specify the full transaction format here. Otherwise, reference the new transaction format when specified.</p>
<p>Implementations that support older transaction formats MAY copy <code>saplingAnchor</code> into each spend's in-memory representation during parsing to reduce code duplication, and MUST ensure that these per-spend in-memory anchors are all identical prior to serialization.</p>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Placing the <code>saplingAnchor</code> field after <code>vShieldedOutput</code> means that it can be conditionally included (saving space when there are no Sapling spends), while ensuring that the transaction can still be parsed unambiguously.</p>
<p>Requiring all Sapling spends to use the same anchor removes a possible performance optimisation in certain classes of (particularly light) wallets, where witnesses for older notes are only updated periodically instead of every block. This optimisation is exactly the kind of behaviour that can be used as a fingerprint in the v4 transaction format, and that we are choosing to prevent with this proposal.</p>
</section>
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal eliminates a possible avenue for distinguishing transactions based on the client implementation that created them.</p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TBD</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencoding" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0205" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zip-0225" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0225">ZIP 225: Version 5 Transaction Format</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

119
zip-0210.rst Normal file
View File

@ -0,0 +1,119 @@
::
ZIP: 210
Title: Sapling Anchor Deduplication within Transactions
Owners: Jack Grigg <str4d@electriccoin.co>
Status: Withdrawn
Category: Consensus
Created: 2019-03-27
License: MIT
Status
======
This ZIP has been withdrawn because a similar change has been incorporated into the
ZIP 225 proposal for a version 5 transaction format. [#zip-0225]_
Terminology
===========
The key words "MUST" and "MAY" in this document are to be interpreted as described in
RFC 2119. [#RFC2119]_
The term "network upgrade" in this document is to be interpreted as described in ZIP 200
[#zip-0200]_.
The term "Sapling" in this document is to be interpreted as described in ZIP 205
[#zip-0205]_.
Abstract
========
This proposal defines a modification to the transaction format whereby a single Sapling
anchor is used for all Sapling spends. This change removes a potential implementation
fingerprint, and reduces the size of Sapling transactions within the block chain.
Motivation
==========
The Sapling network upgrade [#zip-0205]_ introduced new shielded inputs (spends) and
outputs. Each spend proves the existence of the note being spent by including the anchor
of a Merkle tree that contains the note's commitment, and proving in zero knowledge the
existence of a path from the commitment to the anchor (a witness). Valid anchors
correspond to the state of the Sapling commitment tree after each block in the chain.
The choice of anchor leaks information about the note being spent, namely that the note
was created no later than the anchor's block height. This is an unavoidable outcome of the
Zcash design, and the least information it is possible to leak about a note being spent.
However, the Sapling v4 transaction format [#protocol-txnencoding]_ includes
a separate anchor for each Sapling spend, and thus it is possible to leak additional
information by using different anchors for different notes. The anchor selection choices
could also be used as a fingerprint to identify transactions created by particular wallet
implementations, reducing the privacy set.
Modifying the transaction format to have a single Sapling anchor field, instead of one
field per Sapling spend, removes the ability (within the new transaction format version)
to create transactions with this fingerprint. It also reduces the size of the transaction,
costing 32 bytes per transaction instead of 32 bytes per spend.
Specification
=============
A new transaction format is defined, identical to the Sapling v4 transaction format
except for two changes:
- The ``anchor`` field in ``SpendDescription`` is removed.
- A new field ``saplingAnchor`` is placed between ``vShieldedOutput`` and ``vJoinSplit``,
if and only if ``vShieldedSpend`` is not empty.
Consensus rules that previously applied to individual ``anchor`` entries MUST be applied
to ``saplingAnchor``.
TODO: If this is the only ZIP updating the transaction format in a NU, specify the full
transaction format here. Otherwise, reference the new transaction format when specified.
Implementations that support older transaction formats MAY copy ``saplingAnchor`` into
each spend's in-memory representation during parsing to reduce code duplication, and MUST
ensure that these per-spend in-memory anchors are all identical prior to serialization.
Rationale
=========
Placing the ``saplingAnchor`` field after ``vShieldedOutput`` means that it can be
conditionally included (saving space when there are no Sapling spends), while ensuring
that the transaction can still be parsed unambiguously.
Requiring all Sapling spends to use the same anchor removes a possible performance
optimisation in certain classes of (particularly light) wallets, where witnesses for older
notes are only updated periodically instead of every block. This optimisation is exactly
the kind of behaviour that can be used as a fingerprint in the v4 transaction format, and
that we are choosing to prevent with this proposal.
Security and Privacy Considerations
===================================
This proposal eliminates a possible avenue for distinguishing transactions based on the
client implementation that created them.
Reference Implementation
========================
TBD
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0225] `ZIP 225: Version 5 Transaction Format <zip-0225.rst>`_

140
zip-0211.html Normal file
View File

@ -0,0 +1,140 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 211
Title: Disabling Addition of New Value to the Sprout Chain Value Pool
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Credits: Sean Bowe
Status: Final
Category: Consensus
Created: 2019-03-29
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "SHOULD", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">3</a>.</p>
<p>The term "Sprout shielded protocol" in this document refers to the shielded payment protocol defined at the launch of the Zcash network.</p>
<p>The term "Sapling shielded protocol" in this document refers to the shielded payment protocol introduced in the Sapling network upgrade <a id="id3" class="footnote_reference" href="#zip-0205">4</a> <a id="id4" class="footnote_reference" href="#protocol">2</a>.</p>
<p>The term "Sprout chain value pool balance" in this document is to be interpreted as described in ZIP 209 <a id="id5" class="footnote_reference" href="#zip-0209">5</a>.</p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal disables the ability to add new value to the Sprout chain value pool balance. This takes a step toward being able to remove the Sprout shielded protocol, thus reducing the overall complexity and attack surface of Zcash.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The first iteration of the Zcash network, called Sprout, provided a shielded payment protocol that was relatively closely based on the original Zerocash proposal. <a id="id6" class="footnote_reference" href="#zerocash">8</a></p>
<p>The Sapling network upgrade <a id="id7" class="footnote_reference" href="#zip-0205">4</a> introduced significant efficiency and functionality improvements for shielded transactions. It is expected that over time, the use of Sapling will replace the use of Sprout in shielded transactions.</p>
<p>The Sapling and Sprout shielded protocols employ different cryptographic designs. Since an adversary could potentially exploit any vulnerability in either design, supporting both presents additional risk over supporting only the newer Sapling shielded protocol.</p>
<p>For example, a vulnerability was discovered in the zero-knowledge proving system originally used by Zcash that could have allowed counterfeiting <a id="id8" class="footnote_reference" href="#counterfeiting">9</a>. While this particular vulnerability was addressed (also for Sprout shielded transactions) by the Sapling upgrade, and we are not aware of others at the time of writing, the possibility of other cryptographic weaknesses cannot be entirely ruled out.</p>
<p>In addition, the Zcash specification and implementation incurs complexity and "technical debt" from the requirement to support and test both shielded payment protocols.</p>
<p>Removing the ability to add to the Sprout chain value pool balance, is a first step toward reducing this complexity and potential risk. This does not prevent extracting value held in Sprout addresses and sending it to transparent addresses, or to Sapling addresses via the migration tool <a id="id9" class="footnote_reference" href="#zip-0308">7</a>.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Consensus rule: From the relevant activation height, the <code>vpub_old</code> field of each JoinSplit description MUST be zero.</p>
<p>When this proposal is activated, nodes and wallets MUST disable any facilities to create transactions that have both one or more outputs to Sprout addresses, and one or more inputs from non-Sprout addresses. This SHOULD be made clear in user interfaces and API documentation.</p>
<p>Notes:</p>
<ul>
<li>The requirement on wallets is intentionally slightly stronger than that enforced by the consensus rule. It is possible to construct a mixed transaction with inputs from both Sprout and non-Sprout addresses, in which all <code>vpub_old</code> fields are zero, but there are nevertheless sufficient funds from Sprout inputs to balance the Sprout outputs. This is prohibited for usability reasons, but not by consensus.</li>
<li>The facility to send to Sprout addresses, even before activation of this proposal, is OPTIONAL for a particular node or wallet implementation.</li>
</ul>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This design does not require any change to the JoinSplit circuit, thus minimizing the risk of security regressions, and avoiding the need for a new ceremony to generate circuit parameters.</p>
<p>The code changes needed are very small and simple, and their security is easy to analyse.</p>
<p>During the development of this proposal, alternative designs were considered that would have removed some fields of a JoinSplit description. These alternatives were abandoned for several reasons:</p>
<ul>
<li>Privacy concerns raised as a consequence of preventing the use of internal change between JoinSplits, and/or change sent back to the input Sprout addresses. This would have required the total value of the input Sprout notes (or, for some considered designs, the total value of the two Sprout inputs to each JoinSplit) to be leaked. As it is, there is an unavoidable leak of the total value extracted from the Sprout value pool, but not of the sum of values of particular subsets of notes.</li>
<li>Modifications would have been needed to the design of the Sprout to Sapling migration procedure described in <a id="id10" class="footnote_reference" href="#zip-0308">7</a>.</li>
<li>A new transaction version would have been required.</li>
</ul>
</section>
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The security motivations for making this change are described in the Motivation section. Privacy concerns that led to the current design are discussed in the Rationale section.</p>
<p>Since all clients change their behaviour at the same time from this proposal's activation height, there is no additional client distinguisher.</p>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Canopy network upgrade. <a id="id11" class="footnote_reference" href="#zip-0251">6</a></p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p><a href="https://github.com/zcash/zcash/pull/4489">https://github.com/zcash/zcash/pull/4489</a></p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0205" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0205">ZIP 205: Deployment of the Sapling Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zip-0209" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0209">ZIP 209: Prohibit Negative Shielded Value Pool</a></td>
</tr>
</tbody>
</table>
<table id="zip-0251" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zip-0308" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="zip-0308">ZIP 308: Sprout to Sapling Migration</a></td>
</tr>
</tbody>
</table>
<table id="zerocash" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="https://eprint.iacr.org/2014/349">Zerocash: Decentralized Anonymous Payments from Bitcoin (extended version)</a></td>
</tr>
</tbody>
</table>
<table id="counterfeiting" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/">Zcash Counterfeiting Vulnerability Successfully Remediated</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

154
zip-0211.rst Normal file
View File

@ -0,0 +1,154 @@
::
ZIP: 211
Title: Disabling Addition of New Value to the Sprout Chain Value Pool
Owners: Daira Hopwood <daira@electriccoin.co>
Credits: Sean Bowe
Status: Final
Category: Consensus
Created: 2019-03-29
License: MIT
Terminology
===========
The key words "MUST", "SHOULD", and "OPTIONAL" in this document are to be interpreted
as described in RFC 2119. [#RFC2119]_
The term "network upgrade" in this document is to be interpreted as described in ZIP 200
[#zip-0200]_.
The term "Sprout shielded protocol" in this document refers to the shielded payment protocol
defined at the launch of the Zcash network.
The term "Sapling shielded protocol" in this document refers to the shielded payment protocol
introduced in the Sapling network upgrade [#zip-0205]_ [#protocol]_.
The term "Sprout chain value pool balance" in this document is to be interpreted as described
in ZIP 209 [#zip-0209]_.
Abstract
========
This proposal disables the ability to add new value to the Sprout chain value pool balance.
This takes a step toward being able to remove the Sprout shielded protocol, thus reducing
the overall complexity and attack surface of Zcash.
Motivation
==========
The first iteration of the Zcash network, called Sprout, provided a shielded payment
protocol that was relatively closely based on the original Zerocash proposal. [#zerocash]_
The Sapling network upgrade [#zip-0205]_ introduced significant efficiency and
functionality improvements for shielded transactions. It is expected that over time,
the use of Sapling will replace the use of Sprout in shielded transactions.
The Sapling and Sprout shielded protocols employ different cryptographic designs.
Since an adversary could potentially exploit any vulnerability in either design,
supporting both presents additional risk over supporting only the newer Sapling shielded
protocol.
For example, a vulnerability was discovered in the zero-knowledge proving system
originally used by Zcash that could have allowed counterfeiting [#counterfeiting]_.
While this particular vulnerability was addressed (also for Sprout shielded transactions)
by the Sapling upgrade, and we are not aware of others at the time of writing, the
possibility of other cryptographic weaknesses cannot be entirely ruled out.
In addition, the Zcash specification and implementation incurs complexity and
"technical debt" from the requirement to support and test both shielded payment
protocols.
Removing the ability to add to the Sprout chain value pool balance, is a first step
toward reducing this complexity and potential risk. This does not prevent extracting value
held in Sprout addresses and sending it to transparent addresses, or to Sapling addresses
via the migration tool [#zip-0308]_.
Specification
=============
Consensus rule: From the relevant activation height, the ``vpub_old`` field of each
JoinSplit description MUST be zero.
When this proposal is activated, nodes and wallets MUST disable any facilities to create
transactions that have both one or more outputs to Sprout addresses, and one or more
inputs from non-Sprout addresses. This SHOULD be made clear in user interfaces and API
documentation.
Notes:
* The requirement on wallets is intentionally slightly stronger than that enforced
by the consensus rule. It is possible to construct a mixed transaction with inputs
from both Sprout and non-Sprout addresses, in which all ``vpub_old`` fields are zero,
but there are nevertheless sufficient funds from Sprout inputs to balance the Sprout
outputs. This is prohibited for usability reasons, but not by consensus.
* The facility to send to Sprout addresses, even before activation of this proposal,
is OPTIONAL for a particular node or wallet implementation.
Rationale
=========
This design does not require any change to the JoinSplit circuit, thus minimizing
the risk of security regressions, and avoiding the need for a new ceremony to generate
circuit parameters.
The code changes needed are very small and simple, and their security is easy to
analyse.
During the development of this proposal, alternative designs were considered that
would have removed some fields of a JoinSplit description. These alternatives were
abandoned for several reasons:
* Privacy concerns raised as a consequence of preventing the use of internal change
between JoinSplits, and/or change sent back to the input Sprout addresses. This
would have required the total value of the input Sprout notes (or, for some considered
designs, the total value of the two Sprout inputs to each JoinSplit) to be leaked.
As it is, there is an unavoidable leak of the total value extracted from the Sprout
value pool, but not of the sum of values of particular subsets of notes.
* Modifications would have been needed to the design of the Sprout to Sapling migration
procedure described in [#zip-0308]_.
* A new transaction version would have been required.
Security and Privacy Considerations
===================================
The security motivations for making this change are described in the Motivation section.
Privacy concerns that led to the current design are discussed in the Rationale section.
Since all clients change their behaviour at the same time from this proposal's activation
height, there is no additional client distinguisher.
Deployment
==========
This proposal will be deployed with the Canopy network upgrade. [#zip-0251]_
Reference Implementation
========================
https://github.com/zcash/zcash/pull/4489
References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Value Pool <zip-0209.rst>`_
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_
.. [#zip-0308] `ZIP 308: Sprout to Sapling Migration <zip-0308.rst>`_
.. [#zerocash] `Zerocash: Decentralized Anonymous Payments from Bitcoin (extended version) <https://eprint.iacr.org/2014/349>`_
.. [#counterfeiting] `Zcash Counterfeiting Vulnerability Successfully Remediated <https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/>`_

446
zip-0212.html Normal file
View File

@ -0,0 +1,446 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext</title>
<meta charset="utf-8" />
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 212
Title: Allow Recipient to Derive Ephemeral Secret from Note Plaintext
Owners: Sean Bowe &lt;sean@electriccoin.co&gt;
Status: Final
Category: Consensus
Created: 2019-03-31
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The following functions are defined in the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol">2</a> according to the type (Sapling or Orchard) of note plaintext being processed:</p>
<ul>
<li>let
<span class="math">\(\mathsf{ToScalar}\)</span>
be
<span class="math">\(\mathsf{ToScalar^{Sapling}}\)</span>
defined in section 4.2.2 <a id="id3" class="footnote_reference" href="#protocol-saplingkeycomponents">5</a> or
<span class="math">\(\mathsf{ToScalar^{Orchard}}\)</span>
defined in section 4.2.3 <a id="id4" class="footnote_reference" href="#protocol-orchardkeycomponents">6</a>;</li>
<li>let
<span class="math">\(\mathsf{DiversifyHash}\)</span>
be
<span class="math">\(\mathsf{DiversifyHash^{Sapling}}\)</span>
or
<span class="math">\(\mathsf{DiversifyHash^{Orchard}}\)</span>
defined in section 5.4.1.6 <a id="id5" class="footnote_reference" href="#protocol-concretediversifyhash">12</a>;</li>
<li>let
<span class="math">\(\mathsf{KA}\)</span>
be
<span class="math">\(\mathsf{KA^{Sapling}}\)</span>
defined in section 5.4.5.3 <a id="id6" class="footnote_reference" href="#protocol-concretesaplingkeyagreement">13</a> or
<span class="math">\(\mathsf{KA^{Orchard}}\)</span>
defined in section 5.4.5.5 <a id="id7" class="footnote_reference" href="#protocol-concreteorchardkeyagreement">14</a>;</li>
<li>let
<span class="math">\(\mathsf{NoteCommit}\)</span>
be
<span class="math">\(\mathsf{NoteCommit^{Sapling}}\)</span>
or
<span class="math">\(\mathsf{NoteCommit^{Orchard}}\)</span>
defined in section 4.1.8 <a id="id8" class="footnote_reference" href="#protocol-abstractcommit">4</a>.</li>
</ul>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP proposes a new note plaintext format for Sapling Outputs (later extended to include Orchard Actions) in transactions. The new format allows recipients to verify that the sender of an Output or Action knows the private key corresponding to the ephemeral Diffie-Hellman key, in order to avoid an assumption on zk-SNARK soundness for preventing diversified address linkability.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Sapling and Orchard payment protocols have a feature called "diversified addresses" which allows a single incoming viewing key to receive payments on an enormous number of distinct and unlinkable payment addresses. This feature allows users to maintain many payment addresses without paying additional overhead during blockchain scanning.</p>
<p>The feature works by allowing payment addresses to become a tuple
<span class="math">\((\mathsf{pk_d}, \mathsf{d})\)</span>
of a public key
<span class="math">\(\mathsf{pk_d}\)</span>
and
<span class="math">\(88\)</span>
-bit diversifier
<span class="math">\(\mathsf{d}\)</span>
such that
<span class="math">\(\mathsf{pk_d} = [\mathsf{ivk}]\, \mathsf{DiversifyHash}(\mathsf{d})\)</span>
for some incoming viewing key
<span class="math">\(\mathsf{ivk}\)</span>
. The hash function
<span class="math">\(\mathsf{DiversifyHash}(\mathsf{d})\)</span>
maps from a diversifier to prime-order elements of the Jubjub or Pallas elliptic curve. It is possible for a user to choose many
<span class="math">\(\mathsf{d}\)</span>
to create several distinct and unlinkable payment addresses of this form.</p>
<p>In order to make a payment to a Sapling or Orchard address, an ephemeral secret
<span class="math">\(\mathsf{esk}\)</span>
is sampled by the sender and an ephemeral public key
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{DiversifyHash}(\mathsf{d})\)</span>
is included in the Output or Action description. Then, a shared Diffie-Hellman secret is computed by the sender as
<span class="math">\(\mathsf{KA.Agree}(\mathsf{esk}, \mathsf{pk_d})\)</span>
. The recipient can recover this shared secret without knowledge of the particular
<span class="math">\(\mathsf{d}\)</span>
by computing
<span class="math">\(\mathsf{KA.Agree}(\mathsf{ivk}, \mathsf{epk})\)</span>
. This shared secret is then used as part of note decryption.</p>
<p>Naïvely, the recipient cannot know which
<span class="math">\((\mathsf{pk_d}, \mathsf{d})\)</span>
was used to compute the shared secret, but the sender is asked to include the
<span class="math">\(\mathsf{d}\)</span>
within the note plaintext to reconstruct the note. However, if the recipient has more than one known address, an attacker could use a different payment address to perform secret exchange and, by observing the behavior of the recipient, link the two diversified addresses together. (This attacker strategy was discovered by Brian Warner earlier in the design of the Sapling protocol.)</p>
<p>In order to prevent this attack, before activation of this ZIP the protocol forced the sender to prove knowledge of the discrete logarithm of
<span class="math">\(\mathsf{epk}\)</span>
with respect to the
<span class="math">\(\mathsf{g_d} = \mathsf{DiversifyHash}(\mathsf{d})\)</span>
included within the note commitment. This
<span class="math">\(\mathsf{g_d}\)</span>
is determined by
<span class="math">\(\mathsf{d}\)</span>
and recomputed during note decryption, and so either the note decryption will fail, or the sender will be unable to produce the proof that requires knowledge of the discrete logarithm.</p>
<p>However, the latter proof was part of the Sapling Output statement, and so relied on the soundness of the underlying Groth16 zk-SNARK — hence on relatively strong cryptographic assumptions and a trusted setup. It is preferable to force the sender to transfer sufficient information in the note plaintext to allow deriving
<span class="math">\(\mathsf{esk}\)</span>
, so that, during note decryption, the recipient can check that
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\)</span>
for the expected
<span class="math">\(\mathsf{g_d}\)</span>
, and ignore the payment as invalid otherwise. For Sapling, this forms a line of defense in the case that soundness of the zk-SNARK does not hold. For Orchard, this check is essential because (for efficiency and simplicity)
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\)</span>
is <em>not</em> checked in the Action statement.</p>
<p>Merely sending
<span class="math">\(\mathsf{esk}\)</span>
to the recipient in the note plaintext would require us to enlarge the note plaintext, but also would compromise the proof of IND-CCA2 security for in-band secret distribution. We avoid both of these concerns by using a key derivation to obtain both
<span class="math">\(\mathsf{esk}\)</span>
and
<span class="math">\(\mathsf{rcm}\)</span>
.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The specification in this ZIP is intended to be aligned with version 2021.2.16 or later of the Zcash Protocol Specification <a id="id9" class="footnote_reference" href="#protocol">2</a>.</p>
<p>Pseudo random functions (PRFs) are defined in section 4.1.2 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-abstractprfs">3</a>. We will be adapting
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
for the purposes of this ZIP. This function is keyed by a 256-bit key
<span class="math">\(\mathsf{sk}\)</span>
and takes an arbitrary length byte sequence as input, returning a
<span class="math">\(64\)</span>
-byte sequence as output.</p>
<section id="changes-to-sapling-and-orchard-note-plaintexts"><h3><span class="section-heading">Changes to Sapling and Orchard Note plaintexts</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-sapling-and-orchard-note-plaintexts"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification <a id="id11" class="footnote_reference" href="#protocol-notept">15</a>. Before activation of this ZIP, the encoding of a Sapling note plaintext required that the first byte take the form
<span class="math">\(\mathtt{0x01}\)</span>
, indicating the version of the note plaintext. In addition, a
<span class="math">\(256\)</span>
-bit
<span class="math">\(\mathsf{rcm}\)</span>
field exists within the note plaintext and encoding.</p>
<p>Following the activation of this ZIP, senders of Sapling or Orchard notes MUST use the following note plaintext format:</p>
<ul>
<li>The first byte of the encoding MUST take the form
<span class="math">\(\mathtt{0x02}\)</span>
(representing the new note plaintext version).</li>
<li>The field
<span class="math">\(\mathsf{rcm}\)</span>
of the encoding is renamed to
<span class="math">\(\mathsf{rseed}\)</span>
. This field
<span class="math">\(\mathsf{rseed}\)</span>
of the Sapling or Orchard note plaintext no longer takes the type of
<span class="math">\(\mathsf{NoteCommit.Trapdoor}\)</span>
(as it did for Sapling) but instead is a
<span class="math">\(32\)</span>
-byte sequence.</li>
</ul>
<p>The requirement that the former
<span class="math">\(\mathsf{rcm}\)</span>
field be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from descriptions of note plaintexts in the Zcash Protocol Specification.</p>
</section>
<section id="changes-to-the-process-of-sending-sapling-or-orchard-notes"><h3><span class="section-heading">Changes to the process of sending Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-sending-sapling-or-orchard-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The process of sending notes is described in section 4.7.2 of the Zcash Protocol Specification for Sapling <a id="id12" class="footnote_reference" href="#protocol-saplingsend">7</a> and section 4.7.3 for Orchard <a id="id13" class="footnote_reference" href="#protocol-orchardsend">8</a>. In addition, the process of encrypting a note is described (currently) in section 4.19.1 of the Zcash Protocol Specification <a id="id14" class="footnote_reference" href="#protocol-saplingandorchardencrypt">9</a>. Prior to activation of this ZIP, the sender sampled
<span class="math">\(\mathsf{rcm^{new}}\)</span>
and the ephemeral private key
<span class="math">\(\mathsf{esk}\)</span>
uniformly at random during this process.</p>
<p>After the activation of this ZIP, the sender MUST instead sample a uniformly random
<span class="math">\(32\)</span>
-byte sequence
<span class="math">\(\mathsf{rseed}\)</span>
. The note plaintext takes
<span class="math">\(\mathsf{rseed}\)</span>
in place of
<span class="math">\(\mathsf{rcm^{new}}\)</span>
.</p>
<p>For Sapling:</p>
<ul>
<li>
<span class="math">\(\mathsf{rcm^{new}}\)</span>
MUST be computed by the sender as the output of
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))\)</span>
.</li>
<li>
<span class="math">\(\mathsf{esk}\)</span>
MUST be computed by the sender as the output of
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\)</span>
.</li>
</ul>
<p>For Orchard, an encoding of ρ is appended to these PRF inputs, as specified in section 4.7.3 of the Zcash Protocol Specification <a id="id15" class="footnote_reference" href="#protocol-orchardsend">8</a>.</p>
</section>
<section id="changes-to-the-process-of-receiving-sapling-or-orchard-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling or Orchard notes</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-the-process-of-receiving-sapling-or-orchard-notes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The process of receiving notes in Sapling is described in sections 4.19.2 and 4.19.3 of the Zcash Protocol Specification. <a id="id16" class="footnote_reference" href="#protocol-decryptivk">10</a> <a id="id17" class="footnote_reference" href="#protocol-decryptovk">11</a></p>
<p>There is a "grace period" of 32256 blocks starting from the block at which this ZIP activates, during which note plaintexts with lead byte
<span class="math">\(\mathtt{0x01}\)</span>
MUST still be accepted.</p>
<p>Let ActivationHeight be the activation height of this ZIP, and let GracePeriodEndHeight be ActivationHeight + 32256.</p>
<p>The height of a transaction in a mined block is defined as the height of that block. An implementation MAY also decrypt mempool transactions, in which case the height used is the height of the next block at the time of the check. An implementation SHOULD NOT attempt to decrypt mempool transactions without having obtained a best-effort view of the current block chain height.</p>
<p>When the recipient of a note (either using an incoming viewing key or a full viewing key) is able to decrypt a note plaintext, it performs the following check on the plaintext lead byte, based on the height of the containing transaction:</p>
<ul>
<li>If the height is less than ActivationHeight, then only
<span class="math">\(\mathtt{0x01}\)</span>
is accepted as the plaintext lead byte.</li>
<li>If the height is at least ActivationHeight and less than GracePeriodEndHeight, then either
<span class="math">\(\mathtt{0x01}\)</span>
or
<span class="math">\(\mathtt{0x02}\)</span>
is accepted as the plaintext lead byte.</li>
<li>If the height is at least GracePeriodEndHeight, then only
<span class="math">\(\mathtt{0x02}\)</span>
is accepted as the plaintext lead byte.</li>
</ul>
<p>If the plaintext lead byte is not accepted then the note MUST be discarded. However, if an implementation decrypted the note from a mempool transaction and it was accepted at that time, but it is later mined in a block after the end of the grace period, then it MAY be retained.</p>
<p>A note plaintext with lead byte
<span class="math">\(\mathtt{0x02}\)</span>
contains a field
<span class="math">\(\mathsf{rseed}\)</span>
that is a
<span class="math">\(32\)</span>
-byte sequence rather than a scalar value
<span class="math">\(\mathsf{rcm}\)</span>
. The recipient, during decryption and in any later contexts, will interpret the value
<span class="math">\(\mathsf{rcm}\)</span>
as the output of
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))\)</span>
in the case of Sapling. Further, the recipient MUST compute
<span class="math">\(\mathsf{esk}\)</span>
as
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\)</span>
in the case of Sapling, and check that
<span class="math">\(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\)</span>
, failing decryption if this check is not satisfied. For Orchard, an encoding of ρ is appended to the PRF inputs, as for encryption.</p>
</section>
<section id="consensus-rule-change-for-coinbase-transactions"><h3><span class="section-heading">Consensus rule change for coinbase transactions</span><span class="section-anchor"> <a rel="bookmark" href="#consensus-rule-change-for-coinbase-transactions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in <a id="id18" class="footnote_reference" href="#zip-0213">17</a>, MUST have note plaintext lead byte equal to
<span class="math">\(\mathtt{0x02}\)</span>
.</p>
<p>This applies even during the “grace period”, and also applies to funding stream outputs <a id="id19" class="footnote_reference" href="#zip-0207">16</a> sent to shielded payment addresses, if there are any.</p>
<p>Since NU5 activates after the end of the grace period <a id="id20" class="footnote_reference" href="#zip-0252">19</a>, Orchard outputs will always require a note plaintext lead byte equal to
<span class="math">\(\mathtt{0x02}\)</span>
.</p>
</section>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The attack that this prevents is an interactive attack that requires an adversary to be able to break critical soundness properties of the zk-SNARKs underlying Sapling. It is potentially valid to assume that this cannot occur, due to other damaging effects on the system such as undetectable counterfeiting. However, we have attempted to avoid any instance in the protocol where privacy (even against interactive attacks) depended on strong cryptographic assumptions. Acting differently here would be confusing for users that have previously been told that "privacy does not depend on zk-SNARK soundness" or similar claims.</p>
<p>It is possible for us to infringe on the length of the <code>memo</code> field and ask the sender to provide
<span class="math">\(\mathsf{esk}\)</span>
within the existing note plaintext without modifying the transaction format, but this would harm users who have come to expect a
<span class="math">\(512\)</span>
-byte memo field to be available to them. Changes to the memo field length should be considered in a broader context than changes made for cryptographic purposes.</p>
<p>It is possible to transmit a signature of knowledge of a correct
<span class="math">\(\mathsf{esk}\)</span>
rather than
<span class="math">\(\mathsf{esk}\)</span>
itself, but this appears to be an unnecessary complication and is likely slower than just supplying
<span class="math">\(\mathsf{esk}\)</span>
.</p>
<p>The grace period is intended to mitigate loss-of-funds risk due to non-conformant sending wallet implementations. The intention is that during the grace period (of about 4 weeks), it will be possible to identify wallets that are still sending plaintexts according to the old specification, and cajole their developers to make the required updates. For the avoidance of doubt, such wallets are non-conformant because it is a "MUST" requirement to <em>immediately</em> switch to sending note plaintexts with lead byte
<span class="math">\(\mathtt{0x02}\)</span>
(and the other changes in this specification) at the upgrade. Note that nodes will clear their mempools when the upgrade activates, which will clear all plaintexts with lead byte
<span class="math">\(\mathtt{0x01}\)</span>
that were sent conformantly and not mined before the upgrade.</p>
<p>Historical note: in practice some note plaintexts with lead byte
<span class="math">\(\mathtt{0x01}\)</span>
were non-conformantly sent even after the end of the specified grace period. ZecWallet extended its implementation of the grace period by a further 161280 blocks (approximately 20 weeks) in order to allow for recovery of these funds <a id="id21" class="footnote_reference" href="#zecwallet-grace-extension">20</a>.</p>
</section>
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot defeat the EC-DDH assumption of the Jubjub (or Pallas) elliptic curve, for it could perform a linkability attack trivially in that case.</p>
<p>In the naïve case where the protocol is modified so that
<span class="math">\(\mathsf{esk}\)</span>
is supplied directly to the recipient (rather than derived through
<span class="math">\(\mathsf{rseed}\)</span>
) this would lead to an instance of key-dependent encryption, which is difficult or perhaps impossible to prove secure using existing security notions. Our approach of using a key derivation, which ultimately queries an oracle, allows a proof for IND-CCA2 security to be written by reprogramming the oracle to return bogus keys when necessary.</p>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Canopy network upgrade. <a id="id22" class="footnote_reference" href="#zip-0251">18</a></p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In zcashd:</p>
<ul>
<li><a href="https://github.com/zcash/zcash/pull/4578">https://github.com/zcash/zcash/pull/4578</a></li>
</ul>
<p>In librustzcash:</p>
<ul>
<li><a href="https://github.com/zcash/librustzcash/pull/258">https://github.com/zcash/librustzcash/pull/258</a></li>
</ul>
</section>
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The discovery that diversified address unlinkability depended on the zk-SNARK knowledge assumption was made by Sean Bowe and Zooko Wilcox.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-abstractprfs" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#abstractprfs">Zcash Protocol Specification, Version 2021.2.16. Section 4.1.2: Pseudo Random Functions</a></td>
</tr>
</tbody>
</table>
<table id="protocol-abstractcommit" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#abstractcommit">Zcash Protocol Specification, Version 2021.2.16. Section 4.1.8: Commitment</a></td>
</tr>
</tbody>
</table>
<table id="protocol-saplingkeycomponents" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2021.2.16. Section 4.2.2: Sapling Key Components</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardkeycomponents" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2021.2.16. Section 4.2.3: Orchard Key Components</a></td>
</tr>
</tbody>
</table>
<table id="protocol-saplingsend" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/protocol.pdf#saplingsend">Zcash Protocol Specification, Version 2021.2.16. Section 4.7.2: Sending Notes (Sapling)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardsend" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/protocol.pdf#orchardsend">Zcash Protocol Specification, Version 2021.2.16. Section 4.7.3: Sending Notes (Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-saplingandorchardencrypt" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="protocol/protocol.pdf#saplingandorchardencrypt">Zcash Protocol Specification, Version 2021.2.16. Section 4.19.1: Encryption (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-decryptivk" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="protocol/protocol.pdf#decryptivk">Zcash Protocol Specification, Version 2021.2.16. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-decryptovk" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="protocol/protocol.pdf#decryptovk">Zcash Protocol Specification, Version 2021.2.16. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretediversifyhash" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2021.2.16. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretesaplingkeyagreement" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="protocol/protocol.pdf#concretesaplingkeyagreement">Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.3 Sapling Key Agreement</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concreteorchardkeyagreement" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="protocol/protocol.pdf#concreteorchardkeyagreement">Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.5 Orchard Key Agreement</a></td>
</tr>
</tbody>
</table>
<table id="protocol-notept" class="footnote">
<tbody>
<tr>
<th>15</th>
<td><a href="protocol/protocol.pdf#notept">Zcash Protocol Specification, Version 2021.2.16. Section 5.5: Encodings of Note Plaintexts and Memo Fields</a></td>
</tr>
</tbody>
</table>
<table id="zip-0207" class="footnote">
<tbody>
<tr>
<th>16</th>
<td><a href="zip-0207">ZIP 207: Split Founders' Reward</a></td>
</tr>
</tbody>
</table>
<table id="zip-0213" class="footnote">
<tbody>
<tr>
<th>17</th>
<td><a href="zip-0213">ZIP 213: Shielded Coinbase</a></td>
</tr>
</tbody>
</table>
<table id="zip-0251" class="footnote">
<tbody>
<tr>
<th>18</th>
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zip-0252" class="footnote">
<tbody>
<tr>
<th>19</th>
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="zecwallet-grace-extension" class="footnote">
<tbody>
<tr>
<th>20</th>
<td><a href="https://github.com/adityapk00/librustzcash/commit/c31a04a4dbfa5a2ac013139db229f41cd421754d">Commit c31a04a in aditypk00/librustzcash: Move ZIP-212 grace period to end of April</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

Some files were not shown because too many files have changed in this diff Show More