Re: [CFRG] Bitcoin delenda est. Was: Escalation: time commitment to fix *production* security bugs for BLS RFC v4?
Phillip Hallam-Baker <phill@hallambaker.com> Mon, 26 April 2021 19:08 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D73B3A2352 for <cfrg@ietfa.amsl.com>; Mon, 26 Apr 2021 12:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYrG7_0HJard for <cfrg@ietfa.amsl.com>; Mon, 26 Apr 2021 12:07:58 -0700 (PDT)
Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887B33A2351 for <cfrg@irtf.org>; Mon, 26 Apr 2021 12:07:58 -0700 (PDT)
Received: by mail-yb1-f173.google.com with SMTP id z1so66209738ybf.6 for <cfrg@irtf.org>; Mon, 26 Apr 2021 12:07:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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: <CAAEB6g=tU=MF1_QKduEN55ft0rWe+7x0wBbywS083fJrjzP=XA@mail.gmail.com> <20210423195504.d6f74x4jsdrzagcc@muon> <CAAEB6g=dcsRKz6zm7F15F-uZ7Zfi_qF06KwQXmrireKEKZYHFg@mail.gmail.com> <49ca86ec6409217d60e3f2e94e3090ef2b571f80.camel@loup-vaillant.fr> <A1765592-7AF7-4F3A-8B22-C5BD6C059A7C@akamai.com> <CAMm+LwjKV3xT_2StxzL4X3BCeTpvwJBMmFMLQUw66xhQNkDNZA@mail.gmail.com> <CAJm83bB9CjYe6uBJ5W-AwFoUF0JF-qC6Ek0BCa-xSP_2_=N5VA@mail.gmail.com>
In-Reply-To: <CAJm83bB9CjYe6uBJ5W-AwFoUF0JF-qC6Ek0BCa-xSP_2_=N5VA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 26 Apr 2021 15:07:47 -0400
Message-ID: <CAMm+LwjGTexkxo3wCDQ8rW40H3g5QNET=TR+wf8BTGriJdUEDQ@mail.gmail.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000000f784a05c0e4dd43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/OCh5wcQZ1Iiojum29SOIloCK6os>
Subject: Re: [CFRG] Bitcoin delenda est. Was: Escalation: time commitment to fix *production* security bugs for BLS RFC v4?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2021 19:08:00 -0000
On Mon, Apr 26, 2021 at 1:54 PM Daniel Franke <dfoxfranke@gmail.com> 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.
- [CFRG] Escalation: time commitment to fix *produc… Quan Thoi Minh Nguyen
- Re: [CFRG] Escalation: time commitment to fix *pr… Riad S. Wahby
- Re: [CFRG] Escalation: time commitment to fix *pr… Quan Thoi Minh Nguyen
- Re: [CFRG] Escalation: time commitment to fix *pr… Loup Vaillant-David
- Re: [CFRG] Escalation: time commitment to fix *pr… Salz, Rich
- Re: [CFRG] Escalation: time commitment to fix *pr… Paul Hoffman
- Re: [CFRG] Escalation: time commitment to fix *pr… Quan Thoi Minh Nguyen
- [CFRG] Bitcoin delenda est. Was: Escalation: time… Phillip Hallam-Baker
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Daniel Franke
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Kyle Rose
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Michael Sierchio
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Michael Sierchio
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Kyle Rose
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Michael Sierchio
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Phillip Hallam-Baker
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Mike Hamburg
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Mike Hamburg
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Thomas Dineen
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Phillip Hallam-Baker
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Thomas Dineen
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Thomas Dineen
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … denis bider
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Eric Rescorla
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … denis bider
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Soatok Dreamseeker
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … denis bider
- Re: [CFRG] Bitcoin delenda est. Was: Escalation: … Nick Sullivan
- Re: [CFRG] Escalation: time commitment to fix *pr… Jeff Burdges