mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

> 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?

There's a little more complexity involved. First, you have to think about fast-synced pruned nodes. They have to know about past burn somehow. All the information they have is headers, the UTXO set and kernels. So putting the burn in any of those places would likely work. And hopfeully we won't have to worry about SPV for some time. But still, should we commit to total burn in headers?

Now, people. We have a constant emission that people already have difficulties wrapping their head around, strangely enough. If the answer to "what's the total emission at this point in time" requires either checking all kernels or something more evasive like "depends on how full blocks are", that explanation is going to get a lot worse. Emission is a fairly fundamental parameter, being able to just say one per second or 60 times the number of block is a remarkable average that we shouldn't just brush off.

Going back to the data, by adding burn to kernels you're trading off 8 bytes for every transaction against maybe one average unprunable output per block (we could perhaps do less by setting a minima under which burn isn't necessary). I'm also wary of having kernels sign more data. Who knows, maybe we'll figure out signature aggregation at some point and the more we can aggregate the better. Also, by having burn and fees in every transaction, you complicate transaction ordering for miners. It becomes a 2-variables problem which I don't really even want to think about right now.

So I'm not at all against the idea, just pointing out that as-is it comes with a lot more drawbacks than a simple subtraction, and could bear some refining.
​
- Igno
​
-------- Original Message --------
 On 11 February 2018 3:44 PM, John Tromp <john.tromp@xxxxxxxxx> wrote:

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