mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

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.
* Just reduce the allowed reward, making it much harder to audit or reason about the total supply.

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.

- Igno
​

-------- Original Message --------
 On 8 February 2018 11:52 AM, John Tromp <john.tromp@xxxxxxxxx> wrote:

>
>>Is the total miner reward calculated as: BaseReward - Burn [BaseReward * (N
>> / MaxN)^2] + N * TxFee ?
>>
> That's a simplification of the general formulation where all
> transactions have the same #inputs,
> #outputs, #kernels, and fee.
> The burning can be implemented either as a reduction in reward, or we
> can have a burn output
> in addition to the 60G reward output.
>
>>If so, for a miner to maximize reward, would they solve for 0 marginal
>> revenue Reward * 2 * (N / MaxN) + TxFee = 0 instead of solving for burn
>>
> That would be R * -2 * N / MaxN^2 + TxFee = 0,
> giving N = MaxN^2 * TxFee / (2 * Reward)
>
>>neutral i.e. Reward * (N / MaxN)^2 = N * TxFee?
>>
> No, this does not maximize payout to the miner. This is including more tx than
> the above optimum to reduce the payout back to the 60G reward.
>
>>That is to say, for the 1mG case, the miner would choose to include 8
>> transactions to get a 60.004G reward; and for 0.1G case, miner would opt for
>> ~833 transactions to get 101.7G reward.
>>A minor difference but I just want to check my understanding. If that is
>> correct, here is an interactive tool for people to play with different
>> settings: https://beta.observablehq.com/@saurfang/grin-dynamic-block-rewards
>> Feel free to be creative and add different burn functions in the BurnFuncs
>> cell or add additional simulation features. I have included a targeted block
>> size version without the burn free block size variable.
>>
>
> Thanks for providing the insightful notebook. The targeted block size formula
> make little sense to me though; it would incentivize miners to add
> spam tx to blocks
> when the mempool is relatively empty.
>
> regards,
> -John
>
>
>Mailing list: https://launchpad.net/~mimblewimble
> Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mimblewimble
> More help   : https://help.launchpad.net/ListHelp
>