Skip to content
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

Merged
merged 1 commit into from
Oct 12, 2015

Conversation

AdamISZ
Copy link
Member

@AdamISZ AdamISZ commented Oct 10, 2015

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.

@AdamISZ
Copy link
Member Author

AdamISZ commented Oct 12, 2015

Follow up from IRC:

Applying a similar logic to choose_sweep_order is problematic. Since there's no change, and we don't know in advance the coinjoin amount, we can't discard all-but-one of the orders from a single counterparty before going through the choice algorithm. I'm not sure there's a way to enforce this without something kludgy that will fail in edge cases (i.e. occasionally result in a 'insufficient liquidity' error where it needn't). I would argue we should apply this PR as is, and then address the sweep case to whatever extent possible later.

chris-belcher added a commit that referenced this pull request Oct 12, 2015
consider only 1 order from each counterparty before choosing
@chris-belcher chris-belcher merged commit b7c6ce2 into JoinMarket-Org:master Oct 12, 2015
@chris-belcher
Copy link
Collaborator

What if all the orders from one counterparty were bundled into one object that had it's own probability weighting. Then if it's chosen pick an order from the bundle.

ghtdak pushed a commit to ghtdak/joinmarket that referenced this pull request Dec 4, 2015
consider only 1 order from each counterparty before choosing
[gitreformat yapf-ify (github/ghtdak) on Fri Dec  4 04:54:16 2015]
[from commit: b7c6ce2]
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants