A second layer approach

To make a solution that works and is completely verifiable without the need for any third party we have identified some key requirements for any solution that attempts to solve this problem. Different second layer approaches have been proposed to tackle this issue for IOTA but all of them missed one or more of these key features:

It requires a single reusable and unforgeable reference, alias, account, address etc. The main point here is that it needs to be something verifiable unique. Someone must independently be able to verify the correctness of a such a reference and be able to identify fraudulent behavior. The source of all information that is sent to this reference/address must be verifiable. This so that when we expose an unused address we at least know it is the same person doing it. IOTA Seeds must never leave the client. No solution should ever require a seed to be send to a back-end service to work. Nor should a seed be generated and stored in such a back-end service. This compromises the very basic security guarantees that DLT’s in general stand for. This automatically means that IOTA specific addresses must be generate on the client as well. No two parties must have access to the same funds. Seems obvious but if I just give you the key you have the funds right? But we live in a digital world so there is no guarantee that the key creator doesn’t keep a copy himself. This would require immediate action from the receiver for funds to be safe (he has to transfer them to another address, until he does the funds are insecure.). The software needs to be open source. To trust the software we need to be able to view its source. It is not a 100% guarantee but it is a minimal requirement. The software for its functionality should not rely on any back-end servers other then IOTA-Nodes. By just using IOTA Nodes the communication becomes pure ‘Tangle talk’. Meaning the method can be easily portable to each language and platform while only relying on the Tangle protocol.

Point one and two are non-trivial to solve but also are the basis of every true decentralized solution to this problem. How IOTA-Pay solves this on a technical level is described in detail here: https://medium.com/coinmonks/iota-origin-d26b399d3cca

After point one and two are solved the other factors are mostly software design choices but are nonetheless important to create a standard voor single reference payments.

IOTA-Pay

IOTA-Pay implements all these key features into a single fully functional website (and API) that allows you to create a public reference (address) that you can share with anyone. By adding IOTA addresses to such a reference you essentially create a reusable address and therefore take a way the need to communicate each time you need to send funds to someone. You can share this reference through a normal URL, as plain text or a QR code. All you (or your wallet) has to do is make sure there is at least one unspent address in the reference and you are good to go.

And the best of all ? this is 100% on tangle and completely decentralized!

That is all?

As mentioned before IOTA-Pay is meant to make IOTA more human-centric, meaning that creating a reusable references/address is not the only thing IOTA-Pay is capable of or enables.

IOTA-Pay is still in development but the current user interface already offers some features that make IOTA much easier to use and would be impossible with only a protocol level implementation.

Reference/address personalization : (Optionally) Attach your name, email address or website to the reference so you can personalize your public page. You can also provide a specific email-address that is only shown to users when your reference is out of addresses!

: (Optionally) Attach your name, email address or website to the reference so you can personalize your public page. You can also provide a specific email-address that is only shown to users when your reference is out of addresses! Mark addresses as unavailable : with this option you can say to the world that you are planning to spend your IOTA’s so better not to send anything there. The API will automatically select a new one! No more race conditions on spends.

: with this option you can say to the world that you are planning to spend your IOTA’s so better not to send anything there. The API will automatically select a new one! No more race conditions on spends. Select preferred IOTA-Nodes : You (or your wallet) can also tell IOTA-Pay to use specific nodes to check for spends. By setting up your own wallet to use the same nodes you can eliminate network propagation errors(an IOTA-Pay enabled wallet should do this automatically). The IOTA-Pay-Api will always honor these nodes and will try to use them before any other nodes.

: You (or your wallet) can also tell IOTA-Pay to use specific nodes to check for spends. By setting up your own wallet to use the same nodes you can eliminate network propagation errors(an IOTA-Pay enabled wallet should do this automatically). The IOTA-Pay-Api will always honor these nodes and will try to use them before any other nodes. Manual or automatic : IOTA Pay can automatically generate seeds and addresses for you! But for those that are wary enough to not trust this method it is possible to also manually add addresses to IOTA Pay (manually or through QR codes).

: IOTA Pay can automatically generate seeds and addresses for you! But for those that are wary enough to not trust this method it is possible to also manually add addresses to IOTA Pay (manually or through QR codes). (Upcoming) Rotating addresses : display a new address after a configurable amount of IOTA’s is present on an address. Evenly distributing IOTA’s received on all exposed addresses.

: display a new address after a configurable amount of IOTA’s is present on an address. Evenly distributing IOTA’s received on all exposed addresses. This is not all! But most other features are there for developers that want to integrate IOTA Pay in their wallet software.

As noticed from some of the features is that the most benefits from IOTA-Pay are obtained by wallet integration. This to make use of the advantages that comes with keeping state (We all know: Trinity beats the old wallet!). Here are some examples that greatly simplify the use of IOTA Pay and wallet software in general.

Automatic address management. By implementing IOTA-Pay in a wallet the wallet could automatically handle adding extra addresses to the IOTA-Pay reference when spending IOTA’s, removing the need for any manual IOTA-Pay related actions at all! Address books. A wallet could keep a list of references for future use and keep track of their state for super fast address retrieval. Private references. IOTA-Pay can generate from a single login a near infinite number of references. Enough to have a separate per contact! The use of rotating addresses for many parallel instant payments. If you have an address with all your IOTA’s on it and you want to do a micro transaction you will need to wait until it is confirmed before sending another micro transaction. IOTA Pay uses lists of addresses and a unique way to describe them. This allows for sending preferences to be communicated and have spends split up in multiple outputs. This allows for many fast parallel payments. You no longer need to wait for your transaction to be confirmed before sending a new transaction. Note: this removes the need for so called ‘consecutive spend’

Protocol level and second layer symbiosis

IOTA-Pay already solves what the suggested protocol layer approach from the Iota Foundation is solving: Reusable addresses… but in a second layer approach, lets take a closer look to compare the two approaches and see what the benefits are if we combine the two!

Conclusion

IOTA-Pay very much welcomes a protocol layer approach to solve the reusable address problem. However only having reusable addresses doesn’t make it a complete solution. IOTA-Pay already works and because it was designed to be upgrade-able from the start it could easily switch normal addresses with reusable addresses and reap all the benefits that come with the protocol layer solution. However we can already use reusable IOTA-Pay references and if/when reusable addresses are implemented it will make IOTA-Pay better and an upgrade path much easier without the need to change the tech interface!

Thank you for reading my article! Make sure to take a look at the following links.

This is a one man project without funding, any donations would really help!: LJQ9PGEAACTHZITJBOPCTXZDQLNDAKQJEQSPGCZBASFFEMJKOPQWTSIMMWVFEBJWWENSQNPQGBAJUIGZAFXNZZDLF9

(Or use the IOTA-Pay donation address)