Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud)
From a little watching of my connection activity, I observed that a lot of the upload bandwidth was loading older blocks. A limit on bandwidth provided for uploading older blocks would certainly help.
Implemented in Bitcoin Core git master a couple months ago, will be in 0.12; along with many other resource control tools. Though if widely used it will further congest getting blocks to begin with. It's a good trade-off, but not without costs. None of this is magic: cutting down this source of traffic or that is mostly just constant factor reductions. To operate the system needs a safety margin, and we're bumping up against actual limits.Not sure what happened with that, looks like it didn't make it into 0.12, but perhaps I'm not looking hard enough. Or maybe there was a good reason not to include it (apparently network message anti-spamming measure did make it into 0.12)
You weren't looking hard enough 
, it's called -maxuploadtarget see also doc/reduce-traffic.md (though not all of the features are documented yet). (amusingly, this was one of the relatively few PR's that Mike Hearn commented on-- opposing it.)That does not mean I think the crowd will choose big blocks, it means that I think if bigger blocks are needed then I think that something will happen to ensure that bigger blocks happen.
This was one of the big fallacies involved in the "crash landing" spin by Gavin and Hearn; this notion that Bitcoin would willfully commit suicide. Cranking the scale ahead of addressing scaliablity is/was controversial (not just among the most technical, though it's nearly universal there); but if it were strongly _necessary_, and better than the harm of not; then it would no longer be. That we're not there now, shows it isn't. QED. And there is a tone of activity gone on to improve scalablity at all levels of the system, from micro optimizations, to protocol design.