> 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
