Author Topic: Relative orders clarification  (Read 2076 times)

0 Members and 1 Guest are viewing this topic.

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
Also, in addition to cost, there are some differences in what can even be accomplished in principle, due to the fact that bots can only respond with a lag and lose queue position on their order. See here for example: https://bitsharestalk.org/index.php/topic,14835.msg195515.html#msg195515

Price has priority over age, of course, so that shouldn't really be much of an issue - certainly no different from any other centralised exchange.
That may be the case that limit orders provide the same functionality as centralised exchanges. But the question was whether relative orders give a different outcome. And my linked example is a good case where it does help pegging and arbitrage.
« Last Edit: April 08, 2015, 12:05:03 pm by starspirit »

Offline monsterer

Also, in addition to cost, there are some differences in what can even be accomplished in principle, due to the fact that bots can only respond with a lag and lose queue position on their order. See here for example: https://bitsharestalk.org/index.php/topic,14835.msg195515.html#msg195515

Price has priority over age, of course, so that shouldn't really be much of an issue - certainly no different from any other centralised exchange.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
I'm more reluctant to accept that bots can accomplish the same thing as relative orders however.

Where would the difference lie?

Transactions fees is one difference.  For example, I run a bot on 10 different pairs and easily rack up somewhere around 3000 orders a day (no fees).  It could get pretty expensive on the internal exchange the more pairs your trying to make.   relative orders or something like AutoBridging would help reduce the expense.

Also, in addition to cost, there are some differences in what can even be accomplished in principle, due to the fact that bots can only respond with a lag and lose queue position on their order. See here for example: https://bitsharestalk.org/index.php/topic,14835.msg195515.html#msg195515

However the key purpose of my OP is not to challenge the priority decision, as these are an essential part of development progress. I was simply trying to understand what the source of the coding difficulty is, insofar as it may affect future design possibilities.

Xeldal

  • Guest
I'm more reluctant to accept that bots can accomplish the same thing as relative orders however.

Where would the difference lie?

Transactions fees is one difference.  For example, I run a bot on 10 different pairs and easily rack up somewhere around 3000 orders a day (no fees).  It could get pretty expensive on the internal exchange the more pairs your trying to make.   relative orders or something like AutoBridging would help reduce the expense. 

Offline monsterer

I'm more reluctant to accept that bots can accomplish the same thing as relative orders however.

Where would the difference lie?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
IMO relative orders are not worth the development time they'd take to implement.

Someone just needs to port one of the market maker bots to windows/mac and then anyone would be able to do the achieve the same thing with little effort.
Yes, based on the links above, that appears to have been the view taken by the developers till v1.0 is out, and it was inarguably necessary to prioritise things. I'm more reluctant to accept that bots can accomplish the same thing as relative orders however.

I still remain interested in the question I raised above - if there were a market with only relative orders, is this a lot more feasible because the matching is essentially just like a market with only limit orders, and it avoids dealing with the interaction between the two? This may seem like an odd and purely hypothetical question, but it has practical importance to some design possibilities I've been thinking about.

Offline monsterer

IMO relative orders are not worth the development time they'd take to implement.

Someone just needs to port one of the market maker bots to windows/mac and then anyone would be able to do the achieve the same thing with little effort.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
https://github.com/BitShares/bitshares/issues/1368
https://github.com/theoreticalbts/bitshares/blob/market_refactor/docs/market-engine-0.8.0.md
Thanks Xeroc.

I can't pretend to understand the coding side very well, but it sounds to me like one of the main things leading to difficulty is the complex interaction between limit orders and mobile (relative orders). There is another approach to market pegged assets that I've been raising in some other threads - this idea involves having one market that is just like any traditional asset market, where only limit and market orders apply with no price feed constraints (i.e. simple bid/offer, and no shorts), and a separate market where only mobile orders apply (for lenders and borrowers, settled at the feed price - elsewhere I've called this a "bank"). With this functionality separated, the bids and offers in each market would effectively be linked by market-makers and arbitragers operating between the two markets. But importantly this interaction would not need to be part of the built-in code. Ignoring whether you or others agree with such an approach for the moment, do you think that separating these markets would simplify the code-ability?
Honestly, I don't know. My expertise lies in engineering and not market dynamics. But I am sure @arhag has a opinion on this and might find your idea interesting!

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
https://github.com/BitShares/bitshares/issues/1368
https://github.com/theoreticalbts/bitshares/blob/market_refactor/docs/market-engine-0.8.0.md
Thanks Xeroc.

I can't pretend to understand the coding side very well, but it sounds to me like one of the main things leading to difficulty is the complex interaction between limit orders and mobile (relative orders). There is another approach to market pegged assets that I've been raising in some other threads - this idea involves having one market that is just like any traditional asset market, where only limit and market orders apply with no price feed constraints (i.e. simple bid/offer, and no shorts), and a separate market where only mobile orders apply (for lenders and borrowers, settled at the feed price - elsewhere I've called this a "bank"). With this functionality separated, the bids and offers in each market would effectively be linked by market-makers and arbitragers operating between the two markets. But importantly this interaction would not need to be part of the built-in code. Ignoring whether you or others agree with such an approach for the moment, do you think that separating these markets would simplify the code-ability?



Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
Back in February, theoretical made the following comment regarding relative orders. I was wondering if we could get more clarification on what was meant by "fundamental architectural limitations". Is there a fundamental property of bitAssets that does not theoretically allow relative orders (and what is it?), or is it more an issue with the way in which things are currently coded (and if so, what's the current status)? It would help understanding of what's possible and what's not.

Quote from: theoretical

TLDR, ticket in OP is still under discussion.

Some history.  A feature which has been on our road-map for some time is relative orders, where people can place a bid or ask at a given percentage of the feed, like "I want to buy at 95% of the feed and I want to sell at 105% of the feed," without having to run scripts and spam the blockchain with a ton transactions.

I was tasked with implementing relative orders (more specifically, rehauling bytemaster's implementation to use percentages of the feed instead of absolute difference from the feed, and thoroughly testing it in preparation for release).

During the testing, I found certain fundamental architectural limitations of our matching algorithm prevented us from properly matching relative orders.  The same limitations also prevent certain combinations of existing order types from matching correctly in certain circumstances, which subsequently occurred on the main network.  A community contributor (pmconrad) advised us of this, which I already suspected due to what I knew about the architecture, and confirmed in testing.

My solution was to embark on a significant refactoring of our market engine to make orders execute the way we always intended them to.  I had hoped to have it ready for initial testing this week, however I've been hugely distracted upgrading my own delegate for the 0.6.x hardfork.

bytemaster thinks I am being overly optimistic about the timetable for my refactoring, and thus is looking for a change that will fix the problems but be much less expensive (in terms of developer time).  This ticket is the solution he's hit upon.

What we need to do is sit down and discuss the options, which will happen just as soon as I finish dealing with my obstreperous delegate VPS.