Solving the IOTA donations problem by using IOTA cheques

all credits to: Eric Hop – Original post: https://goo.gl/afdp4B

 

The donation problem

For the longest time one of the problems with IOTA has been the impossibility of having a secure and fixed reusable donation address. This is entirely due to the single-signing nature of IOTA addresses. You cannot simply post an IOTA address and have people send funds there, because once you spend from such an address that address should no longer be used. Of course you cannot enforce the closing of the address, because people may have bookmarked it and they can still send funds to it after you spent from it. In which case you open yourself up to a brute force attack the moment you try to spend that next batch of funds.

Most solutions that have been proposed require a separate server and/or cooperation from the wallet software. It usually involves generating a bunch of receive addresses in advance that are then doled out by the server to the senders, or -even worse- the server will receive the funds for you and (hopefully) relinquish them to you upon request.
There obviously are all kinds of (potential) problems with these approaches.

The proposed solution

I have often found that solutions to potentially difficult problems can be achieved by turning the problem upside down. And this one was no different.

Who says that the recipient is the one that needs to generate the donation address? Why not have the sender generate a fresh address, send the funds there, and then make sure that the receiver can access those funds?

It turns out there is a very easy way to do that with IOTA (or any other crypto currency), You simply send the private key of the donation address that contains the funds to the recipient. Now he is able to access these funds and send them to his own wallet. This simultaneously solves the accidental double spending problem.

The only remaining problem becomes one of securely sending the private key of the donation address to the recipient. But we have had ways of doing just that for the longest time: by using asymmetric key cryptography. Just sign the private key of the donation address with a public signing key you get from the recipient and send the resulting encrypted message to the recipient.

Now the recipient can decode the received message using his private signing key, derive the public key (address) from the private key of the donation address, and use those keys to send the donation from that address to his own wallet. Tadaa!

Note that only the recipient will be able to decrypt the received message, because he is the only one with the matching private signing key. So the message can be sent in the open with no possibility for anyone to hijack the funds.

IOTA cheques

Now that we have the concept for the solution it becomes a matter of having a good User Experience so that this whole process will be easy to do for any user. To make it easier to understand for the user, let’s introduce the concept of an IOTA cheque. Most users can easily create a correct mental map of how to use a cheque. So let’s just call it that for easy understanding.

We will see that simply by calling it that way we suddenly open up new ways of looking at this solution. Because now we suddenly realize that we can use this concept for much more than just donations. Writing a cheque to anyone for any purpose and sending it to them is just a small leap now. We can even introduce the concept of a cheque book.

Since the sender will need a separate space to generate the cheque address anyway, to avoid the problem of the wallet accidentally spending the funds in the cheque address. The solution to that is simple: a separate seed. And since we will only use this seed for cheques it will be known as our cheque book seed. Every time we want to create an IOTA cheque, we generate a new receive address in our check book, and send funds from the wallet to that new cheque address.

Now we need a way to get the public signing key of the recipient. Well guess what? That’s a problem that has been long solved. We use a special kind of url. I propose to use the iota:// scheme for that. This enables us to do a lot more as will soon become clear.

The iota:// scheme

So how would you like to have a link that users can click on, that will invoke their wallet, and then automatically create a cheque for you so that all they need to do is fill in the amount and send it to you? This can be done with the iota:// scheme. Suppose the receiver’s private signing key is (in true IOTA fashion) a string of trytes. I propose not to use 81 or 90 trytes, to avoid confusion with seeds and addresses. But any other length will probably do fine.

Then an IOTA cheque request url would become something like:
iota://request/KMNQG9VDSCGH….KKIJU9HGFDSXVJK
It would even be possible to add a predefined amount:
iota://request/2.35Mi/KMNQG9VDSCGH….KKIJU9HGFDSXVJK
The possibilities are endless.

Supporting this with a wallet is pretty easy. The wallet shows a screen asking for the amount to send, then creates a cheque address in his cheque book seed, and sends the amount there. While the funds are underway, the wallet encrypts the private key of the cheque address with the recipient’s public signing key KMNQG9VDSCGH….KKIJU9HGFDSXVJK (decoded from trytes to bytes first), encodes the resulting message bytes as trytes, and sends the trytes to the recipient.

Now here is where it becomes interesting. Since it does not really matter how the recipient receives the IOTA cheque there are several possibilities:

  1. Send the trytes as an iota:// scheme url in an email address or chat message, or even as SMS. Something like:
    iota://cheque/KLUGVES9XGPL….KYBN9FWAXBJJBFDCV
    The receiver now can click on the received url, which will start his wallet, which then processes the tryte string as described above.
  2. Send the trytes as message data to an IOTA address. In this case the recipient wallet will check regularly for any IOTA cheques that arrive at that address. If one does it processes the message trytes as described above.
    So what address will we send the IOTA cheque to? Simple! Take the first 81 trytes of the receiver’s public signing key and use that as the address to send to. Pad with 9’s in the unlikely event that the public signing key would be less than 81 trytes. You don’t even have to worry if the resulting IOTA address is already used, since IOTA messages are zero transfer transactions, and only the correct receiver can decrypt the message.
  3. Send the trytes directly to another wallet using Bluetooth, or NFC, or wifi, or whatever other method is readily available. The receiving wallet would send the public signing key to the sending wallet and the rest is as described above.

Note that the iota:// scheme can have way more uses due to its flexibility.

Imagine for example an IOTA alias server that can convert any url of the much more readable form iota://alias/Eric.Hop to a corresponding tryte string. This would mean that we would need a server where these aliases can be registered, of course. And it would also probably mean a run on ‘popular’ names just like that happened with domain names. But it would sure help with setting up a ‘phone directory’ of how to contact people on an associated address. Maybe for usage with MAM or Flash channels.

Also, it would be possible to have different levels of security or even different methods of asymmetric key encryption and specify those in the url:
iota://request/RSA/1024/KMNQG9VDSCGH….KKIJU9HGFDSXVJK

Conclusion

The proposed method solves IOTA’s reusable donation address problem in an elegant way using already available techniques. And as a bonus it enables sending IOTA tokens to anyone using any method. All that is needed is a little support from the wallet software:

  1. Intercepting and interpreting iota:// scheme urls
  2. Enabling the creation of IOTA cheques in a separate cheque book seed and support sending them to either a Tangle address, an email address, any chat channel, or even as an SMS.
  3. Possibly enabling direct interchange between wallets if so desired
  4. Helping users by generating their private/public signing keys with the desired security level.

 




Leave a Reply

Your email address will not be published. Required fields are marked *