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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@monetize.io>) id 1WeLXN-0007kY-5J
for bitcoin-development@lists.sourceforge.net;
Sun, 27 Apr 2014 09:38:17 +0000
Received: from mail-pd0-f177.google.com ([209.85.192.177])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WeLXL-0000GJ-PR
for bitcoin-development@lists.sourceforge.net;
Sun, 27 Apr 2014 09:38:17 +0000
Received: by mail-pd0-f177.google.com with SMTP id v10so365024pde.36
for <bitcoin-development@lists.sourceforge.net>;
Sun, 27 Apr 2014 02:38:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:organization:user-agent
:mime-version:to:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=9A0Msj8u5ckKFkuoovJaqJ98UMwuNvlEjXvZEvHY+wg=;
b=grOBPPP/uQaIfQg7zKH3NNYLChW4pVHHV9putLG6V4vLH0H1JgtJ7c5DgHKiCKamJJ
vSYAb0FSbIP1DRlsPr+WfKGSJ/aBxBRpufiB+oVZ33oMdCfulZFW1aq/P/pPTH+n1mRK
hNZXPnsz4EHK/6EnrlPeMzrbeQ+qz6rUaF1ZzAD0cPZj9sbcXlWIKaODInJSeJ2OCHIo
GiTaSxT4CPkQhRLH9dGjIDhx/B4t9Hvyps7OqsFoDCGDB5aUQTcilJuyM05i/fOpQcIL
UiRf8idaudqQ3lz3pz6Yf7ABJ6aJQ6mZqUjma/dvubu7VmKjKgSpG22LOEgLpXiRv8Pu
PyOA==
X-Gm-Message-State: ALoCoQn5xpwJZ2OpEi8pQm/W4vffr8cMAFK5V1/Ei3RmQgilIMFoV7Ny+BVlJ4pCshvtrNIEbdNY
X-Received: by 10.66.163.164 with SMTP id yj4mr18740457pab.91.1398591489745;
Sun, 27 Apr 2014 02:38:09 -0700 (PDT)
Received: from [192.168.127.192] (50-0-36-93.dsl.dynamic.sonic.net.
[50.0.36.93]) by mx.google.com with ESMTPSA id
hb10sm27390695pbd.75.2014.04.27.02.38.07
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sun, 27 Apr 2014 02:38:08 -0700 (PDT)
Message-ID: <535CCFFE.5090809@monetize.io>
Date: Sun, 27 Apr 2014 02:38:06 -0700
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20140427070732.GA23422@crunch>
In-Reply-To: <20140427070732.GA23422@crunch>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.177 listed in list.dnswl.org]
X-Headers-End: 1WeLXL-0000GJ-PR
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, 27 Apr 2014 09:38:17 -0000
I'm not convinced of the necessity of this idea in general, but if it
were to be implemented I would recommend serializing the nVersion field
as a VarInt (Pieter Wuille's multi-byte serialization format) and using
the remaining space of the 4 bytes as your extra nonce.
That would allow serialization of numbers up to 0x1020407f (slightly
over 28 bits) before the 4-byte field is exhausted. For version numbers
less than 0x204080 there will be at least one byte of padding space left
over for extra-nonce usage (two bytes if less than 0x4080, three bytes
if less than 0x80). For version values up to 127, the format is exactly
identical when the padding bytes are zero.
On 04/27/2014 12:07 AM, Timo Hanke 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
>
|
