mimblewimble team mailing list archive

[John Tromp <john.tromp@xxxxxxxxx>]

dear Ignotus,

> I like the idea, it's simple and elegant and seems to put the right incentives in place.
>
> I don't like that it relies on burn. It puts us between a rock and a hard place as we either:
>
> * Materialize the burn as specific outputs and keep them forever, bloating the chain.

How about materializing burns similar to fees?
Every kernel would have explicit amounts for fee and burn, and sign for both.
Every kernel set would maintain the sum fee, sum burn, as well as sum
kernel offset.
Every aggregated, possibly cut-through, transaction satisfies

Sum outputs - Sum inputs = Sum kernels + sum_offset * G - (sum_fees +
sum_burn) * H

For a block, which adds a coinbase tx to a tx aggregate, we have

Sum outputs - Sum inputs = Sum kernels + sum_offset * G + (60 Grin -
sum_burn) * H

And the small block incentive requires sum_burn to be at least
quadratic in block size.

Note that in this formulation, transactors have TWO ways to compensate miners:

1) they can pay more fees, which directly go into the miner's pocket.
2) they can burn more coins, which helps the miner satisfy the
quadratic burn constraint.

> The 2nd point is the main argument that convinced me to give up fee burning. It's also arguable that a chunk of the reward that's immediately burnt was ever part of the currency supply, so while the first solution would make the chain accounting simpler, it still significantly complicates supply estimation.

If you decide to implement coin burning in every tx, which has other
possible applications,
then total supply is already complicated. But that seems only a minor
complication.

Should we give up on the possibility to burn coins, and give up on
incentivizing small blocks,
because of the perceived complexity of a subtraction?

regards,
-John