Anonymity Score calculation

[lontivero]

I was working on separating the public keys (HdPubKey and SpPubKey) in Wasabi and found that one of the things difficultin this separation is the existence of at least two properties, anonymityset and cluster, which are not inherent properties of public keys but were introduced as a means of maintaining state or storing privacy level calculations there simply for convenience. Therefore, when trying to move these properties to other data structures outside of public keys, I find myself needing to understand how Wasabi's blockchain analyzer and coinjoin analyzer work. These are two very difficult pieces to understand, not simply due to code complexity or quality, but because of the unexpected concepts they use. Perhaps the most unexpected and surprising is seeing that a coin's privacy level is not only a function of how ambiguous it is but also of the coin's amount.

The fact that a coin's privacy level calculation is a function of its amount is shockingly surprising but primarily creates the need to understand why such a thing is used in the calculation.

Clearly, this doesn't make any sense, so it's necessary to delve deeper into the reasons why these variables have been used. One of these reasons apparently would be the desire to show in the user interface a number indicating the privacy level of the wallet as a whole rather than that of its individual coins—that is, presenting the user with a simple number such as 20%, 45%, 97%, or 100% that they can use to get an idea of how private their wallet, meaning their coins, really is. But this is still a fiction. Imagine we have a wallet with two coins, one of 10 bitcoin and one of 90 bitcoins. The latter has an anonymity set of 1 while the former has an anonymity set of 10. If we insist on displaying only one number to the user, what should we show? Should we show that the wallet is 50% anonymous or that it is 90% anonymous? After all, 50% of the coins are private, but 90% of the capital is in a non-private coin.

If we opt for the first calculation method, then a user with a single-utxo wallet containing 1000 bitcoins that are 100% anonymous who receives 0.001 non-anonymous bitcoin would be in for a big surprise seeing that simply by receiving that small amount, the total privacy of their wallet drops by 50%, right?

Something similar occurs during the consolidation process, since the privacy of an output equals the privacy of the least private input, a small input with a low privacy level can cause a transaction with large amounts to negatively impact its total privacy.

This is particularly important during the coinjoin process because coin selection can cause incorporating a coin of low value and low privacy level to ruin the privacy already gained by other coins of larger amounts. This means that when presenting the user with a simple number after participating in one or more coinjoin rounds, they might see how the privacy of their wallet worsens instead of improving. But the question is: has the total privacy of their wallet actually worsened? Or is it simply that the fiction created by this desire to display just one number fails to represent what is actually happening with the privacy of the individual UTXOs in our wallets?

But don't misunderstand me—showing this number in the user interface is definitely useful and helps the end user to have a notion of at least what to expect from their wallet's privacy level. This doesn't mean the software should deceive itself or believe its own fiction. On the contrary, privacy calculation must be objective and should never include the amount since this has no relationship whatsoever with the privacy level. In other words, the software must calculate the privacy level objectively using only the relevant variables to make the right decisions when helping the user preserve the privacy of their wallet. How to create or calculate the "fictional" number that should be shown to the user in the interface is a separate issue, and it's necessary to separate the concept of objective privacy calculation from the calculation of this indicator that we want to present in the user interface.

Note that the use of the word "fictional" is not pejorative. On the contrary, Wasabi has the functionality to "cancel" transactions when we know that technically this concept doesn't exist and simply creates new transactions that reverse the effects of the original transaction that we want to cancel. This is therefore a fiction but is extremely useful, just as the total privacy number of the wallet is a fiction but is extremely useful.

So what should we do? First, we need to review the current algorithm to have a complete understanding of all the concepts used and understand their reasoning and background, then unfortunately discard it, rewrite it, and also write an algorithm that calculates, based on the privacy level of each coin and its amount, a general level of privacy applicable to the wallet as a whole.