0 Members and 1 Guest are viewing this topic.
Quote from: xeroc on March 06, 2016, 10:37:31 amQuote from: Akado on March 05, 2016, 11:00:18 pmQuote from: xeroc on March 05, 2016, 10:17:28 pm if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??A database needs to be ACID so no one should end with an unwanted asset. If the order is snatched in an intermediate market it can't be allowed be taken some time after by anyone else as that order doesn't exist anymore. It's a different order now. However that will only be updated on the next 3 seconds right (next block)? Unless teh exchange is overloaded with people I dont think this could happen, otherwise that would have caused a problem already with people taking the same order at the same time.The database is atomic out of the fact that it is single-threaded and uses the LMAX technology ..But another trader's order in one of your intermediate markets could have been executed in the same block before your set of orders simply because it reached the current block producer first ..then you might end up in an intermediate asset ..This could probably be prevented as described above .. I'll add a github issue for ithttps://github.com/cryptonomex/graphene/issues/609Is this problem solved?
Quote from: Akado on March 05, 2016, 11:00:18 pmQuote from: xeroc on March 05, 2016, 10:17:28 pm if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??A database needs to be ACID so no one should end with an unwanted asset. If the order is snatched in an intermediate market it can't be allowed be taken some time after by anyone else as that order doesn't exist anymore. It's a different order now. However that will only be updated on the next 3 seconds right (next block)? Unless teh exchange is overloaded with people I dont think this could happen, otherwise that would have caused a problem already with people taking the same order at the same time.The database is atomic out of the fact that it is single-threaded and uses the LMAX technology ..But another trader's order in one of your intermediate markets could have been executed in the same block before your set of orders simply because it reached the current block producer first ..then you might end up in an intermediate asset ..This could probably be prevented as described above .. I'll add a github issue for ithttps://github.com/cryptonomex/graphene/issues/609
Quote from: xeroc on March 05, 2016, 10:17:28 pm if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??A database needs to be ACID so no one should end with an unwanted asset. If the order is snatched in an intermediate market it can't be allowed be taken some time after by anyone else as that order doesn't exist anymore. It's a different order now. However that will only be updated on the next 3 seconds right (next block)? Unless teh exchange is overloaded with people I dont think this could happen, otherwise that would have caused a problem already with people taking the same order at the same time.
if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??
This could solve the over filling issue (I mean if there is better price than you want).But how about partial filling?
Is that really true? Arent they independently evaluated and in a chain of orders that breaks in the middle everything after the crack will be killed but all the orders before are filled.Kill-fill flag is for ops .. not for transactiosn .. what am i missing here
Edit: ... oh .. going via temp account is a great idea .. that fixes a lot!
I think it's even simpler than that. Just put all required orders into a single transaction and set the fill-or-kill-flag for each of them. Then if any of the orders isn't filled the whole tx will fail.
Quote from: abit on March 06, 2016, 05:00:45 pmQuote from: pc on March 06, 2016, 03:08:31 pmHow about that:Move n A from user account into TEMP_ACCOUNTTrade A->BTrade B->CMove m C from TEMP_ACCOUNT to userIf any one of the trades is filled only partially then the next step will fail and the transaction will be rolled back.The downside is that if the user gets a better deal than expected at some point, the TEMP_ACCOUNT will end up non-empty and the TX will also be rolled back.Trade contains 2 steps, place order+fill order. Only place order is in transaction. You can't get another asset immediately after placed the order. So step 3 will fail.Are you sure?AFAICS order matching takes place during the evaluation of order_create and includes modification of the account balances. So after the evaluation of step 2 the TEMP_ACCOUNT should already have been credited with B.
Quote from: pc on March 06, 2016, 03:08:31 pmHow about that:Move n A from user account into TEMP_ACCOUNTTrade A->BTrade B->CMove m C from TEMP_ACCOUNT to userIf any one of the trades is filled only partially then the next step will fail and the transaction will be rolled back.The downside is that if the user gets a better deal than expected at some point, the TEMP_ACCOUNT will end up non-empty and the TX will also be rolled back.Trade contains 2 steps, place order+fill order. Only place order is in transaction. You can't get another asset immediately after placed the order. So step 3 will fail.
How about that:Move n A from user account into TEMP_ACCOUNTTrade A->BTrade B->CMove m C from TEMP_ACCOUNT to userIf any one of the trades is filled only partially then the next step will fail and the transaction will be rolled back.The downside is that if the user gets a better deal than expected at some point, the TEMP_ACCOUNT will end up non-empty and the TX will also be rolled back.
Quote from: pc on March 06, 2016, 01:31:06 pmQuote from: xeroc on March 05, 2016, 10:17:28 pmBUT, in contrast to Ripple, BitShares won't be able to guarantee atomic trades across several markets. Even though you could put multiple order operations into a single transaction .. and could even use the "fill-or-kill"-flag (already available today) .. if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??Aren't transactions all-or-nothing? In that case you'd "only" have to construct a transaction that fails in the last step if not everything went as planned. Perhaps using the assert operation? Or with the temporary account?I'm sure there is a way to do that without a hardfork, and without additional load on the witness nodes.Fill_order is virtual operation, which is out of the transaction's control. So I don't think assert_operation will help much here.
Quote from: xeroc on March 05, 2016, 10:17:28 pmBUT, in contrast to Ripple, BitShares won't be able to guarantee atomic trades across several markets. Even though you could put multiple order operations into a single transaction .. and could even use the "fill-or-kill"-flag (already available today) .. if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??Aren't transactions all-or-nothing? In that case you'd "only" have to construct a transaction that fails in the last step if not everything went as planned. Perhaps using the assert operation? Or with the temporary account?I'm sure there is a way to do that without a hardfork, and without additional load on the witness nodes.
BUT, in contrast to Ripple, BitShares won't be able to guarantee atomic trades across several markets. Even though you could put multiple order operations into a single transaction .. and could even use the "fill-or-kill"-flag (already available today) .. if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??
Quote from: Samupaha on March 06, 2016, 07:41:52 amQuote from: Akado on March 06, 2016, 12:00:35 am1) USD/BTS + CNY/BTS = USD/CNY2) USD/BTS + EUR/BTS = USD/EUR3) BTC/BTS + USD/BTS = BTC/USD4) BTC/BTS + CNY/BTS = BTC/CNYthe first 2 or the last 2?if we use USD/BTS for USD/CNY as the first case and for BTC/USD as the third case, wouldn't we be messing things up?We should decide what Synthetic order books to create/combined order booksI think it's best if we first know what Combined Order Books we need the most, and from there build the Synthetic Order Books as seen on the pictureSo I would guess the last two markets (BTC/USD and BTC/CNY) make more sense for the general trading population, meaning we should get BTC/USD + BTS/USD and join them creating a Synthetic Order Book (BTC/USD) which we would then merge with the Direct Order Book BTC/USD and do the same for CNY+Bitcoin Side Chain=Combo Break!I'd go for the first two. If we are going to make a Bitcoin sidechain, that will lead to diminishing demand for bitBTC so it doesn't make much sense to invest on that. And on the other hand, fiat-pegged currencies on the blockchain are one of our biggest strengths and they should be supported always when possible.What? Imo that doesn't make much sense. If we want a Bitcoin sidechain, the way to support it is doing the last two, because that way we have fiat supporting BTC right? With the first two we are only supporting fiat and not Bitcoin, which doesn't really make sense if we make a sidechain because theoretically bitcoin pairs should have the most volumeBtw, I did that last night and now I noticed the last two pairs didn't make sense. I mixed Synthetic and Combined Order Books, my bad! Maybe that made you think that way.And when I say BTC, in this case I mean SIDE.BTC if we ever do the sidechain thing.
Quote from: Akado on March 06, 2016, 12:00:35 am1) USD/BTS + CNY/BTS = USD/CNY2) USD/BTS + EUR/BTS = USD/EUR3) BTC/BTS + USD/BTS = BTC/USD4) BTC/BTS + CNY/BTS = BTC/CNYthe first 2 or the last 2?if we use USD/BTS for USD/CNY as the first case and for BTC/USD as the third case, wouldn't we be messing things up?We should decide what Synthetic order books to create/combined order booksI think it's best if we first know what Combined Order Books we need the most, and from there build the Synthetic Order Books as seen on the pictureSo I would guess the last two markets (BTC/USD and BTC/CNY) make more sense for the general trading population, meaning we should get BTC/USD + BTS/USD and join them creating a Synthetic Order Book (BTC/USD) which we would then merge with the Direct Order Book BTC/USD and do the same for CNY+Bitcoin Side Chain=Combo Break!I'd go for the first two. If we are going to make a Bitcoin sidechain, that will lead to diminishing demand for bitBTC so it doesn't make much sense to invest on that. And on the other hand, fiat-pegged currencies on the blockchain are one of our biggest strengths and they should be supported always when possible.
1) USD/BTS + CNY/BTS = USD/CNY2) USD/BTS + EUR/BTS = USD/EUR3) BTC/BTS + USD/BTS = BTC/USD4) BTC/BTS + CNY/BTS = BTC/CNYthe first 2 or the last 2?if we use USD/BTS for USD/CNY as the first case and for BTC/USD as the third case, wouldn't we be messing things up?We should decide what Synthetic order books to create/combined order booksI think it's best if we first know what Combined Order Books we need the most, and from there build the Synthetic Order Books as seen on the pictureSo I would guess the last two markets (BTC/USD and BTC/CNY) make more sense for the general trading population, meaning we should get BTC/USD + BTS/USD and join them creating a Synthetic Order Book (BTC/USD) which we would then merge with the Direct Order Book BTC/USD and do the same for CNY+Bitcoin Side Chain=Combo Break!
Thicker orderbooks but maybe most of the orders are with high spread? Technically we can do this, but it need more computing on witness nodes though. Partial filling won't be a problem anyway.
1) USD/BTS + CNY/BTS = USD/CNY2) USD/BTS + EUR/BTS = USD/EUR3) BTC/USD + BTS/USD = BTC/USD4) BTC/CNY + BTS/CNY = BTC/CNYthe first 2 or the last 2?if we use USD/BTS for USD/CNY as the first case and for BTC/USD as the third case, wouldn't we be messing things up?We should decide what Synthetic order books to create/combined order booksI think it's best if we first know what Combined Order Books we need the most, and from there build the Synthetic Order Books as seen on the pictureSo I would guess the last two markets (BTC/USD and BTC/CNY) make more sense for the general trading population, meaning we should get BTC/USD + BTS/USD and join them creating a Synthetic Order Book (BTC/USD) which we would then merge with the Direct Order Book BTC/USD and do the same for CNY+Bitcoin Side Chain=Combo Break!
Quote from: Xeldal on March 05, 2016, 08:17:55 pmAutobridging would be very nice indeed.In the mean time. I've set up a bot with a similar function, that is at least watching a bunch of pairs on the DEX and will route them through various other pairs including many external exchanges 2 and 3 hops if there is a match. It is nice that there is this connection but it would be much better if the orders were actually viewable on the book. A bot could certainly place these orders themselves in a copy cat fashion but I havn't identified all the risk for this or how best to approach it myself.At the moment I'm watching just over 400 different routes, 18 coins, on 6 exchanges including the DEX.So the books may look empty but many of them are in fact being watched, and will take your order if it is good.What are the advantages/disadvantages of having the DEX itself do this vs. a 3rd party replicating the function?Can you do triangular arbitrage? https://en.wikipedia.org/wiki/Triangular_arbitrage
Autobridging would be very nice indeed.In the mean time. I've set up a bot with a similar function, that is at least watching a bunch of pairs on the DEX and will route them through various other pairs including many external exchanges 2 and 3 hops if there is a match. It is nice that there is this connection but it would be much better if the orders were actually viewable on the book. A bot could certainly place these orders themselves in a copy cat fashion but I havn't identified all the risk for this or how best to approach it myself.At the moment I'm watching just over 400 different routes, 18 coins, on 6 exchanges including the DEX.So the books may look empty but many of them are in fact being watched, and will take your order if it is good.What are the advantages/disadvantages of having the DEX itself do this vs. a 3rd party replicating the function?
Can you do triangular arbitrage? https://en.wikipedia.org/wiki/Triangular_arbitrage
Quote from: Xeldal on March 05, 2016, 08:17:55 pmWhat are the advantages/disadvantages of having the DEX itself do this vs. a 3rd party replicating the function?It might put a load on the chain due to always having to calculate a path no? But the advantage would be it would be accessible to anyone which is what we are aiming for. It would appear in the books right? At least I'm assuming so.Since our chain is known by its scalability it should be able to handle it.
What are the advantages/disadvantages of having the DEX itself do this vs. a 3rd party replicating the function?
" Ripple’s Path Finding Algorithm looks for the cheapest path for payments to move across the network. In this context, “cheapest” means the path that incurs the least bid/ask cost for the sender of a pay- ment." Ripple is much advanced than I thought.
This is a must and a killer feature to make BitShares a universal platform. This could enable thousands or even millions of community currencies to function on BitShares. A real resilient ecosystem with diversity , just like a jungle full of vibrant organisms complimenting each other. Well done Akado for bringing this up !