Re: [CFRG] Escalation: time commitment to fix *production* security bugs for BLS RFC v4?

[Jeff Burdges <[e-mail]>]

> On 25 Apr 2021, at 20:23, Quan Thoi Minh Nguyen <[e-mail]> wrote:
> Things will get messier quickly.

This is not a forum where things should be rushed.  If an organizations wants to move fast then it should hire people who can do so securely.  

At its core BLS is a signature for consensus protocols, but consensus protocols require coherent software, invariably led by one organization, and always require an upgrade path, and they’ll always have upgrades in the pipe anyways.  We could tweak BLS every year for then next ten years with zero real harm done.

Increasingly, the serious BLS proponents have turned towards even fancier verification strategies, including:
1.  zkSNARKs verifying BLS with extra properties, ala Celo,
2.  inner pairing product arguments compressing BLS https://eprint.iacr.org/2019/1177
3.  non-BLS VUF that support vastly more scalable DKGs https://eprint.iacr.org/2021/005
4.  zkSNARKs of correct behavior in non-scalable DKGs https://eprint.iacr.org/2021/339

We’re a very long ways from establishing any human consensus across organizations over what really makes sense. 

Jeff

p.s.  It never came up, but you literally cannot deploy BLS for account keys on blockchains because then some asshat writes BIP32-BLS, and their users loose all their funny money.  It’s safer for users if developers stay scared of BLS for a while longer.