Topic: Bitcoin-Central, first exchange licensed to operate with a bank. This is HUGE - page 15. (Read 191876 times)

Yup, I'm really interested in feedback from people that have this kind of professionnal background.

Yes, that's how BC is designed to work, except for the IDs serving the purpose of timestamps. (and having the additional advantage of being absolutely unique unlike timestamps)

Yep, absolutely, I don't really reason in terms of older or younger orders for that matter, I reason in terms of "which order is the one being executed, and which one is the order being executed against" but it has the exact same practical implications.

Say you post a bid with a 10 EUR limit, no asks. Nothing happens during the execution.
Someone else posts a bid @ 9.9 EUR, nothing happens since no matching orders are found during the execution.
Someone comes along and posts an ask with a 9.5 EUR limit, that's the order that's being executed, it first executes against the first bid, the trade is settled at 10 EUR/BTC, if it isn't filled it will continue execution against the other order at 9.9 EUR/BTC.
Now if it's still not filled it remains by itself in the order book.
Now say someone posts a bid with a 11 EUR/BTC limit price, then it will execute at 9.5 EUR/BTC against the only remaining ask in the order book.

If multiple orders are at the same price, the older ones get filled first.

If it doesn't work that way then it is a bug.

We don't offer this feature. The way I see it is that if you change your mind about your order size you lose your spot in the queue.

The last published version of the TradeOrder class is 299 LOC long.
The code that is responsible for automatically testing it, and preventing regressions is 924 LOC long.
The code to test ratio is almost 3. Care was taken. And better, anyone can go check it out independently on github.

Hope that answers your questions

hi, let me specify.

coming from a stockbrokers point of view, the way how, when and in which order orders are filled is essential for a working market.

orders should be filled according to price.
orders at the same limit should be filled in the order of their timestamp, oldest first.

if one order encounters an older order on the other side of the order book, the execution price is that of the older order.
if the older order is filled completely and the younger order meets another, older order, the limit of the oldest order at the next best price will be the next execition price (etc etc).

it should be possible to change an order without it losing its timestamp.
however: if the limit of an existing order is changed or the size of the order is increased, it gets a new timestamp.

all these rules (or different ones for all i care) should be laid out in public and carefully programmed into your system to avoid disputes.

It's not possible to change an order for a user, if you wish to do so you may cancel it and re-enter an other one.

That's easily achieved by cancelling it and re-entering a new one.

I'm not quite sure about what you're asking. Could you be more specific ?
There are fees, these are public, and that's pretty much it.

The source for Bitcoin-Central has been closed for a while now, but the trading engine code hasn't really changed, so anyone can go have a look for themselves on github

When your primary key is an auto-incremented integer you have a clustered index, meaning that the data is stored on disk according to the order of the index, in this case it's the PK.
So it's always going to be easier for MySQL to return data ordered on the ID. So, oldest orders will always show first in the list since their ID will always be smaller the newer orders.
But it is true that even this behaviour is observed by experience, its not guaranteed by the RDBMS, so point taken, I'll add an explicit ID ordering

I think I'll be fine, I spent countless hours fiddling with the InnoDB configs to tune much larger sites than Bitcoin-Central, and there's no way I'd give that kind of fun up :p
And I don't write SQL anymore, I leave that to frameworks (well, I still keep an eye on the way transactions are handled and run everything with the SERIALIZABLE isolation level).
I'm still hoping that at some point I'll have so much work that I'll have to call you

Daveout, when you get at a point where you need help with your database (and if you are successful you most probably will), feel free to contact me: I own a company based in France and you would not be the first company I help with MySQL scaling problems... We don't take Bitcoins for the moment, but I hope you will help make this a viable option in the future 
In the meantime a free advice: don't use any MySQL-specific SQL in your code, for some usage patterns migrating away from MySQL can be the only sane solution. Cleaning SQL code, migrating triggers/procedures is a nightmare...

From my experience (and also from specifications) that's not true: if you want ordering on the primary key you have to specify it.
If you don't specify any ordering then you can receive any order is easier for the dbms, and that's usually the order in which they are stored on disk: this depends on the history of insertion/deletion on that table (or db)

Personally I don't care much, but I think 2WeiX has a point. You should probably check the sources and publish your findings in the FAQ or somewhere on the site for sake of transparency.

so what if I want to *change* an order?
is that possible without deleting the old order?

it should be possible to change an order, lest the new order should get a new, larger ID.
the "new" order should get a new ID *only* if the limit is changed or the size is INCREASED.


you (imvho) carefully consider and then publizise your pricing model.

I don't really know about the specifics of your particular order, but we don't distribute the volume accross orders, oldest orders should get filled first.
When we execute an order we get a collection of matching orders ordered by descending price, there is no actual constraint on the time the order was placed, but MySQL will still implicitly order on the primary key column which is an auto-incremented integer. In other words oldest orders should get matched first.

Let me know if you want to have a look at the source

I have a question about the order matching algorithm.

• I had placed an order (volume 10 BTC, price: €10.10). There was no other order in the book at that price at the time.
• Later I saw over 90 BTC on that price.
• The order got partly filled (5.78 BTC traded 12/20/2012 07:13)
• Currently there are about BTC 70 on at €10.10

Now I don't know how much volume was traded at that time and price, but I'm suspecting that you handle matching of orders at the same price differently from how MagicalTux does it? Namely: distribute the volume across all orders at that price (how?) instead of filling the orders in sequence of submission. Of course it's possible that my order indeed got filled first and only 5.78 BTC have been traded @ €10.10 and someone cancelled an order (to get back down to BTC 70).

I don't know which method I find better, but it'd be nice to know how the order matching actually works.

ok, did so: bitcoin-central.net - usability suggestions and feature requests

Maybe you can start one in the Service Discussion board with these interesting suggestions !

Is there a thread for suggestions regarding the site? I have some:

• Order book asks and bids could be on one page, not 2 separate pages. Own orders could be highlighted
• Favicon could be changed to something that doesn't look like every other bitcoin-related site.
• The market depth graph could have a text-popup displaying some info.

Possible solution for MtGox default risk:

1. Provide free MtGox code withdrawal

2. Arbitraging between MtGox and Bitcoin-Central. Since you don't need to pay transaction fee for your own part, a small price difference would cover the transaction fee or even profit

That's not available yet, it's a project that is in the pipeline on the bank's side, we have no precise ETA, but we know it should be rolled-out in a couple-of-months-ish.

Hm, did I read somewhere I would get my own IBAN in my Name after verifying my account?

My account is verified, but when clicking "deposit", it still gives me the "general" account info of paymium to transfer my EUR to.

... in Romania

/off topic


I admire you determination Davout and will surely follow the example.

Hope we can make a similar announcement from Spain in a couple of weeks.

The French also invented Daft Punk, so I hope this exchange can also trade it harder, better, faster, stronger!

Ahaha. My Kaaba rock.

But seriously now, I take it all back, there's nothing wrong with French tech. They invented the kiss after all, how bad can it be.

Just don't ever drive a Peugeot.

I see what the big deal is, but I also agree that eventually someone was gonna do it.

Your what?