Bitcoin Forum
December 11, 2016, 08:20:49 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Exchange algorithm specifics  (Read 607 times)
helloworld
Full Member
***
Offline Offline

Activity: 182


View Profile
August 19, 2011, 03:06:07 PM
 #1

Trying to work out in my head how an exchange works, specifically how the database tables are designed and what happens internally in the database when someone places an order.

Maybe there's open-source code out there already, but it's kind of fun to do this kind of math/problem solving with just pen and paper (or notepad.exe!)


So, let's say the db has the following orders:

bid, 2.00000000, 10.70000000
bid, 1.00000000, 10.80000000
ask, 2.00000000, 11.00000000
ask, 3.00000000, 11.20000000     <- let's call this order X

Now what happens when these hypothetical orders are placed:

bid, 3.00000000, 10.70000000
check the lowest ask -> 11.
This bid is less than the lowest ask, so no trade occurs, the order it simply gets added to the db.

bid, 3.00000000, 11.50000000
check the lowest ask -> 11.
This bid is above the lowest ask, so check how many coins are available at that lowest price -> 2.
This only fills part of the order, so check the next lowest ask -> 11.2.
Check how many coins are available at that price -> 3.
This is more than enough to fill the order, so the order is complete, however this ask also has 2 btc left to fill.

Question: In this scenario, when order X is only partially filled, would it be best to mark the row as complete and add a new entry with the remaining amount, or just edit the row to show the new amount?

eg.

insert method:
db before:
ask, 3.00000000, 11.20000000
db after:
ask, 3.00000000, 11.20000000, complete
ask, 2.00000000, 11.20000000

or edit method:
db before:
ask, 3.00000000, 11.20000000
db after:
ask, 2.00000000, 11.20000000

1481444449
Hero Member
*
Offline Offline

Posts: 1481444449

View Profile Personal Message (Offline)

Ignore
1481444449
Reply with quote  #2

1481444449
Report to moderator
1481444449
Hero Member
*
Offline Offline

Posts: 1481444449

View Profile Personal Message (Offline)

Ignore
1481444449
Reply with quote  #2

1481444449
Report to moderator
1481444449
Hero Member
*
Offline Offline

Posts: 1481444449

View Profile Personal Message (Offline)

Ignore
1481444449
Reply with quote  #2

1481444449
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481444449
Hero Member
*
Offline Offline

Posts: 1481444449

View Profile Personal Message (Offline)

Ignore
1481444449
Reply with quote  #2

1481444449
Report to moderator
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
August 19, 2011, 03:23:23 PM
 #2

Both approaches work.

On bitcoin-central.net, rows are edited. I'm thinking this should change at some point since you end up losing information, not information that is useful for performing the trading, but history that could be interesting for a trader to have.

Source code is here : https://github.com/davout/bitcoin-central/blob/master/app/models/trade_order.rb

Line 138 is where the magic starts to happen.

helloworld
Full Member
***
Offline Offline

Activity: 182


View Profile
August 19, 2011, 03:31:32 PM
 #3

Great, thanks!

Please excuse my ignorance, but what language is that code?

I wonder what language and what database is most common for an exchange too... I'm sure you need to bundle your sql statements into transactions to be safe.

davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
August 19, 2011, 03:36:05 PM
 #4

Please excuse my ignorance, but what language is that code?
Ruby

I'm sure you need to bundle your sql statements into transactions to be safe.
They are. And you better make use of the serializable isolation level.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!