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
|
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 66242282
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 18:28:47 +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 16F03192
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 18:28:46 +0000 (UTC)
Received: by mail-lf0-f54.google.com with SMTP id m64so58648496lfd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 11:28:45 -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=KI88IwZlQJQRn4yEJdTLRNaqar0z3Ls4l99QKXGXgjU=;
b=mlZHdWAu3cJdop+inbOT9WuME/wpbCh+5i0ve+PtsMAIVM3wrm5dVTzt/GC+g2NhMF
oH97Dwn8CKZv7R07jAkXhWX8sMiJceaTvvtsi/pDbZprglIiXVFrqxDTkTtL0hPNf8du
63V7C1Q9M+UyJ+DufFFIB3sPmr/9JJIQR9fzTKCDiqHoRCpO5n6OmLEZjZkmVGdCxfnW
KTKnaomygMWgg935dO/MN5g1TRvPCAeK6hz8tqu+UBhqb+OFOVGWgijp6qcVuhHE7N7w
rSzyVswynSV3Nq78Ye6KCwx5c+hgKonNgZrCvQ9msXVCYYIdzRvB0E+WtuEeo4R8ohPZ
D2gw==
X-Gm-Message-State: AOPr4FWzil2+O31Sg3x9zPANGaELAtZNqpkilADdlx1bj7ZDwOzB7K6GI+qOVf4StqciUg==
X-Received: by 10.25.88.12 with SMTP id m12mr2339449lfb.42.1462991324288;
Wed, 11 May 2016 11:28:44 -0700 (PDT)
Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com.
[209.85.215.44]) by smtp.gmail.com with ESMTPSA id
q137sm1490457lfq.24.2016.05.11.11.28.43
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 11 May 2016 11:28:43 -0700 (PDT)
Received: by mail-lf0-f44.google.com with SMTP id j8so58523214lfd.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 11:28:43 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.95.114 with SMTP id dj18mr2294318lbb.136.1462991323102;
Wed, 11 May 2016 11:28:43 -0700 (PDT)
Received: by 10.25.144.8 with HTTP; Wed, 11 May 2016 11:28:42 -0700 (PDT)
In-Reply-To: <CAH6h1LuVSSxZtOFNGP-Etx-UQGnWMxp1FL0E137yo7D+Wtcs7A@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>
Date: Wed, 11 May 2016 11:28:42 -0700
X-Gmail-Original-Message-ID: <CAH6h1LsRgZEar8JDR2m-hsTc-DE+=A6BzOq_X2CHSya=bxFRQQ@mail.gmail.com>
Message-ID: <CAH6h1LsRgZEar8JDR2m-hsTc-DE+=A6BzOq_X2CHSya=bxFRQQ@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=001a11360dae1f85b8053295363b
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 18:28:47 -0000
--001a11360dae1f85b8053295363b
Content-Type: text/plain; charset=UTF-8
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
>>
>
>
--001a11360dae1f85b8053295363b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sorry, you must have meant all 12 bytes. That makes findin=
g a collision substantially harder. However, you may have to restrict yours=
elf to 10 bytes because you don't know if any hardware does timestamp r=
olling on-chip. Also you create an incentive to mess around with the versio=
n bits instead, so you would have to fix that as well. So it basically mean=
s a new mining header with the real blockheader as a child header.=C2=A0</d=
iv><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"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;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Luke, do you mean to replac=
e 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 assu=
me you don't care about 12 bytes but rather those 4 bytes.)<div><br></d=
iv><div>This does not work. All it does is adding another computational ste=
p before you can check for a collision in those 4 bytes. It makes finding a=
collision only marginally harder.</div></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 7:28 AM, Luke Dashjr via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian L=
erner 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>
--001a11360dae1f85b8053295363b--
|
