Yes, you are right Sen. Minimum fee in a block will be:
MinTxFee = 2*N/MaxN * BaseReward (there was a - sign missing in
your formula).
I think this will work fine to limit block size. I'm more worried
about the effect in the
monetary supply. If you consider Bitcoin annual fee revenue was under 1% of the
monetary base for years, with negligible minimum tx fee, unless you
reduce progressively
the base reward this will still produce a quasi-linear emission curve.
The higher you put the inflation rate bar in the medium term, the more
difficult it is
to keep a stable price when you go through low demand periods. Volatility is not
good to gain adoption, so the longer you keep a high inflation rate
the more difficult
it will be to gain traction.
On 8 February 2018 at 07:40, Sen Fang <forest.f...@outlook.com> wrote:
> 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
>
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
