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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1SZNoN-0005U8-4O
for bitcoin-development@lists.sourceforge.net;
Tue, 29 May 2012 14:54:15 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169; envelope-from=gavinandresen@gmail.com;
helo=mail-wi0-f169.google.com;
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SZNoH-0006S3-Kr
for bitcoin-development@lists.sourceforge.net;
Tue, 29 May 2012 14:54:15 +0000
Received: by wibhn14 with SMTP id hn14so2322832wib.4
for <bitcoin-development@lists.sourceforge.net>;
Tue, 29 May 2012 07:54:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.145.13 with SMTP id o13mr7599510wej.95.1338303243509; Tue,
29 May 2012 07:54:03 -0700 (PDT)
Received: by 10.223.155.203 with HTTP; Tue, 29 May 2012 07:54:03 -0700 (PDT)
Date: Tue, 29 May 2012 10:54:03 -0400
Message-ID: <CABsx9T1fGy-YzW+3np1u+aSW2MoRMQBtsCDCT5rL1uf54ua-OQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=0016e6de172a6e601404c12e0167
X-Spam-Score: -1.1 (-)
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
1.0 HTML_MESSAGE BODY: HTML included in message
-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
-0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SZNoH-0006S3-Kr
Subject: [Bitcoin-development] Testnet reset for the 0.7 release
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: Tue, 29 May 2012 14:54:15 -0000
--0016e6de172a6e601404c12e0167
Content-Type: text/plain; charset=ISO-8859-1
Testnet "Mark III" will be part of the 0.7 release, and is now in the
master github branch.
"Mark III" because this is the third genesis block for the testnet. The
main reason for the reset is to get a more 'sane' test network; with the
BIP16 and BIP30 and testnet difficulty blockchain rule changes the old
testnet is a mess, with old clients serving up different, incompatible
chains. The good news is the mess uncovered a couple of
large-block-chain-reorganization bugs, but having a stable testnet to test
new implementations or services is more important.
Rules for tesnet3:
+ Minimum difficulty 1.0 (same as main net-- old testnet min difficulty
was 0.125)
+ max-difficulty-protection rule that allows blocks to be mined at min
difficulty if the block's timestamp is 20 minutes or more after the last
block AND the block isn't on a difficulty-adjustment boundary.
To make it easy to run either old code (using the old tesnet) and new code,
the wallet and blockchain are stored in $DATADIR/testnet3 instead of
$DATADIR/testnet.
And to make it easy to find other testnet3-running nodes, the IRC channel
used for bootstrapping is #bitcoinTEST3 (instead of #bitcoinTEST).
The new testnet comes with a new blockchain that is full of interesting
test cases. In particular, there are test cases for:
+ BIP16; early blocks were generated with a timestamp before the BIP16
switchover date, and there are transactions that test the BIP16 switchover
rules
+ Most of the enabled Script opcodes. I created thousands of transactions
that try to exercise edge cases in the Script interpreter. Missing are
comprehensive tests for the signature opcodes and SIGHASH_ modes.
+ Block acceptance rules, including the rule on maximum block size, block
times, etc (thanks to gmaxwell)
If you're re-implementing Bitcoin then accepting the Mark III testnet
blockchain is a good first test for compatibility. You'll still need to do
a lot of work to make sure you reject the same set of invalid transactions
or blocks as the original Bitcoin code.
--
--
Gavin Andresen
--0016e6de172a6e601404c12e0167
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Testnet "Mark III" will be part of the 0.7 release, and is now in=
the master github branch.<div><br></div><div>"Mark III" because =
this is the third genesis block for the testnet. The main reason for the re=
set is to get a more 'sane' test network; with the BIP16 and BIP30 =
and testnet difficulty blockchain rule changes the old testnet is a mess, w=
ith old clients serving up different, incompatible chains. The good news is=
the mess uncovered a couple of large-block-chain-reorganization bugs, but =
having a stable testnet to test new implementations or services is more imp=
ortant.</div>
<div><br></div><div>Rules for tesnet3:</div><div>=A0 + Minimum difficulty 1=
.0 (same as main net-- old testnet min difficulty was 0.125)</div><div>=A0 =
+ max-difficulty-protection rule that allows blocks to be mined at min diff=
iculty if the block's timestamp is 20 minutes or more after the last bl=
ock AND the block isn't on a difficulty-adjustment boundary.</div>
<div><br></div><div>To make it easy to run either old code (using the old t=
esnet) and new code, the wallet and blockchain are stored in $DATADIR/testn=
et3 instead of $DATADIR/testnet.</div><div><br></div><div>And to make it ea=
sy to find other testnet3-running nodes, the IRC channel used for bootstrap=
ping is #bitcoinTEST3 (instead of #bitcoinTEST).</div>
<div><div><br></div><div>The new testnet comes with a new blockchain that i=
s full of interesting test cases. In particular, there are test cases for:<=
/div><div>=A0+ BIP16; early blocks were generated with a timestamp before t=
he BIP16 switchover date, and there are transactions that test the BIP16 sw=
itchover rules</div>
<div>=A0+ Most of the enabled Script opcodes. I created thousands of transa=
ctions that try to exercise edge cases in the Script interpreter. Missing a=
re comprehensive tests for the signature opcodes and SIGHASH_ modes.</div>
<div>=A0+ Block acceptance rules, including the rule on maximum block size,=
block times, etc (thanks to gmaxwell)</div><div><br></div><div>If you'=
re re-implementing Bitcoin then accepting the Mark III testnet blockchain i=
s a good first test for compatibility. You'll still need to do a lot of=
work to make sure you reject the same set of invalid transactions or block=
s as the original Bitcoin code.</div>
<div><br></div><div><br></div>-- <br>--<br>Gavin Andresen<br><br>
</div>
--0016e6de172a6e601404c12e0167--
|
