Topic: Ratio USD transaction volume vs USD price (Read 1700 times)

thx for great input - I still have so much to learn.

Special mention to oda.krell and aminorex your posts are amongst the brightest ones in this forum.

1. Regarding regression over a rolling window (excellent choice 30 days!), I suck at Excel and my Matlab memories from university times also are too damaged to be of help. I'll look into it anyway.

2. Also I was thinking of dividing TV by the number of bitcoins in existence at the time - because that would make the formula dimensionally correct, as dnaleor pointed out. But it actually makes things worse in the sense that at the beginning of the period the "fair price" goes way above the current price and the opposite happens now. It seems that the hoarding behaviour has changed over the last few years, so the number of coins actually in circulation at any given time (which is what I'd really want in the formula) is hard to guess.

Probably a combination of 1. and 2. would give the best results.

BTW here an updated chart. Things are going south atm  
Either there is way more hoarding going on in the last months than in the past (hence invalidating the red line), or we still are way overpriced and as such we'll see another drop.

That's what I meant in my later post ("running regression", no idea if that's the correct term. I'd say a 30d window could be a good candidate). The bigger problem is, imo, what to use for the 'fair price' calculation... calculate the TV/price ratio (or a similar metric) over the entire history, as ET does now, and you won't pick up changes in the fundamentals fast enough (which is what ET might be picking up right now, with fair price being well below actual price). Adjust the ratio more readily on the recent past, and you just have another short-term indicator.

This would at least partially deal with the decline in the running average.

You can have both:  Regress over a rolling window.  Leaves you stuck extrapolating over the length of the window at one or both ends, but no worse than a moving average.

a reasonable way to remove high frequency spikes in the data set is to use a running median filter. just have to test a few window sizes to get a nice result.
 

My idea was to smooth those out, not filter them out. I thought of using a running linear regression for transaction volume instead of an average, which should give less importance to those extreme outliers.

Or, since transaction volume in USD is vol_btc * price anyway, he can take V = vol_btc/total_btc, i.e. the fraction of the total amount of btc in circulation transacted per time unit, unless I'm mistaken.

This might in part be due to the fact that what is being measured is blockchain transactions, and
a) not all of them will be actual economic transactions, they could just be people shuffling their own money between wallets. Could a couple of large exchange movements have caused the spikes?
b) blockchain transaction amounts are always artificially inflated due to having to always transfer entire previous outputs, so change ends up getting counted as spent money
Not really obvious how you could filter either of these effects out, except in the simple case of change being sent back to the original address.

You are almost correct:
http://en.wikipedia.org/wiki/Equation_of_exchange

M*V = P*T
<=>
V = P*T/M = velocity of money

M = total nominal amount of money = m * p
   where m = total number of bitcoins
   where p = exchange rate USD/BTC
P = price level. Lets assume iflation in USD over the past 5 years to be zero. P=1 (ignore P)
T = transaction volume

=>

V = T/(m*p)

So you need to devide the transaction volume in USD by the product of the exchange rate and the number of coins in circulation

First I'd like to say that I really appreciate your thoughtful contributions to this thread. My initial response is that I think TV and Bitcoin comparisons have limited use because TVs are not as fungible as bitcoins. Your question is a very good one and requires more thought before I can give you a good answer. I'm working on it.

Very cool, Eurotrash. Thanks for posting this.

I don't think this is a good way to estimate price because price and volume are highly correlated (he said without providing any data to support his claim )

Further, when we watch the graph it tends to overshoot (in both directions), supporting this idea. At the foot of every growth spurt, the red line is significantly south of the blue line. The situation which also exists today.

Giving it one more bump, after being reminded about it by your post on the wall thread.

Recap: I can see two problems with it, or maybe better: 2 possibly problematic assumptions.

1) the fact that currently, your 'fair price' is well below actual price is largely explained by the overall trend of falling TV/price ratio. Question is then: if you instead calculate 'fair price' based on a "shorter leash" average, will your overall accuracy suffer or not? If not, the current result of fair price < actual price becomes less interesting imo.

2) there are strange spikes in TV that seem to not correspond to price changes. question: what are good ways to smooth them out.

I'll play around with your idea myself if you don't mind, as soon as I have time for it, and will post the result here.

There's a chance that regressing over the data points would be better than averaging, now that I think of it.

This is not my field, so I can't say stuff about this with authority, but if the goal is to dismiss, or value less, certain spikes then minimizing R^2 might be a better idea than taking a (moving) average.

But I'd hope someone with better knowledge of statistical modeling could chip in here.

Thanks. I think that the crossover from last weeks has to be ignored. I think it was either due to one exchange doing an audit or stolen Goxcoins on the move.
The 7-day averaging I chose when I pulled the data from blockchain.info makes the spike look larger than the actual few data points that caused it, where we had almost one million bitcoins moving in a day.

Most obvious change that could be an improvement I can see right now would be using a 30d EMA to get the ratio for the predicted price instead of the all-time average.

About my "crude observation", I just noticed you made it basically yourself in your last post  A simple "cross over" method, similar to pure price based momentum trading, would have outperformed b&h (I say this from eyeballing it ). Some form of treshold is probably necessary, some whipsawing is visible, but what is interesting is that, as opposed to price-derived momentum trading, this one seems to be less lagging, in some cases even anticipating price changes. Example 1: in 2011, the exp. price shot through price, well before the actual price turnaround. example 2: 2013. the bearish CO happened rather late, but the "buy back" signal seems to have preceded the reversal in July by about 3 weeks. THat's a pretty good signal, seriously.

There are problems, obviously, in the sense that a downwards CO would have made you lose parts of the uptrend that happened between July 2013 and December 2013. And, of course, the million dollar question is now, how we price develops now. There's a very clear CO in the past week(s), well above any reasonable treshold, so unless the bear market we're in ends now, that would be a pretty clear bad signal.

Yes. I am using data from blockchain.info because they use "an algorithm which attempts to remove change from the total value".


Yes, I use the all time average for the ratio USD TV/price. Empirically I could see that a moving average over 1 month or more for it does not diverge much from a flat line of ~200000 except for the last few months where it gets closer to 100000, making me think that either the model diverges because of more hoarding in the last months or the model is correct and we still are overpriced.


I'm all ears

Very cool, Eurotrash. Thanks for posting this.

To clarify: transaction volume = total amount BTC transfered on-chain (per day?) times USD per BTC at time of transfer. Yes?

Also, for 'expected price', do you use the all-time average calculated at the end of the series? Or a moving average?


I guess blockchaininfo does a similar calculation on their site, but I like your better because the view is more detailed, and we can discuss it here There's already one (relatively crude) observation I could add after I see that I understood your model correctly.

If I do that, the average ratio becomes 192220.9913 which is still close to 200000. Here you are, with the results scaled to the new average ratio:





Notice that in 2011 the red line spiked up before the reversal, bringing the ratio TV/price off the scale. Lots of bitcoin transactions happened at that time. Why? Maybe Silk Road business was picking up fast and starting giving bitcoin a compelling use case.

nice work
can you try to include 2011 bubble too?

it would be interesting to see if this current difference
between expected and actual price
was also present in the 2011 bear market

I have gone a bit further with this now and I have averaged the above ratio in the last two years, the average being 199950.1965.
Then I have calculated the ratio USD daily TV / (average ratio TV/price) and used the value to "predict" a bitcoin price. Results below. Values are averaged over 7 days.



I am still not happy with the result... I think the "Expected Price" as of today is too low - this because the ratio has taken its new course where it stays closer to 100000 than to 200000. Maybe I should use some better way of averaging, e.g. EMA.

Or probably this is total nonsense.

EDIT: changed to log scale

I calculated a ratio USD transaction volume vs price. I am not an expert but I believe this measures money velocity?



My logic being that in a healthy market the ratio should stay constant over time, or slightly increase.
When the ratio goes up, bitcoin usage goes up (currency case) and the economy grows.
When the ratio goes down, bitcoin usage goes down (store of value case) and the economy shrinks.

Economically I am a noob so this logic is probably flawed; tell me why and how.