I don't think essentially replacing most of Testnet with a specialised test chain is a good idea, but this might be a good time to consider a 4th test network with very large blocks from genesis onwards.

I do tend to think 2 years of 8mb blocks is excessive as a test, too, and while certainly large projects should have or can raise funds for test infrastructure, I would worry about the smaller stuff out there. Is there anything specific 2 years gives us over, say, 6 months?

Ross

On 22/06/2015 20:23, Peter Todd wrote:
On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:

I promised to write a BIP after I'd implemented
increase-the-maximum-block-size code, so here it is. It also lives at:
https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki

It's important that we see a wide range of realistic testing of what an
8MB limit could look in the near future. An important part of that
testing is load testing.

As of writing the BIP above has no mention of what switchover rules will
be used for testnet; code floating around has August 1st 2015 as that
date. I propose we use August 1st 2013.

This switch over date should be set in the _past_ to allow for the
creation (via reorg) of a realistic full-load blockchain on testnet to
fully test the real-world behavior of the entire infrastructure
ecosystem, including questions like the scalability of block explorers,
SPV wallets, feasibility of initial syncronization, scalability of the
UTXO set, etc. While this is of course inconvenient - 2 years of 8MB
blocks is 840GB worth of data - the Bitcoin ecosystem can-not afford to
make a change like this blindly.

I'm sure with a $3.5 billion market cap at stake we can scrape together
the resources to voluntarily run a few hundred full-load full-nodes for
testing a change with the potential to destroy that market cap.




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev