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

Jeff Burdges <> Tue, 27 April 2021 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1004A3A0CE8 for <>; Tue, 27 Apr 2021 03:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sJWryG2YdGfP for <>; Tue, 27 Apr 2021 03:35:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 824283A0CE5 for <>; Tue, 27 Apr 2021 03:35:57 -0700 (PDT)
Received: from [] ( [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by (Postfix) with ESMTP id 4DA831C00D2; Tue, 27 Apr 2021 12:37:54 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Jeff Burdges <>
In-Reply-To: <>
Date: Tue, 27 Apr 2021 12:35:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <20210423195504.d6f74x4jsdrzagcc@muon> <> <> <> <> <>
To: Quan Thoi Minh Nguyen <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [CFRG] Escalation: time commitment to fix *production* security bugs for BLS RFC v4?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Apr 2021 10:36:03 -0000

> On 25 Apr 2021, at 20:23, Quan Thoi Minh Nguyen <> 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
3.  non-BLS VUF that support vastly more scalable DKGs
4.  zkSNARKs of correct behavior in non-scalable DKGs

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


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.