Bitcoin Forum
May 12, 2024, 06:58:27 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Ratio USD transaction volume vs USD price  (Read 1680 times)
EuroTrash (OP)
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
April 13, 2014, 07:46:40 AM
 #1

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.

<=== INSERT SMART SIGNATURE HERE ===>
1715540307
Hero Member
*
Offline Offline

Posts: 1715540307

View Profile Personal Message (Offline)

Ignore
1715540307
Reply with quote  #2

1715540307
Report to moderator
"You Asked For Change, We Gave You Coins" -- casascius
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715540307
Hero Member
*
Offline Offline

Posts: 1715540307

View Profile Personal Message (Offline)

Ignore
1715540307
Reply with quote  #2

1715540307
Report to moderator
1715540307
Hero Member
*
Offline Offline

Posts: 1715540307

View Profile Personal Message (Offline)

Ignore
1715540307
Reply with quote  #2

1715540307
Report to moderator
EuroTrash (OP)
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
April 13, 2014, 07:55:55 AM
Last edit: April 13, 2014, 08:18:25 AM by EuroTrash
 #2

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

<=== INSERT SMART SIGNATURE HERE ===>
GreekGeek
Hero Member
*****
Offline Offline

Activity: 577
Merit: 500


Jesus was a (Goddamn) hippy socialist


View Profile
April 13, 2014, 09:28:01 AM
 #3

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

retirement fund : 1NBM5DM317RfWsHXKUfPUDtba2scavpPoB
EuroTrash (OP)
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
April 13, 2014, 09:50:35 AM
Last edit: April 13, 2014, 10:04:39 AM by EuroTrash
 #4

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

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.

<=== INSERT SMART SIGNATURE HERE ===>
oda.krell
Legendary
*
Offline Offline

Activity: 1470
Merit: 1007



View Profile
April 13, 2014, 04:37:29 PM
 #5

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 Cheesy There's already one (relatively crude) observation I could add after I see that I understood your model correctly.

Not sure which Bitcoin wallet you should use? Get Electrum!
Electrum is an open-source lightweight client: fast, user friendly, and 100% secure.
Download the source or executables for Windows/OSX/Linux/Android from, and only from, the official Electrum homepage.
EuroTrash (OP)
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
April 13, 2014, 05:18:07 PM
 #6

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

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

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

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.

Quote
There's already one (relatively crude) observation I could add after I see that I understood your model correctly.

I'm all ears Smiley

<=== INSERT SMART SIGNATURE HERE ===>
oda.krell
Legendary
*
Offline Offline

Activity: 1470
Merit: 1007



View Profile
April 13, 2014, 06:02:06 PM
 #7

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

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

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

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.

Quote
There's already one (relatively crude) observation I could add after I see that I understood your model correctly.

I'm all ears Smiley

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

Not sure which Bitcoin wallet you should use? Get Electrum!
Electrum is an open-source lightweight client: fast, user friendly, and 100% secure.
Download the source or executables for Windows/OSX/Linux/Android from, and only from, the official Electrum homepage.
EuroTrash (OP)
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
April 13, 2014, 06:28:42 PM
 #8

Thanks. Smiley 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.

<=== INSERT SMART SIGNATURE HERE ===>
oda.krell
Legendary
*
Offline Offline

Activity: 1470
Merit: 1007



View Profile
April 13, 2014, 06:37:12 PM
 #9

Thanks. Smiley 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.

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.

Not sure which Bitcoin wallet you should use? Get Electrum!
Electrum is an open-source lightweight client: fast, user friendly, and 100% secure.
Download the source or executables for Windows/OSX/Linux/Android from, and only from, the official Electrum homepage.
oda.krell
Legendary
*
Offline Offline

Activity: 1470
Merit: 1007



View Profile
April 28, 2014, 12:40:57 PM
 #10

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.

Not sure which Bitcoin wallet you should use? Get Electrum!
Electrum is an open-source lightweight client: fast, user friendly, and 100% secure.
Download the source or executables for Windows/OSX/Linux/Android from, and only from, the official Electrum homepage.
wachtwoord
Legendary
*
Offline Offline

Activity: 2324
Merit: 1125


View Profile
April 28, 2014, 12:48:11 PM
 #11

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 Wink)

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.
billyjoeallen
Legendary
*
Offline Offline

Activity: 1106
Merit: 1007


Hide your women


View Profile WWW
April 28, 2014, 01:07:54 PM
 #12

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.

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.


insert coin here:
Dash XfXZL8WL18zzNhaAqWqEziX2bUvyJbrC8s



1Ctd7Na8qE7btyueEshAJF5C7ZqFWH11Wc
dnaleor
Legendary
*
Offline Offline

Activity: 1470
Merit: 1000


Want privacy? Use Monero!


View Profile
April 28, 2014, 02:24:33 PM
Last edit: April 28, 2014, 03:11:11 PM by dnaleor
 #13

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 Smiley



murraypaul
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250


View Profile
April 28, 2014, 02:34:25 PM
 #14

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

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.

BTC: 16TgAGdiTSsTWSsBDphebNJCFr1NT78xFW
SRC: scefi1XMhq91n3oF5FrE3HqddVvvCZP9KB
oda.krell
Legendary
*
Offline Offline

Activity: 1470
Merit: 1007



View Profile
April 28, 2014, 02:51:48 PM
 #15

So yo need to devide the transaction volume in USD by the product of the exchange rate and the numbver of coins in circulation Smiley

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.

Not sure which Bitcoin wallet you should use? Get Electrum!
Electrum is an open-source lightweight client: fast, user friendly, and 100% secure.
Download the source or executables for Windows/OSX/Linux/Android from, and only from, the official Electrum homepage.
oda.krell
Legendary
*
Offline Offline

Activity: 1470
Merit: 1007



View Profile
April 28, 2014, 02:53:48 PM
 #16

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

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.

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.

Not sure which Bitcoin wallet you should use? Get Electrum!
Electrum is an open-source lightweight client: fast, user friendly, and 100% secure.
Download the source or executables for Windows/OSX/Linux/Android from, and only from, the official Electrum homepage.
bucktotal
Full Member
***
Offline Offline

Activity: 232
Merit: 100


View Profile
April 28, 2014, 03:08:49 PM
 #17

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.
 
aminorex
Legendary
*
Offline Offline

Activity: 1596
Merit: 1029


Sine secretum non libertas


View Profile
April 28, 2014, 04:15:56 PM
 #18

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

This would at least partially deal with the decline in the running average.
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.

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.

Give a man a fish and he eats for a day.  Give a man a Poisson distribution and he eats at random times independent of one another, at a constant known rate.
oda.krell
Legendary
*
Offline Offline

Activity: 1470
Merit: 1007



View Profile
April 28, 2014, 04:27:04 PM
 #19

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

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

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.

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.

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.

Not sure which Bitcoin wallet you should use? Get Electrum!
Electrum is an open-source lightweight client: fast, user friendly, and 100% secure.
Download the source or executables for Windows/OSX/Linux/Android from, and only from, the official Electrum homepage.
EuroTrash (OP)
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
May 02, 2014, 07:40:40 AM
 #20

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

Special mention to oda.krell and aminorex Wink 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. Smiley

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


<=== INSERT SMART SIGNATURE HERE ===>
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!