mimblewimble team mailing list archive

[John Tromp <john.tromp@xxxxxxxxx>]

dear Igno,

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

Yes, cumulative burn should definitely be a header field in my proposal.
And possibly block burn as well (the difference from the previous
block's cum.burn),
if we feel like being generous with header fields.

> 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

It only requires checking current height and one header field. And
then we have a much more precise answer
than bitcoin, which has all sorts of ways in which to burn coins. Some
are used as one-way pegs into other
currencies. Perhaps one day people will do such one-way pegs on Grin as well.

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

I would still claim a 1Grin/sec emission.
That answer can be a little less precise than if the question is
"what's the supply at this time?".

> 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 much rather have every one able to burn rather than only the miner.
It allows more flexibility in miner compensation,
one-way pegs, and perhaps other use cases we haven't thought of yet.
It makes the design more regular in that
the coinbase tx looks less distinguished. 8 bytes per kernel is a
smallish price to pay for that.

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

We already sign fees, and burn is entirely similar. Whatever method
you have to aggregate kernels with fees should also work for burns.

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

This complication is entirely outside the grin codebase. Much like the
complications I introduced in my cuckoo solver to make it run faster.
We really shouldn't worry about what miners will do to maximize their
profit.

regards,
-John