Zmix #12

mikelodder7 · 2019-08-26T13:24:09Z

No description provided.

Signed-off-by: Michael Lodder <[email protected]>

Signed-off-by: Manu Drijvers <[email protected]>

Signed-off-by: Franz-Stefan Preiss <[email protected]>

Signed-off-by: Manu Drijvers <[email protected]>

Signed-off-by: Brent <[email protected]>

Signed-off-by: Michael Lodder <[email protected]>

Signed-off-by: Brent <[email protected]>

Signed-off-by: Michael Lodder <[email protected]>

Signed-off-by: Brent <[email protected]>

Signed-off-by: Michael Lodder <[email protected]>

…ation - Also make some other minor adjustments/improvements Signed-off-by: Franz-Stefan Preiss <[email protected]>

Signed-off-by: Michael Lodder <[email protected]>

- Focus more on *how* all the parts fit together (based on *proof modules* and the generic concept of *statements*) rather than immediately discussion concrete statement types. Signed-off-by: Franz-Stefan Preiss <[email protected]>

dubovitskaya

LGTM, Thanks!

dcmiddle · 2019-09-06T12:44:32Z

0000-zmix/README.md

+
+Zmix is a library for expressing, constructing, and verifying non-interactive
+zero-knowledge proofs (ZKPs). A broad class of zero-knowledge proofs is 
+supported. Schnorr-type proofs are used for many parts and to glue pieces


Is the overall goal to create a proof over an aggregation of proofs?
If so does the reference to Schnorr here imply that there is a Schnorr proof that connects all the sub-proofs?
If so the Proof structure defined later may be missing the 'y' term (i.e. y = g^x) and also the proof orchestrator may need a concept of summing the individual witnesses into a single x such that the y could be created and have meaning.

The idea is that you need to bind sub proofs together somehow. Schnorr is used for that.
An example is a selective disclosure proof and an interval proof. How are they bound? The answer is to use a Schnorr proof that shows message 5 in the disclosure proof is the same value used in the interval proof.

dcmiddle · 2019-09-06T12:49:25Z

0000-zmix/README.md

