Lately I am using tradeblock as their site is fast and informative. https://tradeblock.com/blockchain
For some reason the leadership at blockchain.info has become rudderless and their site is often not keeping up and development there seems static. My impression anyway.
why was that a bad thing? it was a one off to help consolidate all that dust and required that a miner self construct this type of block and transmit it. that wouldn't be a repeatable, viable attack to inflict on the network by a rogue miner looking to gain an advantage over other miners for the following reasons:
1. constructing an 8MB bloat block while the rest of the network is making 1MB blocks runs the severe risk of orphaning
2. if the pool consists mainly of hashers, they would react by redirecting their hash away from the attacking pool to preserve the network
3. if it was coming out of China from a large miner, that miner runs even more risk of orphaning due to the GFC.
4. other miners receiving such a bloat block could react defensively by switching to mining a 0 tx block during the validation process.
5. game theory suggests a miner wouldn't even begin to do this attack for preservation of BTC value and his hardware investment.
Yes. The block which reduced the utxo set. That was the good part (though Greg posted on irc that it could have been constructed much more efficiently). Anyway, the bad part is that validation took 25 secs (because of all the inputs). Bitcoin full nodes have no way at present to look at a block and decide to orphan it in advance because it is a "bloat block" that will take too long to validate, they will all chug through the block first.You are probably right bloat blocks would not propagate fast enough and get orphaned.
here's a subtle theory i have as a result of that 1MB tx block.
i think the only reason an attacker would even try that type of bloat block to try and choke the network is if and when all other miners are creating similar sized blocks; like the situation we have right now with full blocks. that way, it runs less chances of being orphaned (which it wasn't) b/c it doesn't stand out in the crowd of other 1MB blocks. but if we went to no cap tomorrow, trying to attack with a huge bloat block while everyone else is still at 1MB blocks would stand out. all other miners could then react defensively, if they so chose, by mining 0 tx blocks during the 25 sec validation period. or, more likely, it would just get orphaned. thus, any attack would fail with no limit. afaic, there weren't any defensive 0 tx blocks mined after that 1MB single tx block b/c none of the other miners were particularly threatened by it as they were also mining 1MB blocks. then, it would be quite likely their hashers would abandon them for egregious activity perpetrated against the network good and destroy them like they did with ghash.
IOW, what i'm saying is that there will be a tremendous incentive for miners to stay together near the average block size across the network even w/o any cap at all. if they all decide to create larger blocks, fine, they advance to bigger blocks together as most miners are honest. that would be a good thing. the majority of them don't want disruption. spammers would even get wiped out in this situation if the miners in aggregate decide they can handle the spam. which they would by assessing full node functioning across the network and examining their own internal capacities along with user fees and access. spam would even help strengthen the mining industry unbeknownst to the spammer by feeding revenue to them while desperately trying to jack mempools and disrupt users. and IF by chance spammers do start to jack the mempool, then miners can simply dial up their minfees to choke them off.
no limit is the easiest most straight forward way to short circuit the spammers ability to disrupt the user and jack mempools.