In response, it was explained that using compressed key serialization for verification is the easiest choice since public keys can have either even or odd Y coordinates and changing this would break existing key generation mechanisms. When it comes to choosing between (e,s) and (R,s) for signature encoding, there is hardly any benefit for choosing the former over the latter in elliptic curve-based Schnorr. For batch verification, randomization factors are generated independently by the verifier to prevent attackers from cancelling out valid signatures with invalid ones. As for the random number used for signing, while the BIP requires signers to use deterministically generated nonces, it cannot be enforced by the verifier due to privacy implications. Finally, some clarifications were made regarding the motivation behind standardized signatures, the typical message format, and some minor issues pointed out in a pull request.