Quote from: acoindr on July 05, 2013, 10:57:53 PM

I addressed latency and orphans here:

Yeah that isn't a solution. So the attacker simply DDOS the centralized point (or few points) of failure.

Still you seem to gloss over the fact that validating a block takes a non zero time. Most of the delay isn't actual propogation delay it is validation delay.

For example time zero your node is notified (either directly or through so easy to take down centralized MBR what has to happen before you validate the block and begin work on a new one.

1 ) You must receive the list of transactions in the block (this could be modified to a list of tx hashes to be more efficient)
1a) If protocol sends tx hashes you will need to query peers for missing txs.
2 ) You must validate that each tx is valid which means
a) the inputs are unspent outputs (lookup/locate the referenced prior tx output in the UXTO)
b) the tx is properly formed. no invalid structure, parsing issues.
c) pub key for each input matches the pubkey hash of the prior unspent output (i.e. hash the pubkey and match to prior output pubkey hash)
d) for each input compute the simplifed tx form, the simplified tx hash and validate the signature.
e) verify that the sum of inputs exceeds the sum of the outputs. note the difference between sum of inputs and outputs.
f) parse and verify the tx output script is valid.
3 ) compute the merkle tree and merkle root hash (which involves 2n-1 hashes)
4 ) validate the coinbase value is correct (coinbase should be <= computed subsidy based on blockheight + sum of all tx fees in 2a)
5 ) validate the timestamp is within 2 hours of mean network time.
6 ) validate the prior blockhash in header refers to a known block
6a) if prior blockhash is unknown query peers for the block in question (and perform all the steps in this process on that block)
7 ) validate that difficulty & version is correct
8 ) compute blockhash and ensure it meets difficulty target

Even given infinite bandwidth and all miners having all other miners as a peer, this process takes a non-zero amount of time. The most time sensitive elements are indicated in bold. The single largest by time is the validating of all input tx signatures due to the fact that it is 1 ECDSA sig validation (relatively slow process) per input in the block.

Today with relatively low tx volume the time to validate a block is sub 1 second but as block sizes grow (think hundreds of MB and hundreds of thousands or millions of transactions) that time will rise.

Now there are some optimizations possible but propogation delays will cause increased orphan rates in the future if network volume rises even to PayPal levels (50 to 100 tps). A smaller block interval is going to result in higher orphan rates and less security. Why do you think Satoshi decided on 10 minutes, why not 1 minute, or 1 seconds. It never occurred to him that smaller block intervals would be possible? Alt-coin "designers" simply modified the code thinking shorter = better but it is compromise. Now I am not saying Bitcoin is perfect but any block interval is a compromise between Latency and security.