It's only fair to assume the majority of legit transaction of already mixed funds are to an untrusted 3rd party. If you trust that 3rd party with your privacy it'd make sense to manually change that to high anon-set. But a conservative default should be used while these things are implemented.
Example:
Send mixed coin to an exchange requiring KYC
The change still show as high anonymity set. [This is the problem]
Send that change along with more mixed coin to a political activist or a known sanctioned address.
There is a direct link between the KYC information of the fund sent to the exchange and the contentious transaction.
As mentioned here, the change does NOT have anonset 1, because it does not reveal pre-coin join history. [at least in most cases]
I see your point that when an anonset coin [and it's change] gets compromised, that then it can be misleading if you are still seeing the green shield. But it is probably impossible to make a blanket statement algorithm to figure this out...
Thus, I think a better solution would be to have the advanced option to change the shield manually, like #1980 proposes. This is also good when, for example, sending anonset coins to a new wallet of yourself, then it would show as 1, but it might actually be 500.
I couldn't care less about anonset of a fraction of 0.1 that you didn't
send to your own other wallet. That use case is ridiculous. Just send full
UTXO is you're sending to yourself - no change.
Unless otherwise stated the anon set in Wasabi UX represent anonymity value
of a utxo. There is a feature called select private utxo only. If we don't
know what a.set to give the change of a transaction it certainly should not
be the same number as the previously unused mixed 0.1.
If you're sending 0.54,
5 x 0.1 to 1wikileak377
0.4 to 1wikileak377
And 0.6 to bc1meAgain
If you can't see how later sending the 0.6 to 1Conbase is linking you
directly to 1wikileak377 I can't help you.
On Mon, Jul 22, 2019, 1:41 AM Max Hillebrand notifications@github.com
wrote:
As mentioned here
https://github.com/zkSNACKs/WalletWasabi/issues/1282#issuecomment-513643890,
the change does NOT have anonset 1, because it does not reveal pre-coin
join history. [at least in most cases]I see your point that when an anonset coin [and it's change] gets
compromised, that then it can be misleading if you are still seeing the
green shield. But it is probably impossible to make a blanket statement
algorithm to figure this out...However, I think a better solution would be to have the advanced option to
change the anonset manually, like #1980
https://github.com/zkSNACKs/WalletWasabi/issues/1980 proposes. This is
also good when, for example, sending anonset coins to a new wallet of
yourself, then it would show as 1, but it might actually be 500.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/zkSNACKs/WalletWasabi/issues/1978?email_source=notifications&email_token=AAC643EQJJSFVNNNW6IDQ33QAVB77A5CNFSM4IFTHRH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2O2KPA#issuecomment-513647932,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC643GG4YPL5I6W5YPHGXTQAVB77ANCNFSM4IFTHRHQ
.
Yes, sending full utxos is very good.
As far as I understand your proposal, this "send to hardware wallet" would be flagged as a "privacy breaking" transaction and it would show anonset 1 with red shield, which as you say does not make sense.
Yes, your example leads to linking. But I think this is already covered by the clear labeling of the coin. If you have a coin with "wikileak" in the label, and you send that to coinbase, than the user sees the link as he is selecting coins.
Requiring "Clear labeling of the coins" Is equivalent to forcing the idea that bitcoins are not fungible even after being mixed with a fee in multiple coinjoins.
If we expect users to have to learn to fallback on coin selection only for these small change then we HAVE TO remove that "Select All Private" option. BTW Wasabi UX already sucks compare to what we want it to be.

It is misleading and risky for the coin selection preset to consider these change as any private by default.
bitcoins are fungible - UTXOs are not, each is a unique snow flake :snowflake:
It is a valid concern that the Select All Private also includes change. To be honest, I dislike this button in general, because it makes it tempting to consolidate private utxos, which decreases privacy. Probably good to open another issue to disable it: #1983.
What are you trying to say? Bitcoin are comprised of UTXOs and the whole point it so make them (0.1) fungible when they've been thoroughly mixed.
The interface we're going toward is simplicity, forcing people to select their UTXO by hand is the opposite of that.
That's how I envision the UX
We could have a simple UI design that focus on having two categories of coins
Non-Private and Private with an action to make more of them private.
There would be a default anon-set and customizable threshold to mark an UTXO as being part of one category or another.
https://github.com/zkSNACKs/WalletWasabi/issues/1369#issuecomment-488738851
What are you trying to say?
I think the general message he is trying to get across is that bitcoins are fungible for the receiver but not for a privacy-oriented sender.
What are you trying to say?
I think the general message he is trying to get across is that bitcoins are fungible for the receiver but not for a privacy-oriented sender.
Fungible to the receiver aware and able to use anonymizing technologies. FTFY
bitcoin [lower case b] the currency is represented in the value field of a UTXO, denominated in sats.
UTXO [unspent transaction output] the coin contains the bitcoin, as well as the locking script that define the property rights of who can spend it and the reference to the previous input.
bitcoins are fungible - the number 1000 sats is equal to any other number 1000 sats
UTXOs are not fungible - it depends on the previous input, the redeem script, the tx id, .... ... ...
This is why Wasabi has individual coin control [non-fungible] but also the total balance of [fungible] bitcoin.
Making change anonset 0 would make people want to mix them and inevitably joining them together with pre-mix outputs.
Making change anonset 0 would make people want to mix them and inevitably joining them together with pre-mix outputs.
You're right, Merging of premix output is another problematic privacy
leaking vector and should be discouraged without careful selection based on
labels.
Therefore it'd be important not to select on behalf of the user multiple
sub UTXO when using the "Select all non-private" feature in preparation of
a CJ.
On Tue, Jul 23, 2019, 5:03 PM nopara73 notifications@github.com wrote:
Making change anonset 0 would make people want to mix them and inevitably
joining them together with pre-mix outputs.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/zkSNACKs/WalletWasabi/issues/1978?email_source=notifications&email_token=AAC643BUTUAYQRFGJEESZTLQA5W2JA5CNFSM4IFTHRH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2UN2AA#issuecomment-514383104,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC643DRPTMBBUV73RU3CUDQA5W2JANCNFSM4IFTHRHQ
.
Yes.
Because Wasabi shuffles inputs, it is unclear for an outside observer which inputs are consolidated by one Alice.
But Wasabi learns all coins during the input registration, and because we assume everyone knows what the coordinator knows, this is still not a perfectly private consolidation.
I am in favor of removing the Send All Private & Send All Non-Private buttons, because this encourages consolidation #1983.
What if you spend again from that high anon set change?
Yes, exactly, as explained here change can have anonset - and then you can spend this without revealing pre-pre-mix history.
So, I want to chime in with that I acknowledge the issue. However this is an architectural flaw in Wasabi rather than a bug. Every solution here is a serious tradeoff, those open another can of worms. That is why I would go with the default behavior: red unmixed, green mixed. Introducing a blue for the dead change would be a somewhat correct technical solution, but it'd be a detrimental one also. If even we cannot foresee the full consequences of these changes there's zero chance the user will comprehend it, too.
The solution to this is not to sweep compromises, but replacing Wasabi's mixing architecture with a better one instead.
In the meanwhile Wasabi "Select all private" is auto-merging change with a false anon-set putting people at risk of getting de-anonymized.
Dragging along this "architectural flaw" is turning more and more into negligence.
@Transisto What do you mean? Please elaborate.
People could blindly use "select all private" without much worries to their privacy if Wasabi wasn't making assumption that the change of their spents may or may not be private but deciding it most likely is and adding those in the selection.
Aaah, ok, I almost got a heart attack, because I thought you're referring to something like we're merging all the coins into a transaction, even if they aren't necessary to make the tx.
No, just a bad UX where people can't even expect privacy from the one button that claim to be doing that called "Select all private" because there isn't a way to flag change as "Definitely_not_private" once and for all and drop it's anon-set to 0, they have to be manually removed from coin selection based on labels every time before sending.
Leaving this here, From Electrum

This is implemented: https://github.com/zkSNACKs/WalletWasabi/pull/4724
One caveat is that I think it's not a good thing for current Wasabi coinjoins, but for WabiSabi coinjoins it makes the most sense.
Most helpful comment
So, I want to chime in with that I acknowledge the issue. However this is an architectural flaw in Wasabi rather than a bug. Every solution here is a serious tradeoff, those open another can of worms. That is why I would go with the default behavior: red unmixed, green mixed. Introducing a blue for the dead change would be a somewhat correct technical solution, but it'd be a detrimental one also. If even we cannot foresee the full consequences of these changes there's zero chance the user will comprehend it, too.
The solution to this is not to sweep compromises, but replacing Wasabi's mixing architecture with a better one instead.