IOTA Pay explained

Olaf van Wijk
Aug 13, 2018 · 3 min read

In the last few weeks I have been promoting a solution to solve the ‘donation use-case’ for the cryptocurrency IOTA. In short: IOTA Addresses can only be spent from once. At the moment you expose your address it becomes unsecure the moment you spend from it. Resulting that you always have to re-issue addresses all the time.

There has been other solutions proposed so solve this but here is my take on it.

https://ecosystem.iota.org/projects/iota-pay

NOTE: This is not just an idea it already works and people are testing it!

This is for example my personal reference: https://iota-apy.herokuapp.com/#/IOTAPAY000AKRRYXDOVKRPXH9KUBEATTKWYLUJATXLKRPXWP9ZQIDUAHWENCMGQKOLHETNMAMXHPOZBVGBTWOCAOCUS

To break it down we see below a so called IOTA Pay reference: IOTAPAY000AKRRYXDOVKRPXH9KUBEATTKWYLUJATXLKRPXWP9ZQIDUAHWENCMGQKOLHETNMAMXHPOZBVGBTWOCAOCUS

With this reference we can use the IOTA Pay js api to retrieve an address from the tangle that is still unspent and was pre-exposed by the reference’s owner(me in this case).

This process is 100% tangle based, just like MAM.

So check, we got a unique reference and a 100% decentralized solution. But how does the IOTA Pay ref even gets created and can we validate that the address that is exposed is not some random address from a hacker?

If we look at the reference we will see 10 letters to start with IOTAPAY000, the observant eye will see that the 000’s are non-trytes, this is to make any action on the tangle directly to this reference invalid. So no mistakes you cannot send your funds to the reference directly.

However the rest of reference is just a standard IOTA address:

In essence what I created is an alternative means on the tangle to proof that an address is yours. IOTA Pay is just a first application of this technique.

This however could potentially be used to create transferable assets on IOTA!

But in a nutshell:

Use an encryption based seeded (by your IOTA seed) random number generator to always be able to create an elliptic curve consistent signature that includes the public key (or hash of it). The signature is hashed as an 81 tryte address, the message is then sent to that address. Allowing everyone to verify that the owner of the private key indeed ‘owns’ the address. All other messages sent to that address to be verified with the information that makes up the address.

I call this message the ORIGIN message. To validate that the address is indeed ‘claimed’ anyone can validate the signature with the public key inside the ORIGIN message. If the signature is correct you can Curl hash the signature and the result should match the address that it is sent to on the tangle. And voila you have now validated that the address ‘belongs’ to the private key holder.

Now with the private key you can sign valid IOTA address and others can validate they indeed come from the person that created the reference.

Because of snapshots all non financial data can be deleted. But by using an seeded random generator to only sign the part that claims the address it will always result in the same signature. Allowing someone to ‘reclaim’ their address/reference even after all data was deleted.

The process will be explained in more detail in the readme.md on the repo once released but this is in essence what makes IOTA Pay tick.

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