Wall Observer - MtGoxUSD wall movement tracker

[bowen151]

ya gotta feel for all those people chucking up the low bids of only fractions of a coin
atleast they will own a few million, in a couple of years when they they decide to sell some
whereas people buying the full coins are all knowing they will be the richest people in their
respective locations over the globe in a few years years once acceptance grows

I'll feel nothing for a bot.

[elux]

Contemplating history:

http://bitcoincharts.com/charts/mtgoxUSD#rg10zigHourlyzczsg2011-06-01zeg2011-06-10ztgSza1gEMAzm1g10za2gEMAzm2g21zi1gMACDzi2gRSI
http://bitcoincharts.com/charts/mtgoxUSD#rg10zigHourlyzczsg2013-02-27zeg2013-03-08ztgSza1gEMAzm1g10za2gEMAzm2g21zi1gMACDzi2gRSI
http://bitcoincharts.com/charts/mtgoxUSD#rg10zigHourlyzczsg2011-06-04zeg2011-06-14ztgSza1gEMAzm1g10za2gEMAzm2g21zi1gMACDzi2gRSI

It seems this rally was more dramatic than 2011, and with a deeper initial plunge. The next few days/weeks are going to be interesting for sure.

[molecular]

You've never written a relational database application with millions of rows of data that is queried, inserted and updated at a high rate and that needs to be (pseudo) real time, have you?

you're mistaken. I designed and now maintain 2 such dbs. One of them has tens of millions of rows in some tables (this one is mssqlserver on some 2 year old 2 x quadcore). The other has millions of rows in one of the main tables. I run quite complicated search and update queries on that one (based on http requests). Performance simulations showed >40 of the most complicated search/update/insert_into_multiple tables combos per second on. While production is deployed on ok hardware (single quadcore), these performance tests were done on a fucking single ATOM 350 (dualcore) with nfs-mounted volumes (!!). No oracle magic either, just simple mysql innodb.

For reference: mtgox aggregated order book (acquired by fulldepth api call) currently has about 10,000 entries. Can't be more than 50,000 individual orders in the orderbook.

Maybe I'm missing something, but I still think I could do it on my nexus 4.

[SkRRJyTC]

You've never written a relational database application with millions of rows of data that is queried, inserted and updated at a high rate and that needs to be (pseudo) real time, have you?

you're mistaken. I designed and now maintain 2 such dbs. One of them has tens of millions of rows in some tables (this one is mssqlserver on some 2 year old 2 x quadcore). The other has millions of rows in one of the main tables. I run quite complicated search and update queries on that one (based on http requests). Performance simulations showed >40 of the most complicated search/update/insert_into_multiple tables combos per second on. While production is deployed on ok hardware (single quadcore), these performance tests were done on a fucking single ATOM 350 (dualcore) with nfs-mounted volumes (!!). No oracle magic either, just simple mysql innodb.

For reference: mtgox aggregated order book (acquired by fulldepth api call) currently has about 10,000 entries. Can't be more than 50,000 individual orders in the orderbook.

Maybe I'm missing something, but I still think I could do it on my nexus 4.

+1 for truth.  Free DBMS' and any hardware from this decade should be more than enough if configured properly.

[oakpacific]

You've never written a relational database application with millions of rows of data that is queried, inserted and updated at a high rate and that needs to be (pseudo) real time, have you?

you're mistaken. I designed and now maintain 2 such dbs. One of them has tens of millions of rows in some tables (this one is mssqlserver on some 2 year old 2 x quadcore). The other has millions of rows in one of the main tables. I run quite complicated search and update queries on that one (based on http requests). Performance simulations showed >40 of the most complicated search/update/insert_into_multiple tables combos per second on. While production is deployed on ok hardware (single quadcore), these performance tests were done on a fucking single ATOM 350 (dualcore) with nfs-mounted volumes (!!). No oracle magic either, just simple mysql innodb.

For reference: mtgox aggregated order book (acquired by fulldepth api call) currently has about 10,000 entries. Can't be more than 50,000 individual orders in the orderbook.

Maybe I'm missing something, but I still think I could do it on my nexus 4.

Anyone knows how Gox moves people's deposits around? If you use http://www.bitcoinmonitor.com/ , you would notice that whenever a trade is executed, a lot of transfers take place on the blockchain, in principle it should be just bookkeeping, no real transaction should happen.  I don't know why and if it has anything to do with their sluggishness.

[molecular]

You've never written a relational database application with millions of rows of data that is queried, inserted and updated at a high rate and that needs to be (pseudo) real time, have you?

you're mistaken. I designed and now maintain 2 such dbs. One of them has tens of millions of rows in some tables (this one is mssqlserver on some 2 year old 2 x quadcore). The other has millions of rows in one of the main tables. I run quite complicated search and update queries on that one (based on http requests). Performance simulations showed >40 of the most complicated search/update/insert_into_multiple tables combos per second on. While production is deployed on ok hardware (single quadcore), these performance tests were done on a fucking single ATOM 350 (dualcore) with nfs-mounted volumes (!!). No oracle magic either, just simple mysql innodb.

