IOTA Address Aliases: The Initial Draft


Article number 0 in the series “IOTA Address Aliases”. The next one is about motivation and goals.

One of the main problems with the current IOTA protocol is that due to Winternitz One-Time Signature Scheme we can’t use IOTA addresses more than once. Maybe this is OK for machine world, but for humans it leads to really bad user experience. Your friends can’t just save your address for future use. They should ask your current address at any given time they want to send money to you.

To solve this problem I want to propose an implementation of aliases for IOTA addresses. To fully understand the solution you need to have a basic understanding of how IOTA works and how its transactions look like. For this I highly recommend you to watch this YouTube playlist. Specifically in this video you can find information about the structure of IOTA transaction which will be useful to understand this proposal.

So, let’s begin.


Before solving a problem we need to decide what requirements we have for a possible solution. So, let’s formulate them here and try to imagine what we want from our aliases and how they should look like.

  1. 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.
  2. 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.
  3. Not mandatory: Many use-cases, especially in IoT world, can be handled perfectly well without aliases. Plus some people may prefer to continue using plain addresses without aliases because it increases their anonymity.
  4. Survival after snapshots: We don’t want to force people to remember all aliases and reattach them after each snapshot.
  5. No third-parties: Third-party services opens a huge vulnerability: what will happen if the third-party service returns a wrong address for a requested alias? Obviously the money will be send to to the wrong address and someone will lose their money. In addition to that if the third-party service is centralized it will kill one of the most important features of cryptocurrencies — decentralization.
  6. Backwards compatibility: Changes to the protocol should be as minimal as possible. IOTA nodes which don’t have aliases support should continue working without any problems.


Let’s start from the last two requirements. Yes, making changes to the already working protocol is always a pain. And we have to somehow store aliases in the tangle, because we don’t want to use a third-party solution. So, how can we deliver aliases to the tangle without changing the protocol. Should we do it in a second layer? MAM?

Luckily we already have a field in a transaction structure that can be used exactly for this purpose. This field is obsoleteTag. In the documentation here it says that the obsoleteTag field will be removed soon, but I hope it will never happen and the field will just change its purpose. Right now this filed is used only by the Coordinator for milestone indexes (correct me if I’m wrong). Well, as milestones don’t need aliases the Coo can continue using “obsoleteTag” for its purpose. All other transactions can use this field as a way to deliver aliases to the tangle. obsoleteTag contains 27 trytes which means 4.4e+38 possible values for our beloved aliases — more than enough if you ask me.

So, we have decided how aliases can be delivered to IOTA nodes. Now we have to decide how to attach an alias to a specific address. But before doing this I want to make one important notice: only an owner of the address must be able to CHANGE or REMOVE an alias from the address, but we don’t care who will ADD an alias to the address that didn’t have an alias before. Really, what can possibly go wrong in this case? As far as I can see nothing terrible can happen here.

Now considering all requirements we have for our aliases let me describe how an alias can be added to an address, how it can be changed by another alias, and how the alias can be removed from the address.

Adding an alias to the address

