summaryrefslogtreecommitdiff
path: root/0a/f2aced3d94700d4b5886b64e86030892f868bd
blob: 20e5c4a436959de39b9db4452bd228e47044e4d4 (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
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 E44E0411
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 May 2016 16:24:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com
	[209.85.215.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 07EEC11D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 May 2016 16:24:17 +0000 (UTC)
Received: by mail-lf0-f47.google.com with SMTP id m64so55112664lfd.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 May 2016 09:24:16 -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=nQli84Dm63wMD/byNsuqdzkotGvyYeEMGgEuTzrCsWk=;
	b=DEGBzExyEt6Lv70HJOj78iOk6ixNBaF3h50v7zyNR0umLEpADJmFTZ8aPTXk3AcRHd
	uXqABi+QW476bV1zpaz1qYtbH2sZPQWdrSJCluvVlBoggTyr3JPcQLkSXdL1R1vOAgYB
	8x9AWBPHmb+HGLc1X6vE93PoG/UTtdYicugj7HsUjTPs/UTLrV5RUlEzGQ5wXanREuiz
	NIJ39DoTaTNsl73xtTsg/fEukkcmaY44mEuX4ak4Pa0OwmSFCW0jQxO0uU7K74fIoRhY
	yv33Ae3iNR/OtIQz/4JKyxphziAyiomOweFPJHekppxAcdTyx1YFmEiijx+jscX72vEy
	R55A==
X-Gm-Message-State: AOPr4FWGsH8d01hxgHFjEC9bvYSHugRSxON57XkmYm4okmrnIE58kRaXDIk+cvTmfOqgpA==
X-Received: by 10.112.171.98 with SMTP id at2mr1737613lbc.124.1462983855094;
	Wed, 11 May 2016 09:24:15 -0700 (PDT)
Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com.
	[209.85.215.47])
	by smtp.gmail.com with ESMTPSA id n8sm1403170lbc.17.2016.05.11.09.24.14
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 11 May 2016 09:24:14 -0700 (PDT)
Received: by mail-lf0-f47.google.com with SMTP id m64so55111948lfd.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 11 May 2016 09:24:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.10.9 with SMTP id e9mr1983219lbb.142.1462983853919; Wed,
	11 May 2016 09:24:13 -0700 (PDT)
Received: by 10.25.144.8 with HTTP; Wed, 11 May 2016 09:24:13 -0700 (PDT)
In-Reply-To: <201605111428.25918.luke@dashjr.org>
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>
Date: Wed, 11 May 2016 09:24:13 -0700
X-Gmail-Original-Message-ID: <CAH6h1LuVSSxZtOFNGP-Etx-UQGnWMxp1FL0E137yo7D+Wtcs7A@mail.gmail.com>
Message-ID: <CAH6h1LuVSSxZtOFNGP-Etx-UQGnWMxp1FL0E137yo7D+Wtcs7A@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=001a1136069cecd65b053293783f
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 16:24:18 -0000

--001a1136069cecd65b053293783f
Content-Type: text/plain; charset=UTF-8

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
>

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

<div dir=3D"ltr">Luke, do you mean to replace the first 4 bytes of the seco=
nd chunk (bytes 64..67 in 0-based counting) by the XOR of those 4 bytes wit=
h the first 4 bytes of the midstate? (I assume you don&#39;t care about 12 =
bytes but rather those 4 bytes.)<div><br></div><div>This does not work. All=
 it does is adding another computational step before you can check for a co=
llision in those 4 bytes. It makes finding a collision only marginally hard=
er.</div></div><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=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" 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 Demi=
an Lerner via bitcoin-dev<br>
wrote:<br>
<div><div class=3D"h5">&gt; On Tue, May 10, 2016 at 6:43 PM, Sergio Demian =
Lerner &lt;<br>
&gt; <a href=3D"mailto:sergio.d.lerner@gmail.com">sergio.d.lerner@gmail.com=
</a>&gt; wrote:<br>
&gt; &gt; You can find it here:<br>
&gt; &gt; <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>
&gt; &gt; ck-header/<br>
&gt; &gt;<br>
&gt; &gt; Basically, the idea is to put in the first 64 bytes a 4 byte hash=
 of the<br>
&gt; &gt; second 64-byte chunk. That design also allows increased nonce spa=
ce in<br>
&gt; &gt; the first 64 bytes.<br>
&gt;<br>
&gt; My mistake here. I didn&#39;t recalled correctly my own idea. The idea=
 is to<br>
&gt; include in the second 64-byte chunk a 4-byte hash of the first chunk, =
not<br>
&gt; 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 class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>

--001a1136069cecd65b053293783f--