For reference: mtgox aggregated order book (acquired by fulldepth api call) currently has about 10,000 entries. Can't be more than 50,000 individual orders in the orderbook.

Maybe I'm missing something, but I still think I could do it on my nexus 4.

You really should.

I'm sure a lot of stuff I haven't thought about now would pop up and slow things down, but the main point still stands: it's not a hardware problem or the requirements of the problem itself, but some inefficient implementation(s) that slow things down.

I agree it'd be fucking cool to put "bitcoin exchange server" app into google play store, though.

[Nagato]

You've never written a relational database application with millions of rows of data that is queried, inserted and updated at a high rate and that needs to be (pseudo) real time, have you?

you're mistaken. I designed and now maintain 2 such dbs. One of them has tens of millions of rows in some tables (this one is mssqlserver on some 2 year old 2 x quadcore). The other has millions of rows in one of the main tables. I run quite complicated search and update queries on that one (based on http requests). Performance simulations showed >40 of the most complicated search/update/insert_into_multiple tables combos per second on. While production is deployed on ok hardware (single quadcore), these performance tests were done on a fucking single ATOM 350 (dualcore) with nfs-mounted volumes (!!). No oracle magic either, just simple mysql innodb.

For reference: mtgox aggregated order book (acquired by fulldepth api call) currently has about 10,000 entries. Can't be more than 50,000 individual orders in the orderbook.

Maybe I'm missing something, but I still think I could do it on my nexus 4.

I also think that the hardware used by Gox is insanely overkill.

Like i mentioned in another thread, the bottleneck is likely to be either the trade engine code(which appears to be a seperate module from the front end) or more likely the DB.
molecular - Perhaps 1 thing you are discounting is the large number of concurrent write requests during volatility which your DBs might not be exposed to. Imagine 10k people buy/selling at the same time(each involving multiple queries/updates to different tables), a typical DB setup will not be able to handle that number of DB txns. Couple that with the requirement of having fail-safe redundancy/backups of every trade/txn (meaning write to multiple disks every completed txn before processing next one) means you are limited by disk I/O. 96GB of RAM means little if every update still has to be written to disk.

Im sure these are solved problems(since speed/consistency/redundancy is required in many financial systems) but implementing them might not be as trivial as we assume.

[oakpacific]

Is the lagging even caused by trade volume? Now there is very little rading yet the response doesn't seem to improve a lot.

[humanitee]

I thought the guys at Gox manually audit every trade before it goes through after they got hacked? That's why there is a delay (assuming what I heard is true).

[humanitee]

The fiat is back.

I thought the guys at Gox manually audit every trade before it goes through after they got hacked? That's why there is a delay (assuming what I heard is true).

maybe over a set price, but every bot trade, highly doubt it

Maybe it's up to a certain volume then, I just recall reading that on these forums somewhere.

[mccorvic]

The fiat is back.

How do you mean?



I really don't understand why anyone would sell more than a handful of BTC at a time at the current price.  There is such obvious upwards pressure and willingness to buy at higher prices.

Oh well. Long live the $40 dollar range!

[oakpacific]

You've never written a relational database application with millions of rows of data that is queried, inserted and updated at a high rate and that needs to be (pseudo) real time, have you?

you're mistaken. I designed and now maintain 2 such dbs. One of them has tens of millions of rows in some tables (this one is mssqlserver on some 2 year old 2 x quadcore). The other has millions of rows in one of the main tables. I run quite complicated search and update queries on that one (based on http requests). Performance simulations showed >40 of the most complicated search/update/insert_into_multiple tables combos per second on. While production is deployed on ok hardware (single quadcore), these performance tests were done on a fucking single ATOM 350 (dualcore) with nfs-mounted volumes (!!). No oracle magic either, just simple mysql innodb.

For reference: mtgox aggregated order book (acquired by fulldepth api call) currently has about 10,000 entries. Can't be more than 50,000 individual orders in the orderbook.

Maybe I'm missing something, but I still think I could do it on my nexus 4.

Anyone knows how Gox moves people's deposits around? If you use http://www.bitcoinmonitor.com/ , you would notice that whenever a trade is executed, a lot of transfers take place on the blockchain, in principle it should be just bookkeeping, no real transaction should happen.  I don't know why and if it has anything to do with their sluggishness.

Anyone who could answer my question?

[Piper67]

The fiat is back.

How do you mean?



I really don't understand why anyone would sell more than a handful of BTC at a time at the current price.  There is such obvious upwards pressure and willingness to buy at higher prices.

Oh well. Long live the $40 dollar range!

Just half a year ago, a dump like yesterday's would have taken weeks or months to recover from. Not bad, Bitcoin, not bad at all.

[mccorvic]

