summaryrefslogtreecommitdiff
path: root/d9/be5eabf4a10930ac776d6ef8ccf452313fd81c
blob: 5eb511d9cb3a05feaa23fca263447a75f6fb2829 (plain)
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
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <dscvlt@gmail.com>) id 1WrqNv-0001lQ-EL
	for bitcoin-development@lists.sourceforge.net;
	Tue, 03 Jun 2014 15:12:19 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.169 as permitted sender)
	client-ip=209.85.214.169; envelope-from=dscvlt@gmail.com;
	helo=mail-ob0-f169.google.com; 
Received: from mail-ob0-f169.google.com ([209.85.214.169])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WrqNt-0003Vd-Mp
	for bitcoin-development@lists.sourceforge.net;
	Tue, 03 Jun 2014 15:12:19 +0000
Received: by mail-ob0-f169.google.com with SMTP id vb8so6315436obc.0
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 03 Jun 2014 08:12:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.33.106 with SMTP id q10mr47223963obi.19.1401808332208;
	Tue, 03 Jun 2014 08:12:12 -0700 (PDT)
Received: by 10.182.225.66 with HTTP; Tue, 3 Jun 2014 08:12:12 -0700 (PDT)
In-Reply-To: <CAEM=y+WFofZV-DbqEhkMT477jKdV35daoc+f3RWpCk=Vgy8ONA@mail.gmail.com>
References: <2341954.NpNStk60qp@1337h4x0r> <201406030452.40520.luke@dashjr.org>
	<CAEM=y+WFofZV-DbqEhkMT477jKdV35daoc+f3RWpCk=Vgy8ONA@mail.gmail.com>
Date: Wed, 4 Jun 2014 00:42:12 +0930
Message-ID: <CAOXABZqJL=Qe5bTbPB9LvLPUCdEca9eP9CHhPjd+eq1ZyLLyqA@mail.gmail.com>
From: Ashley Holman <dscvlt@gmail.com>
To: Ethan Heilman <eth3rs@gmail.com>
Content-Type: multipart/alternative; boundary=089e011614a4af436404faefefae
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(dscvlt[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WrqNt-0003Vd-Mp
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Lets discuss what to do if SHA256d is
 actually broken
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 03 Jun 2014 15:12:19 -0000

--089e011614a4af436404faefefae
Content-Type: text/plain; charset=UTF-8

There is a relevant post from Satoshi on this:

https://bitcointalk.org/index.php?topic=191.msg1585#msg1585

Quote:

"If SHA-256 became completely broken, I think we could come to some
agreement about what the honest block chain was before the trouble started,
lock that in and continue from there with a new hash function.

If the hash breakdown came gradually, we could transition to a new hash in
an orderly way.  The software would be programmed to start using a new hash
after a certain block number.  Everyone would have to upgrade by that time.
 The software could save the new hash of all the old blocks to make sure a
different block with the same old hash can't be used."


On Tue, Jun 3, 2014 at 9:21 PM, Ethan Heilman <eth3rs@gmail.com> wrote:

> An attack on the mining difficulty algorithm does not imply violation of
> the typical security properties of a cryptographic hash function*.
>
> Assume someone discovers a method which makes it far easier to discover
> new blocks, this method: may or may not be implementable by the current
> SHA256 ASIC hardware.
>
> 1. If it is usable by the mining hardware, then there will be brief period
> of overproduction and then difficulty will adjust. If the attack is so bad
> that difficulty can't scale and we run out of a leading zero's, then the
> SHA256 collision resistance is broken and we have bigger problems. Under
> this scenario, everyone would see the need to immediately switch to new
> hardware as people could create cycles and irreconcilable forks in the
> block chain
>
> 2. If the attack is not usable by the mining hardware, then the miners
> will need to switch to new ASICs anyways and the hash function can be
> changed without resistance.
>
> But lets ignore all that and say, for some unspecified reason, the bitcoin
> community wants to switch hash functions and has some lead time to do so.
> One could require that miners find two blocks, one computed using SHA256
> and one computed using the new hash function. We could then slowly shift
> the difficulty from SHA256 to the new hash function. This would allow
> miners a semi-predicable roadmap to switch their infrastructure away from
> SHA256.
>
> * It would be a distinguisher which would be bad, but collision resistance
> could be merely weakened.
>
>
> On Tue, Jun 3, 2014 at 12:52 AM, Luke Dashjr <luke@dashjr.org> wrote:
>
>> On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
>> > Hi,
>> >
>> > I thought a lot about the worst case scenario of SHA256d being broken
>> in a
>> > way which could be abused to
>> > A) reduce the work of mining a block by some significant amount
>> > B) reduce the work of mining a block to zero, i.e. allow instant mining.
>>
>> C) fabricate past blocks entirely.
>>
>> If SHA256d is broken, Bitcoin as it is fails entirely.
>>
>> Luke
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--089e011614a4af436404faefefae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There is a relevant post from Satoshi on this:<div><br></d=
iv><div><a href=3D"https://bitcointalk.org/index.php?topic=3D191.msg1585#ms=
g1585">https://bitcointalk.org/index.php?topic=3D191.msg1585#msg1585</a><br=
></div>
<div><br></div><div>Quote:</div><div><br></div><div><div>&quot;If SHA-256 b=
ecame completely broken, I think we could come to some agreement about what=
 the honest block chain was before the trouble started, lock that in and co=
