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
|
Return-Path: <timo.t.hanke@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 14EC95AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 22:49:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com
[209.85.215.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 01F79123
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 22:49:28 +0000 (UTC)
Received: by mail-lf0-f54.google.com with SMTP id u64so62551437lff.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 15:49:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc;
bh=dKh5Q17slN8XLe6H/TnWgtZykEo672WPbVgv5NU0euw=;
b=FZjP/XLCteQy7Amd3C6KbkbvKEm51N0vvTpbJDSs4F9TeNtuZV8TmqXFGF6R1MSW+X
++epzO03y7BdUsycdbyYmBd1w/6uBu/kcbjnY9gkwwoWXwssb717VOsir8ZuR4A81uWN
iT9dcBPhmj/B2quV6tjqlb7fRueG7lVXVjAX467FyUmL6MTYjc7Bh6Hd6uKuWaGJQFTI
LC8aE3u9WCZsRN9mlPNDXMFYR3UpK457ACHJIAIdYsentcoMpiqGiC/w+hpwu13hs2aQ
0VYyAXQ3O7TVQUT30Uz9VjnSgBGb7rJFFJHkq/5q/Qiufzx5g5aY0kr2dDOZp7+FwAvY
cFjw==
X-Gm-Message-State: AOPr4FVG9YO0tDMc4Ahe0eh18FUxFr4A2cdGJ1194MW9/h1NifjmxTiaGofFbzS8IdR0sw==
X-Received: by 10.25.161.141 with SMTP id k135mr2791511lfe.101.1463006967459;
Wed, 11 May 2016 15:49:27 -0700 (PDT)
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com.
[209.85.217.174])
by smtp.gmail.com with ESMTPSA id oq7sm777190lbb.47.2016.05.11.15.49.26
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 11 May 2016 15:49:27 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id h1so2626106lbj.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 15:49:26 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.10.9 with SMTP id e9mr2761333lbb.142.1463006965913; Wed,
11 May 2016 15:49:25 -0700 (PDT)
Received: by 10.25.144.8 with HTTP; Wed, 11 May 2016 15:49:25 -0700 (PDT)
In-Reply-To: <CAH6h1LsRgZEar8JDR2m-hsTc-DE+=A6BzOq_X2CHSya=bxFRQQ@mail.gmail.com>
References: <20160510185728.GA1149@fedora-21-dvm>
<CAKzdR-ou2FYjjxmRBLARhvfhHO-46weiMc2Q2f+GZf1E_JUEAg@mail.gmail.com>
<CAKzdR-pFZGsQZPrHRbJhviFemSLPf8Bo6UWSaaQ-BurCsnAAWw@mail.gmail.com>
<201605111428.25918.luke@dashjr.org>
<CAH6h1LuVSSxZtOFNGP-Etx-UQGnWMxp1FL0E137yo7D+Wtcs7A@mail.gmail.com>
<CAH6h1LsRgZEar8JDR2m-hsTc-DE+=A6BzOq_X2CHSya=bxFRQQ@mail.gmail.com>
Date: Wed, 11 May 2016 15:49:25 -0700
X-Gmail-Original-Message-ID: <CAH6h1Lvao0CXCdGoutEskdtM0gOS0S1bkK_ovGtD523wyab6Zw@mail.gmail.com>
Message-ID: <CAH6h1Lvao0CXCdGoutEskdtM0gOS0S1bkK_ovGtD523wyab6Zw@mail.gmail.com>
From: Timo Hanke <timo.hanke@web.de>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1136069c81e2e9053298da52
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Making AsicBoost irrelevant
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Wed, 11 May 2016 22:49:30 -0000
--001a1136069c81e2e9053298da52
Content-Type: text/plain; charset=UTF-8
Ups, I forgot that you take the midstate which of course depends on the
version number. So forget everything I said about the version bits. You are
right. But why take the midstate? It can be any hash of the first chunk. So
you probably want to take a hash function that's available in standard
software libraries. And I suppose midstate() is not.
On Wed, May 11, 2016 at 11:28 AM, Timo Hanke <timo.hanke@web.de> wrote:
> Sorry, you must have meant all 12 bytes. That makes finding a collision
> substantially harder. However, you may have to restrict yourself to 10
> bytes because you don't know if any hardware does timestamp rolling
> on-chip. Also you create an incentive to mess around with the version bits
> instead, so you would have to fix that as well. So it basically means a new
> mining header with the real blockheader as a child header.
>
> On Wed, May 11, 2016 at 9:24 AM, Timo Hanke <timo.hanke@web.de> wrote:
>
>> Luke, do you mean to replace the first 4 bytes of the second chunk (bytes
>> 64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4
>> bytes of the midstate? (I assume you don't care about 12 bytes but rather
>> those 4 bytes.)
>>
>> This does not work. All it does is adding another computational step
>> before you can check for a collision in those 4 bytes. It makes finding a
>> collision only marginally harder.
>>
>> On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via
>>> bitcoin-dev
>>> wrote:
>>> > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
>>> > sergio.d.lerner@gmail.com> wrote:
>>> > > You can find it here:
>>> > >
>>> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo
>>> > > ck-header/
>>> > >
>>> > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of
>>> the
>>> > > second 64-byte chunk. That design also allows increased nonce space
>>> in
>>> > > the first 64 bytes.
>>> >
>>> > My mistake here. I didn't recalled correctly my own idea. The idea is
>>> to
>>> > include in the second 64-byte chunk a 4-byte hash of the first chunk,
>>> not
>>> > the opposite.
>>>
>>> What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?
>>> Would that work?
>>>
>>> Luke
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>
--001a1136069c81e2e9053298da52
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ups, I forgot that you take the midstate which of course d=
epends on the version number. So forget everything I said about the version=
bits. You are right. But why take the midstate? It can be any hash of the =
first chunk. So you probably want to take a hash function that's availa=
ble in standard software libraries. And I suppose midstate() is not.<div><b=
r></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Wed, May 11, 2016 at 11:28 AM, Timo Hanke <span dir=3D"ltr"><<a href=3D"=
mailto:timo.hanke@web.de" target=3D"_blank">timo.hanke@web.de</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Sorry, you must=
have meant all 12 bytes. That makes finding a collision substantially hard=
er. However, you may have to restrict yourself to 10 bytes because you don&=
#39;t know if any hardware does timestamp rolling on-chip. Also you create =
an incentive to mess around with the version bits instead, so you would hav=
e to fix that as well. So it basically means a new mining header with the r=
eal blockheader as a child header.=C2=A0</div><div class=3D"HOEnZb"><div cl=
ass=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed=
, May 11, 2016 at 9:24 AM, Timo Hanke <span dir=3D"ltr"><<a href=3D"mail=
to:timo.hanke@web.de" target=3D"_blank">timo.hanke@web.de</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Luke, do you mean t=
o replace the first 4 bytes of the second chunk (bytes 64..67 in 0-based co=
unting) by the XOR of those 4 bytes with the first 4 bytes of the midstate?=
(I assume you don't care about 12 bytes but rather those 4 bytes.)<div=
><br></div><div>This does not work. All it does is adding another computati=
onal step before you can check for a collision in those 4 bytes. It makes f=
inding a collision only marginally harder.</div></div><div><div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, May 11, 2016 at 7:2=
8 AM, Luke Dashjr via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via bitcoin-dev=
<br>
wrote:<br>
<div><div>> On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <<b=
r>
> <a href=3D"mailto:sergio.d.lerner@gmail.com" target=3D"_blank">sergio.=
d.lerner@gmail.com</a>> wrote:<br>
> > You can find it here:<br>
> > <a href=3D"https://bitslog.wordpress.com/2014/03/18/the-re-design=
-of-the-bitcoin-blo" rel=3D"noreferrer" target=3D"_blank">https://bitslog.w=
ordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo</a><br>
> > ck-header/<br>
> ><br>
> > Basically, the idea is to put in the first 64 bytes a 4 byte hash=
of the<br>
> > second 64-byte chunk. That design also allows increased nonce spa=
ce in<br>
> > the first 64 bytes.<br>
><br>
> My mistake here. I didn't recalled correctly my own idea. The idea=
is to<br>
> include in the second 64-byte chunk a 4-byte hash of the first chunk, =
not<br>
> the opposite.<br>
<br>
</div></div>What if we XOR bytes 64..76 with the first 12 bytes of the SHA2=
midstate?<br>
Would that work?<br>
<br>
Luke<br>
<div><div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
--001a1136069c81e2e9053298da52--
|
