-
Notifications
You must be signed in to change notification settings - Fork 179
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
Comments
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).
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. |
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. |
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:
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. |
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. |
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. |
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.
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?).
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.
The text was updated successfully, but these errors were encountered: