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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kevinsisco61784@gmail.com>) id 1WrpwL-00034M-NX
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Jun 2014 14:43:49 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.52 as permitted sender)
client-ip=209.85.192.52; envelope-from=kevinsisco61784@gmail.com;
helo=mail-qg0-f52.google.com;
Received: from mail-qg0-f52.google.com ([209.85.192.52])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WrpwJ-00085C-Vp
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Jun 2014 14:43:49 +0000
Received: by mail-qg0-f52.google.com with SMTP id a108so13141285qge.39
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Jun 2014 07:43:42 -0700 (PDT)
X-Received: by 10.224.112.9 with SMTP id u9mr33485495qap.38.1401806622298;
Tue, 03 Jun 2014 07:43:42 -0700 (PDT)
Received: from [192.168.1.115] (ool-43521013.dyn.optonline.net. [67.82.16.19])
by mx.google.com with ESMTPSA id
6sm26974773qam.44.2014.06.03.07.43.40
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 03 Jun 2014 07:43:41 -0700 (PDT)
Message-ID: <538DDF1B.30701@gmail.com>
Date: Tue, 03 Jun 2014 10:43:39 -0400
From: Kevin <kevinsisco61784@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <2341954.NpNStk60qp@1337h4x0r>
In-Reply-To: <2341954.NpNStk60qp@1337h4x0r>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.4 (-)
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
(kevinsisco61784[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (kevinsisco61784[at]gmail.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.52 listed in list.dnswl.org]
-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: 1WrpwJ-00085C-Vp
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 14:43:49 -0000
On 6/3/2014 12:29 AM, xor wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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.
>
> Bitcoin needs to be prepared for this as any hash function has a limited
> lifetime. Usually crypto stuff is not completely broken instantly by new
> attacks but gradually. For example first the attack difficulty is reduced from
> 2^128 to 2^100, then 2^64, etc.
> This would make scenario A more likely.
>
> Now while B sounds more dangerous, I think in fact A is:
> Consider how A would happen in real life: Someone publishes a paper of a
> theoretical reduction of SHA256d attacks to 2^96 bit. Mathematicians will
> consider this as a serious attack and create a lot of riot.
> If no plan is made early enough, as in now, the Bitcoin Core team might then
> probably want to just do the easiest approach of replacing the hash function
> after a certain block number, i.e. a hard fork.
> But what about the Bitcoin miners, those who need to actually accept a change
> of mining algorithm which renders their hardware which cost MILLIONS
> completely worthless?
> Over the years they have gotten used to exponential growth of the Bitcoin
> networks hashrate, and therefore exponential devaluation of their mining
> hardware. Even if the attack on SHA256d causes a significant growth of
> difficulty, the miners will not *believe* that it is an actual attack on SHA256d
> - - maybe it is just some new large mining operation? They are used to this
> happening! Why should they believe this and switch to a new hash function
> which requires completely new hardware and therefore costs them millions?
> They will just keep mining SHA256d. Thats why this is more dangerous, because
> changing the hash funciton won't be accepted by the miners even though it is
> broken.
> Something smarter needs to be thought of.
>
> Now I must admit that I am not good at cryptography at all, but I had the
> following idea: Use the altcoin concept of having multiple hash functions in a
> chain. If SHA256d is broken, it is chained with a new hash function.
> Thereby, people who want to mine the new replacement hash function still will
> need ASICs which can solve the old SHA proof of work. So existing ASIC owners
> can amend their code to do SHA256d using the ASIC, and then the second hash
> function using a general purpose CPU.
> This would also allow a smooth migration of difficulty - I don't even know how
> difficulty would react with the naive approach of just replacing SHA with
> something else: It would probably be an unsolvable problem to define new rules
> to make it decrease enough so new blocks can actually be mined by the now
> several orders of magnitude slower CPU-only mining community but still be high
> enough to be able to deal with the fact that millions of people will try their
> luck with mining at the release date.
>
> While this sounds simple in theory, it might be a lot of work to implement, so
> you guys might want to take precautions for it soon :)
>
> Greetings,
> xor - A Freenet project developer
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQIcBAEBCAAGBQJTjU9DAAoJEMtmZ+8tjWt5pNEP/2460eHu7ujrUSxinJXY7+wF
> E759/NcpNuakqu4NsS3ndi8lSiVIeixiOWZxPwLYkzC0pgPd5JrK5hdrYewsgreL
> Ltkh6LKB4YZLYrV3jm62ZPMTzCopYQ1l872xbN3PJQJoXhEp4fKu99++LDzVg9Gk
> n7rvrk6Iy/nSsZ1IMANpKghbU8/Gtn6ppCJv9rxRE//CZdTso1tTyOXXkEEMTHcV
> y/iv6CHXtTXPvOgEgciU0oCPq0NOUKdIAOD//ybcKzncOoHSmwr1rZdreCTH6/Ek
> 9uwq/HaQnseHPrq9qrIkIKrZDlnjKu7Tqw1BlbyBeCrWdJPCeDJg2kyCXgTvIzFD
> oXwZ6r16tb2QPR4ByyO1lZy9G2Pp26thk12BnadnPYTf1rMvsY15BjfUrCU9ppt/
> YpFAZSFlXUGOuOBKUznUeO8U1bXJylcTTnyER/cudOpcKR8Jt9l5tfm5LTHCB6Q2
> Tjmvsmd0BzwafLEhHD5FHoTZFNVdXWvEUO/w4I/2UWTS7CacbE1qk0rVpsF/4L1K
> /oFVnZIUKqsm5mMMb6WTQq+MjP2TF/eAAwm2UtFYmj0FVML9HBNwyiAc5UKwnD4Y
> Yq3Pl5QfRobwu6pgT3zO7vK+saOl8sePWbU8Skj41OTEDrJM4QIQGAqs1U8xke8+
> YnUYiyzreJ8ofHhNBs4/
> =dkuk
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> 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
It is good to start thinking about such things. Let's face it, it could
happen. However, short of having bitcoin use another algorithm for
encryption, I am not sure much could be done. That's just me.
--
Kevin
|
