Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some ideas on improving coin selection #1410

Open
kristapsk opened this issue Dec 17, 2022 · 6 comments
Open

Some ideas on improving coin selection #1410

kristapsk opened this issue Dec 17, 2022 · 6 comments

Comments

@kristapsk
Copy link
Member

  1. Currently coin selection makes no distinction between coins sent to EXTERNAL vs INTERNAL addresses. When doing coinjoin as a maker, from yield generator, IMO it would make sense to prioritize EXTERNAL UTXOs. As they are likely unmixed coins and you want to mix them ASAP.

  2. When doing payment as a taker, we could prioritize cj-out UTXOs vs others as they have potentially bigger anonymity set. This one was already discussed somewhere (IRC?).

  3. When doing non-cj simple send to P2WPKH address, we could try to select two inputs even when only one is required, so that tx looks more like a potential payjoin tx. Also discussed before somewhere. Question is does it makes sense to do it at all. Probably it does when txfee is low ("low" could be configurable, defaulting to something like 2 or 3 sat/vB), as it also cheap way to consolidate UTXOs. OTOH, if mixing taker and maker modes, it's always cheaper to consolidate UTXOs as a maker, as then taker pays the transaction fee.

These ideas involves potentially three new values to take into account when doing coin selection: a) are we in maker or taker mode, b) what is UTXO status (cj-out or something else), c) what is tx feerate.

Would love to hear counterarguments about these ideas.

@AdamISZ
Copy link
Member

AdamISZ commented Dec 18, 2022

All 3 ideas are interesting and sound, as far as I understand.

I would not say that any of them are necessary (I guess you would agree).

Would love to hear counterarguments about these ideas.

One general point: try to avoid coin selection behaviours being distinct between makers and takers, in coinjoin coin selection. While there are many flags that help distinguishing T/M behaviour, we don't want to introduce more - so that the percentage chance of a behaviour being "unambiguously from a maker", say, is increased.

For example 2. if it is a rule only applied to Taker selection, it slightly shifts that balance in the wrong direction. Actually in general, of the 3 suggested, 2 is the one I am least convinced is worthwhile.

1 is much easier to justify, but theoretically, it would also have the same issue, if it is indeed only applied to Makers.

I do realise that this 'critique' is very marginal, based on very small shifts in probabilities, but it's worth considering.

@AdamISZ
Copy link
Member

AdamISZ commented Dec 18, 2022

  1. When doing non-cj simple send to P2WPKH address, we could try to select two inputs even when only one is required, so that tx looks more like a potential payjoin tx. Also discussed before somewhere. Question is does it makes sense to do it at all. Probably it does when txfee is low ("low" could be configurable, defaulting to something like 2 or 3 sat/vB), as it also cheap way to consolidate UTXOs. OTOH, if mixing taker and maker modes, it's always cheaper to consolidate UTXOs as a maker, as then taker pays the transaction fee.

It sounds unpleasantly complicated to add this as 'yet another config var', but .. that's a minor point. The idea is at least interesting. Maybe you could go slightly further, and with some interesting probability, perhaps 30%, also make it so that the coin selection violates UIH1 and or UIH2. See here for those who don't remember what that means.

@kristapsk
Copy link
Member Author

2 is the one I am least convinced is worthwhile.

How about applying this rule only when doing non-cj sends? There you would really prefer cj-outs, to have some guaranteed anonymity set.

@AdamISZ
Copy link
Member

AdamISZ commented Dec 26, 2022

2 is the one I am least convinced is worthwhile.

How about applying this rule only when doing non-cj sends? There you would really prefer cj-outs, to have some guaranteed anonymity set.

Yes, sure that's another perfectly reasonable idea.

For a long time my perspective has been that what JM does is:

  • treat each mixdepth/account/'pocket' as one clump of funds for which there is never a guarantee of delinking between coins in them, even if, in practice, there are often delinkings. And any sweep essentially creates a new pocket.
  • Allow the user to be more fine grained than that, if they want, by giving them 100% control: coin selection (via the 'freeze' method or clicks in the GUI). At that point it's up to them.

The argument that a much more sophisticated set of rules, including things like quantification of anon set according to coin history should be used ... well for sure, you can't say it's wrong to try to do that, but at the very least, I would be cautious about somehow implying that, if the user is given 3 or 4 more simple rules, then somehow magically all the privacy problems are "fixed".

I think our very simple model is viable; it doesn't pretend that the issues can be 100% removed, they can't.

@kristapsk
Copy link
Member Author

I would be cautious about somehow implying that, if the user is given 3 or 4 more simple rules, then somehow magically all the privacy problems are "fixed".

Agree on this. One should always live with assumption that all UTXOs on the same mixdepth are linked. And we should be clear about that in docs. But doing small tricks with smarter coin selection may sometimes increase users privacy little bit.

@kristapsk
Copy link
Member Author

  1. Currently coin selection makes no distinction between coins sent to EXTERNAL vs INTERNAL addresses. When doing coinjoin as a maker, from yield generator, IMO it would make sense to prioritize EXTERNAL UTXOs. As they are likely unmixed coins and you want to mix them ASAP.

And when sending as a taker should do opposite, especially for non-cj sends. INTERNAL coins have bigger chance of having some anonymity than EXTERNAL ones.

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

No branches or pull requests

2 participants