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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <eth3rs@gmail.com>) id 1WrnFx-00045O-Fi
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Jun 2014 11:51:53 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.174 as permitted sender)
client-ip=209.85.212.174; envelope-from=eth3rs@gmail.com;
helo=mail-wi0-f174.google.com;
Received: from mail-wi0-f174.google.com ([209.85.212.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WrnFv-0000tp-W8
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Jun 2014 11:51:53 +0000
Received: by mail-wi0-f174.google.com with SMTP id r20so6378138wiv.13
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Jun 2014 04:51:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.249.228 with SMTP id yx4mr47857205wjc.53.1401796305278;
Tue, 03 Jun 2014 04:51:45 -0700 (PDT)
Received: by 10.180.231.42 with HTTP; Tue, 3 Jun 2014 04:51:45 -0700 (PDT)
In-Reply-To: <201406030452.40520.luke@dashjr.org>
References: <2341954.NpNStk60qp@1337h4x0r> <201406030452.40520.luke@dashjr.org>
Date: Tue, 3 Jun 2014 07:51:45 -0400
Message-ID: <CAEM=y+WFofZV-DbqEhkMT477jKdV35daoc+f3RWpCk=Vgy8ONA@mail.gmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a11c2a05ad2dfba04faed2252
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
(eth3rs[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: 1WrnFv-0000tp-W8
Cc: 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 11:51:53 -0000
--001a11c2a05ad2dfba04faed2252
Content-Type: text/plain; charset=UTF-8
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
>
--001a11c2a05ad2dfba04faed2252
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">An attack on the mining difficulty algorithm does not impl=
y violation of the typical security properties of a cryptographic hash func=
tion*.<br><br>Assume someone discovers a method which makes it far easier t=
o discover new blocks, this method:=C2=A0may or may not be implementable by=
the current 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'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<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"gmail_extra"><br><br=
><div class=3D"gmail_quote">On Tue, Jun 3, 2014 at 12:52 AM, Luke Dashjr <s=
pan dir=3D"ltr"><<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">lu=
ke@dashjr.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Tuesday, June 03, 2014 4:=
29:55 AM xor wrote:<br>
> Hi,<br>
><br>
> I thought a lot about the worst case scenario of SHA256d being broken =
in a<br>
> way which could be abused to<br>
> A) reduce the work of mining a block by some significant amount<br>
> 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 class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
Learn Graph Databases - Download FREE O'Reilly Book<br>
"Graph Databases" 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>
</div></div></blockquote></div><br></div>
--001a11c2a05ad2dfba04faed2252--
|
