Topic: Stabilized Bitcoin using eMunie economics - page 6. (Read 4317 times)

The system funds itself by directing a percentage of new supply created into the buffer.  In the case of an oversupply due to dropping demand, the system burns currency from the buffer.  Should the trend reverse and there be a supply deficit once more, it will receive its percentage of new supply once again.  Rinse...repeat.  (this was omitted from the Bitcoin simulation to ensure it was more in line with Bitcoins behaviour)

The token assets are then created by converting the base currency (BTC in our test, EMU in the real thing) back and forth between these token assets that represent real world currencies on demand.  

Only the system can do this direct conversion, no one else, not me, not you, your mother, or your dog.

Who exactly is funding the "buffer" (and why)?

(this is starting to look more and more like BitShares to me)

Also, I chose the BTC test data as a source as it contains almost an entire spectrum of human trading behavior at the extreme.

A more stable currency will have a more predictable trading behavior, which in turn amplifies the stability of the currency further as a matter of course.  The live BTC data used was probably the most chaotic and difficult to stabilize, and as no order sentiments were modified (only the relative price/pressure), or dropped, it got a real work out.

your model may have many fancy rules to control supply and demand, but you cannot control peoples desires.

even if you had rules to stop people selling if the price dropped. that is called ignoring orders..

also to note. by you controlling what is acceptable price movements, and you controlling the supply and demand, breaks many freemarket rules, and wont be a benefit to the community.
people would not use your exchange if you were ignoring or delaying peoples desires, even if the point would be to avoid price dumps.. and so your supply would drop out because people cant trade or react to price movements. which would affect the results because you wouldnt have the supply that was there in the historic data.

so the supply that might be used to hold up a resistance point to prevent prices from dropping would get weaker. because less users are trusting you with their funds.

people who dont withdraw, would instead change their values of their order to try getting into the 10% target rule just to get their order processed, even if it means losing out.

the end result would that once you do the first tweak. and ignore the first order. you can no longer rely on historic data.. people will move funds out or change their orders and so anything after 2011 is irrelelevant as the human element which you ave not factored in. would have changed orders.

so although your economics may look good on paper, i feel you are lacking in the social impacts of economies, which i do not think that you have added as a variable that can totally change any results you have created using logic alone.

EG

say i had 6 orders in historic data (b)=buy
(b) 0.105cent
(b) 0.102cent
(b) 0.098cent
(b) 0.096cent
(b) 0.094cent
(b) 0.092cent

lets say that was a historic trend where on a tuesday. you had a rule that no trades would be processed below 0.095. those last 2 trades wont just sit there as a unprocessed order creating a resistance point.. those trades would either get canceled and withdrawn so they can buy coin elsewhere at their desired price. or they would at worse change the price to be 0.096 just to force the order through.

by wednesday.. historic data is irrelevant as its no longer valid, different people are trading at different prices that history.
(its like the butterfly effect of time travel.. change one thing can change history)

i dont think you have thought about the butterfly effect of changing history

Ok, So I took the USD txns that Dan did from his simulation of BTC using the eMunie economics and aggregated the trades to a monthly open/high/low/close stock chart view.

Here's the BTC chart for reference (like we need reminding of what volatility looks like):  

Bitcoin (weekly view since Aug 2011) http://imgur.com/YYGsEjO
Low $2.22 / High $1163

Here's the view if BTC was using the eMunie economics method (Baseline start cost $0.10): http://imgur.com/cMIHT2P

min/max btc (from the chart above): $2.22/$1163 (delta: 1160.78 or 1160780.00%)

min/max emu (from the chart above): $0.09832/$0.10322 (delta: 0.0049 or 4.9%)

Here is an interesting and meaty post for everyone to chew on and provide some food for thought no doubt

Over the past couple of weeks I have been putting the final touches to the eMunie economic model (amongst other things). Despite some stiff arguments presented against it on a number of occasions, I was always confident that it would operate effectively in all but the most extreme of "black swan" events.

A few days ago I got to the point where it was feasible to test it out, the majority of the core economic algorithms and execution models had been implemented culminating in the completion of 3 years of heavy thought, notes, tweaks and sleepless nights

However, I obviously found myself lacking in test data, or the ability to generate it. To generate such data would require completion of the decentralized exchange and other systems, plus a lengthy process to generate such a data set which would allow confidence in the results.

Eager to test out our economics model, I decided to investigate if it would be possible to create a simulator that uses the eMunie economic model as is, using existing Bitcoin trade data to see if it was possible to "stabilize" the price of Bitcoin and review the performance of the economic model as a whole.

If such a volatile (and perhaps even manipulated) currency such as Bitcoin could be stabilized, then it is safe to assume that EMU (and any currency for that matter) could use our economic model to achieve the same goal.

Overview

The white paper which will explain our economic model in detail is not yet finalized and needs to include the most recent changes, which of course will take a little time to do. A basic overview of its operation is presented here which should allow sufficient understanding despite the lack of mathematical representation at this point.

