Quote from: martin on July 25, 2011, 12:54:51 AM

The thing is, faster blocks would take less effort to generate, so to get the same level of security as you currently get by waiting 30 mins for three blocks, you'd have to wait 30 mins for 15 blocks. So, nothing would go faster, you'd just be consuming more traffic spamming the network with more blocks.

While it is true that faster blocks would require a lower difficulty, the constant latency means that the wasted effort grows with block speed. If you can cut latency 50% across all nodes then you can cut block speed 50% with insignificant loss of efficiency (this excludes memory and bandwidth requirements which will obviously increase).

Quote from: iopq on July 26, 2011, 09:58:57 AM

not quite true, because some merchants only wait for one confirmation to credit you with the money

But a faster confirmation will be more than proportionally less robust. With a doubled block speed competing forked block chain rates will more than double. As an extreme example, if the block speed were a few seconds (about the same as latency), then the network would thrash with the majority of 'confirmation' blocks being invalid. Less than a minute and the miners will spend twice as much energy producing the same number of hashes (with maybe 15% of all 'confirmations' invalid).

Miners could (and probably should) make direct connections to each other. However such a protocol requirement would make the network less robust. Indeed malicious miners would simply isolate the honest nodes.