diff --git a/bip-0374.mediawiki b/bip-0374.mediawiki
index 7e3bdffb..50a9b583 100644
--- a/bip-0374.mediawiki
+++ b/bip-0374.mediawiki
@@ -64,7 +64,7 @@ Input:
 * The secret key ''a'': a 256-bit unsigned integer
 * The public key ''B'': a point on the curve
 * Auxiliary random data ''r'': a 32-byte array<ref name="why_include_auxiliary_random_data"> ''' Why include auxiliary random data?''' The auxiliary random data should be set to fresh randomness for each proof. The same rationale and recommendations from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#default-signing BIP340] should be applied.</ref> 
-* The generator point ''G'': a point on the curve<ref name="why_include_G"> ''' Why include the generator point G as an input?''' 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.</ref>
+* The generator point ''G'': a point on the curve<ref name="why_include_G"> ''' Why include the generator point G as an input?''' While all other BIPs have used the generator point from secp256k1, passing it as an input here lets this algorithm be used for other generators on secp256k1.</ref>
 * An optional message ''m'': a 32-byte array<ref name="why_include_a_message"> ''' Why include a message as an input?''' This could be useful for protocols that want to authorize on a compound statement, not just knowledge of a scalar. This allows the protocol to combine knowledge of the scalar and the statement.</ref>
 
 The algorithm ''GenerateProof(a, B, r, G, m)'' is defined as:
@@ -87,15 +87,15 @@ The algorithm ''GenerateProof(a, B, r, G, m)'' is defined as:
 
 === DLEQ Proof Verification ===
 
-The following verifies the proof generated in the previous section. If the following algorithm succeeds, the points ''A'' and ''C'' were both generated from the same scalar. The former from multiplying by ''G'', and the latter from multiplying by ''B''.
+The following verifies the proof generated in the previous section. If the following algorithm succeeds, the points ''A'' and ''C'' were both generated from the same scalar ''a'', i.e. ''A = a⋅G'' and ''C = a⋅B''.
 
 Input:
 * The public key of the secret key used in the proof generation ''A'': a point on the curve
 * The public key used in the proof generation ''B'': a point on the curve
 * The result of multiplying the secret and public keys used in the proof generation ''C'': a point on the curve
 * A proof ''proof'': a 64-byte array
-* The generator point used in the proof generation ''G'': a point on the curve<ref name="why_include_G"> ''' Why include the generator point G as an input?''' 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.</ref>
-* An optional message ''m'': a 32-byte array<ref name="why_include_a_message"> ''' Why include a message as an input?''' This could be useful for protocols that want to authorize on a compound statement, not just knowledge of a scalar. This allows the protocol to combine knowledge of the scalar and the statement.</ref>
+* The generator point used in the proof generation ''G'': a point on the curve<ref name="why_include_G" />
+* An optional message ''m'': a 32-byte array<ref name="why_include_a_message" />
 
 The algorithm ''VerifyProof(A, B, C, proof, G, m)'' is defined as:
 * Fail if any of ''is_infinite(A)'', ''is_infinite(B)'', ''is_infinite(C)'', ''is_infinite(G)''