Why not multiply "six confirmations" and divide Time-Between-Blocks and Reward by the same factor?

Question

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. — rny, Jan 10 '17 at 05: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 07: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
@renlord - yes, bandwidth requirement goes up with capacity. Orphaned blocks go up too, but only cause half the loss they normally do. — Dave Scotese, Jan 11 '17 at 06:09
@Sven-Williamson - yes, fundamentally the same, but doesn't double bandwidth for each block or the mempool load as blocksize increases do. — Dave Scotese, Jan 11 '17 at 06:10
@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 06:10
@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, Jan 11 '17 at 20:45
related: Why is a short blocktime considered to be unsafe?, Why was the target block time chosen to be 10 minutes?, Which cryptocurrency has the smallest block time?, Would it be possible to make a functional Bitcoin fork that confirmed a block of transactions every millisecond? — Murch, Jan 12 '17 at 10:02

Murch · Answer 1 · 2017-01-14T01:33:48.173

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 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

Why not multiply "six confirmations" and divide Time-Between-Blocks and Reward by the same factor?

1 Answers1

Advantages

Disadvantages

Linked