Let's talk about Autobridging as a way to improve liquidity

[pc]

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 it
https://github.com/cryptonomex/graphene/issues/609

Is this problem solved?

The problem has never existed, see my post above for a solution.

[paisea]

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 it
https://github.com/cryptonomex/graphene/issues/609

Is this problem solved?

[cube]

bump.

[xh3]

Locking the whole transaction seems unlikely, so maybe this could be implemented without a guarantee of success with the lack of certainty being the cost of the function.  maybe with estimated probability of success within a certain price range to perform the operation.   such as 90% certainty within 1.5% of target price... computed based on amount of steps and adjacent orders on the books.

[noisy]

bump

[pc]

This could solve the over filling issue (I mean if there is better price than you want).
But how about partial filling?

Partially filled orders are not completely filled and will trigger an exception if the fill_or_kill flag is set. See limit_order_create_evaluator::do_apply and database::apply_order .

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

If any of the operations in a transaction throws an exception during evaluation, the whole transaction is rolled back. (More precisely, it is only committed when no exception is thrown, see database::_generate_block)

Edit: ... oh .. going via temp account is a great idea .. that fixes a lot!

Well, yes. I attempted to create such a transaction manually and found that it's a real PITA because you essentially have to apply the full market logic with all kinds of fees etc to make sure that the TEMP_ACCOUNT ends up empty. Doable, but definitely not simple.

[xeroc]

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.

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!

[abit]

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.

This could solve the over filling issue (I mean if there is better price than you want).
But how about partial filling?

[pc]

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.

[abit]

How about that:

• Move n A from user account into TEMP_ACCOUNT
• Trade A->B
• Trade B->C
• Move m C from TEMP_ACCOUNT to user

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

It turns out that you are right. We can do it. @xeroc?

//update: I think assert operation is even better.

//update 2: best if result of an op can be used to calculate input of next op. Is it possible?

[pc]

How about that:

• Move n A from user account into TEMP_ACCOUNT
• Trade A->B
• Trade B->C
• Move m C from TEMP_ACCOUNT to user

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

[xeroc]

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 ??

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.

You can set fill/kill flag for order OPS! not for the whole transaction. That ia the issue

[abit]

How about that:

• Move n A from user account into TEMP_ACCOUNT
• Trade A->B
• Trade B->C
• Move m C from TEMP_ACCOUNT to user

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

[pc]

How about that:

• Move n A from user account into TEMP_ACCOUNT
• Trade A->B
• Trade B->C
• Move m C from TEMP_ACCOUNT to user

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

[abit]

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 ??

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.

[Samupaha]

1) USD/BTS + CNY/BTS = USD/CNY
2) USD/BTS + EUR/BTS = USD/EUR
3) BTC/BTS + USD/BTS = BTC/USD
4) BTC/BTS + CNY/BTS = BTC/CNY

the 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 books
I 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 picture
So 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 volume
Btw, 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.

Ahh, I thought you meant bitBTC because you left "bit" out of other currencies as well.

But anyway, I think that focusing on fiat-smartcoins is the way to go, at least first. We need more liquidity and tighter peg for them if we want that average people start using them. BTC isn't so high priority for me because it's mostly for traders.

[pc]

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 ??

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.

[Akado]

1) USD/BTS + CNY/BTS = USD/CNY
2) USD/BTS + EUR/BTS = USD/EUR
3) BTC/BTS + USD/BTS = BTC/USD
4) BTC/BTS + CNY/BTS = BTC/CNY

the 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 books
I 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 picture
So 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 volume
Btw, 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.

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.

At current prices isn't it enough for witnesses to have equipment with the required computing power for that? What if the price goes to 1cent?

[abit]

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.

[xeroc]

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 it
https://github.com/cryptonomex/graphene/issues/609

[Samupaha]

1) USD/BTS + CNY/BTS = USD/CNY
2) USD/BTS + EUR/BTS = USD/EUR
3) BTC/USD + BTS/USD = BTC/USD
4) BTC/CNY + BTS/CNY = BTC/CNY

the 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 books
I 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 picture
So 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.

[Pheonike]

Yeah, partial fill orders will be tricky.

[Akado]

Bridge Order Book + Bridge Order Book = Synthetic Order Book
1) USD/BTS + CNY/BTS = USD/CNY - this would be merged with the Direct USD/CNY Order Book
2) USD/BTS + EUR/BTS = USD/EUR - this would be merged with the Direct USD/EUR Order Book
3) BTC/BTS + USD/BTS = BTC/USD - this would be merged with the Direct BTC/USD Order Book
4) BTC/BTS + CNY/BTS = BTC/CNY - this would be merged with the Direct BTC/CNY Order Book

