Topic: Yet another Decentralized Exchange Topic (Read 2476 times)

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

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

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.

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?

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.



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.

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.

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://bitcointalksearch.org/topic/tlsnotary-cryptographic-proof-of-fiat-transfer-for-p2p-exchanges-173220

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

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.

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.

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

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.

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.

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.

http://bitcoincharts.com/markets/

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

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.

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.

Yes, you just described ripple gateways...

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