Bitcoin-Central, first exchange licensed to operate with a bank. This is HUGE

[Rassah]

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

[paraipan]

...
Just don't ever drive a Peugeot.

... 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.

[molecular]

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.

[davout]

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.

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.

[jl2012]

I will register as soon as you get the debit card

Actually, a real Bitcoin debit card (not the prepaid credit card that BitInstant calls a debit card...) would be awesome.

That is, balance is always in Bitcoins; deposit cash at an ATM to "buy" bitcoins automatically, or withdraw/spend it to "sell".

Davout, the site mentions a lack of fees to deposit MtGox codes, but I don't see any way to actually do it?

We're going towards a dual debit card, with EUR and BTC balances spendable.

Depositing MtGox codes is on our roadmap, (it's also technically developed) but we haven't rolled it out yet. We need to figure out the proper way to accept them without relying too much on MtGox. We would be in deep sh*t if we were holding a massive balance at MtGox and it suddenly went under. We will do it, but we will do it the right way, probably something along the lines of "Paymium takes the risk of a MtGox default by actually buying your code for EUR/USD when you deposit it". You see the problem ?

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

[molecular]

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.

[davout]

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.

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

[molecular]

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.

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

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

[molecular]

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.

[davout]

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.

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

[2weiX]

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.

[molecular]

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.

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

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.

[Dusty]

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.

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)

[gyverlb]

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.

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)

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...

[davout]

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

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.

it should be possible to change an order, lest the new order should get a new, larger ID.

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

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

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.

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.

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

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.

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)

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.

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)

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

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...

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

[2weiX]

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.

[davout]

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

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

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

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)

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).

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.

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.

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.

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.

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

[molecular]

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.

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

Thanks for putting that smiley, otherwise I'd be mad now .

Again, I support what 2weiX said. I'm missing this kind of transparency on MtGox: Tell users exactly how the trade matcher works in a language everyone can understand (english maybe, not SQL/python/whatever). Telling people to go read some source that might or might not be what's currently being used on the site is not sufficient and doesn't say anything about wether or not the policies of the trade matcher will remain like that.

Apart from the details 2WeiX requested in his last post, there are other details that might be interesting, for example: Can a bot pull orders while an order (say big dump) is being executed and will the bot receive updates "on the way down" and get a chance to react or is that huge order executed atomically with noone being able to interfere?

Please, I urge you to stand out and be better than Gox in this regard. Btw: You're currently better than MtGox at customer support as far as I can tell (although it might not be indicative of what happens once you gain a larger customer base).

The trading aspect of your endeavour might not be your highest priority (I don't know), but I would really love to see you guys do it "right" from the beginning.

[2weiX]

Please, I urge you to stand out and be better than Gox in this regard. Btw: You're currently better than MtGox at customer support as far as I can tell (although it might not be indicative of what happens once you gain a larger customer base).

+ OVER NINE THOUSAND

[davout]

Tell users exactly how the trade matcher works in a language everyone can understand (english maybe, not SQL/python/whatever).

Well, ask and you'll be answered.

Telling people to go read some source that might or might not be what's currently being used on the site is not sufficient and doesn't say anything about wether or not the policies of the trade matcher will remain like that.

It's still a good indication, and a good incentive for the operator to have a zero-bullshit policy

Can a bot pull orders while an order (say big dump) is being executed and will the bot receive updates "on the way down" and get a chance to react or is that huge order executed atomically with noone being able to interfere?

It will be executed atomically thanks to MySQL transactions now, and it will remain that way because I'm going to roll-out functionality that will queue everything and execute all jobs in an asynchronous fashion.

Please, I urge you to stand out and be better than Gox in this regard. Btw: You're currently better than MtGox at customer support as far as I can tell (although it might not be indicative of what happens once you gain a larger customer base).

We do as best as we can, and frankly, I think that being better at customer support is the best way to grow.
I don't really like doing it, but it still makes me a little fuzzy inside when people give you nice words for helping them without them having to wait a week.

The trading aspect of your endeavour might not be your highest priority (I don't know), but I would really love to see you guys do it "right" from the beginning.

We strive to do things right since 2010