Just half a year ago, a dump like yesterday's would have taken weeks or months to recover from. Not bad, Bitcoin, not bad at all.

For sure. The pattern we've been seeing for the last two months seems to be 1. Bitcoin breaks into new $10 increment range 2. Some bears try really really hard to dump 3. Buyers snatch up low priced coins and price goes back to where it started 5. Everyone realizes that the demand at new range is for real and everyone buys as many coins as they can 4. Rinse and repeat

At the moment, it seems the pattern is repeating for $40. It'll be interesting to see if it continues. 

[Rampion]

Just half a year ago, a dump like yesterday's would have taken weeks or months to recover from. Not bad, Bitcoin, not bad at all.

For sure. The pattern we've been seeing for the last two months seems to be 1. Bitcoin breaks into new $10 increment range 2. Some bears try really really hard to dump 3. Buyers snatch up low priced coins and price goes back to where it started 5. Everyone realizes that the demand at new range is for real and everyone buys as many coins as they can 4. Rinse and repeat

At the moment, it seems the pattern is repeating for $40. It'll be interesting to see if it continues. 

So you think there will be no further correction today?

[zby]

Contemplating history:

http://bitcoincharts.com/charts/mtgoxUSD#rg10zigHourlyzczsg2011-06-01zeg2011-06-10ztgSza1gEMAzm1g10za2gEMAzm2g21zi1gMACDzi2gRSI
http://bitcoincharts.com/charts/mtgoxUSD#rg10zigHourlyzczsg2013-02-27zeg2013-03-08ztgSza1gEMAzm1g10za2gEMAzm2g21zi1gMACDzi2gRSI
http://bitcoincharts.com/charts/mtgoxUSD#rg10zigHourlyzczsg2011-06-04zeg2011-06-14ztgSza1gEMAzm1g10za2gEMAzm2g21zi1gMACDzi2gRSI

It seems this rally was more dramatic than 2011, and with a deeper initial plunge. The next few days/weeks are going to be interesting for sure.

Hmm the growth in the 10 days included on the chart in 2011 was from 10 to 30 - that is 3x - on the chart from 2013 the growth was from 30 to 50.  I think the first one was much more dramatic.

[mccorvic]

Just half a year ago, a dump like yesterday's would have taken weeks or months to recover from. Not bad, Bitcoin, not bad at all.

For sure. The pattern we've been seeing for the last two months seems to be 1. Bitcoin breaks into new $10 increment range 2. Some bears try really really hard to dump 3. Buyers snatch up low priced coins and price goes back to where it started 5. Everyone realizes that the demand at new range is for real and everyone buys as many coins as they can 4. Rinse and repeat

At the moment, it seems the pattern is repeating for $40. It'll be interesting to see if it continues. 

So you think there will be no further correction today?

The only correction will be upwards.

But no, I don't think the price will get below $42 or so again unless there is another huge jump up like yesterday. The demand for BTC at $45 is so real you'd be stupid to sell below it. Like, real dumb.

[Piper67]

Just half a year ago, a dump like yesterday's would have taken weeks or months to recover from. Not bad, Bitcoin, not bad at all.

For sure. The pattern we've been seeing for the last two months seems to be 1. Bitcoin breaks into new $10 increment range 2. Some bears try really really hard to dump 3. Buyers snatch up low priced coins and price goes back to where it started 5. Everyone realizes that the demand at new range is for real and everyone buys as many coins as they can 4. Rinse and repeat

At the moment, it seems the pattern is repeating for $40. It'll be interesting to see if it continues. 

So you think there will be no further correction today?

The only correction will be upwards.

But no, I don't think the price will get below $42 or so again unless there is another huge jump up like yesterday. The demand for BTC at $45 is so real you'd be stupid to sell below it. Like, real dumb.

There's no way of knowing, really. I think we may see a more pronounced weekend dip than in the last few weeks, simply because of the "OMG Bitcoin is crashing!"  effect. So I'm sending money into the exchange to be ready just in case 

[mccorvic]

There's no way of knowing, really. I think we may see a more pronounced weekend dip than in the last few weeks, simply because of the "OMG Bitcoin is crashing!"  effect. So I'm sending money into the exchange to be ready just in case 

I'll always be the first to admit that no one knows until we know That's why I don't try to pretend I know with stupid charts with MS paint lines drawn on them

I really don' think there is a "crashing" effect any more though. We're back at $45, which is higher than we started yesterday and even with all the wackiness of yesterday we ended up with a green bar on bitcoincharts.  Like I said, barring another flash up by $5 dollars or something, I feel we're back on track.

[Zangelbert Bingledack]

The price action today was in line with the exponential growth since January. For the first time, the price started growing even faster than that exponential trendline, and it quickly overcorrected to below the exponential trendline, then back onto the trendline. It simply got overexcited, then reverted to the norm.

We remain almost uncannily dead-set on that exponential curve that puts BTC at $50 by late March and $100 by the end of April.