of the input in case of Orchard), were accidentally swapped in the
protocol specification relative to ZIP 212. The implementation in zcashd
correctly followed ZIP 212, using [4] to derive rcm and [5] to derive esk.
[Note added 2023-12-07: This commit, which is between spec versions
2022.3.8 and 2023.4.0, does not accurately reflect what was deployed.
In fact the domain separators for Sapling were implemented according to
ZIP 212, but the ones for Orchard were implemented according to the spec,
i.e. swapped relative to Sapling. This has been documented in spec
version 2023.4.0.]
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
was incorrectly given as $\mathbb{J}^{(r)*}$, rather than the correct
$\mathbb{J}^{(r)*} \cup \{\bot\}$.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
\crossref{inbandrationale}, we now use the fact that g_d has order greater
than the maximum value of ivk, rather than assuming that g_d is a non-zero
point in the prime-order subgroup. (In the case of Sapling, the circuits
only enforce that g_d is not a small-order point, not that it is in the
prime-order subgroup. It is true that honestly generated addresses have
prime-order g_d which would have been sufficient for the security argument
against this class of attacks, but the chosen fix is more direct.)
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
There is currently a bug that will cause them to be rendered incorrectly
if they have only one paragraph, but that doesn't matter for the usage
in this PR.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
* Remove redundancy between the list of reasons to reject an update and
the "Specification of Status Workflow" section, and move things to the
right section.
* Define "Released".
* Remove use of "proposed" (which was not intended to be the same as the
status "Proposed").
* Add another reason to reject an update: it violates a conformance
requirement of any Active Process ZIP (including this ZIP);
* Clarify that ZIP stubs, and only ZIP stubs, MUST use Status: Reserved;
* Clarify when a Released ZIP can be changed to a non-Released status;
* Require that changes in status other than Draft <-> Withdrawn in
general need consensus among ZIP Editors, and eliminate resulting
redundancies. This is technically a strengthened requirement for
changes other than to Proposed or Rejected, but reflects existing
practice.
* Clarify how the Owners of a ZIP change it to Withdrawn.
* Active can now only be reached from Proposed. Strengthen the
requirements for rough consensus in this case to say that the ZIP
has been complete for at least a month and Proposed for at least
a week. This will impose a bit more overhead but I think it's
necessary; previously, a Process or Informational ZIP could have
gone directly from Draft to Active without sufficient notice.
* Require that a Consensus ZIP has an implementation merged into at
least one consensus node codebase (currently zcashd and/or zebra)
before it is moved to Implemented, and make the existing discussion
of timing relative to a network upgrade apply only to Consensus ZIPs;
* Require that if a non-editorial update is made to an Obsolete or
Withdrawn ZIP, its status MUST be changed appropriately.
* Allow a status transition from Implemented to Obsolete, and clarify
when transitions to Obsolete occur.
* Add a responsibility for the ZIP Secretary to share significant
changes in ZIP status, in particular progression of a ZIP to Proposed,
on the Community Forum.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
Daira Emma Hopwood
teor
str4d
dependabot[bot]
Deirdre Connolly