Random block size and the fee market

[TierNolan]

With a constant block size, your transaction is either above or below the BTC per byte threshold.  

If it's above, then it will likely get included in the next block.  If not, it could end up stuck for ages.

Simply increasing the block size removes the incentive to pay fees.

A random block size would keep the fee incentive while increasing the average block size.  Higher fees mean greater chance of the next block being large enough to include your transaction.

Since a block size rule change means a hard fork anyway, hard forking changes are possible.

As an example, the merkle root could be changed to be a merkle root of the merkle root of 16 sub-blocks.  Only the first sub-block would have a coinbase.

The bottom 4 bits of the block hash would be used to decide how many of the blocks are actually valid.  

This is compatible with SPV for the branches.  They would need to be updated anyway to make sure they look at the nibble to determine which paths to actually accept.

If the bits were 0111, then 7 of the blocks would be valid.  The miner would send the transactions in all 7 sub-blocks and only the merkle roots of the remaining 9.

Each of the 16 sub-blocks would have a different fee.  If you only pay enough to get into sub-block 15, then it would take around 16 blocks before your transaction is included.

A low probability of a very large block would clear the memory pool every so often.

nibble) total block size

0) 1MB
1) 1MB
...
6) 1MB
7) 1MB
8) 2MB
...
11) 2MB
12) 4MB
13) 4MB
14) 8MB
15) 16MB

This gives an average of around 2MB per block, but still gives 16MB every so often.  

It could be extended past 16MB, with 32MB having a 1/32 chance of being allowed.

If the large blocks had a probability higher than the inverse of their size, then it can push up the average size even more, while not having much effect on the fast transaction fee market.

This helps with having stable relay rules.  The relay rule could be that your transaction must pay enough to get into the 16MB block to be relayed (maybe 150% of the fee to get into the 16MB block), but users would still have an incentive to have higher fees.

This protects against DOS, since any transaction sent with 150% of the 16MB block fee threshold will eventually get included.  You can't spam with fees that are high enough to be relayed but to low to be included in the blocks.

[1715127432]

1715127432

[1715127432]

1715127432

[TrueBeliever]

Random does not imply dynamic, in your case the block size does not ramp up immediately to confirm transactions in a timely manner.  For your idea it would be better to implement a deterministic variation, a large block every n blocks, so that low fee transactions can expect to wait n * 10 minutes instead of a random wait time.

Fixed block sizes of different sizes and probabilities do not inherently overcome any fundamental problem a single block size has.  If we calculate a weighted average of your block sizes and implement that as a new block size then the blockchain will process the same number of tx per given period, therefore the transaction in your example would also eventually be confirmed.

BTW I am not advocating fixed or dynamic block size, the debate is still in the hands of better informed minds than mine.

[TierNolan]

Random does not imply dynamic, in your case the block size does not ramp up immediately to confirm transactions in a timely manner.  For your idea it would be better to implement a deterministic variation, a large block every n blocks, so that low fee transactions can expect to wait n * 10 minutes instead of a random wait time.

That would work too.

The advantage of random is that it doesn't cause regular cycles.  If there was a large block in the next 2-3 blocks, then nobody would bother paying high fees until it passes.

Random means that you don't know when the next large block is going to happen, so you have multiple market prices depending on which block you want to get into.

Fixed block sizes of different sizes and probabilities do not inherently overcome any fundamental problem a single block size has.  If we calculate a weighted average of your block sizes and implement that as a new block size then the blockchain will process the same number of tx per given period, therefore the transaction in your example would also eventually be confirmed.

The proposal isn't to increase the total number of transactions, that is a separate issue.  The advantage of this system is that higher fees more directly give you faster confirms.

Once there is two to three blocks worth of transactions in the memory pool, there would be a very clear market price for fees.  If you pay lower than that, you are likely to simply be rejected.  This softens the edge, and means that there can be a range of fees.

[jl2012]

This helps nothing, if not making it worse. The chance of having a long chain of small blocks is approximately same as the chance of having a single big block. You may have a lot of small blocks during peak hours, and many big blocks when the mempool is empty.

[edmundedgar]

Another interesting thought in this area is Greg Maxwell's suggestion that you could make the block difficulty depend on the block size. A transaction with high fees could not only ensure you get into the next block, it also could increase the probability that the next block will be found quickly, because miners are incentivised to drop their block size and reduce the difficulty to increase their chances of collecting the fee. This also scales up in the opposite direction where needed to handle a capacity crunch, because if you've got a long tail of transactions waiting with a reasonable cumulative fee, you're incentivized to stretch out the block size to accomodate them.

[TierNolan]

This helps nothing, if not making it worse. The chance of having a long chain of small blocks is approximately same as the change of having a single big block. You may have a lot of small blocks during peak hours, and many big blocks when the mempool is empty.

That is a good point. 

The random nature of finding blocks pretty much means that the system already effectively has variable sized blocks (as measured in data per minute).