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

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