Add DLEQ proof implementing BIP 374 #1802

macgyver13 commented at 1:39 AM on January 15, 2026: none

This PR adds a DLEQ (Discrete Logarithm Equality) proof module as specified in BIP 374.

Based on PR [#1651](/bitcoin-core-secp256k1/1651/) by @stratospher and the secp256k1-zkp implementation.

Public API

Exposes two functions for proof generation and verification:

secp256k1_dleq_prove
secp256k1_dleq_verify

These are designed to support rust FFI bindings and follow the API patterns established in similar modules.

Questions for Reviewers

Should this module be optional (current behavior) or enabled by default?
Are there additional changes needed to support existing Silent Payments PRs?
Feedback on API design, documentation, and test coverage?

Notes

Addressed outstanding comments from PR [#1651](/bitcoin-core-secp256k1/1651/):

BIP-374 v0.2.0 test vectors
Proper memory clearing with memclear

furszy commented at 3:01 AM on January 15, 2026: member

Have you talked with @stratospher before opening this PR? I don’t want to draw conclusions prematurely, but opening a parallel PR that implements the same changes without first engaging on the existing one by reviewing it, leaving a comment, or waiting for the author's public response is not how we usually collaborate in open source. The lack of (co)authorship on the commits is also unusual.

If you have contacted stratospher, please ignore this comment. It's just to avoid putting the original author in an unfair or difficult position if still working on the PR.

macgyver13 commented at 3:22 AM on January 15, 2026: none

Have you talked with @stratospher before opening this PR?

Yes, stratospher and I had discussed who should submit this new PR. I drew the short straw :)

macgyver13 marked this as a draft on Jan 15, 2026

macgyver13 force-pushed on Jan 15, 2026

macgyver13 marked this as ready for review on Jan 15, 2026

in src/modules/dleq/main_impl.h:63 in 30d6f5e883

  58 | +}
  59 | +
  60 | +static int secp256k1_dleq_hash_point(secp256k1_sha256 *sha, secp256k1_ge *p) {
  61 | +    unsigned char buf[33];
  62 | +    size_t size = 33;
  63 | +    /* Reject infinity point */

stratospher commented at 7:32 AM on January 16, 2026:

2457f89d: I guess this comment might be applicable now since the public API takes in secp256k1_pubkey and the ge we get is now from there - so unlikely for it to be infinity and VERIFY_CHECK might be better. though if we think about a function in isolation - it makes sense to reject infinity point.

cc @theStack

macgyver13 commented at 8:55 PM on January 25, 2026:

45911b2c attempts to handle the 'invalid proof (e.g., all zeros)' case more clearly by moving the infinity check from secp256k1_dleq_hash_point to secp256k1_dleq_verify_internal, where R1 and R2 are computed. The check now occurs before calling secp256k1_dleq_challenge.

A check is required: invalid proofs (e.g., all zeros) will generate R1 and R2 as infinity points, which would cause verification to fail at VERIFY_CHECK(!secp256k1_ge_is_infinity(elem)); during serialization.

Open to a better solution.

in src/modules/dleq/main_impl.h:98 in 30d6f5e883

  93 | +            masked_key[i] = key32[i] ^ ZERO_MASK[i];
  94 | +        }
  95 | +    }
  96 | +
  97 | +    secp256k1_nonce_function_bip374_sha256_tagged(&sha);
  98 | +    /* Hash masked-key||msg||m using the tagged hash as per BIP-374 v0.2.0 */

stratospher commented at 7:36 AM on January 16, 2026:

2457f89d: you could clarify that msg contains A and C. and that's different from m.

in src/modules/dleq/main_impl.h:109 in 30d6f5e883

 104 | +    secp256k1_sha256_finalize(&sha, nonce32);
 105 | +    secp256k1_sha256_clear(&sha);
 106 | +    secp256k1_memclear_explicit(masked_key, sizeof(masked_key));
 107 | +}
 108 | +
 109 | +/* Generates a nonce as defined in BIP0374 v0.2.0 */

stratospher commented at 7:40 AM on January 16, 2026:

2457f89d: not sure if we should mention the exact version - we don't mention the version for other modules like musig for example. only difference in newer version is the randomness computation in proof generation anyways.

