Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[wallet] Use destination groups instead of coins in coin select #12257
This PR adds an optional (off by default)
It is a privacy improvement, as each time you spend some output, any other output that is publicly associated with the destination (address) will also be spent at the same time, at the cost of fee increase for cases where coin select without group restriction would find a more optimal set of coins (see example below).
For regular use without address reuse, this PR should have no effect on the user experience whatsoever; it only affects users who, for some reason, have multiple outputs with the same destination (i.e. address reuse).
Nodes with this turned off will still try to avoid partial spending, if the fee of the resulting transaction is not greater than the fee of the original transaction.
Example: a node has four outputs linked to two addresses
The node sends 0.2 btc to
As noted, the pro here is that, assuming nobody sends to the address after you spend from it, you will only ever use one address once. The con is that the transaction becomes slightly larger in this case, because it is overpicking outputs to adhere to the no partial spending rule.
It doesn't avoid reuse (you still need to sign for each input), and has security issues in the event of QC (but that's already a hypothetical big issue for us anyway), but seems useful anyway.
Is this affected by the current coin control grouping defect, where it includes change in the same group as unrelated outputs? That would be a serious privacy risk, I think, since it would basically tell the world which output was change.
I'm not sure what this defect is. Is it described somewhere?
@ziggamon Change outputs will go to a different destination so they will be considered separate from their inputs. In other words,
Jan 24, 2018
referenced this pull request
Jan 25, 2018
Some notes I am leaving here but to think about:
I think keeping it off by default for now is reasonable, until we get enough of an idea of the general consensus among people. I suspect, though, that most people won't care, as long as it doesn't give overly huge fee increases.
Also some people have a "permanent" address that they receive payments to over a long period of time (e.g. charities). They also care little about privacy, usually, as their address is publicly tied to them anyway.
Good point. I think the dust limit check can be added to the grouping method fairly easily.