Listen to the 2nd half (I think) of the most recent The Daily Bitcoin podcast https://soundcloud.com/mindtomatter/e11-armory-gli-ph-security?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheDailyBitcoinShow+%28Let%27s+Talk+Bitcoin%21%29&utm_content=FeedBurner

When talking with the Armory founder/developer he said they have the technology to basically have a sort of escrow system where in both the seller and buyer would have a key that confirms the transaction in the cloud. The coins would be locked on the cloud software (I imagine as they were first talking about Armory and then relating it to a decentralized exchange I believe) and then unlocked ONLY when the buyer and seller agrees. There would be other layers I am sure but I am just wanting to mention it as I think that part was HUGE. It is going in the right direction (technologically) to be applied for a decentralized exchange.

IAS

To clarify, the design provides:

    • Fully decentralised history of trading data; volumes traded and inter currency rates going back over time.
    • Fully decentralised history of bid/ask data; a set of the bid/ask history going back over time.
    • System will also include live bid/ask data.

This is stored in a totally decentralised way so is publically viewable to anyone on the exchange.

The decentralised history will be for all crypto to crypto and crypto to fiat trade data and bid/ask data. Graphs etc can be rendered form this as required.

Yes, this is exactly the point I made in post 12 on this thread: https://bt.irlbtc.com/view/218516.msg2306004#msg2306004

I'm still hoping that the OP has an answer to this, but it seems unlikely.

Escrow HOLDS the USD (not just locks them). That means escrow must be trusted. The "escrow" in this model is functionally a "mini-exchange".

So our system rollout is two stage:

The first stage enables crypto to crypto exchange. This uses an automated escrow enforced by the network: when two users exchange currency the network waits the for the specified number of confirmations for each blockchain, if both lots of funds are in the longest blockchains after the longest specified number of confirmations the automated escrow provides access to the new funds to each party, if they are not it provides access back to the original funds. Thus only two parties and the decentralised exchange are involved in this transaction. These types of transactions and the bid/ask data are all logged by the decentralised exchange so can be publically viewed as graphs, charts etc.

The second stage extends the automated escrow AIP to allow fiat to be exchanged for crypto using a 3rd party escrow. This could be a person operating from a personal bank account or a large organisation. The 3rd party escrow confirms that: A. Funds are in the longest blockchain after the specified number of confirmations and B. fiat has cleared into the 3rd party escrow's bank account, the escrow releases access to the crypto blockchain address to one party and transfers the USD onto the other party's bank account. Else a refund is provided.

This form of transaction requires three parties: bidder, asker and 3rd party escrow. The decentralised exchange offers a pool service for 3rd party escrows to sign up and make themselves available to bidders/askers in decentralised manner. This is a decentralized system so we are not in charge; we do not control who the escrows are and who signs up. Because the system is decentralised this will be managed by the community through a trust based system. All fiat transactions are also logged by the decentralised exchange. This means all fiat valuations, volume's traded and bid/asks along with any other information are stored in the decentralized exchange and can be can be publically viewed as graph, charts etc.

A trust based system is built into the decentralised exchange, this will be for:

    • 3rd party escrow's,; e.g. a party you know and trust trust this escrow.
    • Bidders/askers, to help identify parties that may have double spent; degrees of trust violation can vary depending on whether a transaction was double spent or an exchange failed due to errors beyond a party's control such as a blockchain programmatic error.
    • Trust will also be ascribed to specific cryptocurrencies themselves if for example they become a haven for double spending attacks and/or their blockchains prove to be programmatically unreliable.

Hope this clarifies the design a bit more.

Umm, recent US military actions (overt and covert)... Vietnam, Cuba, Grenada, Indonesia, Dominican Republic, Guatemala,Chile, Angola, Iran, Panama, Iraq, Afghanistan, Bosnia, Yougoslavia, Haiti, etc...but I'm sure you mean using legal systems right?

Financial Sanctions: Iran, South Africa, Cuba, Brazil, China, Russia, North Korea, etc...

And of course, the Patriot act is now being used to cover non-Governmental situations on a global scale.

I agree that any successful escrow system will need to be highly granular to avoid regulatory scrutiny. Just for giggles, I'd argue that the right level of granularity would require everyone that is online to potentially act as an automated escrow agent with the network randomly assigning the escrow duties. And no, I have no idea how to do this. 

No_2,

Can you address the issues brought up here about the free option given to those exchanging fiat to crypto? They have the option to default by not transferring funds, which they would do if they see the price has gone against them in the meantime.

Also, what about the general problem of latency between transacting and being able to access the funds?

Such an exchange might be fine for longer term business transactions, but seems way too slow for active trading.

I haven't read through all of the other threads on this, but I'm surprised no one has commented on the possibility of clawing back funds sent through the traditional fiat banking infrastructure.

At least in the US, a bank transfer is called ACH and suffers from the possibility of a "claw back" if the customer goes to their bank within 60 days and claims they never authorized the transfer.

A discussion of ACH technologies and claw backs can be found here:
  http://mitchellwfox.com/2012/10/26/ach-payments-for-web-developers/

No one will want to escrow fiat in the US if it can be clawed back within 60 days.

What are the "claw back" periods for SEPA or international wire transfers?   How about postgiro or bankgiro?

I don't think the clawback periods are a deal breaker, but it could limit the usefulness for fast trades unless a way to protect the escrow company was found.   I do not think reputation alone is sufficient protection; a long con to build up reputation would be easy to pull off.

[edit]

Found this wiki link with more information on "hardness" of transfers:  https://en.bitcoin.it/wiki/Payment_methods  Seems like wiretransfer (expensive) or maybe SEPA are good options for the fiat side of things.

[\edit]

how do you determine who has 'first dibs' on a bid/ask?

I agree this is a very important issue. However, the description of NACHA rules on this page:
http://www.reba.net/news/wtransfer
contradicts that description. But it was written in 2007 and maybe NACHA rules have since changed. Do you know of any other evidence for this 60 day figure?

Meanwhile, wire transfers are definitely best; they are the most cash-like transaction you can get online. Of course, they are more expensive and in general slower.

These can be tonnes of data (over time) if transactions are frequent. Will the system users pay for downloading these data? From whom? - a decentralized system of data brodcasters should be established just like a system of escrow agents.


The above is good for depth of market (DOM) analysis, but you will most importantly need:

   • Live trading data (in ticks) - data of actual transactions happening is needed to plot charts.

It would be okay if the timestamping were not just in seconds. If the system is to succeed, in future you need at least milliseconds or even microseconds (for both historical and real-time events (ticks).