Re: [CFRG] Bitcoin delenda est. Was: Escalation: time commitment to fix *production* security bugs for BLS RFC v4?

Phillip Hallam-Baker <> Mon, 26 April 2021 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D73B3A2352 for <>; Mon, 26 Apr 2021 12:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GYrG7_0HJard for <>; Mon, 26 Apr 2021 12:07:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 887B33A2351 for <>; Mon, 26 Apr 2021 12:07:58 -0700 (PDT)
Received: by with SMTP id z1so66209738ybf.6 for <>; Mon, 26 Apr 2021 12:07:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eu48YdWyXXig80BZH7DbCMOwYpLTqGybH+yjZLp6pSE=; b=myOpsrDUqE/b0qYC4AOsN7Rr7fIOt4DCV0MsDOC40JgUk67G1iCJisLwUiIYq5bNLL 6ZPJXDP5UL0d31fe1qaC1WhWUG2GYXDkVYLDX/1FpgcNq51HcbFDTQVy9FZ3pWYMgNWp lJ3xq+UMNwuNJfG68+iu0xI0VUyQ/UxSQATHE3qpF9/HEf5kMpf4UNBcP8CeCz1AJY6K rMs2Wnlx+vCJJvT/Z9Ueplhzkmw/8BCSzI0bWnWBXfHkGU60cmwFprVvIXlQOrAvQIcL 65eTOP/6Hxdko16BbNtnQ0gFnSClCD7LxzKAoAzuq3D8frRVeiqXUnsb6KZl6Cmckssk sDqw==
X-Gm-Message-State: AOAM532S3HxIgf1jMssOYvcL5NxcDP/PNeEnwdzAe7biuqq2CW0b2DAT UXNKhtKHWgEgR+Ra7UEFYPkmmwx4rgR39EqpaqA=
X-Google-Smtp-Source: ABdhPJy9TfOqXwCwRZmFIWRwP5te9B7v4ZuCyATDJCPLyHkxxwxPBR49UfDzkYAFlAFA5KVFOdRwwe1AaLAtx5FNZW4=
X-Received: by 2002:a25:b186:: with SMTP id h6mr13350768ybj.523.1619464077407; Mon, 26 Apr 2021 12:07:57 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210423195504.d6f74x4jsdrzagcc@muon> <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Mon, 26 Apr 2021 15:07:47 -0400
Message-ID: <>
To: Daniel Franke <>
Cc: "Salz, Rich" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000000f784a05c0e4dd43"
Archived-At: <>
Subject: Re: [CFRG] Bitcoin delenda est. Was: 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: Mon, 26 Apr 2021 19:08:00 -0000

On Mon, Apr 26, 2021 at 1:54 PM Daniel Franke <> wrote:

>  I share your alarm at the economic waste and environmental harm inherent
> in proof-of-work-based cryptocurrency. (I do not share your other
> objections, and see great promise in permissioned and proof-of-stake-based
> blockchains). But what does this have to do with the instant draft? We're
> not specifying a proof-of-work function. We're specifying a pairing-based
> signature scheme — something with myriad applications beyond
> cryptocurrency. Your argument reminds me of demands that we compromise, or
> not build, end-to-end encryption schemes because they will be useful to
> terrorists. The IETF has categorically rejected those arguments. Why should
> we accept yours?

Providing communications between individuals unrestricted by government
diktat has always been understood as core to the IETF mission. Providing a
means for Ponzi scammers to get rich has not.

The original article is predicated on the claim that the IETF should do
something urgently in order to prevent harm to the cryptocurrency
communities that have deployed on the basis of a draft. I am arguing that
this is a reason to delay rather than accelerate response.

It is well known I am pretty keen on threshold crypto. But I have yet to
see a really compelling case for threshold signatures that cannot be met by
multi-signatures that involves more than one distinct party. I can see real
purpose in using a threshold t out of n signature scheme to back up a t out
of n quorum redundancy scheme. I can see real purpose in splitting
signatures across multiple HSMs. But these are all applications where there
is one principal and there are multiple shares required to create a
signature (e.g. signing the DNS root zone) and all make use of completely
standard algorithms.

The only reason to go to pairing is if you want a random collection of
parties that are not co-operating to sign. And that is a concern that is
pretty much unique to BitCoin et. al.