Bitcoin Forum
May 02, 2024, 01:36:11 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Bitcoin and exchanges  (Read 712 times)
btcmind (OP)
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
September 12, 2013, 08:16:03 AM
Last edit: September 12, 2013, 08:44:45 AM by btcmind
 #1

In this thread I want to develop some ideas around exchange markets and how they relate to bitcoin. I will start with a discussion of basic functions of a market, using some pseudocode or simulations. The idea is to evaluate what market models make sense, and if there could be alternative market models. If there are new forms of money one can speculate about new forms of markets. See Mike Hearn's work on this wiki https://en.bitcoin.it/wiki/Contracts or in the forum. Here I'm more interested in the market, than in contracts, i.e. I assume we use standard contracts as they are currently defined, such a stock ownership, bonds or futures. I should also point out there is a lot of academic research in this area, called microstructure and agent-based economics. Some of it might be useful, but I doubt it.

Basic datastructure of a market

So let's start to understand markets a bit, as they currently operate. By markets I mean financial markets, i.e. the stock market will serve as a reference. Basically any market which is operated by an exchange, such as the NYSE, the LSE, the Deutsche Börse, and so on (the NASDAQ actually has a different model than the NYSE).

The fundamental datastructure of a market is a limit order. A limit order signals a willingness to buy or sell a predefined product, at a limit price, with a given quantity.

Quote
class LimitOrder:   
   product = "stock.AAPL"
   action = "action.buy"
   quantity = 100
   price = 480

Then, in a double auction market you have a limit order book, which holds all limit orders which have not yet been filled. To we have to add to the LimitOrder a timestamp. This timestamp is given by the exchange at the point of arrival. The client doesn't necessarily know about timestamps. I will define what a client is perhaps later, but currently I assume that all clients are hooked up to the central node, the exchange.

Note that time is a crucial aspect of the willingness to buy or sell. In the example I don't intend to buy AAPL stock one year from now. A very typical assumption is to assume that the timeframe of my order is only one day. So we should add a property which says that the LimitOrder is GoodForDay. The new datastructure looks like this

Quote
class LimitOrder:   
   product = "stock.AAPL"
   action = "action.buy"
   quantity = 100
   price = 480
        timestamp = 1378974170.840874 # UTC. given by exchange at arrival
        timeframe = GFD # cancel on day's end
     

Network

We have a central server, which could be a certain legal entity as well. I assume this is a server which is known to all clients, say by a URL. Clients are just computers operated by the owners. We don't have brokers here. The clients and the server are connected, traditionally on a private network via UDP.

I assume that clients and server have protocol. Let's call this a trading protocol (TXP). In reality this is almost always the FIX, but I want to imply we could have different kinds of FIX'es.

Server: txp://account.exchange.com

Semantics

We have actions, which correspond to entering limit orders and canceling limit orders. There are no other actions, such as dispute mediation. Say for instance the servers fill my order at a price which is incompatible with my order. Then I'm filled at this price by force. I trust the exchange to operate always according to the protocol.

Clearing

Also there is no settlement yet. If I buy AAPL stock it is unclear how the stock will be transfered, so that I'm the legal holder of this document equipped with rights and obligations. Transferring rights electronically is the clearing mechanism which on a stock market takes usually 1-3 business days. Settlement requires that the transfer of ownership is in own namespace of law (jurisdiction).
BitcoinCleanup.com: Learn why Bitcoin isn't bad for the environment
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714613771
Hero Member
*
Offline Offline

Posts: 1714613771

View Profile Personal Message (Offline)

Ignore
1714613771
Reply with quote  #2

1714613771
Report to moderator
1714613771
Hero Member
*
Offline Offline

Posts: 1714613771

View Profile Personal Message (Offline)

Ignore
1714613771
Reply with quote  #2

1714613771
Report to moderator
1714613771
Hero Member
*
Offline Offline

Posts: 1714613771

View Profile Personal Message (Offline)

Ignore
1714613771
Reply with quote  #2

1714613771
Report to moderator
daybyter
Legendary
*
Offline Offline

Activity: 965
Merit: 1000


View Profile
September 13, 2013, 07:41:25 PM
 #2

I think the order also needs an owner (who created the order) and a status (open, partially_filled, filled etc). It should also hold the traded good or currency pair (btc in usd, or so).

I already started a data model for such an exchange. That's a good start and you can create code from it (i.e. sql).

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!