In the following text EMU may be substituted for BTC, LTC or indeed any other digital currency.

The purpose of our economic model is to stabilize the price of EMU over the short term, providing protection against legitimate large movements which may disrupt the price and inadvertently snowball into a panic buy or sell, as well as "pump and dumps", manipulation and similar for-profit activities, whilst allowing long term price trends to proceed unhindered.

The primary components to achieving the above goal are a system buffer and "token" functionality. An additional preferred component is an exchange integrated into the economy which can be "trusted" to provide legitimate trade data.

The economic model is decentralized and bound by a set of rules and consensus and is autonomous.  No party has any control of the economic model, nor the funds available in the various buffers.

In the eMunie platform this exchange is decentralized and built into the platform natively, and all user actions and trades are validated by the network as well as the regular transactions, providing a trustworthy entity by which the economics can operate.

Stability Target

The stability target dictates the maximum desirable price movement of EMU over the duration of a year as a percentage. The economic model will attempt to keep within bounds of this target to the best of its ability.

This target is used at a much granular level most of the time, and it is easy to calculate the corresponding desired maximum movement over any period of time.

For example if the annual target was 10% and one wanted to calculate the daily allowed movement, it is simply 10% / 365 (or 366 for a leap year).

Delta targets are also used extensively, and provide a means to determine what the maximum allowed movement during two points in time may be.

Pressure

Trades on the exchange are converted to buy/sell pressure metrics which the economics model uses to determine both the estimated supply figures for that moment in time, and whether it needs to take action to ensure the price stays within target bounds.

A pressure metric in its simplest form is a percentile delta between the current and last trade for EMU in a particular currency pair (EMU/USD).

For example, if the last trade price was $1 and the next is $1.1 then there is a pressure of +10%. If the prices $1 and $0.90 then there would be a pressure of -10%.

Supply

The economics model can function in both fixed (such as Bitcoin) and elastic supply economies.

eMunie employs an elastic model that responds to "pressure" signals from the decentralized exchange, which are in turn used to calculate the supply/demand estimates at any point in time.  In the case of a supply deficit, a quantity of new supply being created and distributed to the various actors in the system as per a set of defined rules, an excess of supply results in EMU currency being burned by the system.

Tokens

Whether an exchange is decentralized or not, tokens that represent real world currencies are required so that users can "cash out" of EMU. This may be for a period of time as a strategy to maximize their position, or to exit the economy completely by later exchanging those tokens for their real world counterparts.

As eMunie is intended to operate almost completely isolated from existing centralized infrastructure, these tokens that represent fiat currencies are used extensively. Users that wish to cash out entirely would exchange these tokens for the real world counterparts via our TRAID system.

In the case of Bitcoin, these tokens are currently exchanged for fiat by the exchange at which they are held. Should Bitcoin ever advance to using decentralized exchanges and fiat currency on/off ramps, "colored coins" would suffice for use as these tokens.

Buffer

The buffer should receive a portion of all new EMU supply, allowing it sufficient funding to perform its task, and this portion should be significantly higher than any feasible holding by another entity in the system. In the case of the simulated tests, this buffer was set to 10%.

The buffer should receive real time trade information from the exchange, including the buy/sell pressure of that trade and the currencies being traded.

If the pressure percentile of that trade would exceed the allowed delta target, then the buffer is used by the economic model to fill that trade.

As the buffer will be both buying and selling EMU, it not only needs to have a quantity of EMU itself but also be able to hold various "tokens" that represent currencies such as USD which are being traded for EMU.

A critical feature of the buffer is that it is the only party who is allowed to convert digital currency to fiat currency tokens and vice versa, and do so in a frictionless manner without cost. All other parties in the system must trade their USD tokens on the exchange for other currency tokens, assets or EMU.

To maintain balance, should the buffer require some USD tokens, it will convert a quantity of EMU it holds into USD tokens at the current EMU->USD price and record it in a FIFO (first in first out) queue for future use. If later it is required that some USD tokens it holds should be converted back to EMU, it polls the EMU->USD FIFO queue and converts back to EMU using the values stored in those records.

This ensures that the buffer does not profit (or incur loss) from conversions and upset the balance of the system as would be the case if USD was converted back to EMU at the current rate, rather than the rate at which it was made.

Buffer Trades

The buffer only intervenes and fills trades if the pressure of that trade exceeds the target delta since the last trade. In the case that the pressure is beyond bounds the buffer fills the trade at the current maximum allowed ask as per the delta, which then becomes the current price for EMU.

For example assume the current EMU price is $1, the last trade was 1 day ago, and the max daily target delta is 1%. ($0.01) If a trade were now presented to buy at $1.10 per EMU, the buy pressure would be 10%, 9% more than the allowed delta.

The buffer would then sell EMU at $1.01, filling the trade and setting the current price to $1.01, which is the maximum allowed by the delta.

