Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E78A69B4 for ; 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 ; Wed, 19 Aug 2015 17:30:35 +0000 (UTC) Received: by obbfr1 with SMTP id fr1so10354963obb.1 for ; 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: References: Date: Wed, 19 Aug 2015 10:30:35 -0700 Message-ID: From: Danny Thorpe To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev > 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
>>
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.=C2=A0

>>
<= span style=3D"font-size:12.8px">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!=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.

=
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?

T= hanks,
-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@li= sts.linuxfoundation.org> wrote:
>
> 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.
>
> And when I refer to testnet, I mean the public global testnet blockcha= in, 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--