Masked Authenticated Messaging (MAM) is a second layer data communication protocol which allows users to emit and access an encrypted data stream. Such data stream consists of messages which are delivered through zero-value transactions in the tangle. Each message is encrypted and signed using Merkle tree based signature scheme. The root of the Merkle tree is used as the ID of the channel. Knowing this root you can decrypt the message and validate its signature. Since a single tree only lasts for a short period of time, each message contains the root of the next Merkle tree, making it is easy for users to follow the stream.

MAM has three different modes:

Public: the Merkle root is used as the address of the transaction that the message is published to. A random user to stumbling across a message can then decode it by using the address of the message. Private: the hash of the Merkle root is used as the address of the transaction. This makes a MAM stream only readable by those who are provided with the root. This mode is depicted on the picture above. Pay attention to the transactions addresses, they are different from the roots (in the public mode they would be the same) Restricted: the hash of the authorization key and the Merkle root is used as the address of the transaction. A message publisher can stop using the authorization key without changing their channel ID (that is, the Merkle tree) so access could be in essence revoked from subscribers if desired. When a key change event occurs the new authorization key needs to be distributed to the parties that are allowed to follow the stream.

So, how can it help us with solving address aliases problem? Well, very easy. We can publish the last “unspent” address in a MAM data stream! In this case the Merkle roots of the stream will become the aliases of the last “unspent” address.

The logic is following:

Sending money

Before sending money to the recipient the user retrieves the last “unspent” address of the recipient using his alias. The alias is the root of the Merkle tree as it was said earlier. So the user can easily find the MAM data stream related to this root and retrieve the last “unspent” address of the recipient from there. The user sends money to the retrieved address.

Spending money:

Before spending money from the current address the user publishes the next address of his seed to the MAM data stream. This “next address” becomes the last “unspent” address for our alias. After the last “unspent” address is updated, the user creates a transaction that spends money from the current address.

That’s it.

By using Private and Restricted modes we can grant access only to those users who have our alias (and authorization key in case of restricted mode). That will greatly improve our anonymity as random users can’t see the history of our spending anymore. Only trusted users can see it.

In addition to that this solution allows users to have a lot of different aliases for the same address. The aliases (Merkle roots) IKQZEWUH…, A9MCODRO…, PBBPZBFP…, VMAQJWN9… from the picture above reference the same data stream and lead to the same last “unspent” address. It means you can give different aliases to the different friends of yours and all of them will be able to send money to the same address. Cool, huh?

But the biggest advantage of such approach is that it doesn’t require any changes to the protocol. No changes at all! It means we can easily implement it without touching the current infrastructure. This can be done much faster than if we need to update the nodes. Plus if a better alternative solution is found in the future it will be much easier for us to switch to it than in case if the aliases support was implemented inside the protocol itself.

So, is MAM a silver bullet for solving our address aliases problem? Well, there are several issues in this solution unfortunately. I’ll explain them all in my next article.

Stay tuned!