<p>The lower confirmation time schemes for mining a block will have a pronounced effect on orphaned blocks, with an inversely proportional relationship prevailing.</p>

<p>Generally this can be explained quite simply; because shorter confirmation times for blocks will mean numerous simultaneous competing chains lengths. Of these competing chains, one will eventually be integrated into the ledger when the block height is greater than the competing chains' heights. However, the chains which are rendered obsolete (ie the shorter chains not integrated into the ledger) will mean orphaned blocks are much more likely as confirmation time decreases. </p>

<p>Take an example where it's 1 minute confirmation times. If there's 4 competing chains each 5 blocks in height/length then all it takes is for one of the chains' blocks to be confirmed in, say, 10 seconds, followed by the next confirmation in 10 seconds (which is not a rare event) which will make the block height 7. Therefore, the other chains of height 5 (or perhaps 6 if a block was solved) will be rendered orphaned, and all Txns therein will be orphaned.</p>

<p>There is a balance that needs to be struck between confirmation time and orphaned blocks, and from my experience with altcoins, the 2 minute mark (as employed by Litecoin) is the functional limit. Ethereum has a much, much shorter confirmation time because it's a totally different kind of altcoin. However for POW coins like LTC/BTC, a ~20s confirmation time is infeasible.</p>

CC BY-SA 3.0
2014-12-04T22:10:28.290Z
Note that the confirmation time doesn't totally control how long blocks take to be generated - the average time between blocks in Bitcoin is 10 minutes, but that can be shorter or longer.
Nick ODell
CC BY-SA 3.0
2014-12-04T23:29:23.947Z
@nickodell I did try to cover that without the math using the 10s block eg but you've raised another good point; what variables should/could be considered to improve on Bitcoin's 2016 block/10 min (eg some altcoins employed Kimono Gravity Well for difficulty adjustment, but assessing the mining reward paradigm could provide far superior improvements, ie like Ethereum/sidechains promise)
Wizard Of Ozzie
CC BY-SA 3.0
2014-12-04T23:36:31.693Z
Wizard, please can you elaborate more about Kimono Gravity Well and if any mathematical modeling of the difficulty will be close to Kimono Gravity Well equation?
efaysal
CC BY-SA 3.0
2014-12-05T00:13:35.560Z
I'm running off Android at the moment so I don't have the reference handy (I'll aim to do so once I've got access to my Ubuntu bookmarks) but there is definitely material available online for the equation KGW employs. Simply put it's a solution to quickly re targeting difficulty in proportion to hashrate. It is very efficient but extremely sensitive and hasn't seen much use beyond clones of litecoin
Wizard Of Ozzie
CC BY-SA 3.0
2014-12-05T10:30:36.137Z
@efaysal: Perhaps you'll be interested in [How does the Kimoto Gravity Well regulate difficulty?](http://bitcoin.stackexchange.com/q/21730/5406)
Murch
CC BY-SA 3.0
2014-12-05T19:01:28.627Z
@Murch, any step-by-step approach to build Kimoto Gravity Well formula? From assumptions to the model or formula?
efaysal
CC BY-SA 3.0
2014-12-06T11:42:39.423Z
@efaysal Actually the Sourcecode is linked right on the question I posted above as a comment on the question post.
Murch
CC BY-SA 3.0
2014-12-04T20:34:21.207Z
2014-12-04T20:34:21.207Z
Wizard Of Ozzie
<p>Bitcoin, the first blockchain-based cryptocurrency, set a 10 minute confirmation interval time; LiteCoin set a 2 minute confirmation interval time; DogeCoin set it at 1 minute; QuarkCoin set it at 30 seconds; Ethereum set it at 12 seconds.</p>

<p>Is there any serious analysis about the stability of the blockchain when the confirmation time is reduced?</p>

<p>To be more specific: any requirement between confirmation time and the probability to find a block during that confirmation time ( specially when confirmation time is going to zero) ?</p>

