DeathAndTaxes. Thank you for the advice.
...
6 confirmation was never chosen in the paper and what was discussed is the probability of the success of a double spend getting smaller and smaller with every confirmation. I am sorry if I still don't see where I was mistaken please point me to it. I am trying to learn as well as inform in the same time. Thank you.
Well that was the point. The first thing is that there is no magical number of confirmations. It is possible an attacker with enough hash power could reverse a chain of MORE than 6 confirmations. It is also possible in many instances (value of tx vs cost to build an attack chain) that 1 or 2 confirmations is more than enough security and waiting for more simply reduces the user experience. Satoshi never intended for the "THOUGH SHALL HAVE NO OTHER CONFIRMS THAN SIX" to be treated like gospel. Meni wrote a very good paper showing the cost of an attacker to reverse a tx relative to the tx VALUE and number of confirmations. It is a far better method to gauge "how much security do I really need" then just using 6 confirms for everything. We (TC, LLC) paid out millions of dollars in "real money" over the better part of a year after only three confirmations. We also sold low value cellphone pincodes at one time using 1 confirmation and .... GASP 0 confirmations on repeat buyers.
So the fact that 6 confirmation = hour has no validity/significance to the security of the network. Also you correctly surmised that any coin which says it uses 4 confirms (or x confirms) instead of 6 shows a horribly lack of even basic knowledge by the author. Bitcoin doesn't require ANY number of confirms. The number of confirmations is a choice by users not the protocol. Anyone promoting a coin based on only needing 4 confirms doesn't even understand the basics on how POW security works and that is a scary thing if they are writing an alt-coin.
As for the choice of the interval itself. Satoshi chose 10 minutes to be conservative but it isn't as conservative as many people think. Most people say it only takes a second to download a block so why wait 600 seconds, 150, 30 or even 10 seconds should be "more than enough".
The reality is it is more complex than that. It isn't all or nothing you need to consider:
a) Small nearly empty blocks will be faster than very large blocks in the future (the goal should be building the coin for the future not the launch)
b) The block target is just a target. The actual times will vary so even with Bitcoin's "slow" 600 second interval often competing blocks are found before a block fully propagates the network.
c) In a peer to peer network it takes multiple hops so that multiplies the transit time of a block.
d) Any hashing power lost to orphans reduces the security of the network.
Mining is a Poisson Process and the interval between events (block found) will follow a Poisson distribution. So while 10 minutes is the average interval a significant portion of those blocks will be found much faster (and a significant portion much slower). I don't have time to draw the curve for multiple block intervals so I will steal an existing example curve from wikipedia.
One could draw the same curves using seconds in the block target of various coins. The reason for the chart is to illustrate that while a coin may TARGET a specific interval the actual block times will fall in a distribution around the target time. Just looking at the average time is deceptive. For security implications we are interested in how often blocks will be found very quickly (relative to propagation interval). For a chain with a target time of x seconds, about 39% of blocks will be found in 0.5x seconds or less, about 22% will be found in 0.25x seconds or less, about 10% of the blocks will be found in 0.10x seconds or less.
When a block is found before a previous found block propagates the network an orphan occurs. The next block will either build on the previous block or the newly found one. From a security perspective it doesn't really matter which one will be orphaned because regardless work and thus security is lost. Even on Bitcoin's "slow" network about 1% or the hashpower is wasted due to orphans and the network right now is very small and blocks are very small. An attacker is going to keep working on the attack chain even if he is a block behind so orphans help the attack by reducing the effective hashrate and thus security of the network.
Now for small networks (less hops) and low tx volume even very short block targets aren't a significant problem however Satoshi designed Bitcoin not for genesis day but for what would be optimal if Bitcoin became mainstream. Any crypto-currency that grows to any meaningful volume is going to have much larger blocks. Someone saying the brand new "xyz coin" with 10 seconds blocks isn't a problem is being naive when you consider the average block is a maybe a half dozen tx and there aren't more than a few hundred nodes.
So lets look at a more longer term scenario. Imagine a scenario where the average block is 25 MB. To relay that to one peer in 1 second would require 200 Mbps. However no node connects to only 1 peer so even relaying it to the minimum 8 peers would require 1,600 Mbps. For a miner (if you work for a pool you are a worker the pool is the "miner") 8 peers is insufficient to rapidly broadcast a block and poor connectivity means higher relative and less revenue. With just 50 peers to relay a 25MB block in 1 second requires 10 Gbps.
However the miner can only influence his relative oprhan rate (his orphans vs network average orphans) the overall orphan rate is based on the average node connectivity and the size of the network. Also remember there will be multiple hops and before relaying each node has to verify each tx, each tx hash, each leaf of the merkle tree (requiring 2n-1 hashes for n txs), the block header, and the block hash. The average node may a minimum of 8 connections but for propagation what matters is unique connection. When a node learns of a block how many nodes is it connected to that don't already know the network. Lets estimate the unique connectivity between Bitcoin nodes is 5. In a network of 50,000 nodes that means 7 hops to propagate the block to all nodes.
So lets start making some assumption about a future network to see how long propagation could take.
50,000 nodes
5 unique connections between nodes
1 Gbps of upstream bandwidth
25 MB block size.
100 ms latency between blocks
15% overhead due to TCP/IP
250 ms to verify block & txs.
We are looking at 7 hops and ~10.5s for propagation to all nodes in the network. This is just an estimate in reality due to the disimilar nature of peers makes any computation essentially impossible it would either need to be observed or simulated. I would point out that this example network is pretty optimistic from a delay standpoint. It has a low occurrence of redundant connections and very high average upstream bandwidth (probably unrealistically so for residential connections even in the intermediate future). Still we are looking at 10.5 s from the time a block is found until all nodes have received and verified it. Now one may say 10.5s is smaller than even a block time of 20s so it shows Bitcoin is unrealistic. However remember the interval just being a target, actual interval between blocks will be a distribution. It isn't all or nothing any propagation delay increases the rate of orphans. We use the term "network" like it is a single continually in sync system but the reality is it is an ocean of independent peers. The network is never 100% in sync but the larger propagation delay the longer there is a lack of consensus on the longest chain, and an orphan can occur. Even on slow Bitcoin network about 3% of blocks will be found in 10.5s or less and that assumes difficulty is perfectly matched with hashrate. Right now the network is operating 30% faster than the assumed hashrate for the current difficulty so that would be closer to 4% orphans. The smaller the target interval relative to the expected propagation delay the more security will be "counterfeited" by orphans (miners working on mutually exclusive blocks).
So what is the perfect block interval? There isn't one. It is compromise between security and responsiveness. Changing it is very difficulty (if not impossible) and the "perfect" target time is very dependent on network conditions and tx volume and those are going to change over the life of the currency. Satoshi chose conservatively based not on the conditions at the time of launch (tiny blocks, and a handful of nodes) but based on the potential future (massive blocks and tens of thousands of nodes). Even for Bitcoin as the network grows larger and more complex the "peer finding mechanism" will probably need to be improved to ensure the network has good end to end connectivity. Nodes will want to work together to avoid creating bottlenecks which can make propagation unnecessarily long.
BTW I am not saying LTC (or any particular coin) is doomed but there IS a tradeoff between response time and security. The point remains that looking at the target block interval compared to propagation times on a small network with nearly empty blocks is a nearly useless metric. Any network can operate under those scenarios. What happens when the network grows. The further you reduce the interval the more likely it is that the improved responsiveness doesn't warrant the reduced network efficiency and the security implications that brings. My opinion is that block times in the 2-5 minute range are probably "fine" but the future is hard to predict and it could be a problem down the road. I don't see the ultra short block intervals as being viable for anything other than a short lived pump and dump.
For those who are interested in actually innovating hopefully this shows that using the model Bitcoin uses you can't simply change the parameters blindly however it doesn't mean there aren't alternative methods to secure the network but it will require some thinking outside the box. I have considered a variety of different models which would allow faster confirmations and I am sure there are other novel ones waiting to be thought up.
