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

choose_sweep_orders algorithm #356

Open
AdamISZ opened this issue Dec 11, 2015 · 3 comments
Open

choose_sweep_orders algorithm #356

AdamISZ opened this issue Dec 11, 2015 · 3 comments

Comments

@AdamISZ
Copy link
Member

AdamISZ commented Dec 11, 2015

In running tumbler tests on the new versions of the yield generator (-mixdepth, -deluxe), I am getting "not enough liquidity" errors, where there is actually sufficient liquidity in the orderbook.

At the moment, it filters the orders based on minsize (not maxsize, understood: because we don't yet know the cj_amount), then passes to chooseOrdersBy and then chooses one at a time. The problem seems to be that, since it filters out all other orders from the same counterparty after choosing one, it might by chance pick too-small orders from each counterparty, and not achieve a sufficiently large list (n) of orders with a sufficient size.

This is partly ameliorated, assuming chooseOrdersBy is random weighted choice, by repeatedly trying after the liquidity error until you by chance get the orders with sufficient size. (Hence the -q option for tumbler can help). An alternative would be to choose the largest order for each counterparty, but that would mean being insensitive to cjfee price.

If we did not remove all orders from a single counterparty after trying once, then this problem goes away, but that reintroduces the problem of a maker gaming the system by flooding with lots of repeated orders.

Two questions: have I understood right, and is there a better way?

@raedah
Copy link
Contributor

raedah commented Dec 11, 2015

I havent used the tumbler much. Why doesnt it know the cj_amount? Its counter intuitive to try to pick the fill order when you dont know your cj_amount yet.

@AdamISZ
Copy link
Member Author

AdamISZ commented Dec 13, 2015

@raedah It's because of the fact that: suppose you have 3BTC in the mixdepth. You want to create a transaction to spend all of it. But, until you know exactly which counterparties you're transacting with, you don't know the fees you're going to be spending (both cjfees and tx fees). And so you don't know the exact size of the coinjoin output.

This is what makes sweep logic rather tricky. So it's specific to sweeps but not the tumbler; you can also sweep with sendpayment.

@chris-belcher
Copy link
Collaborator

Note that we don't have to assume chooseOrdersBy, we can check with

if chooseOrdersBy == weighted_order_choose:

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

No branches or pull requests

3 participants