Topic: "Number of Confirmations". One reason why ALL alts are a fail! (Read 2069 times)

I don't think there is a scenario where the network never resolves splits but the shorter the block interval to the propogation time the longer and deeper those reorganizations are.  It is rare for Bitcoin to have orphan chains which are 2+ blocks deep.

Thank you!! This is the best explanation I have ever found!

The one thing I zeroed in on was the thought that the shorter your block interval, the more 'compressed' your distribution is going to get on the negative(less than target) side. This would mean that you could have a cascade of orphans if the situation hit where multiple miners hit a 'lucky streak'. With something like a 10 second block time and 50,000 miners, that distribution almost insures this would happen sometime. How long would it take the chain to work that out? And if the hashpower gets splintered significantly among a cascade of different orphan chains, it seems ( on first thought ) that the network my hit a point that it couldn't recover. Maybe I'm missing something there, but damn, that's a scary thought. um...DID I miss something?

Just wanted to take the timt to brag about my 80 Gb/s down, 30 Gb/s up, Fibre Op connection....
I think blocks propogate just fine, in short ammounts of time...
Gone are the days, of dial up internet, watching naked pics of Pamela Anderson load, pixel by pixel

You've already been told, many times over. Try reading the information that's already been posted to the thread.

Then please comment them out and correct me man. I feel like there is something very fundamental that I missed!. I really want to know what that is.

What you are saying is not correct. He has told you already that you're incorrect. The information stating that you're incorrect is even on the Bitcoin wiki, and that wiki is extremely biased (mostly thanks to the Bitcoin developer Luke).

Wow so I started an idiotic discussion? It is interesting how my idiotic discussion is the same thing you are praising here it is just DeathAndTaxes is more knowledgeable and explained my point in details. Also when I explained myself he actually agreed.

It is amazing how many times I get attacked personally not according to the content I write....

There are ways around this if the people making alt-coins were interested in real innovation.  Part of the problem comes from the fact that (IMHO wisely) the Bitcoin network doesn't rely heavily on time because proving timestamps in a decentralized manner is a very challenging problem.  This means that the distribution of block times is even (half shorter, half longer) and the "tails" extend out quite a ways roughly 14% of blocks will take 2x the target or longer, 5% will take 3x the target or longer, 2% will take 4x the target or longer and occasionally (about 1 in 2000 blocks) it will take 10x the target or longer.

However imagine a scenario where miners broadcast not just block solutions but also the headers which meet a certain lower difficulty target as well.  This would work very similar to how p2pool's "share chain" works except it would just be for tracking the amount of work since the last block.  If the block has a min difficulty of x then a lower difficulty hash of x/20 will be 20x as likely. These lower difficulty headers could be called "timestamps" are maybe "workstamps" is a better term.  As they are just small headers (<1KB) they could propogate the network quickly and would occur very frequently.  To ensure miners don't keep them a secret a small reward could be incorporated into the workstamp system.  If there was no other change it wouldn't be much good other than a more precise timer but if the protocol lowered the difficulty based on how many workstamps have occured since the last full block it would get "easier" to find a block the longer it has been.  This would reduce the frequency that very longer than the target blocks occur at.

So imagine a network with difficulty 1000 and workstamps are 5% as difficulty (50 difficulty) they will on average occur 20 times between blocks.  Each workstamp since the last block makes the min difficulty for a hash to solve the next block drop by 5%

Block found.   Next block difficulty = 1000
Workstamp found. Next block difficulty = 950
Workstamp found. Next block difficulty = 902
Workstamp found. Next block difficulty = 857
Workstamp found. Next block difficulty = 814
Block found.   Next block difficulty = 1000
Workstamp found. Next block difficulty = 950
Workstamp found. Next block difficulty = 902
Workstamp found. Next block difficulty = 857
Workstamp found. Next block difficulty = 814
....
Workstamp found. Next block difficulty = 144
Block found.   Next block difficulty = 1000

The longer it takes to find a block the easier it becomes.  While "long" blocks can still happen they will be more rare.  It doesn't have to work exact this way there are lots of ways to build upon how Bitcoin works.  Of course this assumes alt-coins are actually about innovation.

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.




  

light is relative.

soon is relative...

Soon we will all be on fiber thanks to Google...   

-tb-

speed of light? only applies to fibre optic networks ie the backbone of the internet. normal lines are slightly slower.

I absolutely agree with you, these are not the days of the Pony Express, there is no need to wait an hour for 6 confirmations, it is a serious flaw/weakness with bitcoin. There is another issue with waiting 10 minutes for one confirmation, the huge number of trades that can form/accumulate in one 10 minute period, if bitcoin is to be the electronic currency that the world decides to settle one, it will fail miserably. It will not be able to log all the transaction in a minor city, much less a country, that take place in a ten minute period. Having a faster confirmation time lets the number of transactions that are logged increase. Besides, in 1 minutes, or 30 seconds a network can send a million messages across the world, My God we are talking about the speed of light.

eh you're probably right and us with fast confirm coins are all in denial >.<

Thanks OP! You are correct.

10 minutes is a time carefully chosen as a balance between usability and security.

6 confirmations (6*10 minutes) is a number carefully chosen as a balance between usability and security. 6 confirmations are just a recommendation though, you can choose higher or lower security depending on your needs.

lophie, one can argue that transactions have enough time to propagate around to enough nodes in about 3 minutes. hell, even on small time coins, like my recent OSC, a transaction is broadcast through 19 nodes or more on average, within about 20 seconds. its safe to say that satoshi was being overly cautious i think. in 2009, i had a 300 kb/ps internet connection for about 60 bucks a month. in 2013, i have a 20 mb/ps connection at 45/month. alot has changed my friend. i did a test yesterday in routing transactions through proxies on osc and back to a computer in my subnet not on the proxy. it took about 37 m/s longer for a transaction going through the proxy server in the netherlands. versus the instantaneous transaction on my subnet. just food for thought, and you know i have respect for your opinions. if 3 minutes ever becomes a problem for OSC i will increase it to 6 confirms/1 minute instead of 3 confirms/1minute.

Id be interested to get feedback on the community feeling regarding lower frequency time , so BTC chose 10 minutes and 6 confirms , LTC chose something less than that .

But there are other vectors to this argument of course , of security that is , LTC has a few different fundamentals .

When one looks at say DGC it has a 60 second frequency yes ?  I didnt really take notice before , but what could be the effects either way of such a fast frequency ?  

Edit 20 seconds for DGC - which is interesting , i expect this is why they introduced checkpoint measures.

In 15 minutes I can get 6 confirms with Litecoin. I'll get 1 with Bitcoin. Do you understand how this works? We aren't back in 2008 where most of North America was still on 100KB/s connections. The data does not take that long to sync across the network. The hash rate is high enough and spread equally in Litecoin.

Do I care about the shitcoins like FTC that get 51% attacked every week? No. They can deal with their shitty developers and diseased community on their own, it doesn't affect Litecoin in any way.