BIP-374 now reduces its challenge modulo the curve order
Serguey Asael Shinder2 min readBIP-374, the draft specification for discrete log equality (DLEQ) proofs, moved to version 0.3.0 on 21 September. The change is small, mechanical, and exactly the kind of thing that decides whether two implementations agree.
In GenerateProof, the challenge is now computed as the hash reduced modulo the curve order: e = int(hash_BIP0374/challenge(...)) mod n. In VerifyProof, the verifier reads e = int(proof[0:32]) and must now fail if e >= n — the same guard that already applied to s. The reference implementation carries both changes, and the test vector generator gained two new negative cases: a proof whose e equals the curve order, and one whose s does.
The BIP is authored by Andrew Toth, Ruben Somsen and Sebastian Falbesoner, is licensed BSD-2-Clause, and remains Draft.
What it means
An unreduced scalar is an interoperability bug waiting for the one input that exposes it. A 256-bit hash is occasionally larger than the order of the secp256k1 group. Libraries that reduce implicitly and libraries that do not will produce the same proof for almost every input and different results for the rare one — and the failure lands on whoever generated that proof, not on the implementer who was sloppy.
Rejecting out-of-range values on the verify side is the half that matters for safety. Making generation deterministic fixes agreement between honest parties. Refusing e >= n removes a class of malleability where a proof could be re-encoded with an equivalent but different scalar.
The test vectors are the deliverable here, not the prose. A spec that says "fail if e is out of range" is a sentence implementers can skip; a vector file with a case whose e equals the curve order is a test that goes red. Both new cases shipped in the same commit.