Intersango exchange (formerly Britcoin)

[sonba]

My money arrived at Barclays, today (asked for it on the 14th not on the 13th, though). Thanks, genjix!

[1714166084]

1714166084

[1714166084]

1714166084

[1714166084]

1714166084

[1714166084]

1714166084

[1714166084]

1714166084

[1714166084]

1714166084

[genjix]

Yep, it's a block of payments on the 13th that we're having trouble getting access to. Trying to fix that.

I had to write this document for phantom & the new exchange we're all working on. You might all find this info useful:

==============================
How does order matching work?
==============================

When you place an order, it goes into the orderbook. Every new order is umarked
at first. It just gets filed to be processed.

Every minute, cron kicks in and starts processing the orders. Each matched order
is marked with a flag indicating that it's been processed.

For each order that is processed, we look to find other equivalent orders which
are open, want the currency we own, have the currency we want and have a rate
equivalent to or better than us. Looping through the matching orders with no
ordering (we plan to fix that) we try to fulfill our order with the opposing
order. Each loop creates a new transaction that indicates a trade occured
between two users.

We keep doing this until the entire order is fullfilled (order is closed) or we
run out of matching orders; the remaining amount stays in the orderbook (order
is open).

The fulfilling part checks to see if our order has a smaller depth than the
other one. If so, our order is completed at their exchange rate and closed. The
matching finishes up.

The other case is where we have a larger depth, and want to fulfill ourself
partly using their order.

    ...
    Order 14: We are offering 10 GBP for 1 BC
    ...
    Order 18: They are offering 2.5 BC for 5 GBP
    ...

We need to calculate how much of our order will be chipped off, while
preserving their exchange rate.

    ...
    Order 14-1: We are offering 5 GBP for 2.5 BC
    Order 14-2: We are offering 5 GBP for 2.5 BC
    ...

We fulfill our order and close their order.

    ...
    Order 14-2: We are offering 5 GBP for 2.5 BC
    ...

A new transaction is created for record keeping purposes and the users funds are
updated accordingly.

A better algorithm would firstly order the matching equivalent orders by best
price first so we move up the orderbook, rather than select random matches.
Secondly an improvement perform linear programming to find the optimised rate
for two given orders given the constraints- although that isn't too important.

One minor addition would be to never accept orders where the want / offer
doesn't produce a perfectly divisible amount so we don't get these random
remainders that are credited to a random account once the order matching is
completed.

* See process_orders.php. pacman does the order fulfillment once the new amounts
  are computed.

[scribe]

Thanks for the detailed info genjix, great to see such an open and professional exchange.

Trying to do anything with British banks is why I'm so interested in Bitcoins to start with... Bit of a racket, if you ask me

Tell me about it. I must have aged by 10 years during these last few months due to dealing with this POS bank all the time. I'm a coder, not a bureaucrat. Put me back where I belong. A good 60% of my time overhead = dealing with the bank. What a waste. How are people supposed to work? And people ask me why Bitcoins are needed in the world when we have banks!!

Yup. We take strong crypto for granted now - Banks deal with insecurity through paperwork and paranoia instead. It's going to be really interesting to see how the challenges they try to solve get re-solved under Bitcoin/any other decentralised system. The MtGox stuff is just the start.

[Caesium]

genjix, I assume the process you've detailed above is not currently implemented for the live britcoin?

A day or two ago while there were BTC buy orders for £9 and up, I put in a test sell at £5, and it sold for exactly £5, not the £9 or so I would have expected; ie, I was setting a minimum price of £5 that I'd accept, not £5 I wanted and ignore the better buy offers.

If this is fixed in the new exchange then great, that's how it should work.

[genjix]

The process I detail above *is* how the current exchange works.

---------------

