mimblewimble team mailing list archive

[praxeology_guy <praxeology_guy@xxxxxxxxxxxxxx>]

=========================================
=== 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.