Reusable addresses with IOTA-Pay!
The full article was originally published by Olaf van Wijk on Medium. Read the full article here.
For those familiar with IOTA knows that it takes a novel approach to Distributed Ledgers Technology in the form of the Tangle. The Tangle has completely different properties compared to the blockchain like infinite scalability, no miners, no transaction fee’s and quantum-resistance.
The reusable address problem
“One of those choices was to use a quantum-resistant signature scheme, which (while being safe from quantum computers) does not allow spending multiple times from the same address, without putting the funds on that address at risk. Most critics of this feature argue that issues like quantum computing are not an imminent threat and that adjustments can be made when vulnerable signature algorithms become a real problem. Especially if the alternative creates usability problems for current users.”
IOTA-Pay focuses on ‘Human initiated interactions’ implemented as a second layer solution on top of the Tangle to solve exactly the problem described above and much more! IOTA-Pay relates heavily to the proposed protocol level solution because they both solve this issue, a detailed comparison is made later in this article.
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.