Speaking for myself, and as a former ZIP Editor and an Owner / original drafter of ZIP 0 on its intended meaning.
Noted.
The argument wasn’t that this provision of the draft failed to meet a narrow mechanistic definition of implementability. On the contrary, it is technically possible to implement the ZIP’s conformance requirements. But to be considered implementable in respect of the intent —as the ZIP Editors interpreted it— of ZIP 0, that isn’t enough: there must also be a reasonable chance that implementing the conformance requirements would achieve (i.e. help to cause) the claimed effect.
I will file a PR intended to clarify this. [*] You are of course welcome to provide feedback on that PR.
In this particular case, the claimed effect is that preventing disbursement from the lockbox would increase the likelihood of ZSA deployment and zcashd deprecation happening sooner. There was a consensus in the meeting (if I remember correctly, it was unanimous among ECC and ZF representatives present with their zcashd and Zebra engineer and manager hats on) that this wasn’t possible: the ZIP could not achieve its claimed effect because preventing lockbox disbursement could not have any positive impact on the schedule for deploying ZSAs.
It’s not that we claim to be infallible in making schedule estimates; far from it. Note, though, that answering whether a particular change will help to advance the schedule is a lot easier than making an overall estimate. The people present were precisely those with the relevant experience to answer this question, and we had high confidence in our answer.
Where node implementors (for both zcashd and Zebra, in this case) attending a ZIP editing meeting express strong confidence about an issue within their direct competence, the ZIP Editors — even if they are some of the same people with a different hat on, which admittedly is not ideal — are entitled to rely on it.
For example ZIP 1014 required that Dev Fund recipient organizations MUST publish quarterly transparency reports, that Zcash Foundation Board members MUST not own equity in ECC, and a great many other MUSTs besides. ZIP 1015 says the ZCG grants MUST not go to the Financial Privacy Foundation (FPF), that FPF MUST publish a grants dashboard, and so on.
Yes, and those are all requirements that could arguably achieve their claimed effects. In fact, my understanding is that some of the reporting requirements of ZIP 1014 were not only enforceable, but were in practice enforced on ZF. At some point ZF was failing to publish the required transparency reports, and that provision of ZIP 1014 was used by Jason McGee to pressure them to do so. As a result, they did, and the desired direct effect of the public being able to read ZF transparency reports was achieved. (For the purpose of this discussion it does not really matter whether all intended indirect and more subjective effects, such as incentivizing effective uses of funds, flowed from that. The direct effect is nontrivial and sufficient.)
So it is clear that such requirements do not provoke the “manifestly unimplementable” clause.
- it manifestly violates common expectations of a significant portion of the Zcash community.
Manifestly violating common expectations of a significant portion of the Zcash community is a pretty bad bug in a technical upgrade, but kind of essential to governance.
I disagree, and as the person who wrote this line in the ZIP, I am sure that I absolutely intended to include governance. In fact governance decisions were near the top of my mind when writing it. Each entry on this list of reasons for rejecting a ZIP apply to all ZIPs, and that was definitely not an oversight. I remember considering them all individually and whether there should be different criteria for different categories of ZIP, and concluding that they should not be.
That speaks to the original intent, but let’s also consider the merits. I still don’t see a useful distinction between “technical” and “governance” ZIPs here. I put those in quotes because it’s not always a dichotomy; governance ZIPs can include more or less technical components.
It’s a common pattern (and often preferred) that a governance ZIP such as ZIP 1014 depends on a ZIP providing technical mechanism such as ZIP 207 (Funding Streams). The former is clearly governance and the latter is clearly technical. But what about ZIP 214 (Consensus rules for a Zcash Development Fund), which defines the actual funding streams called for by 1014 (and 1015)? That is both governance and technical.
So if, for the sake of argument, the unimplementability / ineffectiveness provision applied only to technical considerations, it would have to apply to technical considerations within any ZIP, even if that ZIP mainly dealt with governance — and also if the requirement in question was deemed by the ZIP Editors to have both technical and governance aspects. Arguably (and this would be the decision of the ZIP Editors, in this hypothetical), the “Lockbox Distribution Prerequisite” provision of draft-jackgavigan-defer-and-extend did have both technical and governance aspects, and so could still have been subject to the unimplementability / ineffectiveness provision.
I think you may also be implying that governance issues are more subjective. Indeed they often are. But are they inherently subjective, or are there cases where their unimplementability and/or ineffectiveness can be assessed (by the people with direct experience of the relevant area) with high confidence?
I would argue that the governance vs technical distinction, even in cases where the distinction is clear, is merely a heuristic. What matters is whether, on a case-by-case basis, a requirement of a submitted draft can reliably be judged to be unimplementable and/or ineffective. The ZIP Editors’ collective statement posted by @str4d explained, to my mind quite adequately, why they thought the spirit of this reason for rejection applied here.
A significant portion of the Zcash community strongly felt that ZIP 1014’s creation of the Dev Fund after the expiration of the Founders Reward was a manifest violation of their expectations. Their conviction was so strong that some of them created the first Friendly Fork – Ycash – as a branch of the Zcash blockchain that implemented their expectations. On the other hand, an even larger portion of the Zcash community strongly felt that sunsetting ongoing support and development of Zcash would manifestly violate their expectations. That’s governance for you.
Yes this issue does need to be addressed when clarifying this provision. There will be cases where the issue of “manifestly violates common expectations” is more of a matter of opinion, and subject to interpretation.
But the provision and interpretation is nevertheless absolutely needed. I remember that one of the examples motivating this provision was a hypothetical proposal to expand the monetary supply curve significantly above the Bitcoin supply curve. Although that does involve a technical component, it could easily be framed as a governance decision. It’s unclear what other reason given in the list would cover it (unless you consider a bound on the supply curve to be a security requirement, but there is no explicit statement of that in any Zcash specification document).
You could argue that it’s enough to allow publishing even an outrageous proposal as a draft, and then rely on the community to reject it. I disagree, because:
- It would be essentially trolling. Such trolling could do a lot of damage and carries reputational risk.
- It’s a denial-of-service on the governance and specification processes.
Notice, in any case, that “The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP for any of the following reasons: […]” It’s “MAY” precisely in order to give a certain amount of flexibility, and also because the process doesn’t and shouldn’t rely solely on the ZIP Editors to reject bad proposals.
Someone might also argue that “manifestly violating common expectations of a significant portion of the Zcash community” is too common for governance provisions (regardless of whether they are also technical provisions), and so the unimplementability / ineffectiveness provision should not be applied to them because it would be too likely to stymie progress.
To that I would argue that no such problem has been seen in practice. The provision had never been invoked before, and to my knowledge it had never got close to being invoked. (Although I’m not a ZIP Editor any more, I still attend almost all ZIP editing meetings. I do not remember there being any serious discussion of not publishing any previous draft due to this provision.)
The only thing I can remember that might have run into this provision if it had got any further is Qedit’s proposed surveillance protocol, which they withdrew after strong pushback from me and the rest of the community. That was a grant proposal rather than a draft ZIP, but if it had been a draft then I would argue that the ZIP Editors would have been correct, in that hypothetical situation, to use this provision (and the “has manifest security flaws” provision) to deny publication.
The third reason given is not one of the reasons currently in ZIP 0:
- “However, we also feel that there is an additional reason that should be added to ZIP 0: it attempts to use the ZIP process to effect behaviour on specific Zcash ecosystem participants, without a privacy or security motivation.”
Again, it makes sense that a technical ZIP could be rejected if it did this, but doing this is kind of the point of a governance ZIP.
Please consider the parts of my response above about ambiguity of whether a ZIP or provision is governance, technical, or both; about governance only being a heuristic; etc. to also apply here.
In addition, I absolutely do not agree that “the point of a governance ZIP” is to effect non-privacy-or-security-motivated behaviour from specific Zcash ecosystem participants. As partial evidence of that, none of the previous governance ZIPs have needed to do so, as @str4d laid out.
The reporting requirements of ZIP 1014 are, in my opinion, security-motivated: they limit the scope for misuse of funds, and that is the main point of them in my view. If there were no security or privacy motivation then they shouldn’t exist. Putting non-privacy-or-security-motivated requirements on specific parties is unduly coercive. Especially so if in practice much of the burden would fall on specific individuals whose expertise is needed for review, and who do not consent to being put under intense pressure to do highly difficult work in order, in this case, to unblock other organisations’ and individuals’ grant applications.
Also, I do not think it is actually a problem if there is a relatively high bar for particularly controversial proposals to be published.
[*] The PR will also address an ambiguity due to the fact that there are apparent criteria for deciding whether to accept a ZIP that are outside the main list:
“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.”
This wording comes from the BIP Work Flow section of BIP 1 (Bitcoin’s counterpart to ZIP 0). Since it doesn’t use BCP 14 keywords, it is unclear what force it has. So that needs to be cleared up. I do not actually think that being overcomplicated is by itself sufficient reason not to publish a draft ZIP — unless it is so complicated as to be necessarily unimplementable or ineffective, say.