Our bank says they no longer wish to do business with us (due to what we're dealing with), so we're required to move elsewhere in 1 month's time.

Do not deposit into this LLoyds TSB bank account after 21st July. We will update the new details on the website, and add a new bank account soon.

[realnowhereman]

One minor addition would be to never accept orders where the want / offer
doesn't produce a perfectly divisible amount so we don't get these random
remainders that are credited to a random account once the order matching is
completed.

That sounds bad.

Want ten pounds for three BTC.  10/3 = 3.33333333333

Division is always going to produce annoying numbers.

"Perfectly divisible" is never going to work out.

The problem you have is that partial orders are always going to leave unusual amounts.  Those unusual amounts then get divided by something and produce an even more unusual amount.

There will always be strange little decimals left over.  Consolidation is the only way to get rid of them.  You could offer a tip account that users could donate them to.

To be honest I've found it annoying that Britcoin won't take arbitrary bitcoin amounts for withdrawl, stopping at two decimal places.  I've often wanted to move all my coins from Britcoin to Mt.Gox, but can't.  Mybitcoin is the same.  So now I've got three accounts that all have funny little extra decimals in and no way of ever consolidating them to make a whole number.

There is actually a severe Superman III problem with this attitude because there is nothing to stop the site operators collecting all the untransferrable little bits and using them.  Since no one can ever get them out, their true owners would never know they're gone.

[Caesium]

genjix, ok, then it's not working.

I realise you have a lot on your plate at the moment with the bank situation, but if you or someone (is there a support address to email that might be better suited?) could take a look at why order 9314 was completed at £5 and not the £9+ that was on offer at the time, I would be most grateful.

I don't care about the lost £4, I do care about the same thing happening when I put in a larger order.

[scribe]

Our bank says they no longer wish to do business with us (due to what we're dealing with), so we're required to move elsewhere in 1 month's time.

Do not deposit into this LLoyds TSB bank account after 21st July. We will update the new details on the website, and add a new bank account soon.

They're refusing to deal with it because it's Bitcoins? Or due to security fears etc?

Good luck finding a new one - I'm looking at switching banks soon too, so will love to know which ones are "Bitcoin-friendly", so to speak. As long as it's not Barclays

[dooglus]

genjix, ok, then it's not working.

I realise you have a lot on your plate at the moment with the bank situation, but if you or someone (is there a support address to email that might be better suited?) could take a look at why order 9314 was completed at £5 and not the £9+ that was on offer at the time, I would be most grateful.

It may be working as described and still do what you see.

The algorithm as described is to find any two orders which match, and to fulfill them using the rate specified by of one of the orders.  There seems to be no attempt to match the highest buy with the lowest sell, and no attempt to use the rate set by the older of the two orders.  It's apparently random which of the suitable buy orders you get paired up with.

"Looping through the matching orders with no ordering (we plan to fix that)"

See?

[ribuck]

Every minute, cron kicks in and starts processing the orders.

I can understand why you used cron, but it's definitely sub-optimal.

When a new order arrives, there's no reason why it can't be immediately matched against the current order book, sorted in price order. This gives a correct result, and speedier trades.

So I hope in your new systems you will move towards non-cron order matching.

[dooglus]

    ...
    Order 14: We are offering 10 GBP for 1 BC
    ...
    Order 18: They are offering 2.5 BC for 5 GBP
    ...

We need to calculate how much of our order will be chipped off, while
preserving their exchange rate.

    ...
    Order 14-1: We are offering 5 GBP for 2.5 BC
    Order 14-2: We are offering 5 GBP for 2.5 BC
    ...

We fulfill our order and close their order.

    ...
    Order 14-2: We are offering 5 GBP for 2.5 BC
    ...

A new transaction is created for record keeping purposes and the users funds are
updated accordingly.

I'm not sure this is a good way of doing it.

Suppose I'm trying to buy 1,000 BTC at 10 GBP each.  The sellers are wanting 12 GBP each at the moment, so no trade happens.  I'm waiting for a seller to ask for less.  Then some joker comes along and offers to sell 1 BTC for 1 GBP.  His offer matches my request to buy, and so, working the example as before:

    ...
    Order 14: We are offering 10,000 GBP for 1,000 BC
    ...
    Order 18: They are offering 1 BC for 1 GBP
    ...

We need to calculate how much of our order will be chipped off, while
preserving their exchange rate.

    ...
    Order 14-1: We are offering 1 GBP for 1 BC
    Order 14-2: We are offering 9,999 GBP for 9,999 BC
    ...

We fulfill our order and close their order.

    ...
    Order 14-2: We are offering 9,999 GBP for 9,999 BC
    ...

A new transaction is created for record keeping purposes and the users funds are
updated accordingly.

After buying the joker's 1 BTC for 1 GBP, the rest of out order is now changed, offering only 1 GBP per BTC.  Unless someone else comes along with a very cheap sale, our buy order will never get matched.  Even if some 2nd guy comes and offers 1 BTC for 2 GBP, we won't get to buy it, because we're now only offering 1 GBP per BTC.  What's the reasoning for changing the rate in "Order 14-2" above?  I think it should either keep the GBP spend and rate the same, and buy more BTC with the saving we made from the joker, so if the 2nd part is matched at the rate we requested we end up getting a total of 1,000.9 BTC for 10,000 GBP:

    ...
    Order 14-1: We are offering 1 GBP for 1 BC
    Order 14-2: We are offering 9,999 GBP for 999.9 BC
    ...

or keep the rate and BTC requested the same, and spend less GBP, so if the 2nd part is matched at the requested rate we end up getting 1,000 BTC for a total of 9991 GBP:

    ...
    Order 14-1: We are offering 1 GBP for 1 BC
    Order 14-2: We are offering 9,990 GBP for 999 BC
    ...

Did I misunderstand something?  Was the example I quoted wrong?  Or is the current implementation kind of weird?  Notice this is what happened to Caesium.  He offered to sell BTC at a low price when someone was already trying to buy at a higher price and the trade was carried out at his low price.

[Caesium]

It may be working as described and still do what you see.

The algorithm as described is to find any two orders which match, and to fulfill them using the rate specified by of one of the orders.  There seems to be no attempt to match the highest buy with the lowest sell, and no attempt to use the rate set by the older of the two orders.  It's apparently random which of the suitable buy orders you get paired up with.

Ah, ok, thanks for the clarification dooglus. Hope this is improved upon soon then.

[dooglus]

I've taken a look at the cron/process_orders.php code and compared it to the doc/process_order documentation.  It turns out that the code isn't doing what the documentation says it is:

For each order that is processed, we look to find other equivalent orders [...]

The fulfilling part checks to see if our order has a smaller depth than the
other one. If so, our order is completed at their exchange rate and closed. The
matching finishes up.

It's completed at 'our' exchange rate, ie. the newly processed order's, not the old order's.

The other case is where we have a larger depth, and want to fulfill ourself
partly using their order.

[...]

We need to calculate how much of our order will be chipped off, while
preserving their exchange rate.

Again, what the code is doing is using the new order's rate, not theirs.

I think the description you wrote is how it should be, and how you wanted it to be.  But I think the code is backwards.  This explains why people are getting the rate they ask for, rather than the best available rate in the order book.

A better algorithm would firstly order the matching equivalent orders by best
price first so we move up the orderbook, rather than select random matches.

Order by price, and then by date.  The first person to offer to sell at a certain price should be the first person to get matched at that price.

Secondly an improvement perform linear programming to find the optimised rate
for two given orders given the constraints- although that isn't too important.

What's the optimised rate?  For the seller, higher is better.  For the buyer, lower is better.  I think the way most exchanges work is that new orders get matched at the best price possible, and if they don't immediately match then they are left as standing orders and will only be matched at the requested price or not at all.

One minor addition would be to never accept orders where the want / offer
doesn't produce a perfectly divisible amount so we don't get these random
remainders that are credited to a random account once the order matching is
completed.

I don't think that helps because different parts of the order can be matched at different prices.

[afly]

Did lloyds say why they're closing the account?

I can somewhat understand their suspicions, but there's no fraud and you're not a business. If they have no evidence of any wrongdoing then it sounds like they're just being petty.

[ribuck]

Did lloyds say why they're closing the account?

Feel free to post a scan of the letter, genjix...

[genjix]

There's no letter. It's been an ongoing thing with LLoyds for nearly 2 weeks now everyday. They think our business is too high risk for them, so we've been given a 30 day notice to move to another bank.

Anyway, it's too difficult answering every small message here otherwise I/we won't get any work done. I think everything should be OK since we have several contingency plans already in place from before. The new setup will either be rescinding the LLoyds notice (somewhat likely) or registering under a sole trader before forming a new LL to move the account to. Currently Britcoin runs under the Bitcoin Consultancy umbrella, so we'd be maybe looking to form a new platform for Britcoin (either Britcoin or an exchange group under Intersango) and find a backer.

I'm trying to stay away from backers if possible since that could mean turning the Britcoin platform into a 'product' rather than a service, and mean making the sourcecode closed. Wherever possible I want to stay away from making political decisions that negatively affect the quality of the site... But it might be something my hand will be forced to do. I've already been fighting a ton with everyone to keep this software as an open platform but it's exhausting. We have the new exchange in the works which we plan to roll out (intersango 2). I hope it's opensourced.

[genjix]

BTW is anyone in London and want to meet up later? We might get a pizza or something with a few other community members.

[dooglus]

I've taken a look at the cron/process_orders.php code and compared it to the doc/process_order documentation.  It turns out that the code isn't doing what the documentation says it is [...]

I made a clone of the git repository and made some changes to fix these problems:

1) process new book entries in the order they arrive

2) chew through the existing order book matching best prices first

