Skip to content
This repository has been archived by the owner on May 13, 2022. It is now read-only.

Select orders dynamically / send fill messages in serial #724

Open
eduard6 opened this issue Mar 25, 2017 · 0 comments
Open

Select orders dynamically / send fill messages in serial #724

eduard6 opened this issue Mar 25, 2017 · 0 comments

Comments

@eduard6
Copy link
Contributor

eduard6 commented Mar 25, 2017

Sending the !fill messages in serial might have a big benefit for Takers. Instead of selecting all orders at the start and keeping with them they could select new orders each time a Maker responds.

  1. Taker selects orders O1, O2, O3, O4 from Makers M1, M2, M3, M4
  2. Taker sends !fill to M1 and gets response
  3. Taker sends !fill to M2 and gets response
  4. Taker sends !fill to M3 but does not get response
  5. Taker selects new orders: selectOrders(include=[O1, O2], ignore=[M3])
  6. Taker's new orders are O1, O2, O6, O7 from Makers M1, M2, M6, M7
  7. Repeat until all orders are filled
    ...
  8. Possibly a similar process for !tx and !sig responses (too late because of PoDLE blacklisting by Makers?)

This would be a large help with the problem of Takers running out of commitments. They would not need a new commitment due to any number of Makers not responding. And they would nearly always get the number of Makers they wanted and minimum_makers would only be needed if there were not enough matching orders from responding Makers in the orderbook.

Implementing this would require the change in #723. If the suggestions there are used (e.g. commitment can be used 10 times) then Taker would be able to dynamically select orders up to 10 times using a single commitment (probably more since Makers that don't respond will also probably not broadcast the commitment).

Sending orders in serial would also prevent the Sybil style attack described in #693 (comment)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant