This is a very nice kickoff for the commit & prove standard!

Iâ€™m not sure how to proceed more on the schedule, but here are some personal comments on the charter and the documentation.

It seems the document style is closer to a cryptographic paper (which I understand it is somehow unavoidable); but if weâ€™re building a firm standard for general usage, it seems more reasonable to make it easier to read. I believe the goal of the standard is to define the general outline of the concept, so that it can be connected to other concept by structure. (This is just an opinion; are there any other ideas?)

In other words, the definition of â€ścommit & proveâ€ť which specifies the formal outline of algorithm (e.g. section 4.3, 4.4) should be more emphasized, while security definitions (e.g. knowledge soundness, binding) should be out of focus or moved to appendix. (Again, this is just a personal idea; but it would be nice to have a continuous discussion on the proposal to create a formal standard documentation.)

In a simple summary, I think the standard should be as general and short as possible: the main priority should be the definition of â€śtermsâ€ť (e.g. what is commit & prove), definition of â€śstructureâ€ť (e.g. what functions do commit & prove system possess), and some â€śexamplesâ€ť (e.g. a scenario example on how commit & prove system works).

Based on the idea above, I suggest discussing priority ideas to be included in the charter.

Also, as a different topic, our group will soon come up with the charter for encrypt & prove: we think that defining the structure of â€śencrypt & proveâ€ť should be enough for the relation to the commit & prove working group. If there are any ideas or suggestions, please feel free to post comments or send messages.

Thank you all!