3) when a new order meets an existing order, use the price specified in the existing order, so if there are cheap coins available, it's impossible to buy expensive coins before the cheap coins are gone.

https://gitorious.org/~dooglus/intersango/dooglus-intersango

I've done some basic testing on my local install and it seems fine, but please review the code!

One question:

If you place an order "I want to buy 10 bitcoins for $100" and it turns out there are coins available for less, would you want to
  (a) buy 10 bitcoins and get change from your $100, or
  (b) spend $100 and get more than 10 bitcoins

Likewise, if I say "sell 10 bitcoins for $100" and someone wants to buy them for more, should it:
  (a) sell until you have $100 and keep some bitcoins around, or
  (b) sell all the bitcoins and give you more than $100

It strikes me that in both cases the sensible thing to do is option (b) - don't worry about exceeding what the user said they wanted to get, keep going until they've traded away everything they said they wanted to trade.

Right?

Currently the code is stopping early, doing option (a) in effect when lots of small orders are matched, and option (b) when your order is matched by a single large order.

[drgr33n]

BTW is anyone in London and want to meet up later? We might get a pizza or something with a few other community members.

Bit far for me I'm in norwich Would be good to arrange a bitcoin boffin meet though

[Teleshot]

Can you give us an update about the payments on the 13th?

Have you managed to access them yet and do you know when you'll be able to credit the accounts? also, will the 30 day notice from the bank affect these payments in any way?

Many thanks