Topic: Proposal: Fully Decentralised Exchange Mechanism for All Cryptocurrencies & Fiat - page 2. (Read 9951 times)

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

Multiple escrow agents will contribute to the safety of the system. It could work like TOR / Vidalia - you may choose to (i) work as a client only or / and (ii) relay traffic (render escrow services for a fee).

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.

Don't jump to conclusions... I think that their idea here is awesome.

They're saying that the network, like bitcoin is open. And that one client software (like bitcoin-qt) is open, and another client software (Like armory) is to be closed and sold so that they can make some money.

That's a great way to monetize open source.

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

here we go again,


http://www.coindesk.com/uk-firm-promises-skype-style-bitcoin-exchange/

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]

I have been thinking of a similar concept, the only problem is you can only store fiat in the form of debt, if one could determine whether a debt has been paid out via a simple true/false variable (if every money transmitter theoretically offered a JSON api for example) then you could create a more elegant system like Bitcoin that would also be completely decentralized but better suited for the existing infrastructure.

I am however quite happy with BTC, being the hardcore that I am central banks are evil.

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.

Thanks for the warm reception everyone. We're grateful for the positive reactions and all the support we've received so far. We'll be keeping an eye on this thread and making announcements as and when appropriate.

I know that many of you have still got a lot of questions, so we're aiming to do an AMA on http://redd.it/1f7p7z in about three weeks or so.

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. 

/s/escrow/exchange/ ....   

(+ of course wiring money to Cuba would be an interesting proposition!)

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.

So there will be a feedback system? Or at least a ratings system for escrow accounts?

I think the idea is to create so many escrow options that trying to regulate or shut down all of them would be impossible.

If someone setup a major escrow in the Caymans or Cuba I dont think there is much the US Gov could do about it.

(also consider changing the thread title to include MetaLair, although I think that name could be revised...)

Yes, this is exactly the point I made in post 12 on this thread: https://bitcointalksearch.org/topic/m.2306004

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

I think this is a good idea & design wise it's great for the exchange platform as bringing a different approach to the table.

I might of misunderstood it, but is it a bit how localbitcoin works, but taking it step further, so your not even having to worry about the escrow aspect yourself (as an exchange), instead allowing your own members to do that.

To confirm, technically this is a platform where you have 3 types of members you hoping to bring in;

1: Buyers (of BTC with local currency)
2: Sellers (of BTC for local currency)
3: Escrows (hold BTC and local currency)

My only concern is some Escrow members will end up acting on such a large scale with Local (and sometimes foreign) Currency going through their accounts, they'll have no choice but to make sure legally they have applied to run as a money service business (MSB), just like most exchanges do. There is relatively few people I'd actually trust to be an escrow and I'm sure others feel the same way, so as pointed out, their will end up being favouritism of certain escrow's.

How do you plan to make sure, every escrow is being run legitimately?
Then also handling if they get in trouble with local law enforcement, while doing business on your site?

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.

Well said. It is just sad that people would do something like that to another just over money.

But, my lesson was learned and it didn't cost me much $$$. Now I know what to expect in the future so if and when I do sell, I won't do so as to give the buyer some form of "F*CK ME" insurance.

IAS

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

This is what we in the biz call a "free option". The higher the volatility, the more valuable this option is to its holder (the buyer of BTC) and the more value taken from the writer (you). You can argue that this is institutionalized theft, and even with a 12 hour wait time the volatility of BTC can be so high that it's worth it for the buyer to accept being banned.

The other problem is the long confirmation takes away the buyer's option to sell immediately (no good for short term trading).