IOTA-Origin

(A repost of: https://medium.com/coinmonks/iota-origin-d26b399d3cca)

An alternative reusable method to claim ownership of an IOTA address.

Origin: “the point or place where something begins, arises, or is derived.”

What is the problem exactly?

IOTA and its tangle take a novel approach to distributed ledgers with the result of fee-less and quantum secure transactions and without theoretical scaling limitations. Because of this feelessness it makes IOTA very interesting for data-centric applications that have no immediate use for a token (that is like 99.9% of the applications) but do need a DLT for the basis of decentralization and transparency.

Everything in IOTA is a transaction that sends something to an address. This can be either tokens or data. To proof the IOTA tokens are yours you will have to spend them. But the ability to proof that some data is yours is currently not possible with the exception of Masked Authenticated Messaging(MAM). Which is very well explained here:

https://medium.com/@abmushi/iota-mam-eloquently-explained-d7505863b413

For the creation of IOTA-Pay (a working solution for the donation problem: https://ecosystem.iota.org/projects/iota-pay), I studied MAM extensively and my first prototype was also based on MAM. However MAM is a streaming method and does that very well but was not completely what I needed.

What I needed was something just like the MAM root, an alternative way of proving the address is ‘yours’. So like MAM but more flexible and potentially transferable to other addresses and that also works outside of the tangle, something like:

this is my address and if I send a zero value transaction there you can be damn sure it was me who did that.
And if I direct to another IOTA address that is signed by me then you can be as sure that the 0 value transaction to that address came from the same... origin.

I won’t go into specifics here about IOTA Pay, but during its creation I believe I created something that will be extremely beneficial to the entire ecosystem. Something extremely flexible that allows us to create new starting points or origins in the tangle on which data-centric applications can build on. But lets first dive in on how it works and at the end we explore some of its potential!

How does it work?

This is a step by step explanation explaining how we can create an IOTA-Origin reference. The process is also described with a flowchart below.

• The very start of everything for IOTA-Origin is an Origin-seed. This Origin-seed can be literally anything as long as it is random enough, random binary data, 24 random words or even a traditional IOTA seed. With this Origin-seed we can then deterministically generate a public-private key pair that will be the cryptographic base for IOTA-Origin.
• The next process of IOTA-Origin is the creation of an Origin message. The Origin message contains the information that you think is important for the creation of the Origin-Reference, this can be anything: Some identifier, index, version, a date or some other claim/info. The most important part is that the public key(or its hash if you like it private) is inside the message as well. By including the public key inside the message, the message will become self validating.
• After this the origin-message needs to be signed with the corresponding private key.
• After creating a normal signature the Origin-seed is used to instantiate a Seeded Random Number Generator (SRNG). - This SRNG is then used as the RNG for the signing process of the fields that will make up the Origin-Reference. By using this method we can -at a later point in time- always re-create the (consistent)signature and thus prove we own the address and reveal it’s original contents even in the case of a snapshot!
• The consistent signature is then Hashed in a 81-Trytes Origin-reference.
• The reference is then used as an address to send the Origin-message to.

We have now claimed the address! See the workflow in the schema below.

IOTA-Origin reference creation process

Origin-reference validation
Now we have an Origin-reference we need to look at how we can validate the reference.

• If we get a reference from someone we can ask any IOTA Node to give us the transactions related to that reference(IOTA-Address).
• We need to find the latest Origin-message because potentially multiple could exists. (What is defined as ‘latest’ is application specific but generally this will be a timestamp).
• From the Origin-message we will extract the Public key.
• We validate the normal and consistent signatures. If they are invalid we can ignore the Origin-message.
• If the signatures are valid we will hash the consistent signature. If the hash matches the address the Origin-message is found on we have validated the reference.

IOTA-Origin verification process

Great! Now what?
This is the best part! Now there is an address, a location on the tangle with an associated public key. This means that everything that is sent to that particular Origin-reference can be 1) Validated that it came from the owner of the address,

1. Be directed to only the owner (encrypted message by public key) or 3) can be ignored!

It’s potential

It’s potential is massive! Because it solves a major problem for data-centric applications mainly referencing ‘owned’ data.

Each of the possibilities below could have their own medium post that I might publish later and explain how it should work in detail but for now the short descriptions give an indication on what is possible.

Publicly exposed data(IOTA-Pay)

Already referenced before but this is the use-case that actually made me develop the basics for IOTA-Origin. IOTA-Pay is already based on the principles of IOTA-Origin and works! but it extends IOTA-Origin with application specific functionality for IOTA-Pay: Namely an event-sourced mechanism that conveys contact information, transaction node preferences and most importantly: which addresses are available and safe for transferring IOTA to. That all under one single IOTA-Origin reference. IOTA-Pay just prefixes the reference with IOTAPAY000 so the API recognizes how to interpret the messages.

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

Personal account data

Any piece of software that requires some personal account data to be stored in some decentralized manner and be accessible from anywhere could use IOTA-Origin as a base to store encrypted data on the tangle. By using a single Origin-seed to also generate the keys all data can be recovered from just using your Origin-seed.

Communication

General communication requires a means of key exchange. Because IOTA-Origin provides a way to expose public keys it allows for a PGP style key exchange. This opens up the possibility for the creation of chat and other communication mechanisms on- and off-tangle. It could solve the AES key exchange required for restricted MAM streams.

Identity & verifiable claims

Since we have a single ID (Origin-reference) with a connected public key we can ask external parties to provide claims about us or have our own claims signed off by others. Since everything is connected to an Origin-reference we could build up a reputation along with it. This all in the public domain.

Transferable assets

Since you can include any type of data inside your Origin message you could include some identifier. Like a unique ID representing some asset generated by your application. Since your keys are tight to the creation of the digital asset you will be able to post a new owner in the form of a new public key signed with your own private key! It is then up to the application (just like it is now) to validate to the correct owner! Allowing for all sort of applications including anything requiring non-fungible-tokens like CryptoKitties!

Subscription based tangle indexing

Because everyone on the tangle is free to send anything to your address/reference it opens up the possibility for address spam. This spam could render any address useless because it costs the public nodes too much time/bandwidth to transfer all data on that reference to you. Essentially denying the use of that address any further. Unfortunately we seen this happen with some addresses already.

But because the owner of a reference can now prove it’s owner ship we could have an IOTA extension interface that could -on demand- remove unowned messages from the exposed ‘index’ and provide a filtered list of transactions! This could be run by yourself on your own nodes, you could provide this as a service as part of your application or as a payed public service based on a subscription model. ‘Keeping addresses clean’

Whatever you can think of

These are of course just some of IOTA-Origin’s possibilities on the Tangle I came up with but let your imagination run free and come up with some of your own!

Conclusion

In the process of creating IOTA-Pay I might have created something that might be of much more value to the IOTA-Ecosystem then what IOTA-Pay could possibly be. However IOTA-Pay is the living proof that IOTA-Origin works and to me the proof it can provide much more value to the ecosystem as an independent method.

Any questions ? Feel free to contact me on the IOTA Discord!