BIP-374: treat challenge hash result `e` as scalar #2262

pull theStack wants to merge 2 commits into bitcoin:master from theStack:bip374_treat-e-as-scalar changing 4 files +24 −5

theStack commented at 3:08 PM on August 19, 2026: contributor

The purpose of this change is primarily to improve clarity for implementers (e.g. in libsecp [1]) and for consistency with existing BIPs like e.g. BIP-340 and BIP-327, where the challenge hash result is reduced modulo the curve order as well:

https://github.com/bitcoin/bips/blob/857a7debc6625a3dadbaecee1ee7b2ed5e8ada75/bip-0340.mediawiki?plain=1#L156 https://github.com/bitcoin/bips/blob/857a7debc6625a3dadbaecee1ee7b2ed5e8ada75/bip-0327.mediawiki?plain=1#L434

It seems not strictly needed from a pure specification point of view, but I think it makes sense to treat e as scalar throughout, given that we perform scalar operations at the proof generation side for calculating $s = (k + e \cdot a) \bmod n$, so implementers would need to do a conversion (and hence decide whether to wrap-around or not) anyways.

Under the assumption that reaching a challenge hash with e >= n is negligible, I think this change can be treated as logically equivalent and thus backwards compatible (but maybe there is more subtlety to it that I don't see); note that the newly introduced test vectors would also fail without the new early rejection branch, but at a later point due to not fulfilling the verification equation.

Thanks to @macgyver13 for making me aware that e is currently not specified to be in the scalar range.

[1] see PRs https://github.com/bitcoin-core/secp256k1/pull/1651 and https://github.com/bitcoin-core/secp256k1/pull/1802

BIP-374: treat challenge hash result `e` as scalar, bump to version 0.3.0

Note that the purpose of this change is primarily to improve clarity
for implementers and consistency with existing BIPs like BIP-340 and
BIP-327. Under the assumption that reaching a challenge hash with
`e >= n` is negligible, the newly introduced test vectors in the next
commit would also fail without the new rejection branch.

c88e295d92

BIP-374: add test vectors for out-of-range proof values fc874dd5d3
theStack commented at 3:10 PM on August 19, 2026: contributor

pinging the BIP-374 co-authors and some "friendly cryptographers from next-door" :-) @andrewtoth @jonasnick @real-or-random @RubenSomsen @sipa
jonatack added the label BIP Update by Owner on Aug 19, 2026
in bip-0374/reference.py:39 in c88e295d92 outdated
```
  35 | @@ -36,7 +36,7 @@ def dleq_challenge(
  36 |              + m,
  37 |          ),
  38 |          "big",
  39 | -    )
  40 | +    ) % GE.ORDER
```
theStack commented at 3:16 PM on August 19, 2026:

leaving a note for reviewers that we could also take better use of secp256k1lab's types in the reference implementation (e.g. directly return a Scalar here instead of working with ints), but that's out of scope for this PR
murchandamus commented at 9:36 PM on September 18, 2026: member

Hey, @theStack, what’s the next step here? Is this ready for merge, would you like to wait longer for the other authors to chime in, or is there something else that we should wait for?
macgyver13 commented at 7:44 PM on September 19, 2026: contributor
ACK fc874dd

Ran both gen_test_vectors.py and run_test_vectors.py locally. Generation produces expected csv output with new proof vectors 15 and 16, matches the committed version. The runner correctly rejected invalid proofs. BIP text changes look good to me.
```
python run_test_vectors.py
...
Test vector [#15](/bitcoin-bips/15/): (Proof with e equal to curve order)
 * Passed proof verification test.
Test vector [#16](/bitcoin-bips/16/): (Proof with s equal to curve order)
 * Passed proof verification test.
   
All test vectors passed.
```
jonatack commented at 3:20 AM on September 21, 2026: member

ACK
jonatack merged this on Sep 21, 2026
jonatack closed this on Sep 21, 2026

Contributors

Labels

Linked (view graph)

#2304 bip375: sync vendored DLEQ code with BIP-374 #2309 bip375: import DLEQ from BIP-374 instead of vendoring