Imagine if every seed could have a some kind of “public permanent address” that you can share with everyone.

The “VXIOZRXYWEAXPOSUOMXMVKORSPB” is our “public permanent address”. You can send it to your friends, they will store it and later will be able to send you money without having to request your current “unspent” address every moment. Cool, huh?

This is the first article in the series “IOTA Address Aliases” where I will provide detailed explanation how this feature can be implemented in IOTA using so called “address aliases”, what other options we have to implement the feature and why the chosen option is better then others. In my previous article IOTA Address Aliases: The Initial Draft I explained the general idea (this article has kinda “number 0” in the series). The solution provided there had some issues, but they are already solved. I will explain them in my next posts. In this article I want to explain you why we so much need this feature and describe the requirements we have for a possible solution.

So, first of all, what are these “address aliases”? An address alias is a random string attached to a particular IOTA address. Every time we send money from this address the alias is being reattached to the next “remainder” address. That allows us to always get the latest “unspent” address of the user if we know his alias.

With aliases we can implement our “public permanent addresses” for our seed which were mentioned earlier. But it’s not the only way to use this feature. It opens a lot of new opportunities. Let me give you examples of some of them:

Address book. Like it was said earlier, now you can store addresses of your friends and relatives and send them money whether without disturbing them at all or with “post factum” notification. Like: “Hey, honey. I’ve sent you 100 MIota. Have fun tonight and don’t deny yourself anything!” Donation. It’s very hard to use IOTA for donation right now. You literally have to remember all places where you have posted your donation addresses and change them every time you spend money them. There are several different solutions to this problem, but all of them whether involves a third-party service, which is not secure, or require a lot of actions and are not so convenient as a “public permanent address”. Telegram-like messenger. The messenger’s data will be stored entirely inside the tangle. Using our aliases with MAM you’ll be able to send messages (or money) to your friends, create secure private channels, create public news channels and so on. No third-parties. No side servers. Only a client-side application. No one can censor, block or steal information from it. Plus all people who will use this messenger will be helping the network by spamming it (at least at the beginning, until we reach the max possible TPS limited by the law of physics). Online gaming, social networks and any other applications which require a some kind of permanent addresses will become much easier to implement. You’ll be able to buy your beloved “Dwarf’s Sword Of Justice” with IOTA. I don’t say that it’s impossible to implement right now. Everything is possible. But it will become much easier with “permanent addresses”. The less information you need to store on a your own server — the better. As an addition you’ll can shut up all FUDsters who are crying that IOTA can’t be used by humans because its addresses can be used only once. Small, but very nice benefit :)

Now, when we are very motivated let’s formulate a list of requirements for a possible solution. Let’s imagine what we want from our aliases and how they should look like.

Not mandatory: If a user don’t want to have an alias for his seed, nobody should force him to have it. Many use-cases, especially in IoT world, can be handled perfectly well without permanent addresses. Plus some people may prefer to use “not reusable” addresses because it increases their anonymity (payment history is public after all). Multiple aliases for one seed. Having more then one alias for a seed can be very handy in you financial management. For example, you’ll be able to have different aliases in different application, but all of them will send money to the same seed. Independence from seeds or addresses: An alias must not be a result of some function applied to an address, or seed, or something else. It must be just a random string attached to a particular address. If a user wants to reattach the alias to any other address he should be able to do it at any given moment. This random string can look like “VXIOZRXYWEAXPOSUOMXMVKORSPB” as in the example above or it can be something meaningful, for example “ALEXWALLET”. Uniqueness: Aliases must be unique in the system. If some alias is already being in use by someone else you must not be able to use it for your address. Survival after snapshots: We don’t want to force people to remember all aliases and reattach them after each snapshot. Plus some malicious user can be very quick and manage to reattach your alias before you. In this case he’ll be able to collect all money the other users will send to you thinking that you’re still using that alias. No third-parties: Third-party services open a huge vulnerability: what will happen if a third-party service returns a wrong address for a requested alias? Obviously the money will be sent to to the wrong address and someone will lose their funds. In addition to that if the third-party service is centralized it will kill one of the most important features of cryptocurrencies — decentralization. Minimal changes to the protocol (or better no changes at all): making changes to the already working protocol is always a pain. So any solution in our research which doesn’t require changes to the protocol will always prevail over solutions that require such changes (if all other factors are being equal of course).

In the next articles I will provide the solution which satisfies all these requirements. If you so eager to know everything right now, take a look at my previous article. Some things have changed, but the main idea remained the same.

Stay tuned!