Add explicit version to protocol spec about zips

[zookozcash]

Let's plan that (unless things change), what we ship in the Zcash 1.0 product will be the Zcash-protocol-v2.1.

Which will be the thing that we implement after we learn from implementing and reviewing Zcash-protocol-v2.0.

Which is the thing that Daira is currently writing a spec of.

[nathan-at-least]

Ok, so we'll have an N.K version scheme to signal N's are new features and K are "security / bug / implementation feasibility" refinements only.

Edit: I asked a question, but Zooko's probably swamped, so I changed my question to an assertion. ;-)

[zookozcash]

Eh, I guess. I don't want to think that hard about it or to commit to a specific policy. I just want to call that thing 2.1. Being consistent about it or documenting our intent isn't that important to me.

[daira]

The version with the Faerie Gold fix identifies itself as Zerocash Protocol version 2.0-draft-1. The draft number will increment on each feature addition/bugfix. Does that work for everyone?

[ebfull]

That works.

I'm a bit concerned on the scope of the draft. I would like to clean up the current circuit significantly (and compare it to what we have written) before we fix Faerie Gold (and everything else), so that we know we're doing everything right and not missing anything. Is the draft mixing "clarifications of the existing protocol" with "changes to the existing protocol"?

[daira]

The encryption changes and the Faerie Gold fix are in their own pull requests (although the latter branch includes the former). Also, those branches mark all of the changes they make in a different colour. I intend to maintain this separation and "backport" any structural/terminology/completeness improvements I make onto the master branch. (That will take some work but I think it's worth doing.)

[ebfull]

The coloring alone satisfies my question. 👍

[daira]

The spec is now explicitly versioned.