Handle edge cases for cyclic selection in privacy enhanced Yield Generator #900
Conversation
Pantamis
changed the title
|
I'm just dropping a note here to say that I have seen this (and the contribution in the other repo, too), it's just I'm focusing on other things right now. |
That's ok, thanks for your consideration 👍 I still think there is one weird case where this heuristic can be improved but I have to run the experiments to confirm it increases the yield significantly to justify including it in default YG so you have time :) |
|
I started looking at this today and realized it would take me a long time to understand, the logic is very complex. I think my time is better used on other things. Perhaps someone else wants to look at it? |
| # Case where all mixdepths can fill the order: we search the mixdepth which | ||
| # stopped receiving funds the longest by looking at balances around the |
There was a problem hiding this comment.
I don't get "which stopped receiving funds the longest" part of this comment. It just looks at mixdepth total amount, not when funds were received.
|
Needs rebase. |
Not only this should increase potential maker's yield, but also overall JM orderbook liqudity. |
Context: edge cases of #808. The new cyclic order selection logic of
yg-privacyenhanced.pyis preserved in general case. However, it may return more than one mixdepths and in #808 we select the "lowest one" under the same heuristic as basic yield generator (which is not always a good choice). This PR adds a better heuristic for this case with the goal of maximizing maker's yield.When several mixdepths are returned by cyclic order selection, instead of using the lowest one, the new heuristic uses the one such that the amount of funds in the receiving mixdepth is higher. This is in order to maximize the probability that the receiving mixdepth will be used to fill bigger orders.
However, we cannot handle correctly the case where all the mixdepths can be used to fill the order with this edge case heuristic. In that case we search for the mixdepth that didn't received any funds since the longest time, we expect it has more UTXOs to consolidate and less funds. We might expect it is right after the mixdepth with most of the funds because it will received funds only if an order big enough to force the use of the mixdepth with most funds is filled. But there are other possibilities:
They are basically 4 cases depending on if there are more funds in mixdepth before the one with most funds or after and if the previous mixdepth with more funds was used already. In the end the searched mixdeph is one, two or three mixdepths after the one with most of the fund: it is either one or two mixdepths after the one with more funds (if there are more funds in mixdepth before the one with more funds than after), either two or three (if not). Comparing balances of mixdepths allow us to roughly estimate in which case we are, we compare the balance of mixdepth before with the mixdepth after the one with most of the funds and depending of the result we select the mixdepth with least funds between the two relevants mixdepths.
On simulated experiment, I saw a consistent increase of the yield when using both of these heuristics together. The resulting yield generator is very very hard to beat in terms of yields for a given choice of number of mixdepths. I tries many other strategies on simulated order amounts (from probability laws like exponential and pareto), this one is the most consistent at maximizing the maximum order size and so the yield.