Die DLEQ-Challenge in BIP-375 wurde nicht modulo Gruppenordnung reduziert
Pull Request #2304 von Bruce039 ist in das BIPs-Repository eingegangen und berührt eine einzige Datei - bip-0375/deps/dleq.py - mit drei Ergänzungen und einer Löschung. Der Kern ist ein Operator. In dleq_challenge wird der aus den gehashten Eingaben gebildete und aus Bytes gewandelte Wert nun als ... ) % GE.ORDER zurückgegeben statt als rohe ganze Zahl, und in dleq_verify_proof kommen zwei Zeilen hinzu.

Was das bedeutet
Ein DLEQ-Beweis - Gleichheit diskreter Logarithmen - zeigt, dass zwei öffentliche Punkte denselben geheimen Skalar teilen, ohne ihn zu verraten; BIP-375 führt einen in seinen Referenzabhängigkeiten. Die Challenge in so einem Beweis ist ein Skalar, muss also im Bereich der Gruppenordnung liegen. Leitet man sie durch Hashen ab und behandelt das Ergebnis als Ganzzahl, entsteht ein Wert, der meistens im Bereich liegt und manchmal nicht. Die Reduktion modulo GE.ORDER macht das ausdrücklich statt zufällig.
Warum ein Diff von einem Operator in einer Referenzimplementierung erwähnenswert ist: Interoperabilität. Referenzcode in einem BIP ist das, was unabhängige Implementierer lesen, um zu entscheiden, was ihr eigener Code tun muss - und eine nicht reduzierte Challenge ist genau das Detail, das zwei Implementierungen unterschiedlich behandeln, ohne dass es jemandem auffällt: die Abweichung zeigt sich nur bei Eingaben, deren Hash über der Ordnung liegt, und das ist selten genug, um jeden handgeschriebenen Test zu bestehen. Wer reduziert, erzeugt eine andere Challenge, und der Beweis scheitert implementierungsübergreifend aus Gründen, die wie Datenkorruption aussehen.
Die allgemeine Form kennt man auch außerhalb der Kryptografie: ein Wert mit angegebenem Wertebereich, eine Operation, die den Bereich nicht erzwingt, und ein Testkorpus, der ihn nie verlässt. Die Lösung ist, die Bedingung ausführbar statt dokumentarisch zu machen. Wer BIP-375 gegen diese Referenz implementiert, sollte die zwei neuen Zeilen in dleq_verify_proof mitnehmen: dass Prüfung und Erzeugung gleichzeitig ändern, ist der Weg, auf dem ein Versionsversatz zum Kompatibilitätsfehler wird.