To add an alias to the address we need to send a transaction to the address where the “obsoleteTag” field will contain a new alias (for example “OURALIAS9OURALIAS9OURALIAS9"). The transaction don’t have to be signed.

Every node that will receive this transaction will check if the alias is unique. If it’s not the transaction will be considered “invalid” and it will never be confirmed (the same way as in “double spend” scenario). Otherwise the node will store this alias for the address and once the transaction is confirmed we can be sure that the alias is added to the address.

Changing the alias by another alias

To change the alias by another alias we need to send a transaction to the address where the “obsoleteTag” filed will contain a new alias (for example “NEWALIAS9NEWALIAS9NEWALIAS9”). In this case the transaction has to be signed.

Again every node that will receive the transaction will check if the new alias is unique and the signature is valid. If everything is ok it will replace the old alias by the new alias. Once the transaction is confirmed we can be sure that the alias was changed.

Removing the alias from the address

To remove the alias from the address we need to send a zero-value transaction to the address where the “obsoleteTag” field will be empty (“9” trytes). The transaction has to be signed in this case.

Again every node that will receive the transaction will check the its signature and if everything is ok it will remove the alias from the address. Once the transaction is confirmed we can be sure that the alias was removed.

Survival after snapshots

The last problem we need to solve is to make aliases continue to work after snapshots. Well one simple solution I see here is to just include aliases into the snapshots themselves. For example right now an ordinary IOTA snapshot looks like:

After adding aliases to the snapshot it will look like:


Let me give you an example how this is going to work in a real use-case.

Suppose we want to send 10 Miotas to some guy we want to support. We don’t know the address of this guy, but we know the alias of his address. For example it can be “AWESOMEGUYALIAS999999999999”.

To make our case more complicated let’s assume that the address we are going to spend money from also has an alias already. Because of that we’ll need to move this alias to the new remainder address. For example our address is “QGNXKYQ9CMNPMCTONCOWJSBXAA9QUZRHVXFACCNOGGCFUN9BCHYEDGSVSEQSWFURAJTOFAHCEPCYYUWSB” and its alias is “OURALIAS9999999999999999999”.

So, our steps:

  1. We insert the “awesome guy” alias into “Recipient Address” field of our IOTA wallet.
  2. The wallet determines that the “Recipient Address” is an alias (obviously by its length) and makes “getAddressForAlias” HTTP request to the full node.
  3. The full node returns the address for specified alias. For example it can be “NQEJUCZOSBWKPNHQSIBVFITUMDONZUACK99TCEOCVAGRCOACCLUETDMJQKDTFOSKNTVEISJLBIMUFOEUE”
  4. The wallet creates a bundle using the address received from the full node and send the bundle to the full node. The bundle will look like:

As you can see we have removed the “OURALIAS9999999999999999999” alias from our previous address (QGNXKYQ9CMNPMC…) and added it to the new one (TJRSZZEEJEYKZBNDEBNVTII…).

Also take attention to one important fact: we have provided the awesome guy alias together with the recipient address in the output transaction. That’s very important. We have to do it to prevent a malicious node to steal money from the user by returning incorrect recipient address to him. If the alias is specified for output transaction then all IOTA nodes must check if the specified alias corresponds to the specified address and if it doesn’t such transaction will be considered “invalid” and it will never be confirmed.

That’s basically it. After the bundle is confirmed we can consider our task done. We have sent 10 Miotas to the “awesome guy” and moved our alias from our previous (and now already spent) address to the new one.


So what we have in the results:

  1. Very robust aliases implementation. Now anyone can send you some funds without any fear that the address is already spent.
  2. Using this implementation we can create an alias for you seed — some kind of “public permanent address” that can be used as many times as you want. You can share this alias with your friends and be sure that they will never send their money to a wrong or already spent address.
  3. It’s not mandatory to use aliases. Everyone who wants to continue using plain addresses can continue to do so without any problems.
  4. There are no changes to the IOTA transaction structure. Only updates for IRI and iota-wallet are required.
  5. This solution doesn’t use a third-party service, which can trick you and steal you funds. Aliases are stored in the tangle itself.

I hope you will like this idea. If you have any questions or concerns, express them in comments. Please, be as critical as possible. I want to cover all interesting questions, concerns, edge-cases and possible attacks in my next post. For example: what will happen if the owner of the alias is trying to withdraw money from it and at the same time someone else is sending his funds to the alias ? (spoiler alert: nothing terrible will happen, only one of these two transactions will be confirmed).


Ooh, yeah, I’ve almost forgotten. Right now I’m writing a fullnode implementation for Node.js. So any financial help is much appreciated. My IOTA address is:


Unfortunately it’s not an alias yet:(


Written by


Software developer

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade