Solving the IOTA address aliasing problem by using IOTA cheques

#IotaAlias

The alias problem

After solving the IOTA donations problem in a previous article I was left with one more enigma: how to solve the IOTA alias problem. People have been requesting for a while now to be able to use a simple alias to denote IOTA addresses because the addresses themselves are 81 trytes long and that makes them not very handy to say the least. To combat typos we even had to add a 9 tryte checksum to the address, which only makes it more tedious to type it in.

And yes, of course you can copy/paste addresses, but to be sure they simply look ugly, and if you want someone to simply be able to make sure that he is using the correct address to send to, a nice mnemonic short name would be preferable to having to compare 90 random trytes.

In addition the alias problem suffered from the one-time signing nature of IOTA addresses. Coupling an alias to a donation address, for example, was made more difficult by the fact that such an address would have to change after every spend from it. Luckily, the donation problem no longer is a problem. By turning the problem upside down I managed to come up with a solution where you can have a single address to send funds to by using the IOTA cheque mechanism I devised.

Most solutions that have been proposed to solve the alias problem involved a separate server, or even modifications to the node software. And they suffer from the problem that the alias needs to keep track of which address it is currently attached to.

The proposed solution

Well guess what, I accidentally created most of the solution by creating the IOTA cheque mechanism earlier this week. The comment I got the most from people that read my article on those cheques was that they would like to be able to use an alias. After some thinking it turns out that the IOTA cheque mechanism holds the key (pun intended) to the solution of the alias problem.

What I am proposing is that the owner of the private/public key pair of an IOTA cheque creates a transaction that stores 3 things on the cheque address associated with his public key. Remember how we can safely use the first 81 trytes of the public key that is used to encrypt the IOTA cheques as the receive address for a cheque? Chances of anyone else having that same 81 tryte prefix in his public key so small as to be in all practicality zero.

So here is what I want to store at that address in a single zero value transaction bundle:

1. An alias for the cheque address. The alias should be case insensitive and searchable, so we will use the tag field of the transaction to store the alias. That should give use 27 trytes/characters. We will encode the alias by turning it to upper case and replacing anything that is not a latin alphabet A thru Z with a 9. That way the encoded tag is kept maximally readable. So for example the tag ‘Eric’s special alias’ would be encoded as ‘ERIC9S9SPECIAL9ALIAS9999999’.
2. The public key for the cheque address. Stored in the signature part of the transaction. It can be verified that this is the public key because it starts with the 81 trytes of the address. It also gives us a first, easily verifyable, hint that this could be an alias transaction. It’s also a logical place to store it in case we want to encrypt an IOTA cheque to send here.
3. The encrypted version of the tag field, encrypted by the private key of the cheque address, also stored in the signature field. We can now verify that this tag was actually put there by the owner of the address/public key combination simply by decrypting the encrypted version with the public key and comparing it to the tag field. This is also the way in which we can determine for sure that this is actually a transaction that declares an alias for the address. And no one else could have put it there.

It would probably be desirable to specify the format of the signature field a bit more. We may want to add the type of asymmetric encryption, the encryption level, and any other necessary encryption parameters. This will be done in a future article that will describe the full technical solution.

Discussion

The proposed solution has several desirable properties:

• Tamper-proof. No one else can create that same transaction because they don’t have the private key to the cheque address.
• Fits in with the iota:// scheme discussed in the previous article. For example I could use ‘iota://alias/Eric’s.special.alias’ as an alias for the address, or even use ‘iota://request/Eric’s.special.alias’ as an alias to the cheque’s public key (which can now also be found at the cheque address).
• Multiple different aliases can be attached to the same cheque address if so desired.
• Re-uses parts of the IOTA cheque protocol that was built entirely on top of the IOTA protocol. So this integrates nicely with my previous solution.
• Completely decentralized on-Tangle solution. No external servers will be harmed in the making of aliases 😛
• Can co-exist with anything already out there on the Tangle.
• Leverages existing findTransactions() API for searching specific tags.
• Very simple to implement by wallets, especially if they already implement IOTA cheques.

There are only two problems left to solve. The only way I see for them to be solved at the moment is with some cooperation of the IRI software:

1. The uniqueness of the alias.
   Right now it is possible for anyone else to set up an alias with identical name on their cheque address. Since we cannot use timestamps reliably yet, it would be nice if there would be support from the IRI software to solve this. It can easily/quickly be detected whether a transaction is a valid alias transaction, by checking to see if the prefix of the signature field is equal to the address, and then verify that it is actually the public key that will decrypt the encrypted alias, which should match the tag field. Once such a transaction has confirmed the IRI could mark any other alias transaction with the same name as invalid so that it will never confirm. That means the wallet can simply search for the tag and only use a resulting transaction if it is an alias transaction that has confirmed.
2. Surviving a snapshot.
   In the face of possible attackers that may try to re-establish an alias transaction with the same alias before the actual owner has the chance to do so. This could be done by adding one more list to the snapshot: all addresses that had an alias with their alias. It would be up to the wallet to reattach the entire alias transaction to the cheque address and the IRI could validate the transaction against the list. That way only the original owner can re-create the alias transaction.

If anyone can come up with a better way to keep the alias unique and/or to survive a snapshot, especially without modifications to the IRI, please let me know.

Revoking/transferring an alias

(edit) I was asked if it would be possible to move an alias to another cheque address. Although this is not an event I see occurring very often, because the cheque address is not use to hold or transfer funds, I can see 2 possible future needs: revoking an alias and transferring an alias to a new owner. These can both be accomplished by introducing a revoke possibility.

Revoking could be done by creating a special transaction that proves ownership again. The simplest would be to set the tag to the same alias, and provide the public key in the signature field (so that it’s part of the alias detection functionality), but instead of encrypting the alias with the private key we could encrypt the alias prefixed by a revoke command.

In the example above we would then encrypt the alias REVOKE9ERIC9S9SPECIAL9ALIAS9999999. Note that this does not interfere with aliases that start with the work ‘revoke’ because the length of the encrypted alias is now longer.

Moving an alias to another address would then become as simple as creating a transaction bundle that simultaneously revokes the old one and creates a new alias transaction on the new address, which would now be valid. The extra logic necessary to check for the case where the alias is revoked is limited and should not happen very often. And the extra transactions will vanish with the next snapshot.

Handing over the alias to a third party could be achieved in the same way. All that the third party needs to do is provide the current owner with the public key and the encrypted alias and then the current owner can use the revoke-and-move described above. This makes a handover atomic so there is no way for someone to quickly grab the alias once it is revoked by the original owner. The new owner could even use an alias to pass the original owner the public key 😛

Conclusion

The proposed method synergistically solves IOTA’s aliasing problem and also allows for using aliases for the unwieldy public keys for the IOTA cheque mechanism. The modifications to the wallet software should be fairly simple. And even the necessary modifications to the IRI have been kept to a minimum.