> 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.tr...@gmail.com> 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
>


-- 
Mailing list: https://launchpad.net/~mimblewimble
Post to     : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help   : https://help.launchpad.net/ListHelp

Reply via email to