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.

  • 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. – renlord Jan 10 '17 at 5:20
  • 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 Jan 10 '17 at 7:56
  • 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 Jan 10 '17 at 16:51
  • 1
    @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 Jan 11 '17 at 6:10
  • 1

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


  • 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


  • 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 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?.

  • 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 Jan 12 '17 at 15:55
  • @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 Jan 12 '17 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.