Impact of Range Proof Optimizations on M_O

Question

After beginning at 60kB, the M_0 (minimum penalty-free block size) proved problematic after the v4 fork (introduction of RingCT) led to increased transaction (and block) sizes. Following an initial recommendation of 240kB from JollyMort, further discussion and research on an ideal M_0 was conducted. 300kB was settled on as the new M_0 in the v5 fork.

Is M_0 likely to be adjusted again in the future to account for future TX size reductions resulting from RCT range proof optimizations? If so would the most likely outcome be a proportional decrease in M_O based on the proportional decrease in transactions sizes resulting from those optimizations?

Answer 1

It could be argued that there's no need to re-adjust M_0 again as just reducing typical TX size would give us more margin and would further reduce the effect of TX size / block size ratio. However, do-not-relay fee could be adjusted at any time to keep the price/fiat at some reasonable level and deter irrational network use.

The more TX-es can fit in a block, the less likely we are to experience problems with dynamic block size as it can then be better fine-tuned by the miners to give smaller step increases.

Unlike Bitcoin which has a hard-coded max. block-size, with Monero the block-size is not a parameter but a state of the network negotiated by the participants. Users bribe the miners by offering the fee, and miners increase the block size if it's economical or reduce to match reduced TX demand. They actually earn the most if blocks are always 100%+ full so they'd also want to reduce the size if network is under-utilized.

If there's no TX-es in the mempool, miners are actually motivated to reduce the size to match usage because that would bring individual fees up and give them more total earnings. 60kB worth of TX-es at 60kB current median yields more than 60kB worth of TX-es at 120kB current median because in the latter, the fee/kB would be smaller. This is just because of dynamic fee calculation. Taking dynamic block size into account, anything over the median is even more economic than that base case until the point determined by the fees offered in the mempool.

M_0 is simply the lowest possible median, and if "background radiation" network usage will become such that at any given time the actual median block size will be bigger than M_0, then M_0 will become completely irrelevant forever! It's there just to ensure we don't get to some weird low-energy state where the cap would be so small that adding a single TX over the median becomes too hard to negotiate - like starting a cold engine. M_0 ensures it's always warm and ready to rumble.