Topic: BitXChange: A peer-to-peer currency exchange system (Read 1192 times)

Advantage of having checksum on each ask and bid
Each bid and ask should be signed by the client software of node B. So when node B is sending a bid or an ask to node A, node B will have to refer to a previously established contract, and the software will also have to sign the bid or ask. If a bid or ask is cancelled, a cancel message is created and signed by private key.
Node A specifies in the contract with B the maximum number of messages or RPC that B is allowed to send per second.
If node A receives a flood of messages, but these have the wrong checksums, they are simply thrown away. Perhaps it would be possible to have the GPU do the checking, since this work seems to be of the type that GPUs are good at. This would allow even a modest computer with a GPU to do significant amount of checksum or message-checking.

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.

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?

We can assume it's only a matter of time before banks will get so afraid of bitcoin that they will stop processing transactions relating to bitcoin altogether. Governments as well is not going to like bitcoin's continued success.
Even moving funds in and out of MtGox is problematic. Localbitcoins.com is a very good start, but it also has its limits.

I propose a system for dealing with this problem called BitXChange. It's the outlines of a peer-to-peer currency exchange where the users can download a client to set up a server. The similarities with BitcoinQt are intentionally many.

http://www.scribd.com/doc/146822045/BitXChange

The easy part is to come up with the ideas of solving all the problems with creating a P2P exchange. The harder part is to work out the code. The coding is of course the more time-consuming work, and I cannot spend the time required to implement the solution right now, so I'm hoping the community will grab the valuable ideas and run with them.

Hopefully there are others out there with the skills and time to build the open source P2P exchange.

Tell me what you think of the suggested system, if you love the idea as much as I do, see flaws with it or something else. Go to http://www.scribd.com/doc/146822045/BitXChange to evaluate the system.