Neutro Yellow Paper — “Probabilistic Anonymity” chapter

The “Probabilistic Anonymity” chapter presents us with the technique of encrypting the part of the transaction that contains information about the receiving address(es) and amounts involved. This data is encrypted using a symmetric key and that symmetric key is in turn encrypted using the chosen shard-chain block producer’s public key. In essence, only you, the receiver (if other than you) and shard-chain block producer knows to which address and what amount of tokens you sent from your address. But, because the information about which address you sent your tokens from and how much is visible for everyone, the network can confirm that no new tokens were created and none were destroyed. Because the shard-chain block producer can be punished, in case he acts maliciously, there is no danger of tokens being lost, as long as the network works correctly and according to the rules of the protocol.

For this to work, special “rules of anonymization” must be applied e.g. the amounts involved must be broken into specific denominations; any address used in the process must be a one-time address; decoy-addresses must be used in order to prevent analysis of the size of encrypted data (so the analyzer won’t know to how many addresses you sent your tokens to); to prevent the analyzer from knowing how many anonymizing transactions a certain amount have gone through, the amount of miner’s fee must be periodically, artificially increased… There are many nuances, but let’s keep things simple and illustrate the process with an example.

Let’s say there is a group of persons (that illustrates the users) and each one of them has an envelope with a number (that represents an address) and an amount of cash in it (that is a metaphor for tokens). Now they are gathered in a room with two additional persons — one is observer (that stands for the blockchain analyzer) and another will be doing some “mixing” with their envelopes and cash inside them (he represents the shard-chain block producer).

Users want to make sure that the blockchain analyzer, which stands in the room with them and sees everything, can’t tell from which envelope to which envelope the cash is being transferred. They do the following:

1) They write on their envelopes the amount to be taken and inserted into another envelope and the number of that envelope (receiving address); that instruction is written in such a way that only the block-producer can know it (it’s encrypted)

2) They give the envelopes to the block-producer; only he understands the instructions; as the amounts that are to be inserted into each new envelope are more or less uniform, after exchanging the envelopes there is practically no substantial difference between one of the new envelopes (ones that the cash is inserted into now) and another — they’re alike; also, the block-producer performs all of this in such a way that neither the users nor the analyzer can see from which envelope he took the cash from and into which envelope he inserted it

3) A new block-producer comes to the room, the users again do the same; and so on, every time new users are coming and some are leaving the room

Now, how can the analyzer say which of the banknotes belonged to which user originally? Because of this uniformity of amounts and one-time addresses (or envelopes in our example) he just can’t — as every time every envelope that “received” some cash is as likely to be credited with cash from one of the “sending” envelopes as from any other of them. And that envelope, that sending one, is as likely to be credited with cash from one of the preceding sending ones as from any other of them. After e.g. 20 “mixing sessions”, how can the analyzer know the trail? He would have to ask the last block-producer — the one that knows the links between envelopes. Then, the preceding one and so on, until he comes to the very first one. If even one of them refuses to cooperate, his invigilation is stopped.

At a first glance, it seems that trusting your privacy to some unknown block producers is not a good idea. But imagine that this system (Neutro) is working for some time, a year or two, and there are thousands of block producers all around the world in dozens of jurisdictions, and millions of anonymizing transactions have occurred in that time. If you are the analyzer and you want to deanonymize a certain transaction that was anonymized, let’s say 20 times in a row again and again, how exactly are you going to do that? First you have to force or bribe (this way or another), the last block-producer that did the anonymiziation, then another and another, and finally 20 of them. You don’t even know how much of them you’ll need to investigate. If even one along the way won’t cooperate, you failed. And let’s begin with the fact that all of them are anonymous, so whom exactly are you going to contact with your demand?

You can say that all of them will simply leak that information to the outside world, but why would they? Putting aside some common assumptions that only a certain threshold of actors behave maliciously, they all benefit from doing this anonymization — from transaction fees that will be much higher than for “normal” transactions; so it doesn’t make sense to destroy that mechanism from their rational perspective. And even if a fraction of them (given that anonymizing is repeated enough times) won’t destroy (by leaking data) that feature of the system, there won’t be any way to know the flow of tokens.

There are other techniques, much more sophisticated cryptographically, to obscure that flow. But every now and then some report is published that pinpoints loopholes in their design and a hard-fork is needed to patch that. If my life depended on this privacy feature, I would be better off with assuming that the entire network I’m using is not corrupt than with assuming that this time the crypto used will be “bullet-proof”.

In reality, any secret is not “bullet-proof” and any sophisticated methods involved in obscuring it are just a bet that an adversary won’t create even more sophisticated way of analyzing it. It is much safer to distribute that risk among thousands of anonymous, invested in protecting your privacy, actors with a very realistic assumption that at least a few of them won’t leak the secrets. Because this method is so simple technically, even the most powerful adversary would have to either own or corrupt the entire or almost entire system (validation tokens) or be able to control every computer and all data flowing in and out of it, connected to the network.

We could implement a wallet that would have two options of operating: normal and stealth. Normal would work, well, normally — no privacy needed from the user’s side. Once on stealth mode, every amount would go through many “anonymizing sessions” before being used for any transaction other than anonymizing one (a user could choose his level of security that would translate into number of anonymizing sessions e.g. normal, safe, extremely safe, paranoid).