Yet another Decentralized Exchange Topic

[greBit]

Apologies if this has already been brought up a million times.

TLDR;

• A degree of centralization is needed when dealing with large quantities of fiat currency
• Mitigate this by making the centralized institutions perform only the simplest possible task
• Price discovery / market place, occurs in a decentralized fashion - in realtime

We need a decentralised mechanism for buying and selling Bitcoin

• After last night, I don't think I need to justify our need for this!

Why is it hard?

• Because we need to deal with fiat currencies over existing banking infrastructure
• Customers' dollars need to be handed over to the control of the exchange engine
• This pretty much requires centralization to be trusted/efficient/legal

Is there not some way to separate out two distinct problems involved. i.e.

• A) Having an efficient medium of communication for allowing a buyer to commit to a contract with a seller to buy X bitcoins for Y dollars
  
• B) Having a fiat currency escrow service. A clearing house.

For example:

1) Bob chooses from a list of USD clearing houses and decides to use MtBox.
2) He creates an account and does all the AML verification stuff to become authorized.
3) He transfers $10k to MtBox's account.

4) Depending on his account level, MtBox can issue Bob with a number of cryptographic tokens that act as Dollar promises.

• i.e. Just like MtGox redeem codes, but which are protected in a similar fashion to Bitcoin against double spends
• or an Alt-coin, backed by an institution, here they are backed by MtBox

5) Now he has amassed say $2k in MtBox coins he can go ahead and place trades on the P2P decentralized marketplace. Seller can chose to accept whichever Alt-coins he wants in exchange for Bitcoin.

• P2P marketplace is 100% dealing with cryptocoins
• Thus far easier to make super resilient and can easily cope with DDOS attacks/large trading volumes
• The spending of MtBox coins is like Bitcoin non-refundable, so sellers can trust it.
• The MtBox coins can be tied to the identity of the depositor, to satisfy AML regulations - the clearing house can see the source & destination of fiat currency

[1714834091]

1714834091

[1714834091]

1714834091

[1714834091]

1714834091

[greBit]

I guess having Colored Coins would be ideal - no need to have a separate MtBox alt-coin blockchain.

Depositor can just withdraw a miniscule amount of Bitcoin from his clearing house, but where MtBox adds 'colour', to specify its real USD value, along with a cryptographic signature to prevent forgeries.

[human]

How does the price discovery happen in (different from now) decentralized way? It is already decentralized. We have already a lot of exchanges around the world. People just have to stop using MtGox and switch to alternatives. That simple it is.

[greBit]

Yeah there are an increasing number of exchanges - we have mtGox, bitstamp, bitcoin-central, bitcoin.de ... - but it is still limited in number.

A motivated group of people can still fairly easily take down all of them down with a DDOS attack, or failure can happen naturally when panic sets in, overloading the exchanges.

If we had a true decentralised manner to perform the buying and selling agreements, this would be close to impossible to shut down.

Only the clearing of 'contracts' into fiat, which does not have the same real-time requirement, would need to happen over the centralised infrastructures.

[nwbitcoin]

Even with the current system, MTGox is the focal point for a lot of price indicators.
With a totally decentralised exchange, that price indicator would be a single number, which would also make the price stronger - think of it like the effect ebay has on second hand goods, where it eliminates local differences in price, and ensures everyone pays the highest market price.

It would protect bitcoin from the kind of dirty tricks that can only escalate if nothing is done now - although I can't see MTGox being very supportive of this idea!

[greBit]

Following on from the 'colored coins' idea, where we represent some subset of Bitcoin as having special value, what about ...

• MtBox maintains a special Bitcoin address, any coins that originate from this address are considered special.
• Anyone can see if a coin is of the MtBox colour and ascertain its true USD value.

1) Bob sends $10k to MtBox
2) Bob creates a Bitcoin wallet
3) When satisfied, MtBox sends a symbolic and tiny amount of Bitcoin to Bob's address. This symbolic quantity of Bitcoin will represent a specific USD amount.

Bob can then send a certain quantity of his colored Bitcoin to a seller for 'real' bitcoin.

4) The seller can send the received colored Bitcoin back to MtBox.
5) MtBox checks the transaction history of the coin, ensuring that it is indeed of the MtBox color
6) MtBox calculates the appropriate USD amount and credits it to the Seller's account.

