Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Sapling] Specify commitment scheme for notes and values #2634

Closed
daira opened this issue Sep 27, 2017 · 4 comments
Closed

[Sapling] Specify commitment scheme for notes and values #2634

daira opened this issue Sep 27, 2017 · 4 comments

Comments

@daira
Copy link
Contributor

@daira daira commented Sep 27, 2017

We are likely to use Pedersen hashes (#2234) for the Sapling circuit. It is convenient and efficient to reuse the Pedersen hash circuit implementation, and the optimizations worked out for it, for Pedersen commitments. So, I propose we define the note and value commitments for Sapling as PedersenCommitr(x) = PedersenHash(x) + [r] H, for random r uniformly distributed on the Jubjub scalar field. Different generators can be used for each instance of the hash/commitment scheme in order to provide domain separation.

There are some details still to resolve:

  • how the generators are chosen (probably by reusing the hash function into the group, GH);
  • the Pedersen hash is only collision-resistant for constant-length inputs — we may either decide to fix this, or decide that it isn't a problem because the length is constant for each separated input domain.
@daira daira self-assigned this Sep 27, 2017
@daira daira changed the title [Sapling] Choose commitment scheme for notes and values [Sapling] Specify commitment scheme for notes and values Sep 27, 2017
@daira

This comment has been minimized.

Copy link
Contributor Author

@daira daira commented Oct 4, 2017

I suggest reserving a counter value of 0 as input to GH to derive H, and then counter values 1..n for the n windows. For hashes, we just omit counter value 0. Each hash or commitment scheme will have a different personalization string, e.g.:

  • ZcashGHNotesTree for the Merkle tree over note commitments;
  • ZcashGHInnerComm for the inner note commitments;
  • ZcashGHOuterComm for the outer note commitments;
  • ZcashGHValueComm for value commitments;
  • ZcashGHDiversify for address diversification;
  • ZcashGHUserToken for user-issued tokens.
@daira

This comment has been minimized.

Copy link
Contributor Author

@daira daira commented Oct 4, 2017

I wrote:

I suggest reserving a counter value of 0 as input to GH to derive H, and then counter values 1..n for the n windows. For hashes, we just omit counter value 0.

Actually that won't work because GH is partial. The cleanest way around this is probably to have two counter inputs where the second is the lowest integer for which GH produces an output.

@daira daira added this to Work Queue in Sapling Protocol Upgrade Oct 5, 2017
@daira

This comment has been minimized.

Copy link
Contributor Author

@daira daira commented Oct 27, 2017

The constraint cost of a Pedersen commitment is the cost of a Pedersen hash over the input (2.666 constraints per bit including boolean constraints), plus a fixed-base scalar multiplication (750 constraints), an addition producing only the x-coordinate (4 constraints), and boolean-constraining r (252 constraints). So it is approximately 1006 constraints plus 2.666 constraints per bit.

@daira daira added this to 1.1.0: Consensus / Node Rules in Release planning Nov 10, 2017
@str4d str4d moved this from 1.1.0: Specification to 1.0.14: Specification in Release planning Nov 13, 2017
@str4d str4d added this to the 1.0.14 milestone Nov 29, 2017
@str4d str4d modified the milestones: 1.0.14, Sapling Specification Jan 2, 2018
@str4d str4d moved this from 1.0.15: Specification to 1.1.0: Specification in Release planning Mar 13, 2018
@daira

This comment has been minimized.

Copy link
Contributor Author

@daira daira commented Mar 19, 2018

Done; see sections 5.4.7.2 and 5.4.7.3.

@daira daira closed this Mar 19, 2018
Sapling Protocol Upgrade automation moved this from Work Queue to Complete Mar 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Release planning
1.1.0: Specification
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.