Wall Observer - MtGoxUSD wall movement tracker

[justusranvier]

$100 by the end of April.

Second half of August.

[Wekkel]

Its slow today in price. May dip to high 30-ies again for some profit taking.

[humanitee]

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!

The graph I linked shows the total amount of fiat on the order book and the total amount of Bitcoin on the order book.
The spike down on the end of the blue line shows yesterdays panic, the liquidation took a large chunk out of the available fiat. The fiat was feeding the rally, and it's back to all time high territory.

[mccorvic]

Hehehe. $44 is dead. Long live $45.

[robocoin]

After the huge dump, it feels easier to convince friends to invest long term. Expectations just got raised. 

[samson]

Hehehe. $44 is dead. Long live $45.

Seems to be hotting up, I wonder how long it will be until MtGox goes bad again.

[mccorvic]

Hehehe. $44 is dead. Long live $45.

Seems to be hotting up, I wonder how long it will be until MtGox goes bad again.

Not very long at all, it seems. Bitcoinity already has a 25 second lag warning.

[Piper67]

Hehehe. $44 is dead. Long live $45.

Seems to be hotting up, I wonder how long it will be until MtGox goes bad again.

Not very long at all, it seems. Bitcoinity already has a 25 second lag warning.

There it is... I swear I could reach across the ocean and slap Karpeles across the back of the head!

[oakpacific]

Hehehe. $44 is dead. Long live $45.

Seems to be hotting up, I wonder how long it will be until MtGox goes bad again.

Not very long at all, it seems. Bitcoinity already has a 25 second lag warning.

There it is... I swear I could reach across the ocean and slap Karpeles across the back of the head!

And when you get back you will find out you trade is just about to be executed.

[naima53]

.....
Something visually similar ...
http://fc01.deviantart.net/fs71/f/2009/362/a/a/ouroboros_pack_by_Anarchpeace.jpg

lol... Just a correction. It is quite predictable.

[thezerg]

Gox's trade matching engine is fundamentally broken.  Anyone who has worked with databases under real load knows that as load rises you need to chunk multiple operations in a single transaction since a transaction commit involves a disk seek and write (10ms) and a network operation (to replicate the transaction to the backup(s)).  But Gox persists in matching executing and committing every single tiny btc txn independently (or so it looks from the feed).  

They need to either solve this scalability issue by combining multiple DB operations in a single transaction OR (potentially as a stopgap) change their fee structure to discourage sub-dollar transactions.  Especially since it seems like these bids are being used to slow down and obstruct normal market price discovery.  In other words, if you put 10000 .00001 BTC bids at 44 (say) and it takes Gox about 1/10th of a second to process a sale, you've managed to put a 1000 second time wall between 44.1 and 43.9.

[mb300sd]

If disk is gox's bottleneck, get some damn SSDs already! Yesterday's profits alone would buy a multi-TB RAID

[naima53]

If disk is gox's bottleneck, get some damn SSDs already! Yesterday's profits alone would buy a multi-TB RAID

No! There are significant issues (problems) of data recovery (using SSD drives)

[naima53]

....
In other words, if you put 10000 .00001 BTC bids at 44 (say) and it takes Gox about 1/10th of a second to process a sale, you've managed to put a 1000 second time wall between 44.1 and 43.9.

This is similar to the vulnerability. Hmm, I did not know about it, I think now they have to change a few things on their website ...

[qwk]

Gox's trade matching engine is fundamentally broken.

Agreed.

They need to either solve this scalability issue by combining multiple DB operations in a single transaction OR (potentially as a stopgap) change their fee structure to discourage sub-dollar transactions.  Especially since it seems like these bids are being used to slow down and obstruct normal market price discovery.  In other words, if you put 10000 .00001 BTC bids at 44 (say) and it takes Gox about 1/10th of a second to process a sale, you've managed to put a 1000 second time wall between 44.1 and 43.9.

Aside from a technical solution, i'd also propose the much quicker to implement, economic solution:
Fixed fee per transaction, 0.001 btc per bid or something like that.

They could even allow bots without fixed fees but skip their transactions once there's too much traffic.

I already suggested that in 2011 and nobody ever listened to me
Well, why would they?

[molecular]

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

I wrote that once somewhere as a joke.

[askgar]

If disk is gox's bottleneck, get some damn SSDs already! Yesterday's profits alone would buy a multi-TB RAID

IF Gox is using a Relational Database that will be their bottleneck, I'd hope they are using a more sensible database system though, there are many non-relational systems much more suited to the job.

[mccorvic]

I blame Mt.Gox lag for the lack of stickyness of $45! Grrr

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

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?

No. The trade engine doesn't concern itself with the blockchain

[Aseras]

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.

One person with a few thousand coins could tank the price if they dropped them all.

If I sold every coin I had ( actually considered it, looking to buy an RV or a house ). I could probably drop the price into the mid $30 range.