rich1.0npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaefhttps://nostr.ae/npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaefnjumphttps://nostr.ae📅 Original date posted:2015-06-23 📝 Original message: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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150623/7a41e361/attachment.html>