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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1St6iB-0005Hx-H0
for bitcoin-development@lists.sourceforge.net;
Mon, 23 Jul 2012 00:41:23 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.175 as permitted sender)
client-ip=209.85.217.175; envelope-from=gavinandresen@gmail.com;
helo=mail-lb0-f175.google.com;
Received: from mail-lb0-f175.google.com ([209.85.217.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1St6iA-00089u-HI
for bitcoin-development@lists.sourceforge.net;
Mon, 23 Jul 2012 00:41:23 +0000
Received: by lbol5 with SMTP id l5so7851789lbo.34
for <bitcoin-development@lists.sourceforge.net>;
Sun, 22 Jul 2012 17:41:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.101.169 with SMTP id fh9mr6958160lbb.18.1343004075983;
Sun, 22 Jul 2012 17:41:15 -0700 (PDT)
Received: by 10.112.17.163 with HTTP; Sun, 22 Jul 2012 17:41:15 -0700 (PDT)
In-Reply-To: <201207222052.28579.luke@dashjr.org>
References: <201207222052.28579.luke@dashjr.org>
Date: Sun, 22 Jul 2012 20:41:15 -0400
Message-ID: <CABsx9T0JK9qBKZu7YWeQCBAjT1Ur05BQ26A5NdLCwD6Wuyc0nQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1St6iA-00089u-HI
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Reconsidering block version number use
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: Mon, 23 Jul 2012 00:41:23 -0000
> The current block height in coinbase addition currently proposes to use block
> version 2. However, the protocol change is in fact to the coinbase
> transaction, not the block itself (which really doesn't have any extensibility
> without a hardfork anyway). Perhaps we should consider bumping the coinbase
> transaction version number to 2 for this instead?
I'd thought about bumping the coinbase transaction version, but the
problem is if we want a smooth rollout then, during the rollout, every
time a new block comes in the percentage of the last 1,000 blocks that
support the new version has to be computed.
If that means looking in the coinbase transaction, then either the
last 1,000 coinbases have to be stored in memory or they have to be
fetched from disk. Which isn't a huge deal, unless we start
aggressively pruning spent transactions, and that coinbase 900 blocks
back got spent and pruned.
On Sun, Jul 22, 2012 at 4:52 PM, Luke-Jr <luke@dashjr.org> wrote:
> It just occurred to me that the block version number could easily be used as a
> cheap "extra nonce" right now. Considering that we will probably see lots of
> ASIC miners running at 1 TH/s per rig before the end of 2012, it might be
> desirable to save the block version for this purpose.
Hmm... I think it'd be ok to give 3 of the 4 block version bytes as a
simple extranonce, so version=0x00000001 is what we have now, version
2 blocks are any with 0x02 in the low byte, 0x03 is version 3, etc. I
don't think we'll go through 253 block versions before we're all dead.
That'd be 7 bytes of nonce in the block header, which is
72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes
So: the changes for version 2 blocks would be "has height in the
coinbase, and has a 1-byte version number with a 3-byte extranonce."
> Also, Jeff noticed that block 190192 has version==2 without a valid block
> height in the coinbase. I suspect this may be the result of combining the
> current blockheight-in-coinbase pullreq with P2Pool. This means that if we go
> forward with the version==2 marker, we will forever need to make an exception
> for that block.
No, the rules are "enforce the rules when the chain has a
super-majority." Since block 190192 is in a part of the chain with
zero other version==2 blocks, the height-in-the-coinbase rule will not
be enforced.
--
--
Gavin Andresen
|