Likewise, if a sell was presented at $0.90 per EMU the sell pressure would be 10% (or the buy pressure -10%) and exceeds the allowed delta of 1%. The buffer would fill that trade by buying the EMU at $0.99 (converting EMU to USD tokens if needed at the current rate of $1.00)

Bitcoin Data

I sourced the Bitcoin trade data from http://api.bitcoincharts.com/v1/csv/ which has data from a number of exchanges and currencies from as far back as 2010. This data is simply formatted as the trade time, the amount of BTC being traded and how much for in a particular currency.

As far as I can determine, this data is every trade that ever happened on the exchange in question. I have been able to find all my past BTC trades that I have made on exchanges within this data set.

To ensure that the economics model can sufficiently handle multiple trade currency types, trade data for USD and CNY was used.

The USD trade data consists of 58M trades made between Sat, 09 Oct 2010 and Tue, 19 Jan 2016 for the major exchanges during that time, namely Bitstamp, Bitfinex, BTCe, Coinbase, Lake, and MtGox.

The CNY trade data consists of 274M trades made between Mon, 13 Jun 2011 and Tue, 19 Jan 2016 for the two major exchanges of OKCoin and BTCChina.

Data Usage

The trade data is fed to our economics model in series, effectively replaying the trades in the order they happened at many multiples of real time.

To counter the phenomenon of varying price across exchanges, and the arbitrage opportunities that come with it, the data was presented in batches from the same exchange for the same timestamp.

Say that Bitstamp had 3 trades at UNIX time 1307942004, and Coinbase has 6. The 3 Bitstamp trades would be applied together, with the 6 Coinbase trades applied after, and so on until all trades for all exchanges and currencies at UNIX time 1307942004 had executed.

Without this batching, the stabilized price of BTC has an small amount of constant "jitter" which was undesirable, with it this "jitter" is eliminated.

A secondary effect due to this phenomenon also needs to be considered when calculating the pressure percentiles. All pressure percentiles should be calculated only from historic data pertaining to the exchange which that trade originated.

In the case of a trade from Bitstamp, if the most previous trade executed occurred on Coinbase, a historic search should be made for the last trade that occurred on Bitstamp and the pressure percentile calculated accordingly.

Emulating Bitcoin

To ensure as close a simulation to Bitcoin as possible, we also simulated Bitcoins supply emission and the rate at which they were generated including halving. 10% of the supply emission was directed to the buffer as already stated, with the remainder going into circulation.

Initial Parameters

The simulation was executed with the first trade occurring on Sat, 09 Oct 2010 02:07:18 GMT which was made at MtGox and was the first purchase of BTC for $0.10.

The quantity of BTC in existence at this moment in time was approximately 4,205,200, 10% of this (420,500) was allocated to the buffer.

A stability target of maximum 10% was specified.

Results

The first test was the processing of USD trades only, and the results were extremely encouraging and interesting to say the least.

After the processing of the 58M trades over the course of almost 6 years, the ending BTC price on the last trade was $0.10085, almost exactly the same as the starting price of $0.10.

Over the course of all the trades, the low and high BTC price was $0.0983 and $0.10321 respectively. Which is obviously extremely stable when considering how volatile BTC has been due to its varying trends and amid large pump and dumps and manipulations.

Also of interest is the fact that at no point was the buffer in danger of expiring its resources, with the minimum and maximum available BTC quantities held by it being 420,500 and 999,126 respectively.  Due to 10% of the BTC issued from block rewards being directed to the buffer, its cumulative purchasing power never actually dropped below the initial value.

The CNY + USD simulation is currently executing, and due to the number of trades (over 320M) it is expected to be completed sometime in the next 12-18 hours. I'll report back with the results of that simulation when it has completed, but as of right now, the results look to be very similar to the USD only simulation.

Some other simulations I would like to run include reducing the buffer allocation and stability targets as low as possible while ensuring stability.

The data sets for these simulations will also be made available for download in MySQL dump format soon, and we will be constructing a basic presentation website where this data can be navigated and queried in a more human form via candle graphs and other charting methods.

Final Thoughts

Application of our stabilizing economic model to Bitcoin unfortunately has some fundamental consequences and I am not suggesting that Bitcoin should do it. The use of its trade data was purely to test our model with intense real world data giving us confidence in the model and the algorithms that power it, and also as a curiosity experiment with regard to Bitcoin.

Perhaps the most critical issue that would prevent any implementation of such a stabilizing model into Bitcoin, is the almost total destruction of the mining economy, which is fuelled by the speculative trading brought about by Bitcoin's fixed rate of supply emission.

In order to supply miners with an incentive should a stabilizing economic model ever be applied, Bitcoin would have to adopt an elastic supply model that, like eMunie, reacts to supply and demand instead of its current fixed emission policy.

Miners then would be rewarded not by an increase in the value of the BTC they hold, but by an increase in the amount of BTC that they hold instead.

Thoughts?