English

ĞMixer, how it works

ĞMixer relies on 3 existing technologies: currency mixing, onion routing, and web of trust. This page aims to enable anyone understanding these technologies.

Summary
  1. Currency mixing
  2. Onion routing
  3. Web of trust
  4. Mix them together

Currency mixing

What is it for?

A lot of cryptocurrency mixers (aka tumblers) appeared with Bitcoin, called bitcoin mixers. Given that bitcoin transactions are not completely anonymous, these services enable users to anonymize some money.

How it works

Let Alice and Bob be two characters, and U be a monetary unit. Alice wants to secretly send 10 U to Bob.

The technical monetary protocol imposes that both the issuer and the recipient of a transaction must be known. If the transaction is directly made, we can easily track it:

Alice directly sends 10 U to Bob.

In order to prevent people from seeing the link between their accounts, they can use an intermediary, which is the mixer. If Alice wants to secretly send money to Bob, she will send money to the mixer, and will tell it to send the money to Bob.

Alice sends 10 U to the mixer, then the mixer sends 10 U to Bob.

This way, it is difficult to an external observer to notice the link between our 2 friends. However, by observing mixer's money input and ouputs, one can easily track the transaction. Thus we need the mixer to pass several transactions at the same time:

Alice, Dave and Elza want to send 10 U respectively to Bob, Carole and Fred. Each of Alice, Dave and Elza send 10 U to the mixer, then the mixer sends 10 U to Bob, Carole and Fred.

As a result, a spy wanting to know who sent 10 U to Bob, cannot distinguish Alice, Dave and Elza, who have the same probability to be the issuer of this transaction.

The centralisation problem

The previous diagram makes the transaction anonymous, but only for an external observer. The mixer knows everything, therefore its clients are at its mercy, because it may sell their data without their knowledge.

This is the problem of all the current bitcoin mixers. To solve it, we need to decentralize. Let's see how.

Onion routing

What's that?

The onion routing technology has been developed for the Tor project: it currently enables to communicate on the Internet in an anonymous and decentralized fashion, in addition to bypass censorship.

Keys for understanding

Let's explain the very basics of cryptography.

Symmetric cryptography is when a message is encrypted (people cannot read it) with a key (like a password), and it can only be decrypted with this key. Thus the key is a shared secret known by the participants. The drawback is that they have to share the key to each other by a safe way before communicating, which is sometimes impossible.

Then we take a look at asymmetric cryptography. Here, each participant has a private key (aka privkey) (like a personnal password) and a public key (aka pubkey), which may be published without problem. It's possible to encrypt a message using a person's public key, then the message will only be readable after decryption using that person's private key. There is no more shared secret, and it's way more convenient.

Alice creates a private key and gives her public key to Bob. Bob writes a message and encrypt it using Alice's public key. Alice decrypts the message using her private key, and reads it.

How it works

Using onion routing needs a servers (aka nodes) network to exist.

Let's say I want to send a message to a distant server, but without beeing recognized by it and the government.

First, I will find 3 random nodes in the network, and then enumerate them 1, 2, 3.

Next, I will append to my message the address of the server I want to contact, then encrypt the whole message using the node 3's public key. I append the node 3's address to the result and encrypt the whole using node 2's public key. I start again for node 1. The final result is a 3-layer onion, with the original message as its core.

I send the onion to node 1, which decrypts the first layer. It cannot go further, and sends the remain to node 2, using the address I gave. Nodes 2 and 3 do the same. The last node sends the message to the recipient, which sends its response following the same protocol.

The superposed layers over the message.

With such a system, each node only knows the 2 other around itself. No-one can rebuild the complete chain, so I'm anonymous, and my message is protected. (I could also encrypt it for the recipient, so the last node cannot read it)

Web of trust

What is it for?

Web of trust (WoT) is a tool allowing to prove that a given public key actually belongs to a given identity. One can be practically sure the message is sent to the wanted person, encrypted with the wanted key.

Something I haven't told you yet about asymmetric cryptography, is that it can be also used for signing. In other words, if I apply my own private key on a document, people can trust the fact (using my public key) I actually signed this document.

Another interesting property of some webs of trust, like the Duniter's one, is that each identity is linked to a unique living person, and one person can have only one identity.

How it works

WoT is simple: in order to certify the authenticity of an identity, I sign its public key, then publish this signature. It's like if you publicly said "Hey, I know this public key pertains to this person." Once the identity has received several certifications, we can be almost sure of its authenticity, even without knowing the person.

The Duniter's WoT has additional rules: only alive people must be certified, and they must have only one identity and understood what it means and what it implies to have an identity in this WoT.

Mix them together

We started with the bitcoin mixer, which had the problem of beeing centralized. Let's take a look at the onion routing and web of trust technologies.

Onion routing

Instead of passing through only one mixer, we can use the same scheme as the Tor network: the transaction passes by 3 different nodes, and the recipient's public key is in the core of the onion.

Alice (client) builds a path. She sends a 3-layer request to the node #1, which checks it and sends the 2 remaining layers to the node #2, which checks it and sends the 1 remaining layer to the node #3, which checks it and sends a confirmation the the node #2, which confirms to the node #1, which confirms to Alice. She checks the confirmations, then sends the transaction to the node #1. The transaction is relayed by the nodes until it reaches Bob.

However, a new problem appears: a node can steal the money it's entrusted with. We need to solve that with a new ingredient...

Onion contracts

Before sending money into the network, I send the onion containing the chosen nodes' addresses, and each of them respond with a signed promise, saying that if they receive my transaction, then they must send it again to the specified address, within the specified duration. If their promises are OK to me, then I send the money to the first node.

In case a node does not honor its promise, I can publish the latter, so everyone can check the signature's authenticity. If it's authentic and the promise is effectively not honored, (everybody can check that in the public transaction history), then the network's users and the nodes themselves can decide to refuse any transaction with the faulty node.

Given that a node's public key is publicly linked to its proprietary's identity, theft is strongly discouraged.