Anyone could act as a colored coins provider (though legal issues may arise).  It would be up to the market to decide which providers to trust or not. We would see differing exchange rates between say MtBoxUSD/Bitcoin and say ZhouTongUSD/Bitcoin, according to the risk factor!

[doobadoo]

https://bitcointalk.org/index.php?topic=172705.msg1802207#msg1802207

[akhavr]

Feels like you're talking about Ripple https://ripple.com/

[Sukrim]

Yes, you just described ripple gateways...

[killerstorm]

It is actually possible to do it without centralized components at all. The idea is that Bitcoins will be held in blockchain-based escrow while USD are on the way to your account. (Inspired by posts of some guys on reddit.)

Three parties are involved

1. seller (sells Bitcoins)
2. buyer (buys Bitcoins)
3. dispute mediator

Seller and buyer agree about price, seller puts his bitcoins into 2-of-3 escrow with buyer and dispute mediator and sends his bank account details to buyer.

Buyer instructs his bank to transfer money to seller's account.

Seller will sign transaction to buyer once he receives US dollars. If there is some fuck up with sending fiat buyer is supposed to sign transaction which sends Bitcoins back to seller.

Now if they disagree, i.e. seller claims that he haven't received funds, dispute mediator intervenes, makes his judgement and transfers bitcoins to party which he thinks is right.

Collusion between dispute mediator and either of parties might be prevented via fidelity bonds.

The only potential problem I see is that it is hard for dispute mediator to check that money indeed was sent. But perhaps bank can produce some signed statement.

In that case we can think that dispute mediator is actually oracle which translates bank signatures into Bitcoin signatures. It is impartial, that is, and is easily verifiable.

[Sukrim]

Exactly this verification is the hard part, not standardized at all and might be expensive, illegal or even impossible to do depending on the bank.

[forbun]

is there a price indicator that is not based solely on mt.gox but incorporates prices across many different exchanges?

[DarkPunk]

is there a price indicator that is not based solely on mt.gox but incorporates prices across many different exchanges?

http://bitcoincharts.com/markets/

[doobadoo]

How does the price discovery happen in (different from now) decentralized way? It is already decentralized. We have already a lot of exchanges around the world. People just have to stop using MtGox and switch to alternatives. That simple it is.

Proof of work.  Orders are matched in blocks.  Clearing houses must sign a tx placed by account holder, may charge incremental fee for modifying order.  Orders overlapping at time of uncertain hash discovery are considered executed.

[doobadoo]

Okay so what would this look like technically:

Customer deposits $100 in mt gox.

Mt gox delivers token privkey to customer & account number (hash of pubkey).
Mt gox signs token pubkey with priv key and transmits to Market Makers.

Market Makers now have a UTXO table, which includes all the pubkeys corresponding to customer account balances, with custody (broker) determined by a sig script entry in the table made with the brokers private key.

They have another table (Balance of Payments, BoP) showing the sig scripts of competing brokers and their endorsements of eachother, a ledger of inter-broker debts, and credit limits brokers impose on eachother before demanding settlement.  (this table is hashed every block, and its hash is included in the following market maker block, see next steps:)

Customer places order by announcing to market makers he wishes to buy 1 bitcoin for $100 dollars.  He signs his bid transaction + fee with his token privkey (issued by gox).

A seller of 1 BTC with a bitinstant token private key signs a tx to sell it for $100

