Bitcoin Forum

Right now (with mtgox) the 2 parties that want to do a transaction are at risk. Person A wants to sell his bitcoins, and needs to send his bitcoins to mtgox first, and is exposed while mtgox holds his btc. Person B wants to buy bitcoins, and needs to send money to mtgox first, and is exposed while mtgox holds his cash.

Person's A's exposure of having to send his bitcoins to an exchange before he can sell them, can be eliminated by creating a new decentralised p2p exchange network, that will run a client which holds Person's A's bitcoins (they never leave his computer).

Person's B exposure of having to send money to an exchange can be 'limited in time' by using a new concept called IOU exchanges. They collect money from person B (through gift cards, wire transfers, ..), and will send this money to Person A when the p2p network confirms the transaction took place. Person A will obviously have to approve/enable this IOU exchange in his client.

This proposal will eliminate the biggest risk: people needing to send their btc somewhere first, to be able to sell them. It will also allow for much easier competition of IOU exchanges, since there will not be an exchange who owns the actual transaction network (which is currently the case with mtgox).

What needs to happen:

- Writing of code/clients that will run the network.
- IOU exchanges (or the adjustment of existing ones to support the network)

Ripple is a good option for something like this.

What would be the best options? Federated servers like OT/fellowtraveller's idea? Blockchain-lite modified clients that reference mining rigs for best percent trades? What is lacking is ready-state WoT to execute trades. We fall back to old-style exchanges because it is what we know, not what we need.

FF

IOU exchanges reminds me an idea about separating two tasks : matching engine and deposit/withdrawing.

Currently exchanges have to implement both parts cause exchange is an escrow agent for counterparties which ensure existence of exctly the amount of product( currency, resource, any object) for exchange to take place.

Definitely to implement and maintain both very efficient matching engine and deposit/withdraw service is much more difficult then seperately. On the other hand deposit/withdraw service in essence replicates model of currency warehouse.

If we imagine the following layout:

person A has account in warehouse W1 and person B has its account in waerhouse W2. Both of which whidely know respectable services.
Then both persons meet on the exchange service and provide their account numbers in W1 and W2 respectively which exchange can verify with W1 and W2 directly or through broadcasting blockchain kind system.

Exchange matches both orders and broadcasts resulting instructions which will be read by W1 and W2. Then W1  can make transfer to W2 and close the transaction.

It is not as concrete as could be but general idea.

In this layout multiple matching services can service multiple warehouse services solving narrow tasks more efficiently.

It would be good to discuss this further of course.