<p>You couldn't make functional Bitcoin-like fork with that fast of block mining. There is a tradeoff between speed of block creation and consistency of the network. In Bitcoin the blocks are created infrequently enough that the entire network can agree on the canonical blocks quickly and transactions can propogate quickly enough of that they tend to get included in blocks fairly quickly (assuming that miners aren't ignoring them due to low/no fees).</p>

<p>If a fork aimed for a block generated a millisecond that would imply that network latency would result in thousands of blocks happening before you could even see the first one. In Bitcoin there are occasional forks of the blockchain due to propagation delays, but they are very quickly resolved by the network. A fork with millisecond blocks (and a large user base) would certainly have thousands of competing forks at any given time, and it would take tens of thousands, maybe even millions of confirmations before it became clear that a fork was dominant. (By which time, there would be thousands of forks of that fork.)</p>

<p>Plus, even without any transactions, each block has a minimum size of overhead, so the size of the blockchain would be growing at an outrageous rate. The same would apply to network bandwidth: the amount of chatter between the nodes would be outrageous: none of the nodes could keep up with the volume. Especially given that the volume would have so much duplication between all of the competing forks of the blockchain.</p>

<p>As Colin Dean points out, Litecoin has established a 2.5 minute target. So changing the target block generation speed is possible. But every time you go lower, the overhead and consistency gets harder.</p>

<p>What's the theoretical maximum? It's hard to say since so much depends on how globally distributed and large the network is. My wild guess, given current technology: anything much less than a minute would have a lot of forks and a lot of overhead. Anything less than a few seconds would almost certainly fail to achieve any kind of stable consensus about the blockchain.</p>

