Bitcoin Forum
August 25, 2019, 09:00:10 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: BitXChange: A peer-to-peer currency exchange system  (Read 1110 times)
AlexanderScott
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
June 10, 2013, 09:59:29 PM
Last edit: June 10, 2013, 10:20:10 PM by AlexanderScott
 #1

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1566766810
Hero Member
*
Offline Offline

Posts: 1566766810

View Profile Personal Message (Offline)

Ignore
1566766810
Reply with quote  #2

1566766810
Report to moderator
BTCLuke
Hero Member
*****
Offline Offline

Activity: 525
Merit: 505


My other Avatar is also Scrooge McDuck


View Profile
June 10, 2013, 10:25:11 PM
 #2

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?

Luke Parker
Bank Abolitionist
AlexanderScott
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
June 11, 2013, 12:34:28 AM
 #3

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.


AlexanderScott
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
June 11, 2013, 01:12:50 AM
 #4

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.
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!