ntinue from there with a new hash function.</div>
<div><br></div><div>If the hash breakdown came gradually, we could transiti=
on to a new hash in an orderly way. =C2=A0The software would be programmed =
to start using a new hash after a certain block number. =C2=A0Everyone woul=
d have to upgrade by that time. =C2=A0The software could save the new hash =
of all the old blocks to make sure a different block with the same old hash=
 can&#39;t be used.&quot;</div>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Tue, Jun 3, 2014 at 9:21 PM, Ethan Heilman <span dir=3D"ltr">&lt;<a href=
=3D"mailto:eth3rs@gmail.com" target=3D"_blank">eth3rs@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">An attack on the mining dif=
ficulty algorithm does not imply violation of the typical security properti=
es of a cryptographic hash function*.<br>
<br>Assume someone discovers a method which makes it far easier to discover=
 new blocks, this method:=C2=A0may or may not be implementable by the curre=
nt SHA256 ASIC hardware. <br>

<br>1. If it is usable by the mining hardware, then there will be brief per=
iod of overproduction and then difficulty will adjust. If the attack is so =
bad that difficulty can&#39;t scale and we run out of a leading zero&#39;s,=
 then the SHA256 collision resistance is broken and we have bigger problems=
. Under this scenario, everyone would see the need to immediately switch to=
 new hardware as people could create cycles and irreconcilable forks in the=
 block chain<div>


<br></div><div>2. If the attack is not usable by the mining hardware, then =
the miners will need to switch to new ASICs anyways and the hash function c=
an be changed without resistance.</div><div><br></div><div>But lets ignore =
all that and say, for some unspecified reason, the bitcoin community wants =
to switch hash functions and has some lead time to do so. One could require=
 that miners find two blocks, one computed using SHA256 and one computed us=
ing the new hash function. We could then slowly shift the difficulty from S=
HA256 to the new hash function. This would allow miners a semi-predicable r=
oadmap to switch their infrastructure away from SHA256.<br>


<br>* It would be a distinguisher which would be bad, but collision resista=
nce could be merely weakened.</div></div><div class=3D"HOEnZb"><div class=
=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tu=
e, Jun 3, 2014 at 12:52 AM, Luke Dashjr <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>&gt;</span> wrot=
e:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Tuesday, June 03, 2014 4:29:55 AM xo=
r wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I thought a lot about the worst case scenario of SHA256d being broken =
in a<br>
&gt; way which could be abused to<br>
&gt; A) reduce the work of mining a block by some significant amount<br>
&gt; B) reduce the work of mining a block to zero, i.e. allow instant minin=
g.<br>
<br>
</div>C) fabricate past blocks entirely.<br>
<br>
If SHA256d is broken, Bitcoin as it is fails entirely.<br>
<span><font color=3D"#888888"><br>
Luke<br>
</font></span><div><div><br>
---------------------------------------------------------------------------=
---<br>
Learn Graph Databases - Download FREE O&#39;Reilly Book<br>
&quot;Graph Databases&quot; is the definitive new guide to graph databases =
and their<br>
applications. Written by three acclaimed leaders in the field,<br>
this first edition is now available. Download your free book today!<br>
<a href=3D"http://p.sf.net/sfu/NeoTech" target=3D"_blank">http://p.sf.net/s=
fu/NeoTech</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
Learn Graph Databases - Download FREE O&#39;Reilly Book<br>
&quot;Graph Databases&quot; is the definitive new guide to graph databases =
and their<br>
applications. Written by three acclaimed leaders in the field,<br>
this first edition is now available. Download your free book today!<br>
<a href=3D"http://p.sf.net/sfu/NeoTech" target=3D"_blank">http://p.sf.net/s=
fu/NeoTech</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--089e011614a4af436404faefefae--