Bitcoin Forum

I'm currently in discussion with a colleague of mine in the formation of a new currency exchange with the specific intention of having little to no lag.

The idea is that it would have two markets, one with api access so bots can use it and the other without so people can use it, these would be on two separate servers. This would allow people to execute trades without lag in the slightly less efficient no api market even when a market panic is in progress. Arbitrage will keep both markets fairly close with a mild inefficiency in the no api market which would be like a fee for ease of execution (this would likely only  ever come about during a panic).

To sum up one market with bots which may lag, one without which may be mildly inefficient (this can be seen as a fee for speedy execution in times of panic).

Thoughts?

How do you enforce the "no bots" market?

There a number of methods but captchas would be an option, a mild annoyance though.

This.... it is trivial to script interaction with any web page.

Also, it is not the bots that are the issue, it is the shitty trade engine that allows unfunded orders.  If you throw that out and only allow fully funded orders you should be able to build something that an handle 10,000x the traffic of MtGox's current engine.  They are rumored to be testing an engine that does exactly that to be released soon, but we don't want to rush them when they already have a hard enough time doing proper QA.

Yeah unfunded orders are ridiculous and there customer service is appalling. They also seem to not have a clue how there actions effect the market both in terms of bitcoins price (to a lesser extent) and faith in its own ability to protect investors funds.

I would like to see a "Discrete Double Auction" style exchange, as described here:
http://www.247btc.com/bitcoins/134/how-i-would-manipulate-the-bitcoin-exchange-market-and-how-a-discrete-double-auction-could-stop-me/

It sounds much easier to build and manage compared to a full real-time exchange, and it seems it would be immune to most of the lag problems that plague regular exchanges.

Okay, I'll give you that would put a kink in scripting it, but see above about it being irrelevant.  Other markets handle much larger volume quite easily because they assume all orders are funded and don't require scanning all of a user's orders for now funded ones each time they are involved in a trade.

Arbitrage between the two markets would require a human. Do you expect that to be a problem?

Also: running an exchange involves a lot of ground work. It means creating bank accounts and legal entities. It means exposing yourself enough that people are willing to trust you with their money. It means complying with the AML/KYC laws in your country, or risking legal trouble if you don't. It means building robust security - professional-tier, not single-weekend hacks.

Are you willing to make that commitment?

As for the human element probably not except in periods of high automated activity. People are very willing to arbitrage for free money even without bots, but during lag on the bot market the risk would be high creating a limit to arbitrage.

Cant say, depends on if its worth the investment and that depends on getting the right people interested in terms of legal personnel, coding personnel and capital investment. I have people in mind for all of them but it could be that this whole idea ends over the next couple of weeks with nothing, I'm currently just fact finding.

People should be allowed to execute trades whenever they want even during times of financial stress, humans can still put orders on either market so they are just gaining an option.

I don't get it, what's so hard about keeping track of the unfunded orders ? They don't come into play until the price reaches their level, at which point you can check the account balance before commiting the trade. As for updating the visual state of the order in the browser, you can do that by scanning all orders every few seconds, not at each and every trade.

On the face of it, this seems like a problem that a single InnoDB transactional engine could do at a few orders of magnitude faster than mtgox is moving. You only need a few tables to handle the users and orderbook, and simple queries. Binary logging for backtraking, battery backup for the main storage for instant commits and you are NASDAQ. It's really not that of a complex problem.

The only contention point is at the market server, all else can be load balanced and parallelized. If you DDoS the front end there's absolutely no reason for the market server to lag - it's sits on a separate firewalled machine for layered security, as does the withdrawal bot holding the hot wallets and bank passwords. Don't waste my time with captchas, stick a minimal fee on each trade and HFT is impossible. All other bots are good and provide liquidity.