While reading BIP 374 I doubted the footnote for why include G ("While all other BIPs have used the generator point from secp256k1, passing it as an input here lets this algorithm be used for other curves") because for it to be able to support other curves it would need more parameters such as the group order.
Looking at the original comment that suggested it, it was about supporting other bases in secp256k1 and not other curves.
This clarifies the footnote and also fix some other small nits.
Concept ACK on the footnote fix. "Other curves" was wrong: BIP374 takes its notation from BIP327, which fixes secp256k1 and its order n, and n is not an input, so G is the only curve parameter that can change. The rewritten verification sentence, with A = a⋅G and C = a⋅B, is also clearer.
106 | @@ -107,7 +107,7 @@ The algorithm ''VerifyProof(A, B, C, proof, G, m)'' is defined as: 107 | * Fail if ''is_infinite(R<sub>2</sub>)''. 108 | * Let ''m' = m if m is provided, otherwise an empty byte array''. 109 | * Fail if ''e ≠ int(hash<sub>BIP0374/challenge</sub>(cbytes(A) || cbytes(B) || cbytes(C) || cbytes(G) || cbytes(R<sub>1</sub>) || cbytes(R<sub>2</sub>) || m')) mod n''. 110 | -* Return success iff no failure occurred before reaching this point. 111 | +* Return success if no failure occurred before reaching this point.
Nit: I'd keep "iff" here, which means "if and only if" and matches BIP340's identical line. With the "Fail if" steps above, both words give the same result, so this is only about consistency.
* Return success iff no failure occurred before reaching this point.
Thanks! lol I thought it was a typo. Updated on af1e6e27c772310c642cfff80c4f04b58b63a439
ACK af1e6e27c772310c642cfff80c4f04b58b63a439. The force-push since my Concept ACK only restores "iff" at line 110, so that review holds at this head.
ACK af1e6e27c772310c642cfff80c4f04b58b63a439
Thanks!