BitXChange: A peei-to-peei cuiiency

exchange system
Alexander Scott
BM-2D8YwQutEXVDuJq3R1KxQ7euDyU8huL2YS
Sunday, June 9, 2013
1 Problem
Today we have centralized exchanges between Bitcoin and fiat currencies[1]. This allows a
government or other aggressors to potentially shut down the buying and selling activities between
fiat and crypto currencies. There are, in other words, single points of failures. At a minimum, the
current authorities in society can make it hard to get in and out of Bitcoin[2].
2 Proposedsolution
The solution that is needed is a distributed system for exchanging fiat currencies to crypto currencies
and back. The system would have to have a set of properties:
1) It should have no single point of failure.
2) Each node decides what level of risk they want to take. Failure of a node should not bring
the rest of the network down; the network should be antifragile [3].
3) It should be easy to set up a new exchange, as simple as downloading an application and
start using it. It can be assumed that if the exchange is too hard to set up, we will have few
nodes and higher risk for each of those nodes. If its easy enough to use, anyone can do it
like with Bitcoin, Bittorrent and Bitmessage, and the system would thus become very hard to
shut down.
4) Transactions should be reliable and irreversible.
5) It should be hard to trace the exact activity of a single node.
6) It should have an automated way to determine how trustworthy each node is.
7) Each node should be able to determine the fees, frequency of RPCs[4], up-time and other
parameters.
When dealing with fiat currencies, like bank deposits and handing over cash, there will have to be a
level of trust between each node. The proposed solution to this problem is that each node has an
incentive not to break the trust of the other node, since this will be reflected in the calculated
trustworthiness.
The BitXChange node will run alongside Bitcoin Qt and possibly also work with Bitmessage [5].
3 Transactionintocryptocurrency
Node A, the exchange in this scenario, is receiving a request from node B. B wants to purchase
Bitcoins. A contract is set up between the two nodes, and the contract is signed by the private keys
of both. The contract is standardized, and contains the terms of the contract, such as due date for
delivery of cash balance, the amount that was transacted, and what currency was used. Both nodes
will have to sign the contract. The nodes will then exchange connection information, similar to the
way its done with Bitcoin and Bitmesage[5]. The contract might be exchanged over Bitmessage in a
standardized format that BitXChange can access.
Now, node B has a valid contract and can connect to the exchange thats located on node As
computer. He can now purchase bitcoins for the equivalent of the currency that he gave node A.
4 Transactionbetweenusersofagivenexchange
Exchanges between users of the same node happen the same way as a centralized exchange, where
buy and sell orders are put into the system and ownership changes when buy and sell cross. In our
scenario node C sold 10 bitcoins on the exchange of node A, and node B bought 10 bitcoins from
node C. This is a very simple computational problem, and ownership of fiat and crypto currency is
switched between node C and B. Out of this node A takes his transaction fees as determined in the
contract between node A and each of the other two nodes. Each contract can be different; the
software looks up the contract and uses the information in there to determine the exact fees. The
nodes can decide if they use a flat fee per transaction or if they use a percentage of the amount
exchanged. The transaction is then signed by A and sent to its peers, verifying that ownership has
changed hands.
5 WithdrawalofBitcoins
Now B wants to withdraw his bitcoins to his own Bitcoin address and the contract between A and B
contains a set of Bitcoin addresses he can use to withdraw to. This pre-definition is set up to
minimize hacks on the server node A. Node As program automatically checks that the Bitcoin
address is defined in the contract. Then it signs over the number of Bitcoins that node B requested. B
has to sign on his end that the funds are received, thus we have a transaction on the blockchain that
has been signed by both A and B as being valid. The calculated level of trustworthiness increases for
both, most for A. However, node A dont want to disclose all transactions thats been conducted by
his server. The solution to this is that the software generates a total sum of the transactions and
calculated trustworthiness that have taken place on his node using zero-knowledge proof [6].
6 Withdrawalofcash/fiat
Node B wants to get cash, and sets up a new contract with node A for selling the bitcoins. The new
contract contains all required information for depositing funds to node A, along with the terms for
the contract. A new Bitcoin address under control of node A is issued, and B sends his bitcoins to this
address. Then node A signs that the bitcoins have been received, and node B can now exchange his
bitcoin balance for currency. There should be a distinction between physical cash and bank deposit
cash. Thus, one node can allow big withdrawals of physical cash, but be more restrictive when it
comes to bank transfers. Another node might have the opposite preference. Each node should set
his own preferences.
It should be noted that a single node can hold multiple currencies, thus making it easier to exchange
not only crypto currencies, but also fiat currencies. The people behind Ripple came up with some
ideas on how to have multiple currencies in one account [7, 8], and their solution seems valid. The
exchange node could set their own buy and sell prices for other currencies, and the contract would
determine how the physical currency should be sent to the recipient.
7 Pricediscovery
A very important feature of any exchange is the price discovery mechanism. In this scenario node A
wants to sell some of his bitcoins on his own exchange. The price on his exchange is 5% above the
general market, and the reason is that there is a shortage of Bitcoins on his exchange. Node A is
prepared for the situation, and has deposited a small amount with another node; node D. So he does
a purchase of bitcoins on node D, and then transfers the bitcoins to his own wallet and selling them
on his own exchange, thus realizing an immediate arbitrage gain. We can see that also D could do
the same, he could be selling his bitcoins on As exchange. If B also has access to both node A and
node D, B could do the same as well.
Combining this with a transaction history that includes the exchange rates used per currency in a
blockchain fashion and we can see that although it might be longer than milliseconds to transact, the
system would be antifragile and price signals could travel between the nodes. The system for
arbitrage could be built into the BitXChange software as default, with each node setting up their own
parameters for how big the price difference between the nodes would have to be before automated
trades were triggered.
8 Datausage
There will be multiple contracts, and each contract will contain a set of values in addition to
signatures. For a single transaction all the way from cash to having bitcoins, there are a total of 4
messages that needs to be processed by the network.
1) Contract signed by both A and B.
2) Signature from A stating that funds are received from B.
3) Signature from A stating transaction has taken place at a given exchange rate.
4) Signature from A and B that bitcoins (or other currency) has been sent. Data about the
transaction from blockchain is also included.
The data will thus aggregate quite quickly in the proposed system. The suggested solution for this is
to split the datasets apart in streams like Jonathan Warren suggests [5]. We can imagine having
separate streams for each currency.
The transaction data can be stored in a similar way as the blockchain or possibly also using
distributed version control system like that of Mercurial [9, 10] or Git [11], sending change-sets
around the network in a peer-to-peer fashion.
Each node will be able to determine how frequent other nodes can call a RPC[4]. Thus, it will be up
to each node to determine if they will allow automated trading or only human-like speed on their
exchange.
9 Leveloftrust
Each node has a numeric level of trust determined by the system, as well as a level of trust between
each of the persons. The numeric level of trust is determined as a percentage of value exchanged
over the lifetime of the node. The argument is that a node that has exchanged with 200 other nodes
of a total value of 10 000 bitcoins in total, with the average transaction being 20 Bitcoins, is not very
likely to defraud you of 1 Bitcoin [12]. If you transferred 10 000 bitcoins to this same node, youll
have a much higher probability of being defrauded. Thus, each node will have to work up their
reputation over time. The node can then prove his level of calculated trust:
T =
_ v-n
n
0
t
where T is Trust, n is the number of transactions, V is value and t is time. For each transaction, he
has to provide evidence that hes in control of the private key belonging to the exchange node that
was in the middle of the transaction. Each node can have many private keys, thus making it harder
to track the activity of a single node. Later stages of the software can also implement usage of
Zerocoin [13] to make it harder to track.
To avoid nodes creating fake transactions, with each completed transaction both nodes will have to
sign off on the transaction, and the BitXChange transaction will contain a blockchain transaction
hash to verify that the transaction took place.
10 Conclusion
We have seen the need for distributed exchanges, proposed a solution to this problem with a system
that runs alongside Bitcoin Qt. The system would not have a single point of failure. There will have to
be a level of trust between users, but this will be accounted for in the software, automatically
leading to a higher trust level for the nodes that keep their contracts. There are four messages that
will be exchanged between nodes, and some of the messages will have to be public knowledge. To
keep a public ledger there would have to be a similar structure to the blockchain, or perhaps usage
of a distributed version control system. Trust would be built by each node over time, without
exposing the total transaction history of each node by using zero-knowledge proof.
11 References
1. BitcoinWiki. Currency exchanges. 2013; Available from:
https://en.bitcoin.it/wiki/Trade#Currency_exchanges.
2. xportz. My bank canceled my MtGox wire, saying it was too suspicious? 2013; Available
from:
http://www.reddit.com/r/Bitcoin/comments/1b37s6/my_bank_canceled_my_mtgox_wire_
saying_it_was_too/.
3. Taleb, N.N., Antifragile: Things That Gain from Disorder 2012.
4. Wikipedia. Remote procedure call. 2013; Available from:
http://en.wikipedia.org/wiki/Remote_procedure_call.
5. Warren, J. Bitmessage: A Peer-to-Peer Message Authentication and Delivery System. 2012;
Available from: https://bitmessage.org/wiki/Main_Page.
6. Wikipedia. Zero-knowledge proof. 2013; Available from: http://en.wikipedia.org/wiki/Zero-
knowledge_proof.
7. Ripple. The world's first open payment network. 2013; Available from: https://ripple.com/.
8. ripplevideo1. How Ripple Works - Gateways and Pathways. 2013; Available from:
http://www.youtube.com/watch?v=M16ZatXbmLg.
9. Wikipedia. Mercurial. 2013; Available from: http://en.wikipedia.org/wiki/Mercurial.
10. Selenic. Work easier Work faster. 2013; Available from: http://mercurial.selenic.com/.
11. Wikipedia. Git (software). 2013; Available from: http://en.wikipedia.org/wiki/Git_(software).
12. LibertarianismDotOrg. Exploring Liberty: The Machinery of Freedom. 2012; Available from:
http://www.youtube.com/watch?v=2YfgKOnYx5A.
13. Zerocoin. What is Zerocoin? 2013; Available from: http://zerocoin.org.