pg. 11 In definition of GenerateProof appears the only use of the mod operator on scalars (it is used elsewhere on integers):
s = (r - c*k) mod G.order().
To be consistent, consider replacing with s = (r - c*k) as scalars lie in GF(p).
pg. 24. 3.3.3, raise InverseError when skS + m = 0.
While it is common practice to return an error message, here the server learns that the key skS is leaked as m is known externally. Given that this is being checked, perhaps add a warning that it may be time to rekey.
The proof batching via ComputeCompositesFast requires 3 + i scalar multiplications to generate a proof for a batch of size i. It's fairly complicated and spans over 4 pages. However, the "basic scheme" in [ChaumPedersen] requires 2 such multiplications for a single proof, and is simple/intuitive. Given that, I think it makes sense to include it in the draft and perhaps move the batching method to an annex as an option. (FWIW I did spend a few cycles looking at the batching proof and the steps taken do seem necessary).
Comment: The original proof by Chaum-Pedersen takes 2*N multiplications to process N instances of the proof. The batched proof in VOPRF document takes N+3 multiplications.
This means that the batched method has more advantage when:
$$
\begin{array}%
2 N \geq N+3 \
N \geq 3 \
\end{array}
$$
Thus, the cases N=1,2 could be subpar, but it is expected that applications relying on batched VOPRFs benefit from this method.
Addresses the comments by NG posted in the list
Comment: The original proof by Chaum-Pedersen takes 2*N multiplications to process N instances of the proof. The batched proof in VOPRF document takes N+3 multiplications. This means that the batched method has more advantage when:
$$ \begin{array}% 2 N \geq N+3 \ N \geq 3 \ \end{array} $$
Thus, the cases N=1,2 could be subpar, but it is expected that applications relying on batched VOPRFs benefit from this method.