joinmarket-clientserver icon indicating copy to clipboard operation
joinmarket-clientserver copied to clipboard

Handle edge cases for cyclic selection in privacy enhanced Yield Generator

Open Pantamis opened this issue 3 years ago • 5 comments

Context: edge cases of #808. The new cyclic order selection logic of yg-privacyenhanced.py is 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.

Pantamis avatar Jun 09 '21 01:06 Pantamis

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.

AdamISZ avatar Jun 17 '21 11:06 AdamISZ

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 :+1:

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 :)

Pantamis avatar Jun 17 '21 12:06 Pantamis

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?

AdamISZ avatar Sep 03 '21 14:09 AdamISZ

Needs rebase.

kristapsk avatar Nov 05 '23 11:11 kristapsk

This PR adds a better heuristic for this case with the goal of maximizing maker's yield.

Not only this should increase potential maker's yield, but also overall JM orderbook liqudity.

kristapsk avatar Nov 05 '23 11:11 kristapsk