Welcome to the party. You're a little late, but we've got room for one more.
Check out
this thread to get organized. Your whitepaper is one of at least 20 on decentralized exchanges here since the bubble pop last month.
About the contracts tho; It's an original start but this idea isn't very flushed out at all. For instance, how would contracts allow for real-time, graphed trading?
There will be multiple contracts, one for each of the four scenarios. Each contract will have different variables, and each of the four contract scenarios will have a different setup. Not all contracts will have to be stored in the distributed ledger. The primary contract that will go into the distributed ledger will be number 3 that contains the exchange rate, currencies used and other relevant information for the transaction.
Real-time:It’s distributed system, thus there will be the lag that you’d normally expect from connecting to multiple peers. It depends on the connection speed etc.
It will of course be a very different animal than centralized exchanges. We should expect some trustworthy nodes to excel more than smaller nodes, just like we see with the mining process in Bitcoin where you have economies of scale[1]. We’d also see that the most dominant nodes will determine the price to a larger extent than smaller nodes, for reasons like market depth, reduced lag etc.
So it will be up to each node how much processing power they want to put on their exchange. The signing of the contracts can be automated, and a different key will be used for signing transactions. It means; you have one set of keys for sending the bitcoins off the exchange, and another set of keys for signing that a transaction took place. Thus, there will be reduced risk of attack on an exchange, because you cannot steal the bitcoins anyway. In addition to this, you’ll have to have a contract with the exchange in order to be able to trade on it. So if there’s any attacks on the exchange, you can see what contract the attack happens under.
Some exchanges might even have a rule that says all bitcoins are kept in cold storage, and the withdrawal happens once every 24 hours.
Just like anyone CAN run a mining operation, so also anyone CAN run a BitXChange. It doesn’t mean that everyone will do it.
Graphed trading:This is done pretty much the same way as a centralized exchange does it today; just display the incoming data in a graph. Differences: your client verifies the signatures of each of the transactions that have taken place* (just like BitcoinQt verifies all of the blocks) and displays historic transactions along with their exchange rate.
Bids and asks:There will be a message signed by both the bidder (node B) and the exchange (node A). So B wants to purchase 1 BTC for 100 USD. He creates this message on his client, and the client signs the order with the key in the contract and sends the message to node A. Node A checks the checksum, and signs the message and puts it onto the exchange.
The same process goes for the ask.
While it might seem like a lot of work for the computer, I’m thinking of structuring it similar to TCP/IP. It’s not the fastest system engineers can come up with, but it’s in use all over the world because it’s very solid. Distributed exchanges should have focus on robustness and antifragility[2] rather than speed. If the exchange is 500 millisecond delayed, it’s annoying, but you can live with it. If it goes down every 2 days, people won’t use it.
* Your client could also just download the last days’ worth of trades, whatever you set your client up to do.
1. Wikipedia. Economies of scale. 2013; Available from:
https://en.wikipedia.org/wiki/Economies_of_scale.
2. Taleb, N.N., Antifragile: Things That Gain from Disorder 2012.
