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
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WgyIv-0004Oe-S4
for bitcoin-development@lists.sourceforge.net;
Sun, 04 May 2014 15:26:14 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WgyIu-00024t-5V
for bitcoin-development@lists.sourceforge.net;
Sun, 04 May 2014 15:26:13 +0000
Received: by mail-ob0-f175.google.com with SMTP id wp4so7416790obc.34
for <bitcoin-development@lists.sourceforge.net>;
Sun, 04 May 2014 08:26:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.146.177 with SMTP id td17mr28055914oeb.16.1399217166597;
Sun, 04 May 2014 08:26:06 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Sun, 4 May 2014 08:26:06 -0700 (PDT)
In-Reply-To: <20140504151451.GB5432@crunch>
References: <20140427070732.GA23422@crunch>
<CAKaEYh+ajt1QUz9_8v1b4azeajCdPB+WuCdsix3J8hO7vLnTvw@mail.gmail.com>
<20140504151451.GB5432@crunch>
Date: Sun, 4 May 2014 17:26:06 +0200
X-Google-Sender-Auth: ZKsjsckAnKLy0oMH_kA8vVqwI6Q
Message-ID: <CANEZrP38P8-NVy5p1zBnk97MMZTZx7Fdhx386CAa2018e64abA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Timo Hanke <timo.hanke@web.de>
Content-Type: multipart/alternative; boundary=047d7b450c1e2dc4e004f894a237
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1WgyIu-00024t-5V
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for extra nonce in block header
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: Sun, 04 May 2014 15:26:14 -0000
--047d7b450c1e2dc4e004f894a237
Content-Type: text/plain; charset=UTF-8
Although I agree 32 bits for a version is overkill, I really don't like the
idea of you simply ignoring the protocol spec to try and reduce your own
costs. Especially because in future we should make unknown versions a
validation rule, so we can easily trigger hard forks.
If this change was introduced through a proper process and software was
properly upgraded to understand the new header format, that'd be one thing.
Arbitrarily exploiting what is IMHO a missing rule in the rule set to shave
a bit more profit is something else.
On Sun, May 4, 2014 at 5:14 PM, Timo Hanke <timo.hanke@web.de> wrote:
> > If changing the structure of the block header, wouldnt you also need to
> > increment the version number to 3?
>
> No, in this case I don't think so. Incrementing the version number has
> two purposes:
>
> 1. inform old clients that something new is going on
> 2. be able to phase out old version numbers and block them once the new
> version number becomes a supermajority.
>
> None of these two is necessary here. Old clients already recognize the
> new block headers as something new because they look like very high
> version numbers to them. And there is no reason to ever phase out blocks
> that have zero in the MSBs of the version.
>
> On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote:
> > On 27 April 2014 09:07, Timo Hanke <timo.hanke@web.de> wrote:
> >
> > I'd like to put the following draft of a BIP up for discussion.
> >
> > Timo
> >
> > # Abstract
> > There are incentives for miners to find cheap, non-standard ways to
> > generate new work, which are not necessarily in the best interest of
> the
> > protocol.
> > In order to reduce these incentives this proposal re-assigns 2 bytes
> from
> > the version field of the block header to a new extra nonce field.
> > # Copyright
> > # Specification
> > The block version number field in the block header is reduced in
> size from
> > 4 to 2 bytes.
> > The third and fourth byte in the block header are assigned to the
> new extra
> > nonce field inside the block header.
> > # Motivation
> > The motivation of this proposal is to provide miners with a cheap
> > constant-complexity method to create new work that does not require
> > altering the transaction tree.
> >
> > Furthermore, the motivation is to protect the version and timestamp
> fields
> > in the block header from abuse.
> > # Rationale
> > Traditionally, the extra nonce is part of the coinbase field of the
> > generation transaction, which is always the very first transaction
> of a
> > block.
> > After incrementing the extra nonce the minimum amount of work a
> miner has
> > to do to re-calculate the block header is a) to hash the coinbase
> > transaction and b) to re-calculate the left-most branch of the
> merkle tree
> > all the way to the merkle root.
> > This is necessary overhead a miner has to do besides hashing the
> block
> > header itself.
> > We shall call the process that leads to a new block header from the
> same
> > transaction set the _pre-hashing_.
> >
> > First it should be noted that the relative cost of pre-hashing in its
> > traditional form depends
> > on the block size, which may create an unwanted incentive for miners
> > to keep the block size small. However, this is not the main
> motivation for
> > the current proposal.
> >
> > While the block header is hashed by ASICs, pre-hashing typically
> happens on
> > a CPU because of the greater flexibility required.
> > Consequently, as ASIC cost per hash performance drops the relative
> cost of
> > pre-hashing increases.
> >
> > This creates an incentive for miners to find cheaper ways to create
> new
> > work than by means of pre-hashing.
> > An example of this currently happening is the on-device rolling of
> the
> > timestamp into the future.
> > These ways of creating new work are unlikely to be in the best
> interest of
> > the protocol.
> > For example, rolling the timestamp faster than the real time is
> unwanted
> > (more so on faster blockchains).
> >
> > The version number in the block header is a possible target for
> alteration
> > with the goal of cheaply creating new work.
> > Currently, blocks with arbitrarily large version numbers get relayed
> and
> > accepted by the network.
> > As this is unwanted behaviour, there should not exist any incentive
> for a
> > miner to abuse the version number in this way.
> >
> > The solution is to reduce the range of version numbers from 2^32 to
> 2^16
> > and to declare the third and forth bytes of the block header as
> legitimate
> > space for an extra nonce.
> > This will reduce the incentive for a miner to abuse the shortened
> version
> > number by a factor in the order of 2^16.
> >
> > As a side effect, this proposal greatly reduces the bandwidth
> requirements
> > of a blind pool protocol by only submitting the block header to the
> miner.
> > # Backwards Compatibility
> > Old versions of the client will accept blocks of this kind but will
> throw
> > an alert at the user to upgrade.
> > The only code change would be a cast of the version number to a
> short.
> > Besides the upgrade alert, old and new versions of the client can
> co-exist
> > and there is no need to introduce a new block version number or to
> > phase-out old block versions.
> > # Reference Implementation
> > # Final implementation
> >
> >
> > If changing the structure of the block header, wouldnt you also need to
> > increment the version number to 3?
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--047d7b450c1e2dc4e004f894a237
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Although I agree 32 bits for a version is overkill, I real=
ly don't like the idea of you simply ignoring the protocol spec to try =
and reduce your own costs. Especially because in future we should make unkn=
own versions a validation rule, so we can easily trigger hard forks.<div>
<br></div><div>If this change was introduced through a proper process and s=
oftware was properly upgraded to understand the new header format, that'=
;d be one thing. Arbitrarily exploiting what is IMHO a missing rule in the =
rule set to shave a bit more profit is something else.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun,=
May 4, 2014 at 5:14 PM, Timo Hanke <span dir=3D"ltr"><<a href=3D"mailto=
:timo.hanke@web.de" target=3D"_blank">timo.hanke@web.de</a>></span> wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">> If changing the structu=
re of the block header, wouldnt you also need to<br>
> increment the version number to 3?<br>
<br>
</div>No, in this case I don't think so. Incrementing the version numbe=
r has<br>
two purposes:<br>
<br>
1. inform old clients that something new is going on<br>
2. be able to phase out old version numbers and block them once the new<br>
version number becomes a supermajority.<br>
<br>
None of these two is necessary here. Old clients already recognize the<br>
new block headers as something new because they look like very high<br>
version numbers to them. And there is no reason to ever phase out blocks<br=
>
that have zero in the MSBs of the version.<br>
<div><div class=3D"h5"><br>
On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote:<br>
> On 27 April 2014 09:07, Timo Hanke <<a href=3D"mailto:timo.hanke@we=
b.de">timo.hanke@web.de</a>> wrote:<br>
><br>
> =C2=A0 =C2=A0 I'd like to put the following draft of a BIP up for =
discussion.<br>
><br>
> =C2=A0 =C2=A0 Timo<br>
><br>
> =C2=A0 =C2=A0 # Abstract<br>
> =C2=A0 =C2=A0 There are incentives for miners to find cheap, non-stand=
ard ways to<br>
> =C2=A0 =C2=A0 generate new work, which are not necessarily in the best=
interest of the<br>
> =C2=A0 =C2=A0 protocol.<br>
> =C2=A0 =C2=A0 In order to reduce these incentives this proposal re-ass=
igns 2 bytes from<br>
> =C2=A0 =C2=A0 the version field of the block header to a new extra non=
ce field.<br>
> =C2=A0 =C2=A0 # Copyright<br>
> =C2=A0 =C2=A0 # Specification<br>
> =C2=A0 =C2=A0 The block version number field in the block header is re=
duced in size from<br>
> =C2=A0 =C2=A0 4 to 2 bytes.<br>
> =C2=A0 =C2=A0 The third and fourth byte in the block header are assign=
ed to the new extra<br>
> =C2=A0 =C2=A0 nonce field inside the block header.<br>
> =C2=A0 =C2=A0 # Motivation<br>
> =C2=A0 =C2=A0 The motivation of this proposal is to provide miners wit=
h a cheap<br>
> =C2=A0 =C2=A0 constant-complexity method to create new work that does =
not require<br>
> =C2=A0 =C2=A0 altering the transaction tree.<br>
><br>
> =C2=A0 =C2=A0 Furthermore, the motivation is to protect the version an=
d timestamp fields<br>
> =C2=A0 =C2=A0 in the block header from abuse.<br>
> =C2=A0 =C2=A0 # Rationale<br>
> =C2=A0 =C2=A0 Traditionally, the extra nonce is part of the coinbase f=
ield of the<br>
> =C2=A0 =C2=A0 generation transaction, which is always the very first t=
ransaction of a<br>
> =C2=A0 =C2=A0 block.<br>
> =C2=A0 =C2=A0 After incrementing the extra nonce the minimum amount of=
work a miner has<br>
> =C2=A0 =C2=A0 to do to re-calculate the block header is a) to hash the=
coinbase<br>
> =C2=A0 =C2=A0 transaction and b) to re-calculate the left-most branch =
of the merkle tree<br>
> =C2=A0 =C2=A0 all the way to the merkle root.<br>
> =C2=A0 =C2=A0 This is necessary overhead a miner has to do besides has=
hing the block<br>
> =C2=A0 =C2=A0 header itself.<br>
> =C2=A0 =C2=A0 We shall call the process that leads to a new block head=
er from the same<br>
> =C2=A0 =C2=A0 transaction set the _pre-hashing_.<br>
><br>
> =C2=A0 =C2=A0 First it should be noted that the relative cost of pre-h=
ashing in its<br>
> =C2=A0 =C2=A0 traditional form depends<br>
> =C2=A0 =C2=A0 on the block size, which may create an unwanted incentiv=
e for miners<br>
> =C2=A0 =C2=A0 to keep the block size small. However, this is not the m=
ain motivation for<br>
> =C2=A0 =C2=A0 the current proposal.<br>
><br>
> =C2=A0 =C2=A0 While the block header is hashed by ASICs, pre-hashing t=
ypically happens on<br>
> =C2=A0 =C2=A0 a CPU because of the greater flexibility required.<br>
> =C2=A0 =C2=A0 Consequently, as ASIC cost per hash performance drops th=
e relative cost of<br>
> =C2=A0 =C2=A0 pre-hashing increases.<br>
><br>
> =C2=A0 =C2=A0 This creates an incentive for miners to find cheaper way=
s to create new<br>
> =C2=A0 =C2=A0 work than by means of pre-hashing.<br>
> =C2=A0 =C2=A0 An example of this currently happening is the on-device =
rolling of the<br>
> =C2=A0 =C2=A0 timestamp into the future.<br>
> =C2=A0 =C2=A0 These ways of creating new work are unlikely to be in th=
e best interest of<br>
> =C2=A0 =C2=A0 the protocol.<br>
> =C2=A0 =C2=A0 For example, rolling the timestamp faster than the real =
time is unwanted<br>
> =C2=A0 =C2=A0 (more so on faster blockchains).<br>
><br>
> =C2=A0 =C2=A0 The version number in the block header is a possible tar=
get for alteration<br>
> =C2=A0 =C2=A0 with the goal of cheaply creating new work.<br>
> =C2=A0 =C2=A0 Currently, blocks with arbitrarily large version numbers=
get relayed and<br>
> =C2=A0 =C2=A0 accepted by the network.<br>
> =C2=A0 =C2=A0 As this is unwanted behaviour, there should not exist an=
y incentive for a<br>
> =C2=A0 =C2=A0 miner to abuse the version number in this way.<br>
><br>
> =C2=A0 =C2=A0 The solution is to reduce the range of version numbers f=
rom 2^32 to 2^16<br>
> =C2=A0 =C2=A0 and to declare the third and forth bytes of the block he=
ader as legitimate<br>
> =C2=A0 =C2=A0 space for an extra nonce.<br>
> =C2=A0 =C2=A0 This will reduce the incentive for a miner to abuse the =
shortened version<br>
> =C2=A0 =C2=A0 number by a factor in the order of 2^16.<br>
><br>
> =C2=A0 =C2=A0 As a side effect, this proposal greatly reduces the band=
width requirements<br>
> =C2=A0 =C2=A0 of a blind pool protocol by only submitting the block he=
ader to the miner.<br>
> =C2=A0 =C2=A0 # Backwards Compatibility<br>
> =C2=A0 =C2=A0 Old versions of the client will accept blocks of this ki=
nd but will throw<br>
> =C2=A0 =C2=A0 an alert at the user to upgrade.<br>
> =C2=A0 =C2=A0 The only code change would be a cast of the version numb=
er to a short.<br>
> =C2=A0 =C2=A0 Besides the upgrade alert, old and new versions of the c=
lient can co-exist<br>
> =C2=A0 =C2=A0 and there is no need to introduce a new block version nu=
mber or to<br>
> =C2=A0 =C2=A0 phase-out old block versions.<br>
> =C2=A0 =C2=A0 # Reference Implementation<br>
> =C2=A0 =C2=A0 # Final implementation<br>
><br>
><br>
> If changing the structure of the block header, wouldnt you also need t=
o<br>
> increment the version number to 3?<br>
<br>
</div></div>---------------------------------------------------------------=
---------------<br>
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE=
<br>
Instantly run your Selenium tests across 300+ browser/OS combos. =C2=A0Get<=
br>
unparalleled scalability from the best Selenium testing platform available.=
<br>
Simple to use. Nothing to install. Get started now for free."<br>
<a href=3D"http://p.sf.net/sfu/SauceLabs" target=3D"_blank">http://p.sf.net=
/sfu/SauceLabs</a><br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--047d7b450c1e2dc4e004f894a237--
|