Wall Observer - MtGoxUSD wall movement tracker

[adamstgBit]

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.

what if you sold 10 coins every 10 mins?

do you think you'd get a better price?

[1714775137]

1714775137

[1714775137]

1714775137

[1714775137]

1714775137

[1714775137]

1714775137

[1714775137]

1714775137

[BitcoinTate]

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.

Sell em! I need to buy back into BTC in the mid 30s lol!

[robocoin]

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.

Consider selling otc when its time. Less slippage, more boat.

[lebing]

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.

Consider selling otc when its time. Less slippage, more boat.

awesome avatar lol

[BTCdude007]

The best thing that can happen for bitcoin stability is that the price bounces around in the 40-45 range for a couple of weeks. This will
make a great base for the next leg up.

[adamstgBit]

The best thing that can happen for bitcoin stability is that the price bounces around in the 40-45 range for a couple of weeks. This will
make a great base for the next leg up.

if the price starts to show signs that its over priced (ex every time we get close to 50 it crashes hard) the market will start heading down...

[thezerg]

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.

Changing the physical technology gets you a bit of an improvement, but its nothing like chunking 100 or even 1000 trades in a single database commit.  And askgar you're right non-relational databases are much better suited.  But you are STILL ultimately stuck with a transactional write to geographically redundant physical media.  Even with SSDs this is orders of magnitude slower then every other part of the trade matching engine.  And so you are back to chunking multiple trades in a single commit.

[crazy_rabbit]

The best thing that can happen for bitcoin stability is that the price bounces around in the 40-45 range for a couple of weeks. This will
make a great base for the next leg up.

+1

[mccorvic]

The best thing that can happen for bitcoin stability is that the price bounces around in the 40-45 range for a couple of weeks. This will
make a great base for the next leg up.

if the price starts to show signs that its over priced (ex every time we get close to 50 it crashes hard) the market will start heading down...

So, if it goes up to much, it's gonna crash.

If it doesn't go up, it's gonna crash.

If it goes down, it's gonna crash.

Bears: Trying to claim every possibility as a victory.

[only]

Someone crash it already.

[David M]

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.

Changing the physical technology gets you a bit of an improvement, but its nothing like chunking 100 or even 1000 trades in a single database commit.  And askgar you're right non-relational databases are much better suited.  But you are STILL ultimately stuck with a transactional write to geographically redundant physical media.  Even with SSDs this is orders of magnitude slower then every other part of the trade matching engine.  And so you are back to chunking multiple trades in a single commit.

I find it very hard to believe that the database is the problem.  The volume on Gox is too small to peg any of the RDBMS on the market.

Hell, on a box a quarter the size of the Gox's, I have client producing 600 uniques attributes a second across a 400 table 6NF schema.

As for geographic redundancy, log shipping shouldn't add too much delay.

[robocoin]

'only', you can use my old avatar. But it's irritating me. idk At first sight I thought somebody gained access of my account. lol

[only]

'only', you can use my old avatar. But it's irritating me. idk At first sight I thought somebody gained access of my account. lol

I'm in love with it. Are you a bull or a bear, btw?

[mccorvic]

'only', you can use my old avatar. But it's irritating me. idk At first sight I thought somebody gained access of my account. lol

I'm in love with it. Are you a bull or a bear, btw?

Is this the new version of a/s/l? a/s/BorB?

[only]

lol

[thezerg]

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.

Changing the physical technology gets you a bit of an improvement, but its nothing like chunking 100 or even 1000 trades in a single database commit.  And askgar you're right non-relational databases are much better suited.  But you are STILL ultimately stuck with a transactional write to geographically redundant physical media.  Even with SSDs this is orders of magnitude slower then every other part of the trade matching engine.  And so you are back to chunking multiple trades in a single commit.

I find it very hard to believe that the database is the problem.  The volume on Gox is too small to peg any of the RDBMS on the market.

Hell, on a box a quarter the size of the Gox's, I have client producing 600 uniques attributes a second across a 400 table 6NF schema.

As for geographic redundancy, log shipping shouldn't add too much delay.

Its just an informed guess on my part derived from writing the Gox stream to a RDBMS.  When you say "producing 600 unique..." it sounds like you are telling me about reads.  These can be cached, etc and so respond much faster... I can also run complex queries rapidly across the Gox data I've written to my RDBMS.

But transactional writes cannot be cached -- by the nature of a transaction they need to be written to persistent backing storage before they are acked.  And of course its very important to commit a trade as a transaction so there is no chance that person A spends his $ or BTC but person B does not receive it.  So essentially the DB performance is chained to the latency speed of the disk -- the time to "seek" and write a few bytes.  But because the time to seek and write a few bytes is not much > then the time to seek and write 10k bytes, if the application chunks multiple operations into a single txn you get massive speedup.  So even with writes its not the RDBMS, but HOW it is used.

Anyway, this is just a theory... but just watch Gox unwind a big market buy, ticking through 100's of .1 btc asks at a human readable speed and it becomes pretty obvious that each trade is handled individually.  This causes all kinds of problem with efficient price discovery, like "fake" walls.  Basically, it looks to me like a bot can use a bunch of .00X btc asks to slow down a big buy and use the time to take down the wall before the buy ticks up to it.

[fabrizziop]

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.

Changing the physical technology gets you a bit of an improvement, but its nothing like chunking 100 or even 1000 trades in a single database commit.  And askgar you're right non-relational databases are much better suited.  But you are STILL ultimately stuck with a transactional write to geographically redundant physical media.  Even with SSDs this is orders of magnitude slower then every other part of the trade matching engine.  And so you are back to chunking multiple trades in a single commit.

I find it very hard to believe that the database is the problem.  The volume on Gox is too small to peg any of the RDBMS on the market.

Hell, on a box a quarter the size of the Gox's, I have client producing 600 uniques attributes a second across a 400 table 6NF schema.

As for geographic redundancy, log shipping shouldn't add too much delay.

Its just an informed guess on my part derived from writing the Gox stream to a RDBMS.  When you say "producing 600 unique..." it sounds like you are telling me about reads.  These can be cached, etc and so respond much faster... I can also run complex queries rapidly across the Gox data I've written to my RDBMS.

But transactional writes cannot be cached -- by the nature of a transaction they need to be written to persistent backing storage before they are acked.  And of course its very important to commit a trade as a transaction so there is no chance that person A spends his $ or BTC but person B does not receive it.  So essentially the DB performance is chained to the latency speed of the disk -- the time to "seek" and write a few bytes.  But because the time to seek and write a few bytes is not much > then the time to seek and write 10k bytes, if the application chunks multiple operations into a single txn you get massive speedup.  So even with writes its not the RDBMS, but HOW it is used.

Anyway, this is just a theory... but just watch Gox unwind a big market buy, ticking through 100's of .1 btc asks at a human readable speed and it becomes pretty obvious that each trade is handled individually.  This causes all kinds of problem with efficient price discovery, like "fake" walls.  Basically, it looks to me like a bot can use a bunch of .00X btc asks to slow down a big buy and use the time to take down the wall before the buy ticks up to it.

If that is true then why they don't get really nice SSDs and place them in RAID1?. They are already making a ton in fees.

[qwk]

If that is true then why they don't get really nice SSDs and place them in RAID1?. They are already making a ton in fees.

Because tossing hardware at the problem will not solve it. You may find equipment that performs 10x faster, but that's it. The performance problems we're talking about are probably in the 1000x range.

[David M]

Its just an informed guess on my part derived from writing the Gox stream to a RDBMS.  When you say "producing 600 unique..." it sounds like you are telling me about reads.  These can be cached, etc and so respond much faster... I can also run complex queries rapidly across the Gox data I've written to my RDBMS.

Not reads.  Writes (update & inserts).  I use the word "unique attribute" to ignore the composite keys.

But transactional writes cannot be cached -- by the nature of a transaction they need to be written to persistent backing storage before they are acked.  And of course its very important to commit a trade as a transaction so there is no chance that person A spends his $ or BTC but person B does not receive it.  So essentially the DB performance is chained to the latency speed of the disk -- the time to "seek" and write a few bytes.  But because the time to seek and write a few bytes is not much > then the time to seek and write 10k bytes, if the application chunks multiple operations into a single txn you get massive speedup.  So even with writes its not the RDBMS, but HOW it is used.

Agreed.  But any half arsed SATA (or probably IDE) drive should not blink at the tps produced by Gox.

But it all depends on the db logical-to-physical mapping...

Anyway, this is just a theory... but just watch Gox unwind a big market buy, ticking through 100's of .1 btc asks at a human readable speed and it becomes pretty obvious that each trade is handled individually.  This causes all kinds of problem with efficient price discovery, like "fake" walls.  Basically, it looks to me like a bot can use a bunch of .00X btc asks to slow down a big buy and use the time to take down the wall before the buy ticks up to it.

I reckon it is the front end matching algo implementation that is screwing performance.  I hazard a guess they are suffering lock/threading issues.

[miter_myles]

This just hit my news feed:

http://www.wired.com/wiredenterprise/2013/03/digital-thieves-pull-off-12000-bitcoin-heist/

Hackers Pull Off $12,000 Bitcoin Heist