1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
Return-Path: <gmkarl@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6C5B7C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 May 2020 07:03:35 +0000 (UTC)
Received: by mail-io1-f65.google.com with SMTP id k18so17765030ion.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <mailman.2587.1590231461.32591.bitcoin-dev@lists.linuxfoundation.org>
<CALL-=e4Eg=iRbZOV+SAzn3_NhZrS-QviDgZdSmxLQTLvoMduPw@mail.gmail.com>
<k4J1fJMk2ySTLdlj8RgYxgb4_U3gtRH65Au5FLsCsVZPiEBRKU1cqy_S--2IxiRUGI1-5P1SMZkxnwlBf8YJ8ZQM_AM7jeuA6Y6dpT9jwi0=@protonmail.com>
<CALL-=e6_hrT9W2j73==cyX4Q=yt+guJn7RSgW1quA4JAgjD42w@mail.gmail.com>
<f74fc5a4-b09b-41d0-a3c4-7d6726cee016@gmail.com>
In-Reply-To: <f74fc5a4-b09b-41d0-a3c4-7d6726cee016@gmail.com>
From: Karl <gmkarl@gmail.com>
Date: Mon, 25 May 2020 03:03:20 -0400
Message-ID: <CALL-=e5ZJsUfkgOyVQhAXHpYp7-2xrpjphO77ixwrva1uTEfmQ@mail.gmail.com>
To: Ariel Lorenzo-Luaces <arielluaces@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ccb38105a673933f"
X-Mailman-Approved-At: Mon, 25 May 2020 10:20:31 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <arielluaces@gmail.com>
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
<div dir=3D"auto">Hi Ariel,<div dir=3D"auto"><br></div><div dir=3D"auto">Th=
anks for your reply.</div><div dir=3D"auto"><br></div><div dir=3D"auto">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".</div><div dir=3D"auto"><br></div><div dir=3D"auto">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.</div><div dir=3D"auto"><br></div><div=
dir=3D"auto">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.</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">How does that land?=C2=A0 Is the idea more a=
vailable with a looser time scale?</div><div dir=3D"auto"><br></div><div di=
r=3D"auto"><div dir=3D"auto">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.</div></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Let's improve the security of the blockchai=
n.</div><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=
=3D"gmail_attr">On Sun, May 24, 2020, 7:51 PM Ariel Lorenzo-Luaces <<a h=
ref=3D"mailto:arielluaces@gmail.com">arielluaces@gmail.com</a>> wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"gmail_quote">On M=
ay 24, 2020, at 1:26 PM, Karl via bitcoin-dev <<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoi=
n-dev@lists.linuxfoundation.org</a>> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
<div dir=3D"auto"><div dir=3D"auto">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?</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">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.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">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.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">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.</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">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.<br></div></div></blockquote></div></div=
></blockquote></div></div>
--000000000000ccb38105a673933f--
|