the 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 books
I 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 picture
So 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!


The thing is, how does Ripple achieve this if they want to create multiple Combined Order Books? Probably the xrp/usd pair will be used in lots of different synthetic order books, they shouldn't be restricted to one single Synthetic Order Book right? So, how do they do it? It's not like you can just cut it in half, since everyone needs the best bids/asks. You can't cut amounts in half because whoever placed the order, didn't place half of it and that's what he would get...

[Akado]

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.

[xeroc]

This is a great idea and most of this could probably be implemented in the backend by adding some more calls that can 'find potential orders' across several markets.
This however will put a lot of extra load on the API servers (the one or the other way) but I don't think that it couldn't work.

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 ??

[CLains]

Excellent idea 

[Pheonike]

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

I was thinking of this awhile ago, but didn't know the term for it. We can then create synthetic markets for low volume pairs. This would be great for the smartcoin markets.  By knowing the usd/btc price of most assets, we could calculate prices for many of the other market pairs.

[Xeldal]

Can you do triangular arbitrage? https://en.wikipedia.org/wiki/Triangular_arbitrage

Yes

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

Right.  Obviously someone is going to have to calculate these paths etc.  If its happening at the core level, that would mean, i guess, that every witness node would be making these calculations which as we scale would be an extra burden, i would think.  I'm not an expert on this but for that reason alone I'd say it should be done either by 3rd party clients or a 3rd party Market Maker.  The effect would be the same, as in, the orders would be on the book, viewable for everyone.  But only 1 client would need to process.  I think a disadvantage would be the Market Maker would have to have significant capital to build all these orders where if its native to a full node its just using whats on the book somewhere else and displaying it in another market. No extra capital required. 

[speedy]

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

If I understand correctly, you only need a path finding algorithm if you are autobridging via multiple currencies. I think all we need is to bridge via BTS, because everything trades against that on BitShares with at least some liquidity. Plus we want market pegged assets to be the eventual preferred markets, so its ideal for BitBTC and BitUSD to be bridged by BTS. I dont think anything else is needed.

[Akado]

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

[MarkoPaasila]

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

[Xeldal]

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?

[Akado]

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

The thing is, isn't this resource consuming? i mean, doing this everytime a bid/ask gets placed or a trade happens...

[bitacer]

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

[JonnyB]

Yes this is a great idea!

It was ripples best feature .

[Akado]

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 !

I also think it would make trading much more solid!

Our chain, being one of the most scalable, could handle this I hope.

[bitacer]

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 !  I always dreamed of this but couldn't articulate, autobridging is a good way to express it .

[speedy]

That diagram explains it very well, and of course BTS would be our central bridge currency.

Yes autobridging is needed! Here is why: If we had autobridging we could share links to the BTC:USD market and users would see the exact same price ranges they expect on other dollar denominated bitcoin exchanges, except without the counterparty risk. They would feel comfortable switching their exchange over to BitShares.

It sounds pretty easy to implement autobridging - we only need to bridge via BTS.

[Akado]

I've noticed there were some talks about this but I think it didn't get much attention so I decided to make this thread.

What is Autobridging?
https://wiki.ripple.com/Autobridging
https://ripple.com/dev-blog/introducing-offer-autobridging/
https://bitsharestalk.org/index.php/topic,15118.msg201331.html#msg201331

This way we would essentially have shared orderbooks and improve liquidity. Imagine if we could merge all OPEN.BTC, METAEX.BTC, TRADE.BTC markets into a single one that trades against BTS or USD. (doesnt work because users could end up with a UIA from a third party that they dont want, BTS should only be used as a bridge currency)Couldn't this, with sidechains, allow users to always get the best prices available vs multiple currencies? Sounds a pretty cool idea. It would be another reason for people to park their BTC in BitShares via our sidechain if we ever go forward with that.

As a simple example:
The BTC → BTS and BTS → USD can be synthesized into a synthetic BTC → USD. The real and synthetic BTC → USD order books can be be further synthesized into single combined order book.

Bridge Order Book + Bridge Order Book = Synthetic Order Book
1) USD/BTS + CNY/BTS = USD/CNY - this would be merged with the Direct USD/CNY Order Book
2) USD/BTS + EUR/BTS = USD/EUR - this would be merged with the Direct USD/EUR Order Book
3) BTC/BTS + USD/BTS = BTC/USD - this would be merged with the Direct BTC/USD Order Book
4) BTC/BTS + CNY/BTS = BTC/CNY - this would be merged with the Direct BTC/CNY Order Book

Do you think it's needed? Would it help? Would it be worth the effort? Why/why not?