Block reward penalties begin if a block gets beyond 60kb in size.
What is the reason why this limit is not dynamically re-calculated to follow a ratio of the blocksize limit instead of a constant?
This limit is based on the median of the last 100 blocks' size, after removing outliers, with a 60 kB lower limit (so blocks can't get TOO small, or you could have a hard time "restarting"). This allows the block size to grow and contract based on transaction volume. The size at which the block reward penalty kicks in is between 100% and 200% of the block size for this coinbase. It follows a continuous function, which I think is quadratic.
See get_block_reward in src/cryptonote_core/cryptonote_basic_impl.cpp for the details of the code.
The 60 kB limit is the minimum median block size limit. Thus, miners are able to construct blocks up to 60 kB without incurring a penalty. This limit was increased from 20 kB in the March 23, 2016 hardfork and was first proposed by smooth. From the proposal:
The minimum median block size is current 20 KB, meaning without the dynamic block size kicking in, any block can be up to 20 kilobytes without any miner penalty. In increasing the block time to two minutes it was initially proposed to increase the minimum median size to 40 KB, which retains the same rate of base block capacity.
It was later proposed to increase this to 60 KB, because of the observation that larger mix sizes will create more split transactions and split transactions are inconvenient for merchants, whose systems are often set up to accept one payment, and further sometimes find payments need to be processed manually due to various problems with split payments. 60 KB is observed to allow most routine payments to be handled without splitting.
So the current plan is to increase the minimum median block size to 60 KB. As a rate this is 300 KB per 10 minutes, so 30% of Bitcoin's maximum rate (1 MB/10 minutes), though of course Monero allows the block size to increase based on transaction demand. The minimum size reduces the resistance to spam attacks and increases the potential for more rapid blockchain growth relative to transaction demand.
It is not necessary to increase the minimum block size at all. In AEON when the block time was increased from 1 to 4 minutes, no increase in the minimum block size was made, and everything still works, with the block size dynamically increasing during high usage. However, this does not provide any relief from the need for many split transactions, and further AEON does not impose a hard minimum on mix factors the way Monero will (post-fork).
Open for discussion or feedback on the proposal to increase the minimum median block size to 60 KB.
After 60 kB the dynamic block size algorithm kicks in (and thus the penalty). The formula of this block size algorithm is as follows:
Penalty = BaseReward * ((BlockSize / MN) - 1)²
The new reward is:
NewReward = BaseReward - Penalty
Where
Note that the formula of the BaseReward is defined as follows:
BaseReward = (M - A) * 2-20 * 10-12
Where
Code details and the actual implementation of the dynamic block size algorithm can be found here. Lastly, there is a small disrepancy between the CryptoNote whitepaper and the actual implementation in Monero. That is, according to the CryptoNote whitepaper the penalty kicks in if blocks are 110% of the median block size, see:
This rule is applied only when BlockSize is greater than minimal free block size which should be close to max(10kb, MN ·110%).
However, in the actual implementation the penalty kicks in when blocks go over the median block size. Thus, for example, a block that is 101% of the median block size would already incur a penalty. Miners will likely increase the blocksize if the the transaction fees are greater than the penalty. In addition, according to the CryptoNote whitepaper, "fees are unlikely to grow quadratically unlike the penalty value so there will be an equilibrium."