Skip to content

improve explanation of NUMS derivation of H and J#42

Merged
ignopeverell merged 1 commit into
mimblewimble:masterfrom
johnzweng:improve_nums_comments
Feb 26, 2019
Merged

improve explanation of NUMS derivation of H and J#42
ignopeverell merged 1 commit into
mimblewimble:masterfrom
johnzweng:improve_nums_comments

Conversation

@johnzweng

Copy link
Copy Markdown
Contributor

Improve documentation on how the generator points have been dervied

This PR only changes comments in the constants.rs file.

When I tried to understand if and how the generation points for Pedersen and Switch Commitments have been derived in a secure, nothing-up-my-sleeve (NUMS) way, I realized it would be helpful to have a better explanation in the comments.

As important properties of the commitment schemes only hold if these points are chosen transparently, I thought this should be better documented.

Let me know what you think about it, or if I should change something. 🙂

@antiochp

Copy link
Copy Markdown
Member

@tromp @ignopeverell @yeastplume Any idea what's going on with this reversed byte order in J?
Did we mess something up with endianness? Or is this expected?

@tromp

tromp commented Jan 23, 2019 via email

Copy link
Copy Markdown
Contributor

@jaspervdm

jaspervdm commented Jan 23, 2019

Copy link
Copy Markdown
Contributor

@antiochp @tromp This is the internal representation of a public key in secp256k1_pubkey. See also discussion in #38. We checked that these bytes in fact do represent the correct point, by comparing the compressed point with the one originally introduced in #9. This is also explicitly tested in secp256k1-zkp

@jaspervdm

Copy link
Copy Markdown
Contributor

@johnzweng Thank you for verifying and checking these points. The expanded documentation on the derivation is also very helpful! 👍

@johnzweng

Copy link
Copy Markdown
Contributor Author

@jaspervdm My pleasure. Glad I could help. :-)

@johnzweng

Copy link
Copy Markdown
Contributor Author

And the PR got the number 42.. 😄 🎉

@johnzweng

Copy link
Copy Markdown
Contributor Author

Another small thought regarding the different notation of J:

Why is the declaration of J in "secp256k1-zkp" different from G and H in the first place (see secp256k1_generator vs secp256k1_pubkey in the function signature of secp256k1_blind_switch).

I am not that familiar with C code or the secp256k1-zkp library but naively I would have assumed that all 3 generator points are used in a similiar fashion (namely EC point multiplication).

G and H in the Pederson commitment as xG + vH (see secp256k1_pedersen_commit, which calls secp256k1_pedersen_ecmult and uses secp256k1_ecmult_const for EC multiplication)

and J in the switch commitment (within the blinding factor calculation) here: secp256k1_blind_switch which uses secp256k1_ec_pubkey_tweak_mul for the EC multiplication.

What is the difference between secp256k1_ecmult_const and secp256k1_ec_pubkey_tweak_mul?

Please bear with me if I got something wrong, or I miss some important points here as I am not a C programmer. 🙂

Also it seems to work correctly like it is. This was just curiosity. 🙂

@ignopeverell
ignopeverell merged commit 304ef72 into mimblewimble:master Feb 26, 2019
@ignopeverell

Copy link
Copy Markdown
Contributor

Merged the improvement as it was good in itself. Don't let that stop the discussion though.

suemto pushed a commit to mwcproject/rust-secp256k1-zkp that referenced this pull request Oct 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants