>> 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 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 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. >