Why will the v5 fork raise the min block size to 300,000 bytes?

Question

Why will the v5 fork raise the min block size to 300,000 bytes?

v5 is now used for an increased minimum block size (from 60000 to 300000) to cater for larger typical/minimum transaction size.

I know that there have been some transaction waiting in the txpool recently but they are eventually confirmed and Monero dynamic block sizes gradually increase with network transaction volumes. Why not leave that portion of the code as is and let dynamic block sizes adjust on their own?

Answer 1

@Jollymort will probably answer this better but the current dynamic size algorithm didn't work well with RingCT transactions. It worked well with non RingCT transactions, which were smaller.

Once a miner has put enough transactions in a block to reach the median size of the last 100 blocks she faces this decision:

1. add one more transaction, which, in case of RingCT, is about 13kB, get the associated fee and pay a penalty
2. push the block without going above the median block size

The only situations where option 1 makes sense are when:

• the fee of the additional block is at least as much as the penalty, or
• the daemon that the miner is running is altruistic

At the moment, the first situation is rare and the penalty is generally much more than a typical fee.

And the network can't really count on miners being altruistic to grow (note that the algorithm of some daemons is in that situation and will grow the size even if it costs money, due to a bug - that possibly explains why the median size grew to 100 kB or so a few days ago).

Hence the idea to grow the block size limit to 300kB, point at which the penalty of adding one transaction is offset by a typical fee and miners have an incentive to slowly grow block sizes.