Is the total miner reward calculated as: BaseReward - Burn [BaseReward * (N / MaxN)^2] + N * TxFee ?
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 neutral i.e. Reward * (N / MaxN)^2 = N * TxFee? 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. Best, Forest On Wed, Feb 7, 2018 at 7:05 AM John Tromp <john.tr...@gmail.com> wrote: > Grin testnet1 burns half the tx fee in an attempt to incentivize > against block bloat. But this attempt fails since miners can still > spam a block with their own 0-fee transactions, or accept user's 0-fee > transactions while demanding an out-of-band fee payment that is not > subjected to fee burning. > > One might try to counter this with a consensus required minimum tx fee, > but that would require a hardfork whenever changes in the price of grin > make the minimum either unreasonably low (inviting spam) or > unreasonably high (preventing medium value transactions). > > So testnet2 will do away with fee burning. > > A better way to incentivize against block bloat is to penalize miners > for bigger blocks. > Cryptonote is the first blockchain design that introduced a Dynamic > Block Size. According to > https://getmonero.org/2017/12/11/A-note-on-fees.html > > Penalty = Reward * ((BlockSize / M) - 1)² if BlockSize > 300KB > 0 otherwise > > Where M is the median of the block size over the last 100 blocks and > the maximum allowed block size is 2M. > > While I like the idea of quadratic burn, I don't like the penalty-free > limit of 300KB, and the variable nature of M. > Removing the penalty free limit, fixing M, and taking the minimal size > into account, results in > > Burn = Reward * ((BlockSize - EmptyBlockSize) / (MaxBlockSize - > EmptyBlockSize))^2 > > MaxBlockSize is the largest size we're willing to accept. Putting a > hard limit on this that even a majority > of miners cannot break means that full nodes can operate within fixed > resource limits. > > The burn formula implies that only empty blocks (with a single > coinbase output) achieve zero burn and get the full 60 grin reward. It > also implies that a rational miner will only add transactions if their > fees compensate for the resulting burn. If we replace sizes above with > number N of included transactions, then we get > > Burn = Reward * (N / MaxN)^2 > BurnPerTx = N * Reward / MaxN^2 > > showing that larger blocks require proportionally larger per-transaction > fees. > The smallest compensating tx fee is then 60/MaxN^2 Grins. With MaxN on > the order of a thousand, > the roughly 60 microGrin fee would not be unreasonably large unless a > single Grin is worth more > than 1 BTC, a possibility we may safely discard. > > How does it work out if one Grin is worth $10 and the mempool is full > of extremely cheap 1-cent-fee transactions? > How many would get included? Assuming a MaxN of 1000, and solving for N, > we get > > 1mG = N * 60G / 1000^2 > N = 1000/60 = 16 > > Great; we're pretty spam proof, while still allowing a trickle of > extreme cheap transactions. > What if Grin is worth $1, and the mempool is full of 10-cent-fee > transactions? > Then N = 100000/60 = 1666 > MaxN. So we could fill up the whole block, > burning the entire 60G reward, > but getting 100G in fees instead. > > In practice, the mempool will have a mix of transaction fees, and the > amount of time we expect to wait for > our transaction to be included is proportional to the volume of > transactions with a higher per-size-fee than ours. > > Note that wherever I used "size" here, it doesn't need to be size in > bytes. We can make size any monotone > function of number of bytes, number of kernels, number of inputs, and > number of outputs, that we like. > > I welcome feedback on this proposal. > > 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 >
-- Mailing list: https://launchpad.net/~mimblewimble Post to : mimblewimble@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
