In practice, all our methods consume either a
merlin::Transcript which developers create handily by feeding data to context specific builders. We do however also support
&mut merlin::Transcript like the
merlin crate prefers. We shall exploit this in future to adapt schnorrkel to better conform with the dalek ecosystem's zero-knowledge proof tooling.
We model the VRF itself on "Making NSEC5 Practical for DNSSEC" by Dimitrios Papadopoulos, Duane Wessels, Shumon Huque, Moni Naor, Jan Včelák, Leonid Rezyin, andd Sharon Goldberg. We note the V(X)EdDSA signature scheme by Trevor Perrin at is basically identical to the NSEC5 construction. Also, the VRF supports individual signers merging numerous VRF outputs created with the same keypair, which parallels the "DLEQ Proofs" and "Batching the Proofs" sections of "Privacy Pass - The Math" by Alex Davidson, and "Privacy Pass: Bypassing Internet Challenges Anonymously" by Alex Davidson, Ian Goldberg, Nick Sullivan, George Tankersley, and Filippo Valsorda.
Aside from some naive sequential VRF construction, we currently only support the three-round MuSig for Schnorr multi-signatures, due to all other Schnorr multi-signatures being somewhat broken. In future, we should develop secure schemes like mBCJ from section 5.1 starting page 21 of https://eprint.iacr.org/2018/417 however mBCJ itself works by proof-of-possession, while a delinearized variant sounds more applicable.