\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>