CC BY-SA 3.0
2014-12-04T21:52:15.450Z
@NickODell Thanks for your editing. Title is now a clear question.
efaysal
<blockchain><security><confirmations>
Lower confirmation time schemes: any requirement between confirmation time and the probability to find a block during that confirmation time?
efaysal
# Lower confirmation time schemes: any requirement between confirmation time and the probability to find a block during that confirmation time?

(Asked by: username_0 on 2014-12-04)

Bitcoin, the first blockchain-based cryptocurrency, set a 10 minute confirmation interval time; LiteCoin set a 2 minute confirmation interval time; DogeCoin set it at 1 minute; QuarkCoin set it at 30 seconds; Ethereum set it at 12 seconds.

Is there any serious analysis about the stability of the blockchain when the confirmation time is reduced?

To be more specific: any requirement between confirmation time and the probability to find a block during that confirmation time ( specially when confirmation time is going to zero) ?

**Tags:** blockchain, security, confirmations

> **Comments:**
> **username_0**: @NickODell Thanks for your editing. Title is now a clear question.  

---

## 1 answers

### Answer by username_1 on 2014-12-04. Score: 1

The lower confirmation time schemes for mining a block will have a pronounced effect on orphaned blocks, with an inversely proportional relationship prevailing.

Generally this can be explained quite simply; because shorter confirmation times for blocks will mean numerous simultaneous competing chains lengths. Of these competing chains, one will eventually be integrated into the ledger when the block height is greater than the competing chains' heights. However, the chains which are rendered obsolete (ie the shorter chains not integrated into the ledger) will mean orphaned blocks are much more likely as confirmation time decreases.

Take an example where it's 1 minute confirmation times. If there's 4 competing chains each 5 blocks in height/length then all it takes is for one of the chains' blocks to be confirmed in, say, 10 seconds, followed by the next confirmation in 10 seconds (which is not a rare event) which will make the block height 7. Therefore, the other chains of height 5 (or perhaps 6 if a block was solved) will be rendered orphaned, and all Txns therein will be orphaned.

There is a balance that needs to be struck between confirmation time and orphaned blocks, and from my experience with altcoins, the 2 minute mark (as employed by Litecoin) is the functional limit. Ethereum has a much, much shorter confirmation time because it's a totally different kind of altcoin. However for POW coins like LTC/BTC, a ~20s confirmation time is infeasible.

> **Comments:**
> **username_2**: Note that the confirmation time doesn't totally control how long blocks take to be generated - the average time between blocks in Bitcoin is 10 minutes, but that can be shorter or longer.  
> **username_1**: @nickodell I did try to cover that without the math using the 10s block eg but you've raised another good point; what variables should/could be considered to improve on Bitcoin's 2016 block/10 min (eg some altcoins employed Kimono Gravity Well for difficulty adjustment, but assessing the mining reward paradigm could provide far superior improvements, ie like Ethereum/sidechains promise)  
> **username_0**: Wizard, please can you elaborate more about Kimono Gravity Well and if any mathematical modeling of the difficulty will be close to Kimono Gravity Well equation?  
> **username_1**: I'm running off Android at the moment so I don't have the reference handy (I'll aim to do so once I've got access to my Ubuntu bookmarks) but there is definitely material available online for the equation KGW employs. Simply put it's a solution to quickly re targeting difficulty in proportion to hashrate. It is very efficient but extremely sensitive and hasn't seen much use beyond clones of litecoin  
> **username_3**: @username_0: Perhaps you'll be interested in [How does the Kimoto Gravity Well regulate difficulty?](http://bitcoin.stackexchange.com/q/21730/5406)  
> **username_0**: @username_3, any step-by-step approach to build Kimoto Gravity Well formula? From assumptions to the model or formula?  
> **username_3**: @username_0 Actually the Sourcecode is linked right on the question I posted above as a comment on the question post.  

---

