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

When "sending all private" use "MixUntilAnonimitySet" as benchmark (?) #1371

Closed
FrancisPouliot opened this issue Apr 25, 2019 · 5 comments · Fixed by #1948
Closed

When "sending all private" use "MixUntilAnonimitySet" as benchmark (?) #1371

FrancisPouliot opened this issue Apr 25, 2019 · 5 comments · Fixed by #1948

Comments

@FrancisPouliot
Copy link
Contributor

I'm not entirely certain (and this may have been fixed if there is an issue) but I noticed that the privacy check (the green checkmark) didn't appear on transactions that had an anonimity set of 11 while our default "mixuntilanonimityset" was 10. When selecting "send all private" it wouldnt select these UTXOs. Is it possible that the benchmark for determining if a utxo is private is always set to "strong?"

I think whatever the benchmark currently is, it should be set to the "mixuntilanonimityset" benchmark since we can safely assume that this is the default one the user wants to use.

Thanks for the consideration

@lontivero
Copy link
Collaborator

The settings that you are looking for are:

  • PrivacyLevelStrong
  • PrivacyLevelFine
  • PrivacyLevelSome

These settings control the shields as well as the selection behaviour in the coin list and can be changed in the config.json file.

The setting that you mentioned is to let the client know when to stop mixing.

I don't remember if there is another setting and i am writing in the phone. Anyway, take a look at the config file.

Sent from my Moto G(4) using FastHub

@nopara73
Copy link
Contributor

nopara73 commented Apr 26, 2019

Maybe we should replace the mixuntilanonimityset that instead of it being an integer, it would be a PrivacyLevelStrong PrivacyLevelFine or a PrivacyLevelSome value? Although it's pretty low priority and not sure the benefits would justify the extra code complexity to make sure of backwards compatibility. Also it'd ruin forwards compatibility (so if you opened Wasabi once with a newer version, you'd fail to open your wallet with an older one.)

I've done a backwards compatible, but not forwards compatible change a while ago and it was quite annoying to handle the issues and questions, because of my stupid change.

@molnard
Copy link
Collaborator

molnard commented Apr 27, 2019

Francis is saying that we should change the Select All Private coins function.
We are always using the Strong privacy level for that even if the mix until is set to a lower level.

SelectAllCoins(true, x => x.AnonymitySet >= Global.Config.PrivacyLevelStrong);

Wasabi should use the mix until level when selecting private coins.

@FrancisPouliot
Copy link
Contributor Author

Francis is saying that we should change the Select All Private coins function.
We are always using the Strong privacy level for that even if the mix until is set to a lower level.

WalletWasabi/WalletWasabi.Gui/Controls/WalletExplorer/CoinListViewModel.cs

Line 316 in 0fb49c8
SelectAllCoins(true, x => x.AnonymitySet >= Global.Config.PrivacyLevelStrong);

Wasabi should use the mix until level when selecting private coins.

Yes that is what I mean, sorry for not being clear. I guess the underlying issue is what determines "private". Seems like within the project, the privacy level is almost strictly determined by the anonymity set (since everything else is pretty much private by default).

May seem like not a big issue but we often have 50+ outputs that we consolidate post-coinjoin. It actually becomes easier to make a mistake by inserting a non-private output by manually having to selecf all the ones we consider private.

@FrancisPouliot
Copy link
Contributor Author

I think I can solve this for myself by simply lowering the "privacylevelstrong" config, but perhaps there is some better system that can be thought of later. This is very low priority as far as I'm concerned.

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