No, this is the stage being prepared for the coming week. The rising price is exactly what Bitcoin needs right now, as all those people waiting in agony when their fiat hits the market are now primed to buy bitcoins immediately. From my own experience, I believe we have about nine hours until the first fresh fiat will hit the floor, so I wouldn't be surprised if we hit $200 within twelve hours.
There is 11 mega USD on bids, so if someone really wanted to buy NOW, he can, immediately. |
|
|
|
|
I HOPE that ASICMINER will soon move out of BTCGuild! It should set up its own pool and go "solo". Its unhealthy for the network.
|
|
|
|
|
The good news is that the market cannot CRASH on MtGox. It will land down .. very slowly .. like a feather ;-)
|
|
|
|
|
Gentlemen, punch your cards with bids and asks and mail or telegraph them to Tibane corp., Tokyo, Japan. Once processed, we will fax you the result of trade.
|
|
|
|
Last night I finally understood what's with the gox engine lag: ...
<MagicalTux> molec: we need to change the way users place orders to solve this
<molec> MagicalTux, in what way?
<MagicalTux> disallow users to place orders they can't fill
<molec> MagicalTux, +1. oh...
<molec> MagicalTux, it's dawning on me
<MagicalTux> and disallow users to withdraw balance required for open orders
<molec> MagicalTux, you have to trickle down the whole order list to set invalid/open status
<molec> MagicalTux, go do it!
<MagicalTux> right now each time a user balance change (trade, etc) we need to recheck all his open orders
...
I think that with proper data structures, one can link together the bids and asks of single user and immediately update "reserve" for the bid/ask after sell or buy. Funding and withdrawing are infrequent compared to trades. The structure can be held in memory, with commits to permanent storage. This should handle hundreds of trades per second, not a few, like it is now. Of course, this requires to avoid using normal relational databases, queries upon them, PHP code in server, etc. Also, the socket with trade data is sometimes overloaded, too. I am not a TCP/IP expert, but I cant see problem with cloning the data between multiple (in order of thousands) sockets open. This would solve all those disconnects on ClarkMoody, MtGoxLive, etc. An exchange, which cannot provide reliable and non-lagged data for its users, is .. unusable. Like that graph at the top of mtgox.com. Isn't it ironic that to trade at MtGox, or just watch it, you need to use third party tools? |
|
|
|
|
I do not care price, nor volume, I need some graph of MtGox lag! Seems its on its highs, today.
|
|
|
|
Lag is increasing again.
LOL, that kind of feeling .. of impact .. you can just sit and watch .. |
|
|
|
|
OK, please, could someone FAX me the current price? Something with less lag like MtGox has?
|
|
|
|
|
Mt.Gox LAG 7 minutes? Are you serious, really? For 0.6% of each trade? OMG.
Its like trading remotely on exchange located on MARS, right?
|
|
|
|
|
Just a question - what would happen if the split was catched too late, allowing to get 100 confirmation for split-mined block to mature? Does it play any role, or just even larger reorg, like several hundred blocks, is still doable (with not too harsh consequences)?
|
|
|
|
|
Ouch .. Bruce Wagner (remember?) just wrote on Twitter:
"I predict Bitcoin will break $100 within the next 4 weeks."
So, everyone SELL, SELL, SELL.
;-)
|
|
|
|
i'm calling 1k pages by the end of May.
Beware of some bears (with moderator rights), they may short the pages down to mere 100 in one quick nasty session! |
|
|
|
|
Filling that bottle with cold water could slow down heating of the whole box, too.
|
|
|
|
|
For solo mining with ASIC, I am not sure if getwork calls from bitcoind will suffice. You will need some STRATUM enabled pool deamon software.
|
|
|
|
|
I guess that recent surge is due to increased popularity of Satoshi Dice between Bitcoin-vanilla gamblers.
|
|
|
|
Sorry folks, but 4199 + 1 = 4200, not 5000. Return back to school.  |
|
|
|
|
Show Posts
