Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6C5B7C016F for ; Mon, 25 May 2020 07:03:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 5F16288179 for ; Mon, 25 May 2020 07:03:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrdnOua5VY3s for ; Mon, 25 May 2020 07:03:35 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by hemlock.osuosl.org (Postfix) with ESMTPS id 709078816A for ; Mon, 25 May 2020 07:03:35 +0000 (UTC) Received: by mail-io1-f65.google.com with SMTP id k18so17765030ion.0 for ; Mon, 25 May 2020 00:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w2rdPnBPtxmcliu39zcJ/D3f88DluIWJxXBl06ZWuE0=; b=m6ePXmfn+ckIM5nBSPYp/W+nuxKsmYJxw7ppL4HjULbrq2rOGez0ItOlQj0kWf8e2y F4GgiFutvMXizf15HXC7At60xPm8BTlo5gjNuTXRyAmm7ePrQp2sjz0XdCI/BrsDwguS yqNKulUtTnrKfG4PSKsULv5Cup14S9E6BMzGVQ0KsbXpESlYvctXlUObcc2h+IEPoIHo 7oFGZaeYXc+d2If7o5GUKPn2VBQGH1GFVYBKizC/82RpIGdTBemUziyMxirl21SDLOiO Jqcp2IXZi9qXIUFFM1m5SivvkKLsFkyWWBbBbcO8E1Pz5CsAADEo5HZNpwpEWcAb9OOj YshA== 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=w2rdPnBPtxmcliu39zcJ/D3f88DluIWJxXBl06ZWuE0=; b=lWvcCpTGrmIxrCocqrA7inRjqzjw8wAcdCjoSsjBNtd9CljH86ffoft0phiHXpVonV fVy1ooGrqUHtpBzNy01XllB2t1ZZf/ul2GCL9qWsrLnrJ6QCuoKfzB0DjLF4LNgAizNQ uxAe/qD4ILNx4YQCYmiGYun88zyCiDu9BmMRdS9yA/fWaGHuCaSGzscJKsdaGJKYRZLR YBpT+Ap9eti57gV0FLEm2fkRQp15ABjHDKxKwEk93cUUWZ90YJ9/6yWwWLHCHOsor91j tAfZrVHMJjh0dUT3XXe2I27qgmsgt+iEJoI2peEmpWgOlfo9E32kr/9RBab0g/159fwB mW2g== X-Gm-Message-State: AOAM533dvppLX/fQiPEyRof6lZ9ZP3MJ8eD+zFjE6AV/shxLQZbkI5yn wYDAFuuKAHEvv/JGS2HibRFZmYUFFs953b5oZV0= X-Google-Smtp-Source: ABdhPJzx2qik+3P1GWtjbgdt7sZeunHxZuB1P1oHunHAoKSLBrJxGz1I0LlLRiv5kHbRwgIWE94/BW/tMmPgt1P7emg= X-Received: by 2002:a6b:5b02:: with SMTP id v2mr2420351ioh.161.1590390214668; Mon, 25 May 2020 00:03:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Karl Date: Mon, 25 May 2020 03:03:20 -0400 Message-ID: To: Ariel Lorenzo-Luaces Content-Type: multipart/alternative; boundary="000000000000ccb38105a673933f" X-Mailman-Approved-At: Mon, 25 May 2020 10:20:31 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] hashcash-newhash X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 07:03:36 -0000 --000000000000ccb38105a673933f Content-Type: text/plain; charset="UTF-8" Hi Ariel, Thanks for your reply. You state that once "the entire world" can quickly find a hash that it then "needs to be changed", but that that "won't happen in a day". It sounds like you believe compromise of the algorithm as a concern provides a _lot_ of time to migrate to a new hash function, and that it is indeed important to do so when it becomes needed. Let's talk about relaxing the time scale. Making such plans seems more important than agreeing on how soon they happen. It's possible it could be decades before having a new hash is actually needed to protect financial security. Who knows. How does that land? Is the idea more available with a looser time scale? It seems to me with ongoing cryptanalysis research, new things like quantum computers, conventional computer hardware always advancing, that some day far in the future it will be easy to find an sha256 preimage on a personal device, somehow. Let's improve the security of the blockchain. On Sun, May 24, 2020, 7:51 PM Ariel Lorenzo-Luaces wrote: > On May 24, 2020, at 1:26 PM, Karl via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> You mention ASICs becoming commoditized. I'd remind you that eventually >> there will be a public mathematical breaking of the algorithm, at which >> point all ASICs will become obsolete regardless. Would you agree it would >> be better to prepare for this by planning algorithm change? >> >> Cryptographic algorithms don't usually break this way. In the case of >> hash functions it may be possible to find an exploit that reduces the >> function's security from 256 bits to 128 for example. So an algorithm that >> could find 80 zero bits per energy unit before can now find 160 zero bits >> per energy unit with an exploit. >> >> If this exploit can be deployed as a software patch to most ASICs then >> the issue will sort itself out on the next difficulty adjustment. >> >> If the exploit instead requires an entirely new ASIC then GPUs and FPGAs >> that could previously find 40 zero bits per energy unit can now compete >> with the less adaptive ASICs until new ASICs that use the exploit start >> getting produced and shipped. >> >> There's never any official "public breaking" of a hash function. The >> function will just loose security over time until it's deemed to not be >> "secure enough" for certain applications. Thankfully mining is an >> application where the only important thing is that the difficulty can be >> increased. In other words, if the entire world can consistently find 256 >> zero bits of SHA-256 in under 10 minutes then definitely the hash function >> needs to be changed. But this won't happen in a day. >> > --000000000000ccb38105a673933f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ariel,

