Hi John,
> In retrospect that seems overly complicated. The simplest
> possible schedule, namely a fixed constant block reward,
> probably works well enough. It"s also what Ethereum uses,
> except they started out with about 7 years worth of rewards
> sold in an ICO, judging from https://etherscan.io/chart/ethersupplygrowth
The 7 years of rewards, plus the many hints at eventually switching to Proof of
Stake and reducing rewards, make Ethereum an altogether bad point of
comparison. Around 72 million coins were distributed via the crowdfunding sale
and to the foundation/developers. Then another 12 million or so per year in
their flat emission. That meant in inflation rate for that first year was less
than 17%, and fell below 15% in the second year.
If a flat block reward is being considered, a better analogy to consider would
be Bitcoin, Litecoin, or Zcash, each of which had/have flat emissions for 4
years. Without Ethereum's premine, they would fit the same scenario. Now
imagine if after those 4 years (and again 4 years later) there had not been
block halvings (I will use #s for Bitcoin but the same could be done for the
others I mentioned). That would mean that today there would be around 24.4
million coins available today with an additional 2.6 million or so mined each
year (10-11% inflation after nearly 9 years), rather than the approximately
16.6 million coins and 660k or so new coins per year we actually have (~4%
inflation today).
Perhaps at the 9-year mark, that's not so bad... 11 percent drops to single
digits in another year, drops below 5% in another 10 years. But those first 9
years are brutal to anyone using the coin as a store of value, **unless user
and transaction growth match the emission growth**. That is what needs to be
considered here... the ramifications of a flat reward on users of Grin during
the nascent years of it's chain. If the primary use is pegged confidential
assets of other coins, than it's perhaps not a big deal. If the primary use is
as a currency itself, then it's everything. It might be okay, but it deserves
discussing.
Of course, if a fee system is implemented that burns fees a la Peercoin (as has
been suggested by some), then the inflation in the system is effectively
decreased.
> The only deviation I"d like to make from that is a slow start, where
> block rewards are initially zero. This allows everyone to setup and
> test their miners and pools in a relaxed manner, no matter their
> timezone, and offers a unique opportunity to advertise an already
> up-and-running coin where people can still get ready to mine the first
> reward.
Testing setups can be just as easily done via a testnet, and it is highly
unlikely any large miner will test for any prolonged period.
> The question is how long the slow start should last. To cover all
> timezones, it should be at least one day. Preferably a few. A week is
> probably more than enough. I propose two options:
>
> 1) At a fixed block height, [rest omitted for brevity...]
>
> 2) As soon as difficulty stabilizes [rest omitted for brevity...]
>
> In either case I propose that we try to overestimate the initial
> difficulty
A prolonged period of 0-reward blocks would be a mistake. First off, there
would literally be 0 coins. What do you do with a chain with 0 coins? Second,
no reasonable miner would spend any longer mining than she has to in order to
make sure she is set up correctly. Minutes, maybe hours at most. If the worry
is that she might not have time on day 1, but will on day 2, then again -
that's a reason for a test net before launch that completely mimics the real
chain.
The problem here is that the first days or weeks would have basically no work
behind them, which basically means that come day 1 of the block rewards, the
chain is still basically 0% secure. But even more problematic, any reasonable
miner will just wait until the rewards start and then start mining, which will
accidentally turn the whole thing into a small instamine because the difficulty
will be too low.
Setting the difficulty overly high is an interesting idea, but only under
scenario 1, and only if the difficulty adjustment algorithm would not allow the
difficulty to adjust down to lower-than-expected-demand levels. Amending
scenario 2, you would want to set the difficulty low, and then have some
threshold of "X blocks over Y difficulty" as your activation. Going high-to-low
(depending on the difficulty adjustment algorithm) would just further play into
the hands of anyone waiting on the sidelines, as not mining is the best way to
drop the difficulty.
Realistically, if you want to have 0-reward blocks as a startup, the best
option is probably to set a constant difficulty for that period that is based
off a best-estimate of the expected hashrate on Day 0, and then a target block
height that will be the first block with rewards. As initial demand is very
difficult to estimate (would requiring looking at recent launches of other
coins), a mechanism could be put in place that will adjust the initial
difficulty up but not down during that 0-reward period... as more miners ramp
up to join, if it turns out there are more than expected the difficulty can
adjust before rewards happen, avoiding an instamine.
But I don't really think a 0-reward start is a good idea... there's too much
guesswork involved, and I'm not sure that it actually achieves any tangible
benefit. Something on the order of 1 day might be acceptable, but any longer is
just missing the point. The simplest model for avoiding an instamine and
allowing people to ramp up has already been played out in a number of
cryptocurrencies: slowly increase rewards over a 1-2 week period, allowing
block rewards to somewhat scale with mining demand, and have a good testnet
available before launch for miners to test out if they would like.
Besides, if block rewards are constant in perpetuity, whether a miner joins in
hour 1 or hour 18 is pretty much a moot point. We're talking well under 1% of
the first year's coin supply, and under 0.1% of the supply after 3 years. Being
a few hours late to a slowly and fairly launched coin isn't an issue. If
someone sees reason to be there from the start, then they will make sure they
are available and ready to go.
Mischief Managed,
Seamus Finnigan
Sent with [ProtonMail](https://protonmail.com) Secure Email.
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : [email protected]
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
