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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B4E2671E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2016 20:27:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com
[209.85.215.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 03D9A145
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2016 20:27:29 +0000 (UTC)
Received: by mail-lf0-f44.google.com with SMTP id y84so28107971lfc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2016 13:27:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to;
bh=/Nx420WGAUHLr9gu9V3wuJubx00p+MZ7K0AKQzO6K2U=;
b=GFgp7IOIjwaYWVyqCzgYWGfSOhVyLQejkGMCu22EEA8i9LE6iMl4mH5dn22ilneHTf
qGKlx0i0+QXetYTu0RWIOg+NlbY98CbzjRP7AdaUNat92LFdrYqROn6UwtVLxTBv8C9k
D3n32XDr/p6fD41N+D5Pr7OfUbE5zUr4twsndLhB+KhrIsfqpY55cVfQ31lBmtz7mW3S
JVrFYcJ295gkykPZEoFs35G6k7Li3vOnWlyx20WKle7pQo1Pt19/DMg6QX4EgGgr/eD1
8FWvCpQk29+fNX3mbFuxJXvdeKG6gvrd93ajHsR2YXEJp4hiYtdy2eOWHekrcsnzD8wl
mX1w==
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;
bh=/Nx420WGAUHLr9gu9V3wuJubx00p+MZ7K0AKQzO6K2U=;
b=MxdXKeldAH00AkL4YeJlx+8WU/w2xAv2SJx47LGsrSXMA4Mxob/o4WHvfiaqCZDJNc
h4uuGgEL2nR64kay2l4Fg8QVoGYYraY0lyL/ziY2MMVFmR0UeAQkauxt5slI5Y7T3DrR
5E0boGKFBaWLzYk8o/WbtfjeoylPGIaEzR5E1Pwo0le/7qUbkOTX0LOwtgL+2Cg7GhJK
iYgKXcpmFGQnLJLLY56uSzZWI1YeRWLv+UZx2lQvDpFOUxO/uj2SjTM46wG1NO4X6vSB
m9EdJ/U2zRUhFk5DP3EaslQ3RT7ul/4QeEp0YRuhsewGz7WPCtZDYO2gqxAQnN/SYV7M
Bm7g==
X-Gm-Message-State: AOPr4FXrJzKhehcBozZ+XhUf0v8YZKoEv5rYp0t9gUgiXcH76NiHGwyyn1ch1nzKlcFLIohGWtmFplLqugoEAA==
MIME-Version: 1.0
X-Received: by 10.112.62.193 with SMTP id a1mr15537584lbs.22.1462912048122;
Tue, 10 May 2016 13:27:28 -0700 (PDT)
Received: by 10.112.31.133 with HTTP; Tue, 10 May 2016 13:27:28 -0700 (PDT)
In-Reply-To: <20160510185728.GA1149@fedora-21-dvm>
References: <20160510185728.GA1149@fedora-21-dvm>
Date: Tue, 10 May 2016 21:27:28 +0100
Message-ID: <CAE-z3OWvLqONwaN+608jBn9=q1yUvU4ggGrMpA8rE6qmjDQHtg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c3c7daf75411053282c0aa
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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: Tue, 10 May 2016 20:27:30 -0000
--001a11c3c7daf75411053282c0aa
Content-Type: text/plain; charset=UTF-8
The various chunks in the double SHA256 are
Chunk 1: 64 bytes
version
previous_block_digest
merkle_root[31:4]
Chunk 2: 64 bytes
merkle_root[3:0]
nonce
timestamp
target
Chunk 3: 64 bytes
digest from first sha pass
Their improvement requires that all data in Chunk 2 is identical except for
the nonce. With 4 bytes, the birthday paradox means collisions can be
found reasonable easily.
If hard forks are allowed, then moving more of the merkle root into the 2nd
chunk would make things harder. The timestamp and target could be moved
into chunk 1. This increases the merkle root to 12 bytes in the 2nd
chunk. Finding collisions would be made much more difficult.
If ASIC limitations mean that the nonce must stay where it is, this would
mean that the merkle root would be split into two pieces.
On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> As part of the hard-fork proposed in the HK agreement(1) we'd like to make
> the
> patented AsicBoost optimisation useless, and hopefully make further similar
> optimizations useless as well.
>
> What's the best way to do this? Ideally this would be SPV compatible, but
> if it
> requires changes from SPV clients that's ok too. Also the fix this should
> be
> compatible with existing mining hardware.
>
>
> 1)
> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>
> 2)
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11c3c7daf75411053282c0aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>The various chunks in the double SHA256 are=
<br><br></div><div></div>Chunk 1: 64 bytes<br></div>version<br></div><div>p=
revious_block_digest<br></div>merkle_root[31:4]<br><div><div><br></div><div=
>Chunk 2: 64 bytes<br></div><div>merkle_root[3:0]<br></div><div>nonce<br></=
div><div>timestamp<br></div><div>target<br><br></div><div>Chunk 3: 64 bytes=
<br></div><div>digest from first sha pass<br><br></div><div></div><div>Thei=
r improvement requires that all data in Chunk 2 is identical except for the=
nonce.=C2=A0 With 4 bytes, the birthday paradox means collisions can be fo=
und reasonable easily.<br><br>If hard forks are allowed, then moving more o=
f the merkle root into the 2nd chunk would make things harder.=C2=A0 The ti=
mestamp and target could be moved into chunk 1.=C2=A0 This increases the me=
rkle root to 12 bytes in the 2nd chunk.=C2=A0 Finding collisions would be m=
ade much more difficult.<br><br></div><div>If ASIC limitations mean that th=
e nonce must stay where it is, this would mean that the merkle root would b=
e split into two pieces.<br></div></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Tue, May 10, 2016 at 7:57 PM, Peter Todd vi=
a bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As part of the hard-=
fork proposed in the HK agreement(1) we'd like to make the<br>
patented AsicBoost optimisation useless, and hopefully make further similar=
<br>
optimizations useless as well.<br>
<br>
What's the best way to do this? Ideally this would be SPV compatible, b=
ut if it<br>
requires changes from SPV clients that's ok too. Also the fix this shou=
ld be<br>
compatible with existing mining hardware.<br>
<br>
<br>
1) <a href=3D"https://medium.com/@bitcoinroundtable/bitcoin-roundtable-cons=
ensus-266d475a61ff" rel=3D"noreferrer" target=3D"_blank">https://medium.com=
/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff</a><br>
<br>
2) <a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-A=
pril/012596.html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2016-April/012596.html</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</font></span><br>_______________________________________________<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>
<br></blockquote></div><br></div>
--001a11c3c7daf75411053282c0aa--
|