A Market maker discovers the correct proof of work and crosses the orders by making offsetting entries in the BoP table between gox and bitinstant (after checking to see that gox and bitinstant haven't exceeded their credit limits with eachother).   UTXO table is also adjusted to reflect the changes (expenditure of keys). 

Gox & Bitinstand, making note of the change in the UTXO table, issue new privkeys for $100 and 1btc, send those to the customers, and submit the public keys to miners maintaining utxo (signed by their private brokerage keys).

With all utxo accounts reassigned (balanced), miners hash UTXO  and BoP tables and include in PoW attempts to create next tx block.  If bitinstant or gox fail to deliver pubkeys after a period of time, the tx is reversed in utxo and adjustment made to BoP, new hashes would be inclued in next tx block.

When customer wants to w/d 1 btc, he presents new token private key to gox for revocation.  Gox uses customer privkey to txs a revocation of the 1 btc value assigned in UTXO.  Gox sends customer 1 btc to his client.  Bitinstand sends $100 to his customers fiat account.

[killerstorm]

Okay so what would this look like technically:

I won't pretend I understood what you wrote fully, but I think it would work much better if gox and bitinstand will issue USDcoins. (Each of their own kind.)

Then  people can trade these USDcoins via atomic coin swap transactions (which are likely much simpler than the monstrosity you outlined), and when somebody wishes to redeem USDcoins he will got with them to gox or bitinstand.

Note that p2ptrade part is already implemented, basically all you need to do is to get somebody semi-reputable to issue USDcoins.

Well, software needs polishing, but at least conceptually it is pretty much complete.

[Sukrim]

Note that p2ptrade part is already implemented, basically all you need to do is to get somebody semi-reputable to issue USDcoins.

Well, software needs polishing, but at least conceptually it is pretty much complete.

Could you link an implementation please? Seems quite interesting...

[killerstorm]

Note that p2ptrade part is already implemented, basically all you need to do is to get somebody semi-reputable to issue USDcoins.

Well, software needs polishing, but at least conceptually it is pretty much complete.

Could you link an implementation please? Seems quite interesting...

Do you mean ArmoryX, or p2ptrade specifically?

https://github.com/killerstorm/BitcoinArmory

https://github.com/killerstorm/BitcoinArmory/blob/color/p2ptrade.py

http://wiki.bitcoinx.org/index.php/P2PTrade

http://wiki.bitcoinx.org/index.php/P2PTrade2

If you want to learn something specific, you can ask me any time.

[greBit]

It is actually possible to do it without centralized components at all. The idea is that Bitcoins will be held in blockchain-based escrow while USD are on the way to your account. (Inspired by posts of some guys on reddit.)

Three parties are involved

1. seller (sells Bitcoins)
2. buyer (buys Bitcoins)
3. dispute mediator

Seller and buyer agree about price, seller puts his bitcoins into 2-of-3 escrow with buyer and dispute mediator and sends his bank account details to buyer.

Buyer instructs his bank to transfer money to seller's account.

Seller will sign transaction to buyer once he receives US dollars. If there is some fuck up with sending fiat buyer is supposed to sign transaction which sends Bitcoins back to seller.

Now if they disagree, i.e. seller claims that he haven't received funds, dispute mediator intervenes, makes his judgement and transfers bitcoins to party which he thinks is right.

Collusion between dispute mediator and either of parties might be prevented via fidelity bonds.

The only potential problem I see is that it is hard for dispute mediator to check that money indeed was sent. But perhaps bank can produce some signed statement.

In that case we can think that dispute mediator is actually oracle which translates bank signatures into Bitcoin signatures. It is impartial, that is, and is easily verifiable.

Yeah this is all well and good for the casual user who just wants to buy or sell a load of bitcoin. Its pretty much how localbitcoins work.

But you cant really have non-disputable real-time trades happening in this way. It does not prevent the buyer from deciding, "well in fact no, i'd rather not make the bank transfer since the price has just shot down!"

So thats the motivation for the tokens/contracts/colored coins etc - it backs up the buyer's promise-to-send-fiat with something more concrete than just his word.

[killerstorm]

Yes, there is probably room for more than one kind of an exchange.

[dansmith]

But you cant really have non-disputable real-time trades happening in this way. It does not prevent the buyer from deciding, "well in fact no, i'd rather not make the bank transfer since the price has just shot down!"

NB: Please understand that my involvement in this thread is not because I'm sceptical about colored coins. By no means. The more ways to enable p2p, the better. I just saw this comment and wanted to respond.

This is how SSL dumps enable real-time trading (with a caveat). Both the buyer the and seller agree to transact a real-time trade. The buyer automatically logs into his website (or his OFX API terminal) and performs the money transfer. The escrows server analyzes SSL dumps in real time and signals to the seller that money's been sent. The seller releases BTC.
The only caveat is that the buyer can revoke the transfer by contacting his bank. But the revocation is not hassle-free (I'd hope) and the buyer's real name and bank credentials are known to the escrow. So why would he revoke the payment.

P.S. jump onto my thread to continue the conversation

https://bitcointalk.org/index.php?topic=173220.0

[Sukrim]

If you want to learn something specific, you can ask me any time.

How would this work to exchange coins on 2 different chains? (e.g. Eurocoin + BTC or LTC + BTC?)

If everything's on one chain, it seems to check out (colored coins etc.) and only Bitcoins current limitations regarding fees and block size would cause issues (SERIOUS issues!) there. If coins are on completely different chains however there might be a way to at least lock funds of market participants.

[killerstorm]

If you want to learn something specific, you can ask me any time.

How would this work to exchange coins on 2 different chains? (e.g. Eurocoin + BTC or LTC + BTC?)

If everything's on one chain, it seems to check out (colored coins etc.) and only Bitcoins current limitations regarding fees and block size would cause issues (SERIOUS issues!) there.

Yes, it is a part of the colored coin client, sorry for confusion.

Bitcoin limitations affect it no more than they affect normal trade. If you're concerned about potential ban on small-value outputs, you can represent 1 USD with 0.0005 BTC, for example. I doubt that they will ban such outputs.

If coins are on completely different chains however there might be a way to at least lock funds of market participants.

Yes, there are problems with cross-chain trade, but I think it can work reliably if miners do not collude. Worst thing which can happen is your funds being locked for a couple of hours.

[mobile4ever]

It is possible to hook up anyone with a local yet decentralized market based on free software and a webhost.


It just a PHP plugin for Wordpress. That's it. Setting up face-to-face trades and such will be easy and it is possible to even make money from getting other people to use the local market.


Any PHP programmers out there?

[aaaxn]

How about making 2 party escrow for p2p exchanges? With enough collateral parties should behave responsible.

Let's suppose Alice wants to buy something for 10 BTC (this thing might be USD) from Bob.
Alice and Bob make a 2-of-2 address and simultaneously fund with BTC.
Alice sends 20 BTC (10 BTC for trade and 10 fro collateral)
Bob sends 10 BTC.
Now both parties are interested to make some agreement on trade or else both parties looses money.
If Alice will receive item and claim she didn't she will end up paying 200% price
If Bob won't send item but claim he did, he looses item value anyway.

This combined with that most people would rather loose some money than let scammer win should make such exchange relatively simple (at least for smaller sums).

EDIT:
Ideally both parties should risk same amount of money, so timeout feature after which Alice gets her extra 10 BTC would be nice. It would require more collateral (20 BTC) though.

[greBit]

How about making 2 party escrow for p2p exchanges? With enough collateral parties should behave responsible.

Let's suppose Alice wants to buy something for 10 BTC (this thing might be USD) from Bob.
Alice and Bob make a 2-of-2 address and simultaneously fund with BTC.
Alice sends 20 BTC (10 BTC for trade and 10 fro collateral)
Bob sends 10 BTC.
Now both parties are interested to make some agreement on trade or else both parties looses money.
If Alice will receive item and claim she didn't she will end up paying 200% price
If Bob won't send item but claim he did, he looses item value anyway.

This combined with that most people would rather loose some money than let scammer win should make such exchange relatively simple (at least for smaller sums).

EDIT:
Ideally both parties should risk same amount of money, so timeout feature after which Alice gets her extra 10 BTC would be nice. It would require more collateral (20 BTC) though.

Could this be the same principle that www.nashx.com works on?

[bytemaster]

2-party escrow creates prisoners dilemma between all honest parties against a thief.

If the honest parties cooperate then they can put the thief out of business.
If they defect from other honest individuals then they will profit and so will the thief.
If they do not defect and a thief does attack them, then they will lose 3x the value they would have lost anyway.

Thus, the thief can play the numbers and if the ratio of honest individuals to "honest defectors" is less than the collateral then the thief can still win in the end after scamming enough people.

This works by the thief holding the money hostage and giving you a choice:  lose 3x or x... your call.   If enough people choose to only lose x, then the thief can afford to loose 2x from time to time and make it up via profits from other defectors.

Thus... it only works in situations where you have *some* trust and is not 'trustless'.