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

Rebase on upstream dbd41db16a0e91b2566820898a3ab2d7dad4fe00 #91

Closed

Conversation

jonasnick
Copy link
Contributor

Fixes #85. My personal motivation is that I'd like to add a few modules soon that would benefit from the latest upstream changes, but are more appropriate to add here than upstream (such as ECDSA adaptor sigs @nkohen).

This PR was created by running git rebase upstream/master.
The only conflicts I had to fix were

  1. related to the upstream addition of the iters argument to the benchmark interface
  2. moving config arguments from travis.yml to travis.sh

See this branch for the fixups I applied).
Should be easy to review/recreate @apoelstra @real-or-random @benma

gmaxwell and others added 30 commits June 18, 2020 20:34
This commit adds three new cryptosystems to libsecp256k1:

Pedersen commitments are a system for making blinded commitments
 to a value.  Functionally they work like:
  commit_b,v = H(blind_b || value_v),
 except they are additively homorphic, e.g.
  C(b1, v1) - C(b2, v2) = C(b1 - b2, v1 - v2) and
  C(b1, v1) - C(b1, v1) = 0, etc.
 The commitments themselves are EC points, serialized as 33 bytes.
 In addition to the commit function this implementation includes
 utility functions for verifying that a set of commitments sums
 to zero, and for picking blinding factors that sum to zero.
 If the blinding factors are uniformly random, pedersen commitments
 have information theoretic privacy.

Borromean ring signatures are a novel efficient ring signature
 construction for AND/OR admissions policies (the code here implements
 an AND of ORs, each of any size).  This construction requires
 32 bytes of signature per pubkey used plus 32 bytes of constant
 overhead. With these you can construct signatures like "Given pubkeys
 A B C D E F G, the signer knows the discrete logs
 satisifying (A || B) & (C || D || E) & (F || G)".

ZK range proofs allow someone to prove a pedersen commitment is in
 a particular range (e.g. [0..2^64)) without revealing the specific
 value.  The construction here is based on the above borromean
 ring signature and uses a radix-4 encoding and other optimizations
 to maximize efficiency.  It also supports encoding proofs with a
 non-private base-10 exponent and minimum-value to allow trading
 off secrecy for size and speed (or just avoiding wasting space
 keeping data private that was already public due to external
 constraints).

A proof for a 32-bit mantissa takes 2564 bytes, but 2048 bytes of
 this can be used to communicate a private message to a receiver
 who shares a secret random seed with the prover.

Also: get rid of precomputed H tables (Pieter Wuille)
… cleanup

Switch to secp256k1_pedersen_commitment by Andrew Poelstra.
Switch to quadratic residue based disambiguation by Pieter Wuille.
* add summing function for blinded generators
* drop `excess` and `gen` from `verify_tally`
* add extra_commit to rangeproof sign and verify
Includes fix and tests by Jonas Nick.
Include test_impl.h
Was failing linking to `*.so` library
apoelstra and others added 18 commits June 18, 2020 20:34
f make helper functions static
f hash noncedata into nonce in nonce_function_bipschnorr
f expose nonce_function_bipschnorr
f fix undefined behavior when shifting an int 31 places
f add cplusplus ifdef to schnorrsig include file
f hash complete pubkey into batch seed
f chacha20 for bigendians
f add schnorrsig to travis
f show in configure if schnorrsig is enabled
remove the set_msg function and require the message in get_public_nonce
at the latest.
Copy link
Contributor

@benma benma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked that the rebase is good on 6a57be0, except possibly for the two comments (not sure if I made a rebase mistake).

There are conflicts with the target branch though.


#undef ROTL32
#undef QUARTERROUND
#undef LE32
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#undef BE32 missing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't find a BE32 in this file

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, was removed in cb8f059, so it was a rebase error on my side.


#undef ROTL32
#undef QUARTERROUND
#undef LE32
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#undef BE32 missing?

@jonasnick
Copy link
Contributor Author

Thanks for the review!

There are conflicts with the target branch though.

I think that's to be expected. This branch will become master and the previous master will be renamed to something else (#68 (comment)).

Copy link

@nkohen nkohen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was able to re-create this branch by doing a git rebase upstream/master myself on this branch https://github.com/nkohen/secp256k1-zkp/commits/rebase-on-upstream
(and then adding two commits to fix up benchmarks and tests and config/travis stuff)

@jonasnick
Copy link
Contributor Author

jonasnick commented Jul 24, 2020

Didn't push the branch in this PR to the secp256k1-zkp branch but instead pushed https://github.com/real-or-random/secp256k1-zkp/tree/202007-secp256k1-rebase. @real-or-random same recreated the almost the same history but cleand it up a bit and rebased on a newer version of upstream libsecp. Closing.

@jonasnick
Copy link
Contributor Author

The pre force push secp256k1-zkp branch is archived at https://github.com/ElementsProject/secp256k1-zkp/tree/secp256k1-zkp-2020-07-24.

@real-or-random
Copy link
Collaborator

Didn't push the branch in this PR to the secp256k1-zkp branch but instead pushed https://github.com/real-or-random/secp256k1-zkp/tree/202007-secp256k1-rebase. @real-or-random did the same recreated the same history but cleaned up the history a bit and rebased on a newer version of upstream libsecp. Closing.

post-(merge ?) ACK

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.

rebase on bitcoin-core/secp256k1