>>
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ón <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 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 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=509 ) could have been
perfectly made using #6382, it just didn't existed at the time.