Th= anks for your reply.

You= state that once "the entire world" can quickly find a hash that = it then "needs to be changed", but that that "won't happ= en in a day".

It so= unds like you believe compromise of the algorithm as a concern provides a _= lot_ of time to migrate to a new hash function, and that it is indeed impor= tant to do so when it becomes needed.

Let's talk about relaxing the time scale.=C2=A0 Making su= ch plans seems more important than agreeing on how soon they happen.=C2=A0 = It's possible it could be decades before having a new hash is actually = needed to protect financial security.=C2=A0 Who knows.

How does that land?=C2=A0 Is the idea more a= vailable with a looser time scale?

It seems to me with ongoing cryptanalysis rese= arch, new things like quantum computers, conventional computer hardware alw= ays advancing, that some day far in the future it will be easy to find an s= ha256 preimage on a personal device, somehow.
=
Let's improve the security of the blockchai= n.

On Sun, May 24, 2020, 7:51 PM Ariel Lorenzo-Luaces <arielluaces@gmail.com> wrote:
On M= ay 24, 2020, at 1:26 PM, Karl via bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:
You mention ASICs becoming commoditized= .=C2=A0 I'd remind you that eventually there will be a public mathemati= cal breaking of the algorithm, at which point all ASICs will become obsolet= e regardless.=C2=A0 Would you agree it would be better to prepare for this = by planning algorithm change?

Cryptographic algorithms don't usually break this way. In the cas= e of hash functions it may be possible to find an exploit that reduces the = function's security from 256 bits to 128 for example. So an algorithm t= hat could find 80 zero bits per energy unit before can now find 160 zero bi= ts per energy unit with an exploit.

If this exploit can be deployed as a software patch to most ASI= Cs then the issue will sort itself out on the next difficulty adjustment.

If the exploit instead re= quires an entirely new ASIC then GPUs and FPGAs that could previously find = 40 zero bits per energy unit can now compete with the less adaptive ASICs u= ntil new ASICs that use the exploit start getting produced and shipped.

There's never any offic= ial "public breaking" of a hash function. The function will just = loose security over time until it's deemed to not be "secure enoug= h" for certain applications. Thankfully mining is an application where= the only important thing is that the difficulty can be increased. In other= words, if the entire world can consistently find 256 zero bits of SHA-256 = in under 10 minutes then definitely the hash function needs to be changed. = But this won't happen in a day.
--000000000000ccb38105a673933f--