Quote from: jaybny on February 20, 2014, 04:40:09 PM

Quote from: IamNotSure on February 20, 2014, 04:01:57 PM

Quote from: jaybny on February 20, 2014, 03:48:07 PM

So you cant really be sure of your position until the standard 6 confirmations.

Also a miner can game the system by front-running trades after solving a block.

Also there are many "latency arbitrage" "alpha" strategies that can be used to game the system, since it is possible to to make a trade in the past based on "future" information.

This is why Decentralized Distributed Exchanges for liquid assets is nearly impossible to implement.

I've read this whole thread and everything about XCP and still have not found details technical info on how the matching works, does it use "atomic transactions" ?

I have some ideas on solutions, PM if interested.. im a 15 year high frequency trading C++ coders. cheers

Hello, not sure if I can help but I've made some trades on the DEX.

Actually I've encountered a simultaneous trade with someone else (within the same block) he was first and since he took the whole order I end up with an unfilled buy order. I think that your are sure of your position as soon as the block is mined (and as long as there is no fork in BTC, which is quite rare)

About the latency arbitrages you're talking about, I have no clue but I'm really interested about this possibility and how to avoid it.

I've also red that DEXes are not (and will probably never be) suited for HFT (I remember Vitalik saying that somewhere in this thread) I have no trading vocabulary but I see the DEX as a low frequency (10m) trading engine. Which is already quite a nice innovation !

Trust me if

Quote from: halfcab123 on February 20, 2014, 04:04:24 PM

Quote from: IamNotSure on February 20, 2014, 04:01:57 PM

Quote from: jaybny on February 20, 2014, 03:48:07 PM

So you cant really be sure of your position until the standard 6 confirmations.

Also a miner can game the system by front-running trades after solving a block.

Also there are many "latency arbitrage" "alpha" strategies that can be used to game the system, since it is possible to to make a trade in the past based on "future" information.

This is why Decentralized Distributed Exchanges for liquid assets is nearly impossible to implement.

I've read this whole thread and everything about XCP and still have not found details technical info on how the matching works, does it use "atomic transactions" ?

I have some ideas on solutions, PM if interested.. im a 15 year high frequency trading C++ coders. cheers

Hello, not sure if I can help but I've made some trades on the DEX.

Actually I've encountered a simultaneous trade with someone else (within the same block) he was first and since he took the whole order I end up with an unfilled buy order. I think that your are sure of your position as soon as the block is mined (and as long as there is no fork in BTC, which is quite rare)

About the latency arbitrages you're talking about, I have no clue but I'm really interested about this possibility and how to avoid it.

I've also red that DEXes are not (and will probably never be) suited for HFT (I remember Vitalik saying that somewhere in this thread) I have no trading vocabulary but I see the DEX as a low frequency (10m) trading engine. Which is already quite a nice innovation !

Quote from: Vitalik Buterin on February 05, 2014, 12:30:32 AM

Quote from: trilli0n on February 04, 2014, 11:43:16 PM

This is an interesting concept but I don't expect widespread adoption of XCP.

First of all, its use is very limited. I don't think it will win over a single professional trader ever. In this time and age of HFT (high frequency trading) in most markets, especially the very liquid ones, where latencies are counted by the microseconds, the pace of 1 block per 10 minutes is not really going to cut it. This alone already rules out liquid markets like FX, MM, rates equities and commodities, where 99.999% of the trades are. Low Lack liquidity in XCP will translate to huge spreads and slippage from hell, making it unprofitable to trade through XCP, which in turn hurts liquidity. You can't break that vicious circle unless you can compete with the lightning speed and market depth at the exchanges. Unfortunately I don't see that ever happening. And oh, the exchange fees in these very liquid markets are negligible, especially for high volumes, so no advantage for XCP there either.

Mind you I'm not dismissing XCP, it's fantastic technology and it will have many novel applications. But I just don't think it's going to have the same level of impact as bitcoin, which was truly a paradigm shift.

I hope I'm proven wrong though!

Blockchain-based technologies in general, whether BTC, MSC, XCP or Ethereum, will not be used for HFT. The scalability is simply not there for that. OpenTransactions servers, on the other hand, are excellent for HFT. Blockchains are for higher-value transactions and settlement.

Forget about HFT. Its all about latency arbitrage. If I have the fastest quotes feeds and the fastest access to exchanges, then there are specific techniques that enable trading with nearly 100% profitability. Goldman Sacks and JPMorgan, are on a streak of hundreds of days in a row with no losses in their "prop program trading book".

In this case, its much worse, because you can decide to take the trade or give it to the original trader, depending on what happened after the trade. So you can rewrite history, it doesn't matter how frequent the trades are.

Also, if this DEX get big and there is a huge trade during a bitcoin "flash crash", I can guarantee that some group of miners/traders will front run and create a fork.

DEX can only work if you only allow trading on confirmed blocks. So basically orders can only be matched against orders that have 6 confirmations, and then you need to wait another 6 confirmations to "clear" the trade.

One idea (off the top of my head) is to have a 6 confirmation pause between "trading sessions", no trading allowed during the pause.

I think you have good points.

Taking latency arbitrage by itself: The granularity of transactions on Counterparty means that the opportunity to arbitrage is limited to gaming the Counterparty order book once every 10 minutes appropriately. That's interesting but whilst you can get your order in faster than anyone else on the DEX, everyone else in the world will be piling in orders too during that time.

The order in which orders are formed in the block is dependent on the miner. Therefore, for the low latency arbitrager it isn't deterministic so not as interesting.

However, what you then go on to describe is latency arbitrage on top of a 51% attack. This is entirely possible. Indeed there are already instances where ghash.io has been accused of gaming satoshis dice.

In fact, a miner with 51% power could deny others from accessing the DEX completely by not including Counterparty orders or cherry pick orders that it likes.

Depending on the attacker's hash rate, waiting for 6 confirmations may be insufficient. Please see section 11 calculations https://bitcoin.org/bitcoin.pdf

I'd love to hear what ideas you have to limit the ability of a large miner to game the Counterparty order book. Keep in mind though we aren't going to be able to solve a problem that is inherent in Bitcoin. That needs to be solved by the Bitcoin community. Unless of course, the utility value of Counterparty starts to outweigh the utility value of Bitcoin...