Re: [Cfrg] I-D Action: draft-irtf-cfrg-vrf-06.txt

[Jeff Burdges <[e-mail]>]

Almost all proof-of-staake blockchain protocols require VRFs for various purposes, including driving random beacons, leading block production or BFT agreement processes, or selecting validation assignments in sharding situations.

Identity schemes come in many flavours, but they should be built on ring or group VRFs, or maybe similar constructions like linkable ring signatures, whenever they must (1) prevent Sibel attacks, and (2) be useable for a wide variety of purposes, and (3) do not trust some issuer with user privacy.

In essence, Sibel protections require some uniqueness per key holder, but being general purpose means that uniqueness must differ across domains to whom the key holder identifies themselves, so that unique amounts to a VRF output, and you need ring or group to hide what key generates it.

There are SNARK constructions that drop (3) and maybe avoid key pairs, making them not "VRF signatures” like described in this draft, but they still possess roughly the same sort of uniqueness, etc. definitions from section 3 of this craft.

Jeff





> On 11 Feb 2020, at 22:50, Manu Sporny <[e-mail]> wrote:
> 
> On 2/11/20 12:31 PM, Leonid Reyzin wrote:
>> This most recent update to the VRF draft consists of minor clarifications.
> 
> Hi Leo, Sharon, Jan, and Dimitris,
> 
> I've been following this work for years now and I still don't know why
> VRFs are useful. Every time you publish a new draft, I got out and scour
> the Web for an easily readable description of a use case that is solved
> by the use of a VRF and end up reading things like:
> 
> "It is a pseudo-random function that provides publicly verifiable proofs
> of its outputs' correctness."
> 
> "VRFs are useful for preventing enumeration of hash-based data structures."
> 
> "VRFs ... useful for providing a 1:1 mapping of low entropy inputs (e.g.
> names, email addresses, phone numbers) to some random values which can
> be committed to in advance, e.g. through a timestamping service such as
> a transparency log."
> 
> I say this as someone that spends quite a bit of time reading IETF
> cryptography specs and writing specifications that directly utilize
> IETF/CFRG cryptography specs (at IETF and W3C).
> 
> Can you please add a few real world use cases where one would use a VRF?
> Are they useful for committing values on a public blockchain in a
> privacy preserving manner? If so, what sorts of values? Are they useful
> when voting? Are they useful for distributed gaming scenarios? Some
> concrete uses would be more helpful than the overly general text in the
> current spec.
> 
> -- manu