Great, great idea.
For my part I would like to beef up the rap sheet against one Gavin Andresen and shine light on the trail of evidence which supports his indictment as Bitcoin traitor and
persona non grata.
Here is Gavin's history of attacks on Bitcoin using the block size as a proxy and purported motivations:
03/12/2013
The "Accidental" fork
Recently Bitcoin came close to unmitigated disaster, in the following way:Gavin diplomatically suggested that miners increase their block size, from the previous magic number of "250k" to something they themselves pick.This approach is flawed: the solution to the problem of having a magic number in the code is not passing the responsibility of choosing it to a larger group. It may work politically, in the sense that where large, vague groups are responsible for a bad move nobody will ever be hung. It does not work practically.
This point does not begin to get sufficient emphasis: stop thinking politically, stick to thinking practically. The political importance, usefulness or competence of a dev is nil. This is not your job, and more importantly this is one of the things you suck at the most. A casual skim through the -dev sessions is ample proof for this, more ridiculous dickwad posturing and knowshitism has never before been seen (outside of the mailing lists of some meanwhile failed open source projects). Snap out of it. Stick to writing code.
Note the foresight of MPOE-PR with regards to the events that came to unfold in the following years.
01/06/2015
The first magic numbers
My goal is to prove that it is safe to raise the maximum block size from 1MB to at least 20MB, with the existing Bitcoin Core code (no fancy invertible bloom filters, no hyper-optimized-for-the Bitcoin-elliptic-curve verification code).
...
My desktop machine (a quad-core, 16GB-memory, "Late 2012" iMac) can easily keep up with a 20-MB-per-block blockchain, and could even keep up with a 200-MB-per-block chain if run with bigger -maxsigcachesize and -dbcache settings.
http://gavintech.blogspot.ca/2015/01/looking-before-scaling-up-leap.html01/20/2015
I'm confident that there are no technical barriers to scaling up
Executive summary: if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks....
... the 0.10.0 version of the reference implementation would run just fine.
http://gavintech.blogspot.ca/2015/01/twenty-megabytes-testing-results.htmlQ3 2015
Why eight? Because it's a Chinese homonym for "prosper" or "wealth"
It crops up in the Chinese Bitcoin community all the time. So this choice obviously wasn't based on any kind of scientific analysis. Having Bitcoin protocol constants be decided by rhymes would obviously have been an embarrassment, but nonetheless, we compromised and did it. - Mike Hearn
https://news.ycombinator.com/threads?id=mike_hearn&next=10921219More on the way...