MIN_CHANGE is a privacy leak, since it is an easily observable wallet behaviour. Any output almost equal, but minimally larger than MIN_CHANGE is highly likely the change output of a tx.
Also, MIN_CHANGE is quite high, considering the value of bitcoin.
An easy fix for the second issue would be to just lower the value, but maybe some randomization can be done to also fix the first issue?
limited by payment value?
I think limited by double the payment value? Otherwise it might be easier to apply the https://en.bitcoin.it/wiki/Privacy#Unnecessary_input_heuristic ?
MIN_CHANGE is a privacy leak, since it is an easily observable wallet behaviour. Any output almost equal, but minimally larger than MIN_CHANGE is highly likely the change output of a tx.
Also, MIN_CHANGE is quite high, considering the value of bitcoin.
An easy fix for the second issue would be to just lower the value, but maybe some randomization can be done to also fix the first issue?
Will making it run time variable fix this? #6669 (review)
It will be configurable similar to long term fee rate added in #22009
Will making it run time variable fix this? #6669 (review)
No, because most users don’t change the default arguments. If there is one user changing it to another constant, it will actually be a more unique fingerprint, making it worse.
I think the solution we came up with (@Xekyo @achow101 lmk if wrong) is to get rid of MIN_CHANGE and, instead, pick the change target for each selection as a random value between 50ksat and 500ksat, also limited by payment value?
This is really just a way to cater to our existing knapsack selector mechanics, which tries to minimize the change amount over the minChange. For SRD, it would just do to have a much smaller minChange.