Transaction fees MUST replace the block subsidy to secure the network.
Competition for censorship-proof transactions on the most secure decentralized ledger in the world is a good thing.
Only spoiled brats who want to send pennies around the world, instantly, for free, are crying. They could care less about Bitcoin's unique use case which makes it truly valuable.
Yes, transaction fees must replace the block subsidy. So under which scenario would more fees be generated?
a) a full 1mb block with an average fee of .0015
b) an almost full 2mb block with an average fee of .001
If you can fit more transactions into a block, the fee can be a bit lower and still generate more revenue for miners and have less congestion and waiting for the average user. So let's get SegWit done and then when blocks start getting full again (and they will), let's have that moderate blocksize increase. Running at 100% capacity only delivers a poor user experience.
This may not work out as you think
The weak point in your suggestion is that you implicitly assume that all blocks will be more or less filled. But right now the fill-up ratio is only about 85-90% on average. Yes, there are jams that happen now and then, though these are mostly thanks to spammy transactions. If the block size gets increased twice as much, the miners' profits obtained via transaction fees will most likely decline since there will be no more competition between senders for faster inclusion which leads to rising fees. So we shouldn't expect miners to accept SegWit or other measures to increase the block size any time soon
If we went with a flat, fixed increase, then sure, it's not ideal if there's no competition at all for space. But I feel a flat cap would be a decidedly clumsy, unsophisticated approach and we can do better. My preference would by a dynamic/adaptive algorithmic blocksize that would only be adjusted if blocks are predominantly filled within any given week or two:
The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain. Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often,
if needed. One possible route is to take the best elements of BIP100 and
BIP106. BIP100 only considers what benefits the miners and not the users. BIP106 only considers what benefits the users and not the miners. So neither is particularly balanced on its own.
But I'm going to alter the code from my old quoted post to make the adjustments more conservative and also reduce the potential to game the system by factoring in the total fees generated in any given diff period, so if all the transactions are spam with low or zero fees, it would invalidate the chance of a blocksize adjustment.
Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig to:
raise blocksize limit by 10%,
lower blocksize limit by 10%,
or remain at current blocksize limit.
This, however, only carries weight if algorithmic conditions based on network traffic and generated fees are met:
If more than 50% of block's size, found in the first 2016 of the last difficulty period, is more than 90% MaxBlockSize
AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty)
Network votes for MaxBlockSize = MaxBlockSize +10%
Else if more than 90% of block's size, found in the first 2016 of the last difficulty period, is less than 50% MaxBlockSize
Network votes for MaxBlockSize = MaxBlockSize -10%
Else
Network votes for keeping the same MaxBlockSize
(credit to both Upal Chakraborty and Jeff Garzik for their original concepts, which this idea merges together and builds upon)
So in plain English, a small adjustment to the blocksize can occur each difficulty period, but only if:
- There are sufficiently full blocks to justify an increase (or sufficiently empty to reduce it)
- There are more fees generated in the last difficulty period than the previous one (blocksize can be reduced regardless of fees)
- Miners agree to the change
No gigabyte blocks by midnight bloat and no sudden, sharp drop in fee pressure. A gradual and sophisticated alleviation to the strain, not a rash and crude hack.
