0. The actual implementation of the code only acts on the 6th received block as that is what is necessary for a full confirmation.

To further clarify: if 5 blocks are sent by one peer, and another block is received by the same peer that has a timestamp within 10 minutes of the first block sent by that initial peer, the peer that sent those 6 blocks is banned.

1. Ip address is used for peer identification.

2. If there are many peers attacking the converging node will be banned and the network will be segmented for a few hours before repairing itself.

3. Faking timestamps is a whole other issue, but Bitcoin generally has resolved this by limiting how far in the future timestamps can be(+2h), thus while such an attack may work, it is fairly easy to counter by limiting the range of the timestamps/mode of determining the current time.

Don't blame us for this, blame the people who decided a non-accurate timestamp was A-OK.

I will look into a way around this inherent flaw in Bitcoin as it seems a hornets nest ready to unravel.

The defense makes no distinction between an attacker and someone who has > 51% of the hashpower... they are equally threatening.

4. Cryptocoin mining should be as distributed as possible, these mega-multi-pools only cause trouble by creating mass spikes of supply where its not wanted and the market no longer needs it.


With regards to the third point, I may decide to abandon the standard Bitcoin client entirely and come up with a new client from scratch and perhaps even a new blockchain (time and life allowing). There are many design decisions that were made by the Bitcoin team that I disagree heavily with. It's time-laxity being one of them.