mimblewimble team mailing list archive

[Sen Fang <forest.fang@xxxxxxxxxxx>]

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