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.

  • Ok, it was my understanding that the "penalty limit" was a constant. It is indeed adjusted with the block size limt, that make more sense. Thank you. – ant Bldel Aug 12 '16 at 20:07
  • I added a bit regarding the 60 kB number too. It's a minimum. – user36303 Aug 12 '16 at 20:11
  • thanks, I got confused 60kb is the minimum limit for the penalty calculation. Much clearer now. – ant Bldel Aug 12 '16 at 21:26
  • Why are outliers removed? They don't have a large affect on medians. – PyRulez Aug 13 '16 at 0:51
  • I assume this is to decrease the vulnerability to maliciously set block times, which could all be set to go in one direction, rather than be "randomly" distributed. – user36303 Aug 13 '16 at 7:58

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

  • MN is the median of the block size over the last N blocks, with N being 100 in Monero
  • BlockSize is the size of the current block
  • BaseReward is the reward as per the emission curve or where applicable the tail emission
  • NewReward is the actual reward paid to the miner
  • The maximum allowed block size, BlockSize, is 2MN

Note that the formula of the BaseReward is defined as follows:

BaseReward = (M - A) * 2-20 * 10-12

Where

  • M = initial number of atomic units is = 264 - 1
  • A = current circulation, which can be found here

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."

  • Do you think this should be updated after the latest hardfork, or do you think a new question should be posted? – sgp Jun 6 '17 at 12:39
  • 1
    Perhaps better to make a new Q&A and make a small edit for this Q&A. – dEBRUYNE Jun 6 '17 at 13:37

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.