Uncompressed Bulletproof Rangeproofs #108

apoelstra · 2020-11-24T06:49:53Z

This PR makes very little effort to be optimized, preferring ease of review. Future PRs will add

rewinding
optimizations (combining the two verifier ecmults, reducing scalar ops)
inner product argument (i.e. "compressed Bulletproofs")
batch verification (after upstream has decided on an API for schnorr/Taproot batching)
streaming verification (this will be significantly slower, is it worth it?)
precomputation of S commitment in proof

jonasnick · 2021-01-12T20:30:26Z

Sorry this was automatically closed. PR needs to be reopened against the master branch.

apoelstra · 2021-06-15T22:14:18Z

Rebased

dr-orlovsky · 2022-01-13T10:43:32Z

Is the PR just pending reviews?

I will work on code reviewing in the next few days, but I am not expert in bulleproofs at all, so who also can be asked to do the review and get this merged?

apoelstra · 2022-01-13T14:33:48Z

It needs a review from a cryptographer (and it needs to be rebased, which I can do, but I need some commitment from a cryptographer to move forward).

dr-orlovsky · 2022-01-13T15:17:03Z

LNP/BP Association - a bitcoin-only non-profit me and Giacomo Zucco are managing - is willing to put a bounty/grant for a high-profile cryptographers to re-view this PR. Do you have anyone in mind who may be interested in that?

apoelstra · 2022-01-13T15:21:02Z

Thanks for the offer! Unfortunately not -- the high-profile cryptographers I know are more in need of time than money these days.

dr-orlovsky · 2022-01-13T15:34:47Z

We may ask Peter Todd who is working with our LNP/BP Association for some time now - but will his review be sufficient to get this merged?

dr-orlovsky · 2022-01-13T15:36:06Z

Yeah, I always say that time->money is a hash function :) One can always get money from their time - but never time from their money.

dr-orlovsky · 2022-01-13T15:38:19Z

Another person I have in mind who may agree to do the review on a grant-sponsored basis (and with whom we worked on other our projects before) is Rene Pickhardt

apoelstra · 2022-01-13T16:31:39Z

Neither of them would be sufficient. I need somebody who is a maintainer of this library, and/or somebody who is an author of the BPs paper or similar (and who has experience writing crypto code).

dr-orlovsky · 2022-01-13T17:08:23Z

@apoelstra reasonable. Where I can get the list of the maintainers of this lib?

ChristopherA · 2022-01-13T18:30:25Z

Maybe Mark Friedenbach @maaku could be incentivized to review this PR?

apoelstra · 2022-01-14T00:41:09Z

@dr-orlovsky the maintainers are me, @jonasnick and @real-or-random. All of us have higher priorities right now. Is there a reason you'd like to push forward on this? I'm happy to start things moving again but there's no way that we can do it in the next week or two.

dr-orlovsky · 2022-01-14T08:18:55Z

Oh, it was not about having this moving in the next week or two, it is about having this moving in the next months :)

The reason is that we have dependencies on bulletproofs in other LNP/BP Association projects and right now have to use Grin bulletproofs implementation, which, as you said, is diverged from the spec, but the only secp-based bulleptroofs implementation available right now.

apoelstra · 2022-07-12T20:22:08Z

Rebased. Had to revert a commit which removes secp256k1_scalar_sqr. No other major changes.

robot-dreams

Concept ACK

