<p>In consideration of replacing the 1 block with <code>N</code> blocks in the same time frame, <code>N &gt; 1</code>, I see the following points:</p>

<h2>Advantages</h2>

<ul>
<li>Expected time until first confirmation is reduced</li>
<li>Mining revenue is distributed smoother among pools</li>
<li>Capacity of network is increased</li>
<li>Smaller peak traffic than increasing blocksize by <code>N</code></li>
</ul>

<h2>Disadvantages</h2>

<ul>
<li>A hardfork is required to adjust the block interval</li>
<li>Increased chance of chain forks and higher stale rate due to block validation taking a larger portion of block interval</li>
<li>Thin clients need to store a larger amount of headers</li>
<li>Slightly bigger bandwidth usage than larger blocks</li>
</ul>

<hr>

<p>Still, it may be that 10 minutes is too conservative and a smaller block interval would provide an overall benefit. For example, at Scaling Bitcoin Milan, Arthur Gervais <a href="https://www.youtube.com/watch?v=_Z0ID-0DOnc&amp;t=8862s" rel="nofollow noreferrer">presented simulation results</a> that he interpreted to suggest that Bitcoin could safely use 1 minute blocks.</p>

<p>CoinDesk covered the topic in <a href="http://www.coindesk.com/lower-bitcoin-block-time-scale/" rel="nofollow noreferrer">A Lower Block Time Could Help Bitcoin Scale, But Will It Work?</a>.</p>

CC BY-SA 3.0
2017-01-12T15:55:25.173Z
How would the money supply be affected?  The proposal was to divide block time and reward by the same divisor, so the money supply would continue to grow over time at the same rate as before (though a bit more smoothly).
Nate Eldredge
CC BY-SA 3.0
2017-01-12T16:21:27.370Z
@NateEldredge: The money supply be very slightly reduced because block subsidies would earlier forfeit part of a satoshi per block when the halvening moves precision to decimals but only full satoshis can be paid out. – However, I just calculated the actual amount, and even for `N = 10` it's just slightly less than 25 mBTC, so I've removed the mention from my answer.
Murch
CC BY-SA 3.0
2017-01-12T15:51:34.853Z
2017-01-14T01:33:48.173Z
2017-01-14T01:33:48.173Z
Murch
<p>It seems that choosing a good factor to use to expand Bitcoin's capacity is a good idea.  The software would divide some of its calculated values by this factor, such as the target time between blocks during difficulty calculation, the number of blocks between difficulty adjustments, and the subsidy.  To achieve the security of "one hour's worth of hashing power," the recommendation for confirmations would be multiplied by this factor.  It seems that using a factor of two from time to time (whenever the community finds it valuable) would be appropriate.</p>

<p>Let's suppose we choose a factor N. This will allow the blockchain itself to grow N times as fast, providing N times the transaction fees to miners, multiplying the number of rewards by N (but dividing the reward itself by N), dividing the average wait for a confirmation by N, and multiplying the rate at which transactions are confirmed by N.  This also reduces the variance of mining revenue.</p>

<p>This allows time (instead of network bandwidth and computer memory) to be used to expand the carrying capacity of the bitcoin ecosystem.  Should such a proposal be written into a BIP?</p>

<p>The objections to this idea so far have been answered in the comments.  If anyone feels that there is an objection adequate enough to drop the idea, please post an answer.  If anyone wants to create a BIP, please let me know so I don't have to do it myself.  I don't mind doing it myself, but I'll probably be slow.</p>

