lol as in "blocksize 101"? MIT get out of here!

when did that happen?  i asked Greg about it late last night and he said it had been assigned.  but it couldn't have been too much before that.  or did it occur after i asked?

https://www.reddit.com/r/Bitcoin/comments/3awomg/how_the_bitcoin_experiment_might_fail/csgt8ed

oh my:

It merely scratches the surface of the capabilities, but achieving only this satisfies the Whitepaper and thus remains my criteria for success.

As a guiding principle for the project, doing anything that reduces this potential in order to achieve something other than this, would be against the spirit of Bitcoin.
Thus, those efforts could/should be a different project, or would otherwise naturally follow from the success of this one goal, which remains a long way off.

You're absolutely right.

Again sorry for being off topic.

Tsipras taking to Twitter!

http://blogs.wsj.com/moneybeat/2015/06/24/equities-turn-red-as-greek-optimism-fades-tsipras-vents-on-twitter/

Is it meant to be humorous that voting is described as arbitrary when compared to a single person picking a number out of his head?

yes the voting has issues.  

The biggest issue is the role the block size cap should have in the network.  

Satoshi, Gavin, et al. see it as a "sanity check".  In software this is essentially an exceptional condition -- a value that the system should *never* exceed.  In this perspective, miners can individually produce smaller blocks (regardless of pending txn count) so why create a mechanism that essentially forces a cartel (collective behavior)?  The only reason would be to maximize miner profitability by manipulating the supply curve.  Closely tracking evolving network and disk capacity is not necessary for a "sanity check" because most miners will simply start mining smaller blocks (than the limit) if network and disk stop following moore's law.

Others want the max block size to be an entity that can be used to actively manage the network.  Presumably if miners are noticing a lot of "spam", but a "misbehaving" miner is mining it, they could vote to reduce block capacity to eliminate this spam.  Also, voting lets the limit more closely track the evolution of network and disk capacity.

Let's assume a spam attacking misbehaving miner ala the large miner, large block attack against small miners that was initially a huge FUD advanced by Wiulle and others that you don't hear anything about anymore. Simple defense, just mine a 0 TX header only block during the time of your large block processing. This is the practical defense that Wang Chun told us they do and that we've witnessed they do during stress tests. And this defense can be done  irrespective of whether as a miner you are connected to Corallo's relay network or not which those Fudsters love to go on about.

Point being miners can and should be encouraged to track TX's and fees and construct blocks appropriately based on their own internal metrics and profitability. Core devs can't possibly do this.

Yes, you could accuse Gavin of trying to be a one man predictor for network growth at this point but his proposal is based on sound growth projections with the larger point being that he is trying to automate out as much human intervention, voting manipulation  and need for future forks as much as  possible.

The full block 'problem' was overplayed for propaganda reasons.  It's the same principle as making loud noises to get a herd of animals to do what you want them to do.

Someone made some graph with his guess at simplistic future predictions which did not (because they can not) make any allowance for future developments.  His genius was to put pretty colors on it which were even more arbitrary.  Since people like shiny and colorful things (a throw-back to our simian ancestry where identifying ripe fruit was important) it was a wildly successful bit of propaganda with many observers.  That does not make it particularly meaningful in reality though.

In point of fact there is a large mostly synthetic utilization of transaction availability even at the 1MB derived rate.  This from people who would not be there if it were not for the fact that BTC transactions are subsidized to the level of being nearly free.  Sloughing off these freeloaders will not threaten the system at all and may be helpful.  This would buy us at least a lot of time.  If/When an actual problem with capacity occurs everyone that I know of (except perhaps MP) is perfectly amenable to increasing capacity through simplistic block size increase methods.  In that case, unlike today, it will be much more easy to gain the 'consensus' that Bitcoin needs.