The Monero block size can expand in two separate ways.
1. The miner can choose to take a penalty on the block reward in order to expand the block.
2. A cap is reached so that miners cannot expand a block past a certain point without the average size of the past something like 50,000 blocks being moved upwards.
This allows Monero to take surges in demand during holidays or high transaction periods, but not actually expand the median block size over a longer period of time.
Login to reply
Replies (1)
I had not researched this.
For a sovereign medium of exchange in an adversarial world, I'd still prefer Bitcoin's architecture - tight, ossified, cheap-to-validate L1 + truly sovereign (non-custodial, batch-heavy) L2s.
Monero's elastic block policy is elegant for burst handling, but it hands adversaries a bloat lever and raises validation costs over time, which erodes home-node density and increases capture surface.
This of course ignores:
- Bitcoin's recent L1 drift - rising default policy that tolerates junk payloads; heavier relay requirements; sync time creeping up year on year.
- Current L2s being mostly "convenience custodians".
Elasticity is a bloat vector in a world where the opponent's budget ≈ unlimited.
If you copy Monero's elasticity, you must add hard ceilings and anti-subsidy heuristics that make adversarial expansion uneconomic — which drifts you back toward... a de-facto small L1.
So it's pros/cons.
Pros for Monero:
- Handles short-term demand surges without massive fee spikes.
- Privacy defaults are strong; observability/censorship is harder at the transaction level.
Cons:
- The Penalty mechanism can be gamed by a rich adversary to expand supply of blockspace and bloat the chain.
- As chain weight grows, residential nodes drop. Privacy without verifiers still invites macro-level capture (ISPs, clouds, peering).
Ideally, I'd put the scale knob on L2, not L1 and scale by:
- More users per UTXO (channel factories, pooled channels, Ark-like constructions with constrained trust, etc).
- More settlement per byte (aggressive batching/aggregation, proof compression, periodic settlement).
- No custodial intermediaries that can be deputized.