Posted by poyuholu
Oct 27, 2026/15:12 UTC
A critical review of the protocol equations reveals a significant omission of the parity factor. The computation for the input key’s secret is given as (a=\sum_i (g c_i)k_i+\tau), indicating that each coefficient should be multiplied by the parity factor (g). However, within the actual protocol, the commitment is computed as (C=\sum_i[c_i]D_i+[\tau]B), and response aggregation uses (c_i z_i) without an explicit inclusion of the parity adjustment.
This discrepancy leads to a situation where, unless the protocol’s definition of (c_i) implicitly incorporates the multiplication by (g), the resulting proof demonstrates knowledge of an incorrect discrete logarithm, particularly when (g=-1). The absence of this factor undermines the validity of the underlying cryptographic proof, as the computed values do not properly reflect the intended relationship dictated by the original secret equation.
Ensuring that the parity factor is consistently applied throughout all computations is essential for the security and correctness of the protocol. If the protocol's notation intends for (c_i) to already include the multiplication by (g), this must be clearly specified and uniformly enforced. Otherwise, the protocol risks producing invalid proofs, especially in scenarios involving negative group elements.
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback