mimblewimble team mailing list archive
Mailing list archive
Fee burning and Dynamic Block Size
Grin testnet1 burns half the tx fee in an attempt to incentivize
against block bloat. But this attempt fails since miners can still
spam a block with their own 0-fee transactions, or accept user's 0-fee
transactions while demanding an out-of-band fee payment that is not
subjected to fee burning.
One might try to counter this with a consensus required minimum tx fee,
but that would require a hardfork whenever changes in the price of grin
make the minimum either unreasonably low (inviting spam) or
unreasonably high (preventing medium value transactions).
So testnet2 will do away with fee burning.
A better way to incentivize against block bloat is to penalize miners
for bigger blocks.
Cryptonote is the first blockchain design that introduced a Dynamic
Block Size. According to
Penalty = Reward * ((BlockSize / M) - 1)² if BlockSize > 300KB
Where M is the median of the block size over the last 100 blocks and
the maximum allowed block size is 2M.
While I like the idea of quadratic burn, I don't like the penalty-free
limit of 300KB, and the variable nature of M.
Removing the penalty free limit, fixing M, and taking the minimal size
into account, results in
Burn = Reward * ((BlockSize - EmptyBlockSize) / (MaxBlockSize -
MaxBlockSize is the largest size we're willing to accept. Putting a
hard limit on this that even a majority
of miners cannot break means that full nodes can operate within fixed
The burn formula implies that only empty blocks (with a single
coinbase output) achieve zero burn and get the full 60 grin reward. It
also implies that a rational miner will only add transactions if their
fees compensate for the resulting burn. If we replace sizes above with
number N of included transactions, then we get
Burn = Reward * (N / MaxN)^2
BurnPerTx = N * Reward / MaxN^2
showing that larger blocks require proportionally larger per-transaction fees.
The smallest compensating tx fee is then 60/MaxN^2 Grins. With MaxN on
the order of a thousand,
the roughly 60 microGrin fee would not be unreasonably large unless a
single Grin is worth more
than 1 BTC, a possibility we may safely discard.
How does it work out if one Grin is worth $10 and the mempool is full
of extremely cheap 1-cent-fee transactions?
How many would get included? Assuming a MaxN of 1000, and solving for N, we get
1mG = N * 60G / 1000^2
N = 1000/60 = 16
Great; we're pretty spam proof, while still allowing a trickle of
extreme cheap transactions.
What if Grin is worth $1, and the mempool is full of 10-cent-fee transactions?
Then N = 100000/60 = 1666 > MaxN. So we could fill up the whole block,
burning the entire 60G reward,
but getting 100G in fees instead.
In practice, the mempool will have a mix of transaction fees, and the
amount of time we expect to wait for
our transaction to be included is proportional to the volume of
transactions with a higher per-size-fee than ours.
Note that wherever I used "size" here, it doesn't need to be size in
bytes. We can make size any monotone
function of number of bytes, number of kernels, number of inputs, and
number of outputs, that we like.
I welcome feedback on this proposal.