Britcoin V2 Community Input

[phantomcircuit]

There are a couple of design decisions to be made when creating an exchange.

The first is how to internally account for trades.

I have come up with 3 separate methods which each have their own advantages and disadvanatages.

The first scheme is the way britcoin operates currently, what I have/what I want pairs.  This allows for a very simple representation and a very simple interface for users.

This scheme results in rounding when calculating the rate at which the trade has been placed, this is unavoidable when using this representation.
There is again potential for rounding when multiplying quantity*rate.
This scheme results in 2 separate instances of rounding where others result in a single instance.

The second scheme is to store quantity/rate/have_currency/want_currency.  This is closer to the normal forex market place, but allows for buying or selling a precise amount of either side of the trade.
This results in rounding both when calculating quantity*rate and when matching 2 buy orders for inverse currency pairs (1/rate).

The third scheme is the normal forex method, in which you have the currency pair/rate/quantity/buy or sell. There is no way to buy/sell a specific quantity of the base currency with this scheme.
This results in rounding when calculating quantity*rate.


So which method do people prefer?

[1713483660]

1713483660

[dooglus]

I propose storing what you have, and the rate you want, along with the currency you have and want.

[ElectricMonk]

I like what you have on the site currently.

The forex method might be the standard for exchanges but these are used by traders all the time.

A standard rule for any user interface is "Don't make me think!"

Like most people on here, I'm an IT nerd so maths, rates and calculation make sense to me but I work with artists all day long and their math skills tend to be poor. My first thought would be how they would respond to the three options. When people change up money for holidays they tend to think of how many euros or dollars etc they're going to need but they also might want to think about it in terms of their home currency but I think they rarely think in terms of rates and the notion that they're either buying/seling euros etc doesn't even come in to it.

My preference would be to put in the number of GBP I want to sell and for the interface to calculate the resultant BTC at the current exchange rate and then to be able to adjust the rate and/or the BTC you're wlling to receive. IMO, That's a more natural way of thinking about it. I guess this is effectively all three methods at once - you can change any parameter and it will recalculate the other params based upon which one was changed. How that's stored in the DB is irrelevant to the user but I guess the forex format of storage is probably the best.

I guess the UI might look something like...

Qty1 * currency_seletor = rate * Qty 2 * currency_selector_2

If you update either quantity then the rate is recalculated. If you change the rate then Qty2 is recalculated. Put that with some nice Ajax currency graphics and you're on your way. It would also be good if it let you know if your order matches any in the orderbook.

[genjix]

Also when phantom says 'rounding', he means to the 8th decimal place. I'm of the opinion that it's totally insignificant and we can make up those prices ourselves. It's unavoidable when you do 2 integer divisions that don't exactly go, and you get a remainder- what to do with it?

for instance, if the rounding is less than 0.000 000 01 and we get 1 million trades a year (optimistic) then that'd be 0.01

We round up for the person and absorb that cost ourselves. So the parties involved get more money than they asked for.

We could even increase the number of decimals internally to make that rounding error smaller.

[Insti]

Surely this is a solved problem in the finance industry?

I think I like 3 the best but I'm still not entirely sure what the problem with it is.

[phantomcircuit]

Surely this is a solved problem in the finance industry?

I think I like 3 the best but I'm still not entirely sure what the problem with it is.

The problem with 3 is that you can only buy/sell a specific quantity in 1 currency in the pair.

So lets say we use GBP/BTC, you could only sell a specific amount of GBP or buy a specific amount of GBP.

This problem is fixed in the financial industry in a pretty convoluted way.  You get a quote from a broker, who has added a spread, the quote is only good for a certain time period, but since the quote is locked in you can calculate the exact amount you end up buying.

So to make it possible to buy an exact amount at an exact rate you pay a broker a spread above market.

[dooglus]

We round up for the person and absorb that cost ourselves. So the parties involved get more money than they asked for.

Your calculations end up with an amount of BTC and an amount of GBP.

The BTC amount is taken from one person and given to the other, and the GBP amount is taken from the 2nd and given to the 1st.  It's a zero sum game as far as you are concerned.  So where's the 'absorb that cost' bit?

When the division isn't exact, one person loses less than 0.01 uBTC and the other gains it.  I don't see how the exchange is absorbing anything.

[kiko]

Aside from the minor internal rounding intricacies I would like to see the auto suggested price changed.  If I enter 50GBP I want it to auto-suggest the best rate that would execute that volume immediately i.e. totalling the bids up to and including the volume entered.  The way it works now is that you enter 50GBP and execute, the order just sits there because there aren't actually any offers at the suggested price; you might as well label the execute button "don't buy".
Just my 0.02BTC, looking forward to the upgrades.
Thanks guys.

[genjix]

When the division isn't exact, one person loses less than 0.01 uBTC and the other gains it.  I don't see how the exchange is absorbing anything.

That's my point. It's totally insignificant as far as I'm concerned, and the exchange operator could absorb that cost if need be.

[phantomcircuit]

When the division isn't exact, one person loses less than 0.01 uBTC and the other gains it.  I don't see how the exchange is absorbing anything.

That's my point. It's totally insignificant as far as I'm concerned, and the exchange operator could absorb that cost if need be.

There isn't anything to absorb.  The rounding occurs in the exchange rate. So we simply run the exchange at that rate.

[dooglus]

There isn't anything to absorb.  The rounding occurs in the exchange rate. So we simply run the exchange at that rate.

I think what Genjix might be saying is that it would be possible to round the result in the favour of both sides of the trade so they both gain a fraction of a 'satoshi', and the exchange loses a satoshi on each trade.

Currently one side gains a fraction and the other side loses a fraction, but it would be possible (and very cheap) for both sides to gain.  Then you could claim to be the only exchange with negative commission!