2
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 – 2017-01-10T05:20:33.040
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 – 2017-01-10T07:56:29.060
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 – 2017-01-10T16:51:42.497
@renlord - yes, bandwidth requirement goes up with capacity. Orphaned blocks go up too, but only cause half the loss they normally do. – Dave Scotese – 2017-01-11T06:09:57.227
@Sven-Williamson - yes, fundamentally the same, but doesn't double bandwidth for each block or the mempool load as blocksize increases do. – Dave Scotese – 2017-01-11T06:10:05.727
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 – 2017-01-11T06:10:10.083
@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 – 2017-01-11T20:45:51.200
1
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 – 2017-01-12T10:02:54.993