Write a Specification for the repo

[drskalman]

• Spec Pedersen-VRF @drskalman
• Spec Ring-Proof @swasilyev
• IETF VRF
• Add test vectors to the spec (for the stuff we spec)

Open Points

So that we're all on the same page and we can have a constructive discussion

• Scalars encoding

  • arkworks encodes big scalars (e.g. points coordinates) in little endian. Is this fine?
  • ark-transcript encodes u32 (lengths) in big endian. Should be little endian instead? (more akin to SCALE)

• Using Edwards form vs Weierstrass form

  • Currently bandersnatch-vrfs is using Weierstrass form (mostly because of ring-proof requirements). At application level we want to encode compressed points in 32 bytes so Edwards form may be preferred (also used by zcash).
  • Change ring-proof API to take points in Edwards form.
  • Does the aforementioned point affect performance? Specifically, when constructing the verifier and passing the list of public keys in Edwards form, should this list of public keys be converted into Weierstrass form internally?

• (For Sassafras/Safrole) For the "plain VRF" (i.e. not the ring one) should we stick with Thin-VRF or switch to RFC 9381?

• If we go with RFC 9381 we need to add associated data to the challenge.

• says there is something wrong with computing $k$

• If we decide to use Thin-VRF we need to spec it.

• ark-transcript appends the length after each item is pushed to the transcript.

  • Should we add a method which doesn't push the length to implement stuff specd differently (e.g. RFC 9381)?
  • BTW, should be noted that if we add RFC 9381 to bandersnatch-vrfs (not to replace thin-vrf, but as an alternative option) then the transcript can be manually created and then fed in one shot to ark-transcript (which also has a constructor taking a byte slice)
  • BTW ArkTranscript adds word challenge before hashing that is not what RFC9381 calls for.

• Hash to field: hashing algorithm (RFC-9380): XMD:Sha512

• Map to curve: We need to introduce Elligator2 as soon as ark-ec 0.4.3 is released. Should ship with this

@drskalman @swasilyev @burdges @AlistairStewart @davxy @andresilva

[drskalman]

• We don't need to spec thin vrf for now.
• Get the definition of VRF from the thin vrf paper but add a VRF.eval to the definition.

[davxy]

Some notes that could help during ThinVRF specs writing :

• RFC 9381 in a nutshell: https://hackmd.io/@davxy/B1EB_Yr0p
• Bandersnatch-VRFs / DLEQ-VRFS: https://hackmd.io/@davxy/Hkm2dKSCa

[burdges]

ark-transcript is robust when used in a larger protocol, like here the same transcript could be used for dleq_vrf and ring-proof. We do this because it's cheap and saves us thinking about things later.

Should we add a method which doesn't push the length to implement stuff specd differently (e.g. RFC 9381)?

No.

The only other serious preposal for robust domain speration in hashing is the SAFE API, which works similarly, but optimized for SNARKs. SAFE API produces a single domain seperation constant, but fills your code with panics if any of the lengths are wrong, etc. It's a nice ida for SNARKs, but they've not made it user friendly enough.

BTW ArkTranscript adds word challenge before hashing that is not what RFC9381 calls for.

We should discuss if this should be something else besides the label "challenge", like maybe a 0x0000, but again we want this to be a clean seperation, because then we do not need to think about it again.

In general, RFC9381 is unsuitable for our use cases. If you can reference RFC9381 usefully then great, but you will break things if you start making changes based upon RFC9381.

[burdges]

We do kinda need vrfs_merge + thin_vrf in sassafras btw, because the claim must uniquely link the ticket. The erased key links the ticket, but maybe no longer exists by claim time. We thus need one common VRF pre-output shared between the ring_vrf and the thin_vrf that claims the ticket, and one VRF pre-output that was never before revealed.

[swasilyev]

https://hackmd.io/ulW5nFFpTwClHsD0kusJAA

[davxy]

Done