What a PR! Overall looks good (though I haven't checked the test code yet).

The main thing I still need to think about is the way you obtained the hash challenges. For example, right now you have y = hash(state), z = hash(y), whereas I could imagine wanting something like y = hash(state || 0), z = hash(state || 1) instead (not sure yet, will look into this more).

General thoughts:

Is the tradeoffs between space savings and nonstandard serialization worth it, for amortizing parity data for two points into a single byte?
Should we document the correspondence between generator notation in the paper and generators used in this PR somewhere?

BTW If you prefer, I can make the suggested changes and push commits somewhere.

robot-dreams · 2022-07-21T14:26:01Z

src/modules/bulletproofs/main_impl.h

+
+struct secp256k1_bulletproofs_generators {
+    size_t n;
+    /* `G_i`, `H_i` generators, `n` each of them which are generated when creating this struct */


Comment: It seemed kind of ambiguous whether there were n or 2*n total generators. Would something like this make sense?

Suggested change

/* `G_i`, `H_i` generators, `n` each of them which are generated when creating this struct */

/* n total generators; set n = 2*k to get G_i and H_i values for i in [1..k] */

robot-dreams · 2022-07-21T14:51:42Z

src/modules/bulletproofs/main_impl.h

+    VERIFY_CHECK(ctx != NULL);
+
+    ret = (secp256k1_bulletproofs_generators *)checked_malloc(&ctx->error_callback, sizeof(*ret));
+    if (ret == NULL) {


Is it necessary to check the return value of checked_malloc in these 4 calls, given that it already does this check internally?

Yes, because after doing the check it may still return NULL.

robot-dreams · 2022-07-21T14:58:17Z

src/modules/bulletproofs/main_impl.h

+        secp256k1_generator gen;
+        if (!secp256k1_generator_parse(ctx, &gen, &data[33 * n])) {
+            free(ret->gens);
+            free(ret);


Do we need to return NULL here?

Yes! This is actually a use-after-free. I should add a test for this.

Lol, it's a use-after-free and a double-free because it's in a loop. Fixed.

robot-dreams · 2022-07-21T15:00:35Z

src/modules/bulletproofs/main_impl.h

+    ARG_CHECK(data_len != NULL);
+
+    memset(data, 0, *data_len);
+    if (*data_len < 33 * gens->n) {


Should we require *data_len be exactly 33 * gens->n since parsing depends on the size?

No, typically we allow an arbitrarily large buffer and then return the actually-parsed size through the outpointer.

robot-dreams · 2022-07-21T15:01:09Z

src/modules/bulletproofs/main_impl.h

+    return ret;
+}
+
+int secp256k1_bulletproofs_generators_serialize(const secp256k1_context* ctx, secp256k1_bulletproofs_generators* gens, unsigned char* data, size_t *data_len) {


Should gens be declared as const?

robot-dreams · 2022-07-22T14:32:37Z

include/secp256k1_bulletproofs.h

+/** A function-like macro returning the size, in bytes, of an uncompressed
+ * Bulletproof proving that a value lies in the range [0, 2^(n_bits) - 1]
+ */
+#define SECP256K1_BULLETPROOFS_UNCOMPRESSED_SIZE(n_bits) (194UL + (n_bits) * 64)


Comment: Is it worth mentioning where 194 came from (65 for A, S, 65 for T1, T2, 64 for tau_x, mu)?

I'll leave it be, because this commit isn't mine, and I don't think it's a huge deal, and also this'll change with BP++.

Ah, I have to edit that commit anyway to address the above comment. Ok.

robot-dreams · 2022-07-22T14:36:24Z

include/secp256k1_bulletproofs.h

+ *               gens: pointer to the generator set to use, which must have 2*n_bits generators (cannot be NULL)
+ *    asset_gen: pointer to the asset generator for the CT commitment (cannot be NULL)
+ *  Out:      proof: pointer to a byte array to output the proof into
+ * In/OUt:  plen: pointer to the size of the above array; will be set to the actual size of


Comment: Do we also need to describe the remaining parameters?

robot-dreams · 2022-07-22T14:37:06Z

include/secp256k1_bulletproofs.h

+/** Produces an uncompressed rangeproof. Returns 1 on success, 0 on failure.
+ *  Args:   ctx: pointer to a context object (cannot be NULL)
+ *               gens: pointer to the generator set to use, which must have 2*n_bits generators (cannot be NULL)
+ *    asset_gen: pointer to the asset generator for the CT commitment (cannot be NULL)


Is the concept of an "asset generator" still relevant in the context of bulletproofs?

If not, would it be safer to create one ourselves, instead of risking that the user passes in an insecure (known discrete log relation with others) generator?

Yes, BPs don't change anything about how we manipulate assets.

robot-dreams · 2022-07-22T14:49:31Z

src/modules/bulletproofs/rangeproof_uncompressed_impl.h

+        secp256k1_scalar_add(&t1, &t1, &l);
+    }
+
+    /* B = t0 - t1 + t2 = l(-1) dot r(-1) */


Style: Is it worth extracting a helper function that does <l(k), r(k)> since this is done for k = 0, 1, -1?

I'm gonna say no, but I could go either way.

robot-dreams · 2022-07-22T14:54:38Z

include/secp256k1_bulletproofs.h

+ *  In:       data: data that came from `secp256k1_bulletproofs_generators_serialize`
+ *        data_len: the length of the `data` buffer
+ */
+SECP256K1_API SECP256K1_WARN_UNUSED_RESULT secp256k1_bulletproofs_generators* secp256k1_bulletproofs_generators_parse(


Do we actually want parsing and serialization in the public API (especially since I don't see it called anywhere outside of tests)? It seems dangerous to trust a serialized list of generators that we didn't create ourselves (there might be some hidden discrete log relation between them), so we might as well always just call create.

It seems dangerous to trust a serialized list of generators that we didn't create ourselves

Many things in life are dangerous :).

In practice I expect this list to be hardcoded, so yes, we need an API that can just blindly accept them.

LOL, fair. Maybe we can include a whitelist of hashes for known safe serialized lists of generators?

How long would this list be?

Length 1 :) if you want to use something that's not the canonical list of generators then it's on you (I'm assuming there's some "unsafe mode" flag or something).

BTW This is not a huge deal, just wanted to note a possible foot gun.

How many generators are on the list?

I was thinking 128

128 won't be enough for zkps.

apoelstra · 2022-08-03T17:11:34Z

Ok @robot-dreams I've gone through all of your comments. I am locally checking that every commit passes valgrind ./tests 1 then will update this branch. I've added fixup commits after every commit I intend to modify; I'll squash them into their parents after you re-review.

robot-dreams

Thanks for addressing the previous comments! Took one more pass through everything, just a few more comments below.

I'm still somewhat uneasy about how we do Fiat-Shamir (it might be ideal to take a systematic approach similar to Merlin), but I'm fine with declaring that out of scope for this PR.

robot-dreams · 2022-08-08T15:57:14Z

src/modules/rangeproof/tests_impl.h

 void run_rangeproof_tests(void) {
    int i;
    test_api();
    test_rangeproof_fixed_vectors();
-    test_pedersen_commitment_fixed_vector();
    for (i = 0; i < count / 2 + 1; i++) {
        test_pedersen();


Does this also need to be removed?

Yes, good catch.

robot-dreams · 2022-08-08T15:58:17Z

src/modules/generator/tests_impl.h

    test_shallue_van_de_woestijne();
    test_generator_fixed_vector();
    test_generator_api();
    test_generator_generate();
+    test_pedersen_api();
+    test_pedersen_commitment_fixed_vector();
+    for (i = 0; i < 5*count; i++) {


Just confirming, you intended to increase the iterations from count / 2 + 1 to 5*count when you moved this?

Hmm, I'm not sure. It seems suspicious that I'd bump this deliberately in a commit marked "MOVE ONLY". I'll revert it.

robot-dreams · 2022-08-08T15:58:49Z

include/secp256k1_generator.h

+/** Initialize a context for usage with Pedersen commitments. */
+void secp256k1_pedersen_context_initialize(secp256k1_context* ctx);


Nit: Can this be removed, since it isn't part of the move-only commit (it looks like a later commit deletes it anyway)?

(BTW I didn't know about color-moved before, that's a helpful feature.)

robot-dreams · 2022-08-08T15:58:57Z

include/secp256k1_generator.h

+/** Initialize a context for usage with Pedersen commitments. */
+void secp256k1_rangeproof_context_initialize(secp256k1_context* ctx);


Nit: Can this be removed, since it isn't part of the move-only commit (it looks like a later commit deletes it anyway)?

robot-dreams · 2022-08-08T17:10:41Z

configure.ac

+    [enable_module_bulletproofs=$enableval],
+    [enable_module_bulletproofs=no])


Nit: Should this be consistent with the other options?

Suggested change

[enable_module_bulletproofs=$enableval],

[enable_module_bulletproofs=no])

[],

[SECP_SET_DEFAULT([enable_module_bulletproofs], [no], [yes])])

Thanks, things changed since these commits were first written :)

robot-dreams · 2022-08-10T23:02:28Z

include/secp256k1_bulletproofs.h

+/** Verifies an uncompressed rangeproof. Returns 1 on success, 0 on failure.
+ *  Args:      ctx: pointer to a context object
+ *         scratch: pointer to a scratch space
+ *            gens: pointer to the generator set to use, which must have 2*n_bits generators


Suggested change

* gens: pointer to the generator set to use, which must have 2*n_bits generators

* gens: pointer to the generator set to use, which must have at least 2*n_bits generators

robot-dreams · 2022-08-10T23:16:40Z

src/modules/bulletproofs/rangeproof_uncompressed_impl.h

@@ -186,6 +185,9 @@ static int secp256k1_bulletproofs_rangeproof_uncompressed_prove_step1_impl(
        return 0;
    }

+    /* Generate new blinding factors tau1 and tau2 */


Nit: Should this be moved to the "step 1" commit?

robot-dreams · 2022-08-10T23:23:28Z

src/modules/bulletproofs/rangeproof_uncompressed_impl.h

+    secp256k1_fe_get_b32(&output[33], &ge.x);
+
+    /* get challenges y and z, store them in the prover context */
+    secp256k1_sha256_initialize(&sha256);


Does it make sense for this to be a tagged hash?

Yes, but let's leave this for a followup PR because there's a bit of boilerplate involved in setting up tagged hashes and it'd be worth getting separate reviews on that.

robot-dreams · 2022-08-10T23:24:58Z

src/modules/bulletproofs/rangeproof_uncompressed_impl.h

+    secp256k1_fe_get_b32(&output[33], &ge.x);
+
+    /* get challenge x */
+    secp256k1_sha256_initialize(&sha256);


Does it make sense for this to be a tagged hash?

robot-dreams · 2022-08-10T23:33:50Z

src/modules/bulletproofs/rangeproof_uncompressed_impl.h

+ *    bytes 64-96:  z (hash challenge)
+ *    bytes 96-160: lr_generator data
+ */
+


Suggested change

/* Generators (paper -> implementation):

* g -> asset_gen

* h -> default secp256k1 generator

* *g*, *h* vectors -> gens

*/

apoelstra · 2022-08-11T20:30:19Z

Lol, sure. Rebased to edit the commit message.

robot-dreams · 2022-08-11T20:31:31Z

ACK 0ab55a5 :)

apoelstra · 2022-08-11T20:36:01Z

@real-or-random are we ok to merge this (once CI passes)? I think it's too heavy to ask for another reviewer.

sanket1729 · 2022-08-12T08:38:54Z

I have started reviewing this.You can merge this, my comments can be addressed in a followup PR

real-or-random · 2022-08-12T13:57:12Z

@real-or-random are we ok to merge this (once CI passes)? I think it's too heavy to ask for another reviewer.

Yep, feel free to merge (or wait for @sanket1729's review).

apoelstra · 2022-08-12T16:24:45Z

Thanks @sanket1729! I'll wait for your review.

sanket1729

moslty ACK. Just some questions, some nits, and doc fixes. How would rewinding work if need to add data that is more than 32 bytes?

sanket1729 · 2022-08-12T09:18:50Z

include/secp256k1_bulletproofs.h

+ *  Returns 1 on success, 0 if the provided array was not large enough
+ *  Args:        ctx: pointer to a context object
+ *               gen: pointer to the generator set to be serialized
+ *  In:         data: data that came from `secp256k1_bulletproofs_generators_serialize`


In 107f5e3:

The documentation here is incorrect. data should Out instead of In and the description is also incorrect

sanket1729 · 2022-08-12T09:32:22Z

src/modules/bulletproofs/main_impl.h

+    for (i = 0; i < gens->n; i++) {
+        secp256k1_generator gen;
+        secp256k1_generator_save(&gen, &gens->gens[i]);
+        if (!secp256k1_generator_serialize(ctx, &data[33 * i], &gen)) {


In 107f5e3
secp256k1_generator_serialize always returns 1, so you can remove this if statement

Sure, removed. Interestingly this is the only place that this function is called internal to the codebase.

sanket1729 · 2022-08-12T09:39:44Z

src/modules/bulletproofs/tests_impl.h

+
+    len = sizeof(gens_ser);
+    CHECK(secp256k1_bulletproofs_generators_serialize(ctx, gens, gens_ser, &len));
+    CHECK(memcmp(gens_ser, fixed_first_3, sizeof(fixed_first_3)) == 0);


In 107f5e3:

It would be good to have a roundtrip test. Just to make sure that parse and serialize API are consistent. From the code review it looks that are consistent

Agreed. I'll add one to the API tests.

Lol, so adding this (indirectly) uncovered a memory leak in the API tests, and (directly) uncovered that our generator-parsing logic doesn't set the n field of the generators struct correctly.

sanket1729 · 2022-08-13T04:45:34Z

src/modules/bulletproofs/rangeproof_uncompressed_impl.h

+        secp256k1_ge sterm;
+        secp256k1_gej stermj;
+
+        secp256k1_scalar_chacha20(&tmp_l, &tmp_r, nonce, i + 2);


In 05e1d6c

nit: Any special reason why this is i+2? Would make sense to go from i+1 as we already used i=0

Nevermind, figured it out in a subsequent commit

sanket1729 · 2022-08-13T04:53:02Z

src/modules/bulletproofs/rangeproof_uncompressed_impl.h

+
+        secp256k1_scalar_chacha20(&tmp_l, &tmp_r, nonce, i + 2);
+
+        secp256k1_ecmult_const(&stermj, &gens->gens[2 * i], &tmp_l, 256);


The documentation of this secp256k1_ecmult_const says:

* Here `bits` should be set to the maximum bitlength of the _absolute value_ of `q`, plus * one because we internally sometimes add 2 to the number during the WNAF conversion.

I am unsure if this means len(bits(q+1)) or len(q) + 1. Everywhere else in the codebase, it is called with value 256, so I presume the value here is correct.

Yes, I believe this is correct. I remember thinking about this around the time we implemented ecmult_const but I don't remember my exact logic. I think: regardless of what we do to scalars, we can't exceed 256 bits because we'll just wrap around.

sanket1729 · 2022-08-14T01:12:44Z

src/modules/bulletproofs/rangeproof_uncompressed_impl.h

+    const secp256k1_ge *t2p;
+    const secp256k1_ge *asset_genp;
+    const secp256k1_ge *commitp;
+    secp256k1_scalar neg_t;


In 04ce24e:
minor nit: neg_t name is highlighted as a typedef. Perhaps, we can rename it? neg_t_hat?

I checked with both vim and emacs and neither has the behavior. It's unfortunate that Github is broken in this way but I don't think we should change our code because of it.

sanket1729 · 2022-08-14T01:37:20Z

src/modules/bulletproofs/bulletproofs_util.h

+    const unsigned char* extra_commit,
+    size_t extra_commit_len
+) {
+    secp256k1_sha256 sha256;


In 05e1d6c:
Trying to understand the scratch space rationale here. It's just 65 bytes? Can't we use the stack for it instead of passing it around? I am sure that we are using more stack space elsewhere in the codebase for creating temp results in ec computations.

Yeah ... this is really weird. I'll try to dig through the git history and see what I was thinking here. I actually did not even notice that this scratch was a byte vector instead of a real scratch space.. I will remove the parameter.

Ah, I see, the reasoning is that in one place we can use the output array as "scratch space".

Yes, we are using more than this elsewhere, but 65 bytes is 65 bytes.

Anyway I'll remove this since it makes the code more complicated. If we get feedback that we're using too much scratch space then we can go hyperoptimizing like this. But my original motivation was for operation on the Ledger Nano, which can't directly use this library anyway since it has its own crypto chip with its own C library.

sanket1729 · 2022-08-14T01:42:11Z

src/modules/bulletproofs/rangeproof_uncompressed_impl.h

+    }
+
+    /* Commit to all input data: min value, pedersen commit, asset generator, extra_commit */
+    secp256k1_bulletproofs_commit_initial_data(commit, scratch_bytes, n_bits, min_value, commitp, asset_genp, extra_commit, extra_commit_len);


In 04ce24e:

Is it not possible to use scratch from the function input? Or is it simpler to do this way and we don't care that much about stack space for verifier?

I just removed the scratch parameter entirely (see above comment).

sanket1729 · 2022-08-14T02:40:28Z

src/modules/bulletproofs/bulletproofs_util.h

@@ -20,6 +20,22 @@ static void secp256k1_bulletproofs_serialize_points(unsigned char *output, const
    secp256k1_fe_get_b32(&output[33], &rpt->x);
 }

+/* Initializes SHA256 with fixed midstate. This midstate was computed by applying
+ * SHA256 to SHA256("Bulletproofs/commitment")||SHA256("Bulletproofs/commitment"). */


In 9db5944
Lol, I can't reproduce this :P . See what I did to reproduce this in this commit. sanket1729/rust-bitcoin@5b289a9 . Even if this is displayed reverse this is not matching

The tagged hash code should 100% be correct because it computes the values for taproot hashes that we have tested on bitcoin network.

🤦 Sorry I missed this during review

I got this:

sha->s[0] = 0x50b6a879ul; sha->s[0] = 0x0d9a7470ul; sha->s[0] = 0xb4400e54ul; sha->s[0] = 0x32d29ac7ul; sha->s[0] = 0xde938408ul; sha->s[0] = 0x923fc797ul; sha->s[0] = 0x29f973a6ul; sha->s[0] = 0xa25e1a1cul;

I get the same. "1c1a5ea2a673f92997c73f92088493dec79ad232540e40b470749a0d79a8b650" which is just displayed reverse

I agree. thanks for catching this. I'm not sure where my original values came from.

sanket1729 · 2022-08-14T02:49:50Z

src/modules/bulletproofs/rangeproof_uncompressed_impl.h

+    int overflow;
+
+    memset(prover_ctx->data, 0, sizeof(prover_ctx->data));
+    memset(output, 0, 65);


In 05e1d6c:
ultra minor nit:
Doing these memsets seems unnecessary as we are always writing data first before reading. But it's a good habit to follow in general, these are not done in steps 2 and 3.

I think I'll leave this for a followup. It's a fair bit of work to audit 0-memsets for whether they're no-ops and/or whether they have some hypothetical security justification, and in the end the compiler will just do what it wants to.

apoelstra · 2022-08-27T17:16:59Z

Rebased and addressed all of Sanket's comments.

…ngeproof module You can verify this commit with `git diff --color-moved=zebra`

This reverts commit 5437e7b.

Silence a compiler warning about an unitialized use of a scalar in case the user tries to provide a 0-length list of commitments. Also ensures that commitments have normalized field elements when they are loaded into ges.

…tors

…eck to do

…I functions

This PR adds a convenience macro enabling callers to allocate the necessary and sufficient space for an uncompressed rangeproof. In particular, this makes it tractible to avoid pessimistically over-allocating the maximum possible space an uncompressed rangeproof might ever occupy. Also, SECP256K1_BULLETPROOFS_RANGEPROOF_UNCOMPRESSED_MAX_LENGTH_ is redefined as a short-cut leveraging the new convenience macro. This both makes clear from where the maximum length is derived, and should avoid the two macros drifting apart should the expected size change (e.g., if compression is supported in the future).

apoelstra · 2022-08-27T17:21:09Z

Rebased again just to sign the commits for github

sanket1729

ACK 6463ffb. Reviewed the range-diff from my previous review.

apoelstra · 2022-12-14T20:23:02Z

Closing in favor of #205 and #207.

apoelstra mentioned this pull request Nov 24, 2020

Bulletproofs (rangeproofs only) #23

Closed

real-or-random self-requested a review November 24, 2020 07:56

apoelstra mentioned this pull request Nov 25, 2020

Remove unused context initializer functions #107

Merged

jonasnick closed this Jan 12, 2021

jonasnick deleted the branch BlockstreamResearch:master January 12, 2021 20:28

jonasnick reopened this Jan 12, 2021

apoelstra changed the base branch from secp256k1-zkp to master January 12, 2021 20:39

apoelstra force-pushed the 2020-11--bulletproofs1-uncompressed branch from 23efce5 to 027adf3 Compare June 15, 2021 22:14

apoelstra mentioned this pull request Jan 12, 2022

bulletproofs: expose a macro returning proof-size apoelstra/secp256k1-zkp#13

Closed

apoelstra force-pushed the 2020-11--bulletproofs1-uncompressed branch from a16c9e5 to 7dc6e3f Compare July 12, 2022 20:20

robot-dreams reviewed Jul 22, 2022

View reviewed changes

real-or-random removed their request for review July 29, 2022 16:21

apoelstra force-pushed the 2020-11--bulletproofs1-uncompressed branch from 7dc6e3f to 4122783 Compare August 3, 2022 18:10

robot-dreams reviewed Aug 10, 2022

View reviewed changes

sanket1729 reviewed Aug 14, 2022

View reviewed changes

apoelstra force-pushed the 2020-11--bulletproofs1-uncompressed branch from 0ab55a5 to ad4c46f Compare August 27, 2022 17:16

apoelstra and others added 15 commits August 27, 2022 17:20

MOVE ONLY: move Pedersen commitment stuff to generator module from ra…

e2061cb

…ngeproof module You can verify this commit with `git diff --color-moved=zebra`

Revert "Remove unused scalar_sqr"

a4ce304

This reverts commit 5437e7b.

generator: cleanups in Pedersen/generator code

290c479

Silence a compiler warning about an unitialized use of a scalar in case the user tries to provide a 0-length list of commitments. Also ensures that commitments have normalized field elements when they are loaded into ges.

bulletproofs: add new empty module

2cc4261

bulletproofs: add API functionality to generate a large set of genera…

b2cdcee

…tors

bulletproofs: implement step 0 of the uncompressed prover

31b998d

bulletproofs: implement step 1 of the uncompressed prover

3385353

bulletproofs: implement step 2 of the uncompressed prover

28c5f18

bulletproofs: implement the iterative step of the uncompressed prover

2e651b9

bulletproofs: implement prove/verify API, still have the actual EC ch…

264924c

…eck to do

bulletproofs: finish the uncompressed verifier

28d8c3c

bulletproofs: add benchmark

ecea06c

bulletproofs: add SECP256K1_WARN_UNUSED_RESULT to all the non-void AP…

e22225c

…I functions

bulletproofs: use tagged hash for committed data within proof

c1d6e95

apoelstra force-pushed the 2020-11--bulletproofs1-uncompressed branch from ad4c46f to 6463ffb Compare August 27, 2022 17:20

sanket1729 approved these changes Aug 29, 2022

View reviewed changes

sanket1729 mentioned this pull request Oct 27, 2022

Bulletproofs++: Norm argument #205

Merged

apoelstra closed this Dec 14, 2022

	/* `G_i`, `H_i` generators, `n` each of them which are generated when creating this struct */
	/* n total generators; set n = 2k to get G_i and H_i values for i in [1..k] /

		/** Initialize a context for usage with Pedersen commitments. */
		void secp256k1_pedersen_context_initialize(secp256k1_context* ctx);

		/** Initialize a context for usage with Pedersen commitments. */
		void secp256k1_rangeproof_context_initialize(secp256k1_context* ctx);

		[enable_module_bulletproofs=$enableval],
		[enable_module_bulletproofs=no])

	* gens: pointer to the generator set to use, which must have 2*n_bits generators
	* gens: pointer to the generator set to use, which must have at least 2*n_bits generators

+/* Generators (paper -> implementation):
+ *    g -> asset_gen
+ *    h -> default secp256k1 generator
+ *    *g*, *h* vectors -> gens
+ */


		secp256k1_scalar_chacha20(&tmp_l, &tmp_r, nonce, i + 2);

		secp256k1_ecmult_const(&stermj, &gens->gens[2 * i], &tmp_l, 256);

Uncompressed Bulletproof Rangeproofs #108

Uncompressed Bulletproof Rangeproofs #108

Conversation

apoelstra commented Nov 24, 2020 • edited Loading

jonasnick commented Jan 12, 2021

apoelstra commented Jun 15, 2021

dr-orlovsky commented Jan 13, 2022

apoelstra commented Jan 13, 2022

dr-orlovsky commented Jan 13, 2022

apoelstra commented Jan 13, 2022

dr-orlovsky commented Jan 13, 2022 • edited Loading

dr-orlovsky commented Jan 13, 2022

dr-orlovsky commented Jan 13, 2022 • edited Loading

apoelstra commented Jan 13, 2022

dr-orlovsky commented Jan 13, 2022

ChristopherA commented Jan 13, 2022

apoelstra commented Jan 14, 2022

dr-orlovsky commented Jan 14, 2022

apoelstra commented Jul 12, 2022

robot-dreams left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

robot-dreams Jul 22, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apoelstra commented Aug 3, 2022

robot-dreams left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apoelstra commented Aug 11, 2022

robot-dreams commented Aug 11, 2022

apoelstra commented Aug 11, 2022

sanket1729 commented Aug 12, 2022

real-or-random commented Aug 12, 2022

apoelstra commented Aug 12, 2022

sanket1729 left a comment • edited Loading

Choose a reason for hiding this comment

sanket1729 Aug 12, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apoelstra commented Nov 24, 2020 •

edited

Loading

dr-orlovsky commented Jan 13, 2022 •

edited

Loading

dr-orlovsky commented Jan 13, 2022 •

edited

Loading

robot-dreams left a comment •

edited

Loading

robot-dreams Jul 22, 2022 •

edited

Loading

sanket1729 left a comment •

edited

Loading

sanket1729 Aug 12, 2022 •

edited

Loading

sanket1729 Aug 14, 2022 •

edited

Loading