This repository has been archived by the owner on May 13, 2022. It is now read-only.
consider only 1 order from each counterparty before choosing #266
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I spent some time thinking about the right way to handle the issue in #197.
From one angle it looks like a very small problem that's being solved here, because the code already enforces one order being accepted from each counterparty. But as noted, the probabilities are skewed in case the choice algorithm chosen is probabilistic, because the weighting is done before that enforcement. This code uses a Python one liner to take only one order from each counterparty - the one with the lowest calculated coinjoin fee - from each counterparty before doing any selection algorithm. I put an if/else in case someone wants to make a manual choice.
(Btw in case you're wondering, reverse=True is correct here - the reason is a bit obscure).
I've done some test runs on a modified branch using new_yieldgen style yieldgen bots, further modified to artificially create multiple orders per mixdepth. I'm pretty sure it's functionally correct.
However, I can well imagine there may be further discussion about the right way to do this. Right now, I believe this would be a meaningful improvement since there are already bots running in the pit that duplicate orders over the same amount range.
And of course it doesn't address the deeper problem discussed in #197.