|
haha, lol. "I called Vladimir this morning and he didn't even pick up the phone.". This shit cracks me up, especially how he's given up all hope and now mines LTC.
Great stuff.
|
|
|
|
With the transition of North American customers to Coinlab, are they still going to use the same trading engine (in Tokyo?)? If all these orders will be done on a new engine in the US, this could drastically reduce the pressure on the current system. If so, when will this transition happen?
I can't imagine them running 2 markets. That doesn't make sense. I guess not, but when Coinlab customers are able to get their dollars on the trade floor within 30 minutes through Silicon Valley Bank, this is gonna weigh on their engine. Then I can imagine that MagicalTux really has to work on a tight schedule. I wish him all the best pulling this of! They can (and should) just maintain a central order book where all orders present are sure do be fully covered (see my previous comment), and have the two "brokers" independantly insert orders into it. This (and your previous description about maintianing 2 balances) is effectively what this change is about. No need to demand it, Magicaltux is on it. Wether or not he will use your implementation idea is up to him. |
|
|
|
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?Absolutely agree with you. I've been long enough to know that bitcoin and exchanges are not the same thing but I can't help to think that this market got too big for what the infrastructure really is. It's just not there yet. And that is exactly the reason why this change on the infrastructure is being made. It's debatable wether or not this could be done with the same order behaviour. mtGox decided to change the order behaviour to make the engine perform better. That's ok with me as long as it actually solves the issue and I know about it beforehand. |
|
|
|
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?
According to MagicalTux (and I can actually believe what he says there), it's not the socket.io/websocket that lags. It's actually "realtime", it's the engine that can't cope with the amount of trades. |
|
|
|
We need to pay attention especially to a rapid price movement scenario, when people will be trying to issue orders desperately, and may never bother to check on their balances, and Gox's UI irresponsiveness only adds salt to the injury, as people will try to issue more orders when they can't see their orders showing on the list. The more orders people issue, the greater the lag, which would make people more anxious and making more vain efforts, which in turn causes even more lag. This vicious closed-feedback loop causes the ridiculous 10-minutes lag we saw on a weekly basis.
The idea is that this change will do away with the lag problem. So the UI will hopefully be responsive. |
|
|
|
I think it may sink below $70 tonight, and then it's ooooonnnnn!  Good luck with that lol. Thanks, smoothie.  Don't know about you -- but I was quite jittery going into Thursday; I took some profits at $90 and missed out on the top, but then was able to re-buy in at the bottom. The market responded very well to what was clearly an organised assault by people speculating in LTC. Before I thought we were starting to look shaky at $90; however given the jump back up, just prior to what was looking like a shaky long weekend with weak buying pressure, I think we look much stronger. The floor is much higher and stronger than expected, and I think we will now have a sideways correction at this level for a few days as confidence fully returns. Organized assault on people speculating on LTC?  WTF! Do you have any idea on how stupid that sounds? Organized assault actually makes sense. Slam-down was coordinated with ddos on mtgox and other exchanges. The thing about LTC I don't understand. |
|
|
|
With the transition of North American customers to Coinlab, are they still going to use the same trading engine (in Tokyo?)? If all these orders will be done on a new engine in the US, this could drastically reduce the pressure on the current system. If so, when will this transition happen?
I can't imagine them running 2 markets. That doesn't make sense. |
|
|
|
Does it also mean that ask side is also working the same way? So this is also bearish?
The situation I described had bearish result (rising market, no more auto-opening of bids => perceptively less bids). The other way around has bullish result: in a crash or falling market no more auto-opening of asks => ask side looks less impressive. So if I judge this right, it could dampen the moves (up and down). But keep in mind: this is mainly by perception. If people judge this correctly, it should not have much impact at all. EDIT: just thought again: of course the order-book will be thinner, maybe this could mean that rebounds will be even quicker. |
|
|
|
Last night I finally understood what's with the gox engine lag: <MagicalTux> sturles: if you need realtime data, use socket.io <molec> MagicalTux, "realtime" ;-) <MagicalTux> molec: socket.io feed is actually realtime <molec> MagicalTux, so it's the engine that can't cope? <MagicalTux> right now, yep <MagicalTux> because it needs to do too many checks <MagicalTux> we are working on changing the way all this works <MagicalTux> but it needs a *lot* of changes <molec> MagicalTux, I think you're doing something wrong. I can't see why it's hard... what's the reason? <molec> MagicalTux, might be my ignorance, but I did quite a few dbs. I might be overlooking some problem,... maybe security-related? <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<molec> MagicalTux, I see. and that gives you concurrency issues like hell <MagicalTux> we're working on solving this, but changing the way the site works need to be done right <MagicalTux> so we're doing a lot of tests first <molec> MagicalTux, I agree. don't haste <MagicalTux> well <MagicalTux> we need to haste, because current volumes cannot be handled anymore by current engine <MagicalTux> we made it faster (no more 30min delays), but it still has troubles with large moves What this means is: you can't have any order in the book that aren't backed by funds. Currently "un-backed" orders will have status "invalid" and wont show in the public order book, but they can exist and once funds become available to back the order, it will change its status to "open". What are the implications of this?Currently, in a uptrend market like we have had for a long time, when price rises and people who have invalid bids get their asks filled, fund become available and (some of) the bids of that user appear automatically in the orderbook. As I see it, this mechanism is rather bullish, because it keeps the bid-side of the book nicely filled up. Once these invalid order cannot exist any more due to the change, the bid-side will not fill up like that any more. This might be interpreted by the market participant as a weakness of the bulls, especiall if the participants are not yet fully aware of the change. On the bright side: we can expect the trading engine to perform much better. |
|
|
|
so this is it right, the last drop b4 we bust up and over 100$  I think there might be a double smack-down this time. Next one on sunday night CET. |
|
|
|
I do not care price, nor volume, I need some graph of MtGox lag! Seems its on its highs, today.
just caught a few sentences of Magicaltux about this: he's rebuilding the engine. The current lag problem is "by design": allowing users to have orders without necessary funding, because that means you have to trickle down order status updates when a users balance changes. It seems makes sense: a lot of fight between threads reading and writing to/from the orderbook table. So the change is to disallow users to place orders they don't have the funds for and disallow withdrawal of funds allocated to orders. What might the implications of this change be? |
|
|
|
I just want to bump this as the loans I am adding are not showing
i think thats because of merging on the table to save scroll space remove the grouping so we can see clearly  |
|
|
|
Ah Just woke up will be sending soon with shipping info!! take your time |
|
|
|
It appears that the market just gets a bit scared of heights sometimes
those are true words, man. that's the only things holding bitcoin back: disbelief. Disbelief that it can really be what it promises to be: one hard liquid world money. |
|
|
|
This crash lasted what, less than a hour?
You can call it whatever you want. .... I care about profit. which currency do you measure profit in? |
|
|
|
gox, stamp, camp, and btc-e are all showing different prices...by multiple dollar amounts
gox is shooting itself in the knee by not getting their shit together. |
|
|
|
Doesn't seem to be much to worry about unless the $75 floor is broken.
was hoping for $65, but bought back in @78. |
|
|
|
I think that I have discovered a vulnerability related to the Casascius Public Keys.
Each Casascius coin has printed a Public code made of 8 characters, for example this 1GdySJP4.
This code is a FirsBits address that resolves to 1GdySJP4RvRPQydyJVavKKuwtNaTvxaa4C.
Checking the public code is the only way of prooving that a coin has not been opened (apart of the hologram).
Thats no vulnerability. The hologram is destroyed when pealing it off. If you can manage to peel one off and fix it back on, then you have found a vulnerabitlity. Then I also don't need to have squatted the firstbits, I can just take the bitcoin after I've sold the casascius. Also: Casascius sends out a list of the coins addresses to each customer when he mails the coins. I usually pass these on as a reseller to my own customers. He also publishes lists of these Addresses. Those sources should be used to check the balance of a coin... not firstbits. |
|
|
|
Hi, I would like to buy 3 coins edit: (I need shipping to Australia, so please PM if extra is required) Thanks molecular, received today - they look amazing! pleasure doing business. happy your happy |
|
|
|
|
Show Posts