CC BY-SA 3.0
2015-07-29T14:56:32.907Z
And see [here](http://www.cs.huji.ac.il/~avivz/pubs/15/btc_ghost.pdf) for a theoretical analysis of the question and a suggested improvement.
stanga
CC BY-SA 3.0
2013-04-03T17:49:47.203Z
2013-04-04T00:07:16.713Z
2013-04-04T00:07:16.713Z
David Ogren
<p>Perhaps you're confused on what the purpose of a Block is, and why several blocks need to be confirmed before you can consider a transaction valid.  The traditional guidance is probably best stated as</p>
<blockquote>
<p><strong>A full confirmation requires: &quot;One hour of compute time,or 6 blocks, whichever is greater.&quot;</strong></p>
</blockquote>
<p>The goal in the Bitcoin network is to ensure that someone with a really powerful computer can't harm the rest of the network by creating double spends and invalidating past transactions.  Waiting for the entire populous of Bitcoin to run their computers for an hour pretty much guarantees that an attacker won't be able to undo your transaction.</p>
<p><strong>Why was 10 minutes chosen as the delay between each block?</strong></p>
<p>It was chosen as a way to balance the following goals:</p>
<ol>
<li><p>Make the chain splits less frequent.</p>
</li>
<li><p>Make the chain splits more manageable when they do split.</p>
</li>
<li><p>Confirm transactions as quickly as possible.</p>
</li>
</ol>
<p>A split chain does nothing but increase the overall time a transaction needs to confirm (assuming it's on the losing end of the split).  If chain splits happen too frequently then confidence in the system will decrease.</p>
<p><strong>Do you want smaller blocks so your confirmation will happen sooner?</strong></p>
<p>Decreasing confirmation time won't solve the issue.</p>
<p>Furthermore, now that we have ASIC miners coming on board, and blocks are getting confirmed quicker, that doesn't really mean that your transactions are more reliable, it still means that you should wait more than 10 blocks before considering the transaction &quot;safe&quot;.</p>
<p>Things will settle down in the future when the difficulty isn't skyrocketing to a new target, and at that point it will be OK to wait just 6 confirmations (assuming 6 confirmations = 1 hour)</p>
<p><strong>TL;DR</strong></p>
<p><strong>Sure, the selection of 10 is debatable, but a reasonable choice.</strong>  But your idea of making a block every millisecond makes #1 and #2  (above) nearly impossible to manage.  Not to mention the &quot;difficulty&quot; selection, network propagation, and act of mining to meet a target all require 1 second at a minimum to complete.</p>
<p>A valid reasonable value would be in the range of 5 to 15 minutes.</p>

CC BY-SA 3.0
2013-04-04T00:35:36.533Z
2013-04-04T00:35:36.533Z
2020-06-16T11:10:03.350Z
makerofthings7
<p>Litecoin is an alternative to Bitcoin that has as a feature a greatly reduced average time of 2.5 minutes between blocks instead of 10 minutes.</p>

<p>Thus, it is possible to create a fork of the Bitcoin protocol that accelerates block frequency. </p>

<p>However, it is not possible to accelerate this block frequency within the canonical Bitcoin protocol without accelerating the hash rate. The difficulty factor acts to counter this acceleration, though, so the acceleration would only be worthwhile for up to two weeks, the average time between automatic difficulty adjustments.</p>

CC BY-SA 3.0
2013-04-03T14:13:03.107Z
2013-04-03T17:28:09.607Z
2013-04-03T17:28:09.607Z
Colin Dean
<p>How fast could you possibly run a blockchain like bitcoins'? Could blocks be added as fast as a microsecond while still having a functional currency?</p>

<mining-theory><scalability><block-interval>
Would it be possible to make a functional Bitcoin fork that confirmed a block of transactions every millisecond?
Mark Smith
# Would it be possible to make a functional Bitcoin fork that confirmed a block of transactions every millisecond?

(Asked by: username_0 on 2013-04-03)

How fast could you possibly run a blockchain like bitcoins'? Could blocks be added as fast as a microsecond while still having a functional currency?

**Tags:** mining-theory, scalability, block-interval


---

## 3 answers

### Answer by username_1 on 2013-04-03. Score: 3

You couldn't make functional Bitcoin-like fork with that fast of block mining. There is a tradeoff between speed of block creation and consistency of the network. In Bitcoin the blocks are created infrequently enough that the entire network can agree on the canonical blocks quickly and transactions can propogate quickly enough of that they tend to get included in blocks fairly quickly (assuming that miners aren't ignoring them due to low/no fees).

If a fork aimed for a block generated a millisecond that would imply that network latency would result in thousands of blocks happening before you could even see the first one. In Bitcoin there are occasional forks of the blockchain due to propagation delays, but they are very quickly resolved by the network. A fork with millisecond blocks (and a large user base) would certainly have thousands of competing forks at any given time, and it would take tens of thousands, maybe even millions of confirmations before it became clear that a fork was dominant. (By which time, there would be thousands of forks of that fork.)

Plus, even without any transactions, each block has a minimum size of overhead, so the size of the blockchain would be growing at an outrageous rate. The same would apply to network bandwidth: the amount of chatter between the nodes would be outrageous: none of the nodes could keep up with the volume. Especially given that the volume would have so much duplication between all of the competing forks of the blockchain.

As username_4 username_4 points out, Litecoin has established a 2.5 minute target. So changing the target block generation speed is possible. But every time you go lower, the overhead and consistency gets harder.

What's the theoretical maximum? It's hard to say since so much depends on how globally distributed and large the network is. My wild guess, given current technology: anything much less than a minute would have a lot of forks and a lot of overhead. Anything less than a few seconds would almost certainly fail to achieve any kind of stable consensus about the blockchain.

> **Comments:**
> **username_2**: And see [here](http://www.cs.huji.ac.il/~avivz/pubs/15/btc_ghost.pdf) for a theoretical analysis of the question and a suggested improvement.  

---

### Answer by username_3 on 2013-04-04. Score: 1

Perhaps you're confused on what the purpose of a Block is, and why several blocks need to be confirmed before you can consider a transaction valid. The traditional guidance is probably best stated as

> **A full confirmation requires: "One hour of compute time,or 6 blocks, whichever is greater."**

The goal in the Bitcoin network is to ensure that someone with a really powerful computer can't harm the rest of the network by creating double spends and invalidating past transactions. Waiting for the entire populous of Bitcoin to run their computers for an hour pretty much guarantees that an attacker won't be able to undo your transaction.

**Why was 10 minutes chosen as the delay between each block?**

It was chosen as a way to balance the following goals:

1. Make the chain splits less frequent.
2. Make the chain splits more manageable when they do split.
3. Confirm transactions as quickly as possible.

A split chain does nothing but increase the overall time a transaction needs to confirm (assuming it's on the losing end of the split). If chain splits happen too frequently then confidence in the system will decrease.

**Do you want smaller blocks so your confirmation will happen sooner?**

Decreasing confirmation time won't solve the issue.

Furthermore, now that we have ASIC miners coming on board, and blocks are getting confirmed quicker, that doesn't really mean that your transactions are more reliable, it still means that you should wait more than 10 blocks before considering the transaction "safe".

Things will settle down in the future when the difficulty isn't skyrocketing to a new target, and at that point it will be OK to wait just 6 confirmations (assuming 6 confirmations = 1 hour)

**TL;DR**

**Sure, the selection of 10 is debatable, but a reasonable choice.** But your idea of making a block every millisecond makes #1 and #2 (above) nearly impossible to manage. Not to mention the "difficulty" selection, network propagation, and act of mining to meet a target all require 1 second at a minimum to complete.

A valid reasonable value would be in the range of 5 to 15 minutes.


---

### Answer by username_4 on 2013-04-03. Score: -1

Litecoin is an alternative to Bitcoin that has as a feature a greatly reduced average time of 2.5 minutes between blocks instead of 10 minutes.

Thus, it is possible to create a fork of the Bitcoin protocol that accelerates block frequency.

However, it is not possible to accelerate this block frequency within the canonical Bitcoin protocol without accelerating the hash rate. The difficulty factor acts to counter this acceleration, though, so the acceleration would only be worthwhile for up to two weeks, the average time between automatic difficulty adjustments.


---

