Yet another Decentralized Exchange Topic

[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

[1715578998]

1715578998

[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'.