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
|
Return-Path: <danny.thorpe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E78A69B4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 17:30:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com
[209.85.214.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1965112
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 17:30:35 +0000 (UTC)
Received: by obbfr1 with SMTP id fr1so10354963obb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 10:30:35 -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
:cc:content-type;
bh=iJCCW7f474ZikuVmx8paQ9e8suWtmI7hui2rEuggKcs=;
b=G2X+/ZOuCtf0F2DQ/hm2Rj0xpXFU4ymvT/mEUBVM33AXa/Epu/1DhNqPP3Um1yFua8
i0dsfx+PGBqwGZYgep3/uU8r/qnqWoLLrAoKcHFPAizL1XrrotmjIJbWcGqFR2Mk75u2
RYR3Out6BWKLVFW/i9UxTbEbu4Ujt6CnUH9JEQrepi4H+hbqSWy7d3vhBTVKWMMhSSjd
i+3gWoiytlUYT1y2KpH2lhVf2pLgUfxYIRDbJxH+NZgOt2KoPivxkXN1yc+kLlMzdoKv
yWBSZq9szDm19DeOvRbjkZoLNz5vY6oFqp8TAc3PHmgaQf9sjxF9u6ehGOj7XOGya8So
L36A==
MIME-Version: 1.0
X-Received: by 10.182.33.38 with SMTP id o6mr11499532obi.41.1440005435337;
Wed, 19 Aug 2015 10:30:35 -0700 (PDT)
Received: by 10.202.134.78 with HTTP; Wed, 19 Aug 2015 10:30:35 -0700 (PDT)
In-Reply-To: <CABm2gDp69g8H4Was2qzixPq3qwQ_smzzeFpE+y2GYEK6F4kUrw@mail.gmail.com>
References: <d17549688c0c747b2077c1f6f96b6445@xbt.hk>
<CAJN5wHV-qyOcEw5spQc74nT7_b29WMiDTmi4Jj0ri_rGCQz2ng@mail.gmail.com>
<E9543641-9D73-4A00-9CB3-FAB62BFB490E@gmail.com>
<CAJN5wHXRwQZ6YmiZiCE9Gx4d-3FTzy1Zv7i2noia0mwtRwVL+w@mail.gmail.com>
<CABm2gDp69g8H4Was2qzixPq3qwQ_smzzeFpE+y2GYEK6F4kUrw@mail.gmail.com>
Date: Wed, 19 Aug 2015 10:30:35 -0700
Message-ID: <CAJN5wHWCst=SmRA-Pu7fmJwxtL9aneCx_hkdDV0Nt7-fAjr5QA@mail.gmail.com>
From: Danny Thorpe <danny.thorpe@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=089e011838f072b3ea051dad6496
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an
experimental hardfork?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 19 Aug 2015 17:30:37 -0000
--089e011838f072b3ea051dad6496
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>>
I would expect any uncontroversial hardfork to be deployed in testnet3
before it is deployed in bitcoin's main chain.
<<
Ok, glad to hear that.
>>
In any case, you can already do these tests using
https://github.com/bitcoin/bitcoin/pull/6382
<<
I saw your post about that awhile ago, thanks for doing the work! My
fiddling with that end of the food chain is gated by my needing to block
out a weekend to set up a bitcoind build environment.
How do "big-block" testnet nodes running this 6382 rev recognize each other
on the peer network? If I set up a 2MB block limit testnet node and
-addnode another 2MB block testnet node (say, JornC's node) to it, and my
node mines a block stuffed with 1.3MB of test txs, the other "big-block"
node should accept my mined block, but it will be rejected / immediately
orphaned by the rest of the testnet network because it exceeds their notion
of block size limit, correct?
Thanks,
-Danny
On Wed, Aug 19, 2015 at 2:29 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Ya, so? All that means is that the experiment might reach the hard for=
k
> tipping point faster than mainnet would. Verifying that the network can
> handle such transitions, and how larger blocks affect the network, is the
> point of testing.
> >
> > And when I refer to testnet, I mean the public global testnet
> blockchain, not in-house isolated networks like testnet-in-a-box.
>
> I would expect any uncontroversial hardfork to be deployed in testnet3
> before it is deployed in bitcoin's main chain.
>
> In any case, you can already do these tests using
> https://github.com/bitcoin/bitcoin/pull/6382
> Note that even if the new testchains are regtest-like (ie cheap proof
> of work) you don't need to test them "in-a-box": you can run them from
> many different places.
> Rusty's test ( http://rusty.ozlabs.org/?p=3D509 ) could have been
> perfectly made using #6382, it just didn't existed at the time.
>
--089e011838f072b3ea051dad6496
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>><br style=3D"font-size:12.8px"><span style=3D"font=
-size:12.8px">I would expect any uncontroversial hardfork to be deployed in=
testnet3</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.=
8px">before it is deployed in bitcoin's main chain.</span><div><span st=
yle=3D"font-size:12.8px"><<</span></div><div><span style=3D"font-size=
:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Ok, glad to=
hear that.=C2=A0</span></div><div><span style=3D"font-size:12.8px"><br></s=
pan></div><div><span style=3D"font-size:12.8px">>></span></div><div><=
span style=3D"font-size:12.8px">In any case, you can already do these tests=
using</span><br style=3D"font-size:12.8px"><a href=3D"https://github.com/b=
itcoin/bitcoin/pull/6382" rel=3D"noreferrer" target=3D"_blank" style=3D"fon=
t-size:12.8px">https://github.com/bitcoin/bitcoin/pull/6382</a><span style=
=3D"font-size:12.8px"><br></span></div><div><<</div><div><br></div><d=
iv>I saw your post about that awhile ago, thanks for doing the work!=C2=A0 =
My fiddling with that end of the food chain is gated by my needing to block=
out a weekend to set up a bitcoind build environment.</div><div><br></div>=
<div>How do "big-block" testnet nodes running this 6382 rev recog=
nize each other on the peer network? If I set up a 2MB block limit testnet =
node and -addnode another 2MB block testnet node (say, JornC's node) to=
it, and my node mines a block stuffed with 1.3MB of test txs, the other &q=
uot;big-block" node should accept my mined block, but it will be rejec=
ted / immediately orphaned by the rest of the testnet network because it ex=
ceeds their notion of block size limit, correct?</div><div><br></div><div>T=
hanks,</div><div>-Danny</div></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Wed, Aug 19, 2015 at 2:29 AM, Jorge Tim=C3=B3n <span d=
ir=3D"ltr"><<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon=
@jtimon.cc</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, =
Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
><br>
> Ya, so?=C2=A0 All that means is that the experiment might reach the ha=
rd fork tipping point faster than mainnet would. Verifying that the network=
can handle such transitions, and how larger blocks affect the network, is =
the point of testing.<br>
><br>
> And when I refer to testnet, I mean the public global testnet blockcha=
in, not in-house isolated networks like testnet-in-a-box.<br>
<br>
I would expect any uncontroversial hardfork to be deployed in testnet3<br>
before it is deployed in bitcoin's main chain.<br>
<br>
In any case, you can already do these tests using<br>
<a href=3D"https://github.com/bitcoin/bitcoin/pull/6382" rel=3D"noreferrer"=
target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6382</a><br>
Note that even if the new testchains are regtest-like (ie cheap proof<br>
of work) you don't need to test them "in-a-box": you can run =
them from<br>
many different places.<br>
Rusty's test ( <a href=3D"http://rusty.ozlabs.org/?p=3D509" rel=3D"nore=
ferrer" target=3D"_blank">http://rusty.ozlabs.org/?p=3D509</a> ) could have=
been<br>
perfectly made using #6382, it just didn't existed at the time.<br>
</blockquote></div><br></div>
--089e011838f072b3ea051dad6496--
|