CC BY-SA 3.0
2017-01-10T05:20:33.040Z
your suggestion also increases network bandwidth, as the time interval between blocks shrinks, the capacity required to propagate blocks increases. There's also a latency that comes into play. As time interval between block shrinks, the proportion of time contributed by latency increases and plays into higher probability of a minted block getting orphaned. Keen to hear what the others think.
rny
CC BY-SA 3.0
2017-01-10T07:56:29.060Z
So if N=2 we have a new 1MB block every 5 minutes instead of 10 with every miner reward halved compared to current protocol? Isn't this fundamentally the same as doubling the block size (albeit in a more convoluted way)?
Sven Williamson
CC BY-SA 3.0
2017-01-10T16:51:42.497Z
One downside is that you have to get all end users to understand that the benchmark for number of confirmations has changed, and do it again each time N changes.  Under the current system, end users can memorize a magic number like 6 confirmations that will never change.  For such end users, a block size increase can be transparent, even if it's a hard fork; they have to upgrade their software, but they don't have to change their ways of thinking.
Nate Eldredge
CC BY-SA 3.0
2017-01-11T06:09:57.227Z
@renlord - yes, bandwidth requirement goes up with capacity.  Orphaned blocks go up too, but only cause half the loss they normally do.
Dave Scotese
CC BY-SA 3.0
2017-01-11T06:10:05.727Z
@Sven-Williamson - yes, fundamentally the same, but doesn't double bandwidth for each block or the mempool load as blocksize increases do.
Dave Scotese
CC BY-SA 3.0
2017-01-11T06:10:10.083Z
@Nate-Elderidge - The security should always have been "an hour's worth of hash power" and changing it to that is a fundamentally sound change.
Dave Scotese
CC BY-SA 3.0
2017-01-11T20:45:51.200Z
@NateEldredge You could implement this as 'fractions of a confirmation.' So instead of seeing 7 confirmations under the new system, they would see 3.5. Problem is that you need all of the wallets to adopt this new numbering system.
Nick ODell
CC BY-SA 3.0
2017-01-12T10:02:54.993Z
related: [Why is a short blocktime considered to be unsafe?](http://bitcoin.stackexchange.com/q/38587/5406), [Why was the target block time chosen to be 10 minutes?](http://bitcoin.stackexchange.com/q/1863/5406), [Which cryptocurrency has the smallest block time?](http://bitcoin.stackexchange.com/q/35932/5406), [Would it be possible to make a functional Bitcoin fork that confirmed a block of transactions every millisecond?](http://bitcoin.stackexchange.com/q/9029/5406)
Murch
<mining-reward><difficulty><scalability><block-size-increase><block-interval>
Why not multiply "six confirmations" and divide Time-Between-Blocks and Reward by the same factor?
Dave Scotese
# Why not multiply "six confirmations" and divide Time-Between-Blocks and Reward by the same factor?

(Asked by: username_0 on 2017-01-10)

It seems that choosing a good factor to use to expand Bitcoin's capacity is a good idea. The software would divide some of its calculated values by this factor, such as the target time between blocks during difficulty calculation, the number of blocks between difficulty adjustments, and the subsidy. To achieve the security of "one hour's worth of hashing power," the recommendation for confirmations would be multiplied by this factor. It seems that using a factor of two from time to time (whenever the community finds it valuable) would be appropriate.

Let's suppose we choose a factor N. This will allow the blockchain itself to grow N times as fast, providing N times the transaction fees to miners, multiplying the number of rewards by N (but dividing the reward itself by N), dividing the average wait for a confirmation by N, and multiplying the rate at which transactions are confirmed by N. This also reduces the variance of mining revenue.

This allows time (instead of network bandwidth and computer memory) to be used to expand the carrying capacity of the bitcoin ecosystem. Should such a proposal be written into a BIP?

The objections to this idea so far have been answered in the comments. If anyone feels that there is an objection adequate enough to drop the idea, please post an answer. If anyone wants to create a BIP, please let me know so I don't have to do it myself. I don't mind doing it myself, but I'll probably be slow.

**Tags:** mining-reward, difficulty, scalability, block-size-increase, block-interval

> **Comments:**
> **username_1**: your suggestion also increases network bandwidth, as the time interval between blocks shrinks, the capacity required to propagate blocks increases. There's also a latency that comes into play. As time interval between block shrinks, the proportion of time contributed by latency increases and plays into higher probability of a minted block getting orphaned. Keen to hear what the others think.  
> **username_2**: So if N=2 we have a new 1MB block every 5 minutes instead of 10 with every miner reward halved compared to current protocol? Isn't this fundamentally the same as doubling the block size (albeit in a more convoluted way)?  
> **username_3**: One downside is that you have to get all end users to understand that the benchmark for number of confirmations has changed, and do it again each time N changes.  Under the current system, end users can memorize a magic number like 6 confirmations that will never change.  For such end users, a block size increase can be transparent, even if it's a hard fork; they have to upgrade their software, but they don't have to change their ways of thinking.  
> **username_0**: @renlord - yes, bandwidth requirement goes up with capacity.  Orphaned blocks go up too, but only cause half the loss they normally do.  
> **username_0**: @username_2-username_2 - yes, fundamentally the same, but doesn't double bandwidth for each block or the mempool load as blocksize increases do.  
> **username_0**: @username_3-Elderidge - The security should always have been "an hour's worth of hash power" and changing it to that is a fundamentally sound change.  
> **username_4**: @username_3 You could implement this as 'fractions of a confirmation.' So instead of seeing 7 confirmations under the new system, they would see 3.5. Problem is that you need all of the wallets to adopt this new numbering system.  
> **username_5**: related: [Why is a short blocktime considered to be unsafe?](http://bitcoin.stackexchange.com/q/38587/5406), [Why was the target block time chosen to be 10 minutes?](http://bitcoin.stackexchange.com/q/1863/5406), [Which cryptocurrency has the smallest block time?](http://bitcoin.stackexchange.com/q/35932/5406), [Would it be possible to make a functional Bitcoin fork that confirmed a block of transactions every millisecond?](http://bitcoin.stackexchange.com/q/9029/5406)  

---

## 1 answers

### Answer by username_5 on 2017-01-12. Score: 3

In consideration of replacing the 1 block with `N` blocks in the same time frame, `N > 1`, I see the following points:

## Advantages

* Expected time until first confirmation is reduced
* Mining revenue is distributed smoother among pools
* Capacity of network is increased
* Smaller peak traffic than increasing blocksize by `N`

## Disadvantages

* A hardfork is required to adjust the block interval
* Increased chance of chain forks and higher stale rate due to block validation taking a larger portion of block interval
* Thin clients need to store a larger amount of headers
* Slightly bigger bandwidth usage than larger blocks

---

Still, it may be that 10 minutes is too conservative and a smaller block interval would provide an overall benefit. For example, at Scaling Bitcoin Milan, Arthur Gervais [presented simulation results](https://www.youtube.com/watch?v=_Z0ID-0DOnc&t=8862s) that he interpreted to suggest that Bitcoin could safely use 1 minute blocks.

CoinDesk covered the topic in [A Lower Block Time Could Help Bitcoin Scale, But Will It Work?](http://www.coindesk.com/lower-bitcoin-block-time-scale/).

> **Comments:**
> **username_3**: How would the money supply be affected?  The proposal was to divide block time and reward by the same divisor, so the money supply would continue to grow over time at the same rate as before (though a bit more smoothly).  
> **username_5**: @username_3: The money supply be very slightly reduced because block subsidies would earlier forfeit part of a satoshi per block when the halvening moves precision to decimals but only full satoshis can be paid out. – However, I just calculated the actual amount, and even for `N = 10` it's just slightly less than 25 mBTC, so I've removed the mention from my answer.  

---