in src/modules/dleq/main_impl.h:281 in 30d6f5e883

 276 | +
 277 | +    secp256k1_dleq_pair(&ctx->ecmult_gen_ctx, &A, &C, &a, &B);
 278 | +
 279 | +    ret = secp256k1_dleq_prove_internal(ctx, &s, &e, &a, &B, &A, &C, aux_rand32, msg);
 280 | +    if (!ret) {
 281 | +        secp256k1_scalar_clear(&a);

stratospher commented at 7:49 AM on January 16, 2026:

078d2da: since we always clear a - we can move it up and out of the if condition.

in src/modules/dleq/tests_impl.h:179 in 30d6f5e883

 174 | +        const unsigned char *m = NULL;
 175 | +
 176 | +        if (i > 2 && i < 6) {
 177 | +            /* Skip tests indices 3-5: proof generation failure cases (a=0, a=N, B=infinity).
 178 | +            * These contain placeholder data from test_vectors_generate_proof.csv that would
 179 | +            * fail to parse. Only indices 0-2 and 6-12 have valid test data.

stratospher commented at 8:00 AM on January 16, 2026:

nit: 2614b2a5: extra white space

in src/modules/dleq/tests_impl.h:195 in 30d6f5e883 outdated

 190 | +
 191 | +        if (is_not_empty(msg_bytes[i])) {
 192 | +            m = msg_bytes[i];
 193 | +        }
 194 | +        
 195 | +        CHECK(secp256k1_dleq_verify_internal(&s, &e, &A, &B, &C, m) == success[i]);

stratospher commented at 8:01 AM on January 16, 2026:

nit: 2614b2a5: extra white space in blank line above

in src/modules/dleq/tests_impl.h:234 in 30d6f5e883

 229 | +    /* Check dleq verify input validation */
 230 | +    CHECK_ILLEGAL(CTX, secp256k1_dleq_verify(CTX, NULL, &A, &B, &C, msg));
 231 | +    CHECK_ILLEGAL(CTX, secp256k1_dleq_verify(CTX, proof, NULL, &B, &C, msg));
 232 | +    CHECK_ILLEGAL(CTX, secp256k1_dleq_verify(CTX, proof, &A, NULL, &C, msg));
 233 | +    CHECK_ILLEGAL(CTX, secp256k1_dleq_verify(CTX, proof, &A, &B, NULL, msg));
 234 | +

stratospher commented at 8:02 AM on January 16, 2026:

nit: 9149b57a: extra white space in blank line

in src/modules/dleq/Makefile.am.include:2 in 30d6f5e883

   0 | @@ -0,0 +1,3 @@
   1 | +include_HEADERS += include/secp256k1_dleq.h
   2 | +noinst_HEADERS += src/modules/dleq/dleq_vectors.h

stratospher commented at 8:05 AM on January 16, 2026:

2614b2a5: tests also need to be added. nit: slight ordering preference for main_impl before test vectors - you can refer some other makefile.

in tools/test_vectors_dleq_generate.py:99 in 30d6f5e883

  94 | +with open(sys.argv[1] + "/test_vectors_verify_proof.csv", newline='') as csvfile:
  95 | +    reader = csv.DictReader(csvfile)
  96 | +    for _ in range(5):  # Skip the first 5 rows since those test vectors don't use secp's generator point
  97 | +        next(reader, None)
  98 | +
  99 | +    for i in range(3):

stratospher commented at 8:07 AM on January 16, 2026:

nit: 2614b2a5: extra white space

in src/modules/dleq/main_impl.h:11 in 2457f89d8a outdated

   6 | +#ifndef SECP256K1_MODULE_DLEQ_MAIN_H
   7 | +#define SECP256K1_MODULE_DLEQ_MAIN_H
   8 | +
   9 | +#include "../../../include/secp256k1.h"
  10 | +#include "../../../include/secp256k1_dleq.h"
  11 | +

stratospher commented at 12:27 PM on January 16, 2026:

2457f89d: #include "../../hash.h"

in src/modules/dleq/tests_impl.h:9 in 2614b2a52b outdated

   0 | @@ -0,0 +1,204 @@
   1 | +/***********************************************************************
   2 | + * Distributed under the MIT software license, see the accompanying    *
   3 | + * file COPYING or https://www.opensource.org/licenses/mit-license.php.*
   4 | + ***********************************************************************/
   5 | +
   6 | +#ifndef SECP256K1_MODULE_DLEQ_TESTS_H
   7 | +#define SECP256K1_MODULE_DLEQ_TESTS_H
   8 | +
   9 | +#include "dleq_vectors.h"

stratospher commented at 12:49 PM on January 16, 2026:

2614b2a5: #include "../../unit_test.h"

stratospher commented at 11:44 AM on January 17, 2026: contributor

sorry for the confusion and thank you @macgyver13 for the PR!

did an initial pass and it looks good! mostly left style nits.

1 API design question I had is whether it would be better for the proof generation API to also accept C as an argument - that is GenerateProof(a, B, r, G, m, C) kind of API instead of GenerateProof(a, B, r, G, m).

When computing silent payment output points, we anyways compute shared secret/C for each output - so there's a possibility to avoid recomputation again if we can pass C. But current approach might be safer since callers could accidentally provide incorrect C and errors could happen.

Did you check other use cases of DLEQ for whether they might prefer passing C or computing C internally in the proof generation function?

qatkk commented at 10:06 AM on January 18, 2026: none

I have a question regarding the choice of parameters passed to this API, and I may be missing some design context here — so I’d appreciate clarification. Is there a specific reason why the second generator B is provided directly as an input? @furszy In the original proposal of DLEQ proofs by Chaum and Pedersen [1], the correctness of the protocol relies on the prover not knowing the discrete‑log relation between the two generators. Specifically, if the prover knows a scalar b such that B=b⋅G, then the two equations for the verification are no longer distinct and will be dependent on each other. In the context of silent payments (and the description provided in BIP 374) this makes sense, since B represents another user’s public key — a point for which the prover does not know the corresponding private key. However, as commented by stratospher #1651 (comment) this PR is intended to support more general DLEQ use cases, I am concerned that allowing callers to supply an arbitrary B might introduce risks in scenarios where generator independence is not guaranteed.

Other constructions with two generators on the same curve (e.g., Pedersen commitments, bulletproofs) typically derive the second generator using a hash‑to‑curve procedure, ensuring that no participant knows the discrete‑log ratio between G and B. I was wondering whether a similar approach might help avoid potential misuse here, or whether this falls outside the intended scope of this PR. I would be very interested to hear your thoughts on this. [1] D. Chaum and T. P. Pedersen, Wallet Databases with Observers, 1992. https://www.hsslb.ch/cryptopapers/other/Chaum_WalletDBswObservers.pdf

real-or-random added the label feature on Jan 23, 2026

dleq: add module structure and internal implementation

Implements BIP-374 Discrete Log Equality (DLEQ) proofs as a new module.

- Build system integration (CMake, autotools)
- Configure dleq module as "optional"
- Public API header declarations
- Internal cryptographic implementation (prove_internal, verify_internal)
- Tagged SHA256 functions per BIP-374 specification
- Nonce generation following BIP-374 v0.2.0

Co-authored-by: stratospher <44024636+stratospher@users.noreply.github.com>

91f6b9890b

dleq: add test framework and BIP-374 test vectors

- Adds test coverage for DLEQ internal functions
- BIP-374 official test vectors (6 generation + 13 verification cases)
- Includes Python script for generating test vectors matching BIP-374
specification.

Tests call *_internal functions directly. Public API tests will be added in a subsequent commit.

Co-authored-by: stratospher <44024636+stratospher@users.noreply.github.com>

029a15b556

dleq: add public API wrappers

Adds public API functions that wrap the internal DLEQ implementation:

- secp256k1_dleq_prove(): Generate DLEQ proof from secret key and base point B.
  Computes A = a*G and C = a*B internally, then generates proof.

- secp256k1_dleq_verify(): Verify DLEQ proof given A, B, C public keys.

662d4ccf12

dleq: add public API tests

Adds comprehensive tests for the public DLEQ API:

- secp256k1_dleq_prove(): Tests valid proof generation, NULL parameter
  detection, invalid secret key handling, context validation

- secp256k1_dleq_verify(): Tests valid verification, NULL parameter
  detection for all required inputs (proof, A, B, C)

a014f0b32e

ci: enable dleq module 403d24566d

dleq: Apply review feedback

Reject proofs that produce infinity points during verification
Add public API test case for infinity point scenario
Add note to clarify contents of msg to reduce confusion with m
Add missing includes
Format tools/test_vectors_dleq_generate.py

45911b2c7b

macgyver13 force-pushed on Jan 25, 2026

real-or-random commented at 1:24 PM on January 30, 2026: contributor

In the original proposal of DLEQ proofs by Chaum and Pedersen [1], the correctness of the protocol relies on the prover not knowing the discrete‑log relation between the two generators.

You probably mean soundness instead of correctness? If I'm not mistaken, this is simply not true. See for instance Nigel Smart's Cryptography: An Introduction (3rd Edition), Section 25.3.1, page 377, PDF page 389. This rather accessible write-up shows that the underlying Sigma protocol has correctness, 2-special soundness, and zero-knowledge, all with probability 1 and without any computational assumption. Technically, one doesn't even need the assumption that the discrete logarithm problem is hard in the group. Note in particular that the proof of special soundness extracts the witness and not the discrete logarithm between g and h (or G and B in our notation); the latter doesn't even show up in the proof.

Specifically, if the prover knows a scalar b such that B=b⋅G, then the two equations for the verification are no longer distinct and will be dependent on each other.

Can you elaborate and also explain why you believe that this requires the assumption that the prover doesn't know the discrete logarithm between G and B?

macgyver13 commented at 10:28 PM on February 2, 2026: none

Thank you for the review @stratospher and appreciate the curious questions about the API!

1 API design question I had is whether it would be better for the proof generation API to also accept C as an argument - that is GenerateProof(a, B, r, G, m, C) kind of API instead of GenerateProof(a, B, r, G, m).

When computing silent payment output points, we anyways compute shared secret/C for each output - so there's a possibility to avoid recomputation again if we can pass C. But current approach might be safer since callers could accidentally provide incorrect C and errors could happen.

If we accept C as an input, I would suggest computing C internally to verify correctness before calling secp256k1_dleq_prove_internal. This would counter the optimization benefit. This is the approach I took when testing that variation of the API.

Did you check other use cases of DLEQ for whether they might prefer passing C or computing C internally in the proof generation function?

I am not well versed in other DLEQ use cases outside Silent Payments, so I surveyed related applications of Discrete Log Equivalence starting with Andrew Toth's BIP-374 review on the OpTech Podcast. Below you will find a list of reviewed use cases and my assessment of whether to require output points like C as input parameters to proof generation.

DLEQ implementations reviewed:

Cashu NUT-12 - computes the blind signature C' internally as C' = a·B'
JoinMarket PODLE - computes output point P2 internally as P2 = x·J
Half-Adaptor (DLEQ with adaptors) - computes output points internally as Pₙ = x·Gₙ

Related protocols reviewed (not DLEQ-based):

Curve Trees - anonymous usage tokens from curve trees
RIDDLE - ring signatures (LSAG) with key images

I don't see a compelling reason to change the API based on these findings, but I'm open to different perspectives.

qatkk commented at 3:42 PM on February 10, 2026: none

Thanks for your response and for the explanation.

You probably mean soundness instead of correctness?

Yes — thanks for the correction.

If I'm not mistaken, this is simply not true. See for instance Nigel Smart's Cryptography: An Introduction (3rd Edition), Section 25.3.1…

Agreed. I’ve encountered DLEQ mostly in other contexts, and in particular in scenarios involving DLEQ across two different curves. In those settings, Pedersen commitments are typically used, which require the independence of the two generators. Writing out the equations explicitly for the single-curve setting makes it clear that this independence assumption is not needed here, as you point out.

Can you elaborate and also explain why you believe that this requires the assumption that the prover doesn't know the discrete logarithm between G and B?

My reasoning was that the second verification equation (the one checking R₂ in this notation) is effectively just the first verification equation multiplied by b, due to how the parameters are constructed. This made me think that knowing the discrete logarithm between G and B might collapse the two checks.