+
+```
+pub struct ProofSpec {
+    message_count: usize,


If these messages are the individual witnesses then a name like witness_count might be more specific. Similarly for the other uses of message in this document with the exception of its use in the BBS example.

fwiw, libsnark refers to hidden and revealed terms collectively as inputs and then differentiates between primary inputs (public terms) and auxiliary inputs (witnesses / secret terms).

@manudrijvers What do you think about using the same terminology as libsnark? I don't like the hiddenormessage name.

dcmiddle · 2019-09-06T12:56:49Z

0000-zmix/README.md

+        challenge_hash: Vec<u8>,
+    ) -> Result<StatementProof, ZkLangError>;
+    fn recompute_hash_contribution(
+        challenge_hash: Vec<u8>,


How will recompute_hash_contribution use challenge_hash? Elsewhere challenge_hash is defined as the hash of the individual contributions. Maybe challenge_hash was meant to be the concatenation of these hashes? Or perhaps there needs to be a list of commitments and the elements of that list can be used to regenerate the challenges in conjunction with the witnesses and other terms?

We need to clean this part. The idea is that each proof contributes to the challenge_hash. @manudrijvers what exactly is recompute_hash_contribution?

One way to do Schnorr protocol is in which the verifier recompute the challenge and compares that (for equality) with the prover's claimed challenge. To recompute the challenge, the verifier recomputes the commitments and then hashes them at the end. HashContribution would be an abstraction over the commitment.

A prover computes so-called t-values based on randomness, hashes t-values to form the "challenge hash" c, and uses that to compute s-values.

When verifying, given c and s-values, you can recompute the which t-values should go with that, and then check that if you hash those recomputed t-values, you indeed get the challenge hash c that was given to you. recompute_hash_contribution would do the recomputation of the t-values.

dcmiddle · 2019-09-06T13:03:51Z

0000-zmix/README.md

+/// * TODO: add further requirements
+pub struct Witness {
+    messages: Vec<Vec<u8>>,
+    statement_witnesses: Vec<StatementWitness>,


What is the purpose of statement_witness (and the use of a struct) vs just having a witness list?

Not sure I completely understand the question but let me try to clarify: We get a vector of witness information such that each piece of the witness information corresponds to one of the proof statements. It's a struct such that we can make it structured data, for example, a BBS signature BBS proof expects a BBS signature as a witness, so we use a StatementWitness struct rather than just bytes.

Why both messages and statement_witnesses in Witness struct? What information is contained in messages that is not contained in statement_witnesses?

lovesh · 2019-09-18T09:37:41Z

0000-zmix/README.md

+zero-knowledge proofs. 
+
+To construct a proof, zmix requires a `ProofSpec s` and a `Witness w`
+(which is a valid witness for `p`), and will output a `Proof p`. 


Typo: "which is a valid witness for p" should be "which is a valid witness for s"

lovesh · 2019-09-18T09:41:10Z

0000-zmix/README.md

+Conceptually, the zmix library will offer the functions:
+
+* `generate_proof(s: ProofSpec, w: Witness) -> Result<Proof, Error>`
+* `verify_proof(p: Proof, s: ProofSpec) -> Result<(), Error>`


This function signature indicates that on failure there is error and success means no error which contradicts the statement given above "To verify a proof, zmix requires a ProofSpec s and a Proof p, and will output a boolean".

lovesh · 2019-09-18T10:14:12Z

0000-zmix/README.md

+The library will offer and support various types of statements, such as signatures and commitments.
+To combine and connect all the statements (i.e., the proof's parts) contained in the proof specification, that is, glue all parts together into a single zero-knowledge proof, the library will use _Schnorr proofs_.
+
+For generating a Schnorr proof that encompasses multiple statements, for each statement one requires a _hash contribution_ on the one hand, and a _proof contribution_ based on an aggregation of the hash contributions on the other hand.


"a proof contribution based on an aggregation of the hash contributions on the other hand" is incomplete. The proof contribution also involves the witness.

lovesh · 2019-09-18T10:18:01Z

0000-zmix/README.md

+    fn get_hash_contribution(
+        statement: Statement,
+        witness: StatementWitness,
+        message_r_values: Vec<Vec<u8>>,


Assuming message_r_values are the blinding factors, why not rename message_r_values to something like that?

lovesh · 2019-09-18T10:47:15Z

0000-zmix/README.md

+        messages: Vec<HiddenOrRevealedValue>,
+    },
+    PedersenCommitment {
+        message_index: usize,


You are also proving the knowledge of randomness in the commitment so there should be a field for that.

lovesh · 2019-09-26T09:53:06Z

0000-zmix/README.md

+### Statements
+
+```rust
+pub enum Statement {


This enum should have variants for equality/inequality of witnesses across statements

Better to generalize the relations as

inequality with public value

inequality among witness

equality with public value (same as disclose)

equality among witness

greater than/less than with public value

greater than/less than among witness

lovesh · 2019-09-30T14:55:28Z

0000-zmix/README.md

+/// * TODO: add further requirements
+pub struct Witness {
+    messages: Vec<Vec<u8>>,
+    statement_witnesses: Vec<StatementWitness>,


Why both messages and statement_witnesses in Witness struct? What information is contained in messages that is not contained in statement_witnesses?

lovesh · 2019-09-30T14:56:46Z

0000-zmix/README.md

+pub enum Statement {
+    /// Boneh Boyen Shacham Signature
+    SignatureBBS {
+        pk: Vec<u8>,


Is the pk enough to identify which signature is being referred?

lovesh · 2019-09-30T14:58:38Z

0000-zmix/README.md

+```
+pub struct ProofSpec {
+    message_count: usize,
+    statements: Vec<Statement>,


It is assumed there is a conjunction (AND) between statements but there can be a disjunction (OR) as well.

lovesh · 2019-09-30T15:00:32Z

0000-zmix/README.md

+### Statements
+
+```rust
+pub enum Statement {


Better to generalize the relations as

inequality with public value

inequality among witness

equality with public value (same as disclose)

equality among witness

greater than/less than with public value

greater than/less than among witness

lovesh · 2019-09-30T15:02:16Z

0000-zmix/README.md

+        commitment: Vec<u8>,
+        params: PedersenCommitmentParams,
+    },
+    IntervalBulletproof {


How do you know which signature is referred?

lovesh · 2019-09-30T15:02:35Z

0000-zmix/README.md

+    },
+}
+
+pub enum HiddenOrRevealedValue {


Should remove.

lovesh · 2019-09-30T15:02:53Z

0000-zmix/README.md

+        messages: Vec<HiddenOrRevealedValue>,
+    },
+    /// Pointcheval Sanders Signature
+    SignaturePS {


How is revocation handled?

lovesh · 2019-09-30T15:04:15Z

0000-zmix/README.md

+
+## Structures
+
+### Statements


There should be separation between instance data and relation. So organize instance data and make it identifiable and then state relations and refer instance data and witness with their corresponding identifiers.

Signed-off-by: lovesh <[email protected]>

dcmiddle · 2022-01-05T21:58:30Z

I suggest we close this.

mikelodder7 force-pushed the zmix branch from 2cb55a8 to db73f8d Compare August 26, 2019 13:38

brentzundel requested review from brentzundel, danintel, dcmiddle, dhuseby, dubovitskaya, hartm, lovesh, mac-arrap, manudrijvers and vaporos as code owners August 26, 2019 20:47

mikelodder7 and others added 19 commits August 29, 2019 13:04

ZMix description

edf5939

Signed-off-by: Michael Lodder <[email protected]>

pass over guide-level explanation

f21f498

Signed-off-by: Manu Drijvers <[email protected]>

First draft for reference-level explanation

093fe5e

Signed-off-by: Franz-Stefan Preiss <[email protected]>

Remove outdated content

779425d

Signed-off-by: Manu Drijvers <[email protected]>

adjusted line length

f104608

Signed-off-by: Brent <[email protected]>

Added Modules

ca52c6f

Signed-off-by: Michael Lodder <[email protected]>

minor edits

4a2468b

Signed-off-by: Brent <[email protected]>

proof module section edits

5c7198e

Signed-off-by: Brent <[email protected]>

Updates to module text

5e65070

Signed-off-by: Michael Lodder <[email protected]>

Added gitignore

dc184d2

Signed-off-by: Michael Lodder <[email protected]>

Edited introduction

0cb1b7a

Signed-off-by: Brent <[email protected]>

Added data models

b59c559

Signed-off-by: Michael Lodder <[email protected]>

Add statement structure and TODO for improving reference-level explan…

f931b7a

…ation - Also make some other minor adjustments/improvements Signed-off-by: Franz-Stefan Preiss <[email protected]>

Initial Language bindings

634d275

Signed-off-by: Michael Lodder <[email protected]>

Minor fixes

4f0e482

Signed-off-by: Michael Lodder <[email protected]>

Minor fixes

d662fb1

Signed-off-by: Michael Lodder <[email protected]>

Update date

d15d3c7

Signed-off-by: Michael Lodder <[email protected]>

Update to include ffi-support

21f04c6

Signed-off-by: Michael Lodder <[email protected]>

Update reference-level text to focus on concepts

266b667

- Focus more on *how* all the parts fit together (based on *proof modules* and the generic concept of *statements*) rather than immediately discussion concrete statement types. Signed-off-by: Franz-Stefan Preiss <[email protected]>

mikelodder7 force-pushed the zmix branch from d79d588 to 266b667 Compare August 29, 2019 19:04

dubovitskaya approved these changes Sep 4, 2019

View reviewed changes

brentzundel approved these changes Sep 5, 2019

View reviewed changes

dcmiddle suggested changes Sep 6, 2019

View reviewed changes

lovesh reviewed Sep 18, 2019

View reviewed changes

lovesh reviewed Sep 26, 2019

View reviewed changes

lovesh suggested changes Sep 30, 2019

View reviewed changes

lovesh added 2 commits October 2, 2019 15:33

minor edits

c75c55d

Signed-off-by: lovesh <[email protected]>

Parially align doc to the PoC

359b9c1

Signed-off-by: lovesh <[email protected]>

Base automatically changed from master to main January 22, 2021 20:49

Zmix #12

Are you sure you want to change the base?

Zmix #12

Conversation

mikelodder7 commented Aug 26, 2019

Uh oh!

dubovitskaya left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dcmiddle commented Jan 5, 2022

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

7 participants