mimblewimble team mailing list archive

[Allan Niemerg <allan@xxxxxxxxxxxxxxxxxxxx>]

It's worth keeping in mind that mining is not just the distribution of the currency but is also a payment for security. Is there a reason to so drastically pay extra for security between years 5 - 15 and to pay relatively so little in years 1-5? Especially since the risk in Years 1-5 are generally the highest for both the currency and the miners?



________________________________
From: Mimblewimble <mimblewimble-bounces+allan=cumberlandmining.com@xxxxxxxxxxxxxxxxxxx> on behalf of praxeology_guy <praxeology_guy@xxxxxxxxxxxxxx>
Sent: Thursday, June 1, 2017 1:52 AM
To: Ignotus Peverell
Cc: mimblewimble@xxxxxxxxxxxxxxxxxxx
Subject: [ext] Re: [Mimblewimble] Supply Schedule: S then 0.25% Inflation

Ignotus Peverell,

> Why? Any evidence that's the best approach? And best for what metric?

The purpose is:
"to make a new liquid electronic money that becomes the predominant form of liquid money uses in daily transactions by most everyone/everything in the world."
The metric would be:
"How many people would want to use the money vs competition"

Please look at these charts comparing Bitcoin's supply schedule with what I am suggesting:

Bitcoin's
https://en.bitcoin.it/w/images/en/4/42/Controlled_supply-supply_over_block_height.png

Sinosoid Then 0.25% Inflation
http://i.imgur.com/wT7OP7Z.png

Normal Distribution Then 0.25% Inflation
http://i.imgur.com/d0InRqr.png

The evidence is:
1. People complain about how a coin is probably a "ponzi scheme" (really snake oil) because the people who mined early are probably doing a "pump and dump".  People don't want to buy in to various coins because they are worried they are going to give too much financial power to the first adopters and might fall victim to the early adopter's price manipulation or other actions.  I posted: "Being too fast would allocate too large of a portion of the money supply to too few hands."
- See how Bitcoin allocates ~50% of the supply in just the first 4 years?
- Verses the sinosoid allocates 5% of the supply, and the normal distribution only allocates 3.5% in the first 4 years, when the peak supply rate is at 10 years.

2. People complain about how much energy is "wasted" mining a PoW.  They would be right if people were still devoting huge resources to mining PoW for the supply bonus, when not very many people are joining the ledger anymore, and the security provided by the work per block is significantly beyond what is needed to disincentivize the 51% double spend attack.  Potentially a competing ledger wouldn't have this excessive inflation/security, and people would migrate to use it instead for higher money transfer efficiency.  I posted: "Being too slow would result in pains from lingering price inflation, and waste a lot of energy on extra unnecessary security against 51% attacks."
- Bitcoin gets down to about 0.25% inflation at 20 years.  (0.4% at 20, 0.2% at 24).
- I scaled both the sinosoid and normal distribution to peak allocation at 10 years and then get down to 0.25% inflation at 20 years.

One must choose some kind of initial allocation phase scheme, and it can't satisfy both of the above, because weighting one too much causes a bigger problem in the other.  So I said: "I propose that a money supply's initial supply growth phase should attempt to match usage growth."  This should hopefully minimize both the problems of #1 and #2... some kind of happy medium.  Again, Bitcoin minimizes #2 but does a terrible job at #1.

Cheers,
Praxeology Guy

P.S. Bandwidth needed for transactions (bandwidth = block size / block period) is said by various Bitcoin research to be the largest cost in running a full node.  So it comes into play when being concerned about how many people would find it worthwhile to run a fully validating node.  The higher the bandwidth, the fewer the people who will relay transactions & blocks, mine, and live synchronize.  What are the chances and how much money could an entity lose if they don't live synch, vs what is the live synch cost?  How few people can live synch before governments can take control?  Such are questions that lead to constraining bandwidth.


-------- Original Message --------
Subject: Re: [Mimblewimble] Supply Schedule: S then 0.25% Inflation
Local Time: May 31, 2017 5:43 PM
UTC Time: May 31, 2017 10:43 PM
From: igno.peverell@xxxxxxxxxxxxxx
To: praxeology_guy <praxeology_guy@xxxxxxxxxxxxxx>
mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>

> I propose that a money supply's initial supply growth phase should attempt to
> match usage growth.

Why? Any evidence that's the best approach? And best for what metric?


I have to say, these topics (coin supply, block size, etc.) quickly trigger my bikeshedding [1] aversion. People tend to address them with mostly opinion and little data or theoretical basis. Pretty much everyone will have an opinion and each reasonable opinion can't really be proven to be better or worse than the next.

When my bikeshedding aversion triggers, I have a very strong propensity to make the absolute simplest choice that doesn't look completely broken and move on to things that will actually make the project progress, like better privacy research, DoS protection in our p2p implementation, compact blocks implementation, range proof optimizations, unit and integration test, etc. If the simplest thing turns out to be insufficient, at least we'll have data to look for the next simplest thing.

- Igno

[1] https://en.wiktionary.org/wiki/bikeshedding

-------- Original Message --------
Subject: [Mimblewimble] Supply Schedule: S then 0.25% Inflation
Local Time: May 30, 2017 10:38 PM
UTC Time: May 31, 2017 5:38 AM
From: praxeology_guy@xxxxxxxxxxxxxx
To: mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>

=========================================
=== Supply Schedule: S then 0.25% Inflation ===
=========================================

=== TL;DR: ===

I recommend an S curve for the initial supply curve that lasts at least 20 years followed by a never ending 0.25% yearly inflation rate.

=== Introduction ===

Lets first assume that our purpose is to make a new liquid electronic money that becomes the predominant form of liquid money uses in daily transactions by most everyone/everything in the world.  If this is not your assumption, and instead you want to make a pump and dump coin, then the following recommendations are not for you.

The coin supply schedule can be split into two different phases: Initial Allocation and Mature Maintenance.  The initial allocation is during a period of rapid market adoption increase.

=== Bitcoin's Supply Curve ===

Bitcoin's distribution model is an exponentially decreasing block supply bonus.  The bonus started at 50 bitcoins every 10 minutes, and then every 4 years the bonus halves... eventually leading to 21 million coins being distributed, and a mature maintenance of 0 bitcoins per block.
https://en.bitcoin.it/wiki/File:Controlled_supply-supply_over_block_height.png
https://en.bitcoin.it/wiki/Controlled_supply

I have two criticisms of this model:
#1 This is it allocates too great a portion of the money supply to the early miners and investors
#2 It assumes that with a mature maintenance of 0 bitcoins supply bonus per block, that transaction fees will be enough to prevent 51% double spend attack.

=== My Recommended Supply Curve ===

My recommendation would be instead have a money supply curve that has an S curve for the initial allocation (such as a sinusoid), followed by a mature maintenance phase that is a constant small % inflation per year (such as 0.25%).

=== Initial Allocation Phase ===

I propose that a money supply's initial supply growth phase should attempt to match usage growth.

Likely if you were to model the number of users who began using the money at each time interval through the future, you may get something like a bell curve [https://en.wikipedia.org/wiki/Normal_distribution].  Not a perfectly balanced bell curve, but a skewed one [https://en.wikipedia.org/wiki/Skew_normal_distribution].  And not smooth, but with irregular spans of slow and fast growth.

If blocks were to have a supply bonus that matched a bell curve or skewed bell curve, then the Cumulative Distribution Function (CDF) would be used to model the total supply.  Such is a S curve or Sigmoid function:
https://en.wikipedia.org/wiki/Sigmoid_function

Some alternatives to the CDF of the normal distribution would be:
Logistic function
-0.5*COS(x) + 0.5

To create a continuously changing block supply bonus: Using block height as the horizontal axis, the difference in CDF values between two in series block heights would be the later block's supply bonus.  To create a supply bonus that has large difficult-for-miners-to-predict-profits supply bonus changes like Bitcoin, do the same thing over a larger height range, and then give each block within the range a supply bonus equal to dY/dH.

Its hard to predict the usage growth function of a new coin before it even hits the market.  Being too slow would result in pains from lingering price inflation, and waste a lot of energy on extra unnecessary security against 51% attacks.  Being too fast would allocate too large of a portion of the money supply to too few hands.  Unfortunately, changing the supply distribution schedule on the fly in a somewhat established coin would be a controversial policy change.  Given the nature of value being subjective: relative to each market participants value scales... the market value of the accounting units is not available to the policy code.

Looking at Bitcoin.... Bitcoin started in 2009.  It currently has a market cap of about $36e9 (2017-05-30). [http://coinmarketcap.com/] Alasdair Macleod's Fiat Money Quantity estimates that the supply of USD near the end of 2016 was about $15e12 USD [https://wealth.goldmoney.com/research/goldmoney-insights/fiat-money-and-gold].  So in ~8.5 years, Bitcoin has about 1/417 of USD's market cap.  Given Bitcoin's recent price rise, the adoption rate is currently increasing rapidly compared to other time periods.  Given this information, at least a 10 year lead up to the peak coins distributed per block would seem prudent in order to prevent issues with concentrated coin allocation.

=== Recommendation on Initial Allocation Phase ===

I don't think I'd recommend a skewed bell curve, because we can't predict exactly where the peak would be, nor can we predict how skewed it should be.

Technically, I'm concerned that if the CDF of the normal distribution uses floating point arithmetic that could potentially have different results on different machines or software.  Someone could weigh in here, but AFAIK IEEE 64 bit floating point arithmetic should round correctly and the same from machine to machine... but I don't know if we should rely on this for something as important as coming to consensus on block bonuses.  Also, some hardware doesn't come with an IEEE FPU, or some math functions can be missing.  So instead of actually performing floating point arithmetic on each machine, the software should come hard coded with linear interpolation points of the supply curve, and then perform the actual block bonus amount calculation with well defined integer operations.  If the normal distribution was used, the x axis would have to be raised on the CDF so that there isn't a pre-mine. The Cos/Sin functions can be mapped very closely to the normal distribution and it's CDF.

So to Keep It Simple Stupid (KISS), I would recommend a "-0.5*COS(x) + 0.5" curve that went from 0 to peak block supply bonus in at least 10 years, and then fell back down to 0 again at double the peak date.

=== Mature Maintenance Phase ===

Eventually a money should switch from the initial allocation phase to the mature maintenance phase.  At this point, preferably most all of the target users have already started using the money.  At this point, allocation of larger quantities of new supply would be an extra cost to long term holders of the money purchasing power (via supply inflation value erosion) for the sake of unnecessary extra security against 51% attack double spends.

The purpose of the mature maintenance phase is to ensure that miners are still motivated to put sufficient work towards securing against the 51% double spend attack.  Note that 51% of the entire hash rate is not even needed to perform this attack... because of the variance in work actually performed to create particular blocks.

=== Confirmation Security Equation ===

The cost of the work that miners put towards securing the finality of the block history approaches the block reward:
block_reward = new_supply_bonus + transaction_fees

The cost to the miner is:
miner_cost = energy_cost + capital_rent + labor

The profit is the difference, which miners compete to fully consume, and approaches zero over time (just like any other non-government-enforced-monopoly business):
miner_profit = block_reward - miner_cost

Given that competition has brought miner profit to near zero, the per confirmation security (cost to find an alternative block history) is:
per_confirmation_security = block_reward

And the cost to double spend a transaction that was confirmed total_confirmation_time minutes ago:
cost_to_double_spend = block_reward * total_confirmation_time / block_period

=== How to Pick the Inflation Rate ===

Once the initial distribution is complete, there is concern that mining fees may not be enough to secure the network vs 51% double spend attacks.  The block reward needs to be some reasonable portion of transaction value transferred within a block, so that people who receive larger amount transactions don't have to wait for a very large number of confirmations before they have confidence their received transaction won't be reversed.  If fees are not enough, the system should have some % inflation in order to subsidize the fees and cause an increase in the work/cost required to perform a 51% double spend attack.

Unfortunately fees may not be enough, because increasing one's own fees beyond the market going rate (beating the competition for block space demand) solely for the purpose of increasing security... is kind of like relying on generous people to voluntarily pay for public services.  The person paying the extra beyond the market going rate for fees is not just paying for his own transaction's security, but also paying for the security of all old and some future transactions.  Given that it is costly for miners to scale up/down their hash rate, miners would not increase their hash rate much for the few random people who once in a while pay extra high fees for the purpose of securing against the 51% double spend attack.  Even if miners could respond instantly to the next block's reward, a sender increasing the reward for the block you receive your transaction in would not increase the security of that transaction, instead only increase the security of transactions in prior blocks.

Given that the price of consuming block space was reduced to nearly zero through future scaling technologies, likely the network would need to be secured solely via new supply bonus.  Different % inflation values would result in a different number of confirmations required by the recipient of larger amount transactions.  The higher the inflation, the lower the number of confirmations needed.  Unfortunately, the higher the inflation, the lower the money retains its purchasing power over time... which decreases the value transfer efficiency of people who have large time spans between when they attain and when they spend the money.  Given there is competition in the new distributed currency market, having too high of inflation may cause people to migrate from a ledger with a higher inflation to migrate to a ledger with a lower inflation model.  So there has to be some balance between increasing security vs 51% double spend attack and inflation.  Also, as mentioned earlier, extra inflation costs excessive wastage of energy towards mining/security.

Let me quantify this by example.  First, the cost of inflation to money holders is strait forward:
cost = units_held * (1 + percent_inflation_per_year / 100%) ^ number_of_years_held

Second, the expected amount of time a recipient needs to wait for confirmations in order to be assured against 51% double spend attack:
confirmation_count = precaution_factor * amount_received / block_reward
total_confirmation_time = confirmation_count * block_period

The precaution_factor is highly subjective and context sensitive.  Ideally it would be at maximum be 1.  But subjective: how much the recipient can trust the sender (trust decreases the factor); context: 1. The random nature of how much work is actually spent in making a particular sequence of blocks (increases the factor); 2. The possibility that higher efficiency miners from other ledgers etc might attack...  such things can make a user want to wait more confirmations (increases the factor).  But... lets assume that the precaution_factor = 1.

Lets assume our goal was to have quick total_confirmation_times for the median income person in a well developed country, and the ledger had about similar usage to USD.  The person may want to receive a $10,000 USD transaction (year 2016 market value) and only have to wait about 60 minutes.

block_period = 10 min
precaution_factor = 1
amount_received = $10,000 USD
total_confirmation_time = 60 min
block_reward = block_period * precaution_factor * amount_received / total_confirmation_time
block_reward = $1666.67 USD

To calculate inflation we need to know the money supply. Alasdair Macleod's Fiat Money Quantity estimates that the supply of USD near the end of 2016 was about $15e12 USD [https://wealth.goldmoney.com/research/goldmoney-insights/fiat-money-and-gold].

block_period = 10 min
block_reward = $1666.67 USD
money_supply = $15e12 USD
inflation_per_block_period = block_reward / money_supply
inflation_per_block_period = 1.111e-10

If the nominal block_reward continuously increased each block, then the following formula would convert this to a yearly rate:

inflation1_ts1 = (1 + inflation_ts0)^(ts1/ts0) - 1
ts0 = 10 minutes
ts1 = 1 year
ts1/ts0 = 52596
inflation_ts0 = 1.111e-10
inflation1_ts1 = 5.844e-6 (note that in this case, this is practically the same as inflation_per_block_period * ts1/ts0, sanity check)
percent_inflation_per_year = inflation_per_year * 100%
percent_inflation_per_year = 5.844e-4% or 0.0005844%.

Wow, so a money with a very large supply compared to transaction amount would only need a very small inflation rate to confirm the receipt of a larger transaction.  Buying a $480,000 USD house would require waiting 48x longer... 2 days.

As a lower bound, Bitcoin's market cap is currently about $36e9 with 16,361,787 bitcoins issued and a price of $2200.25 USD each. [http://coinmarketcap.com/] (2017-05-30)
block_period = 10 min
block_reward = $1666.67 USD
money_supply = $36e9 USD
inflation_per_block_period = block_reward / money_supply
inflation_per_block_period = 4.629629e-8
percent_inflation_per_year = 0.2438%

Given there are currently about 16,361,787 bitcoins issued, that is 0.7575 bitcoins per block.

Anyways... moral of the story... for a money with a market cap of between bitcoins current $36 million USD to the USD's $15 billion USD... an inflation somewhere between 0.25% and 0.0005% per year would be needed, given total transaction fees per block were negligible.

=== Recommendation on Mature Maintenance Phase ===

I would recommend the mature maintenance phase to kick in right when the initial phase's block reward drops back down below the mature phase's inflation rate.  I would suggest starting with an inflation rate of 0.25%, and then if in the future the users decide this rate is too low (unlikely) or too high (likely), then it could be changed with a fork.  The logic could be made in such a way that reducing the inflation rate would be a soft fork.

Given the above math, I would recommend against a flat line quantity of inflation: such eventually effectively approaches 0% inflation as time goes on, where I would then question its purpose.