The 4th part in a series of beginner tutorials on integrating physical devices with the IOTA protocol.Introduction
This is the 4th part in a series of beginner tutorials on integrating physical devices with the IOTA protocol. In this tutorial we’ll be adding a couple of new features to our IOTA payment system. These features are related to how we manage the price of our service in a volatile IOTA market and how we deal with the IOTA one-time signature problem.
This tutorial will be more software oriented compared to the previous tutorials in this series as we will not be adding any new hardware to our project.
The Use Case
Now that we have our LCD based user interface in place we should take a closer look at a couple of issues that was briefly touched upon in the previous tutorial. Let’s start with the topic commonly referred to as address reuse.
Just to be clear, when i use the term “IOTA one-time signature problem”, i’m not referring to “problem” as in any error or bug in IOTA. The IOTA one-time signature scheme is a protection mechanism that was added to the IOTA protocol by design. Still, it’s something we need to be aware of, and deal with, when building applications on top of the IOTA protocol. As described in the previous tutorial “as long as the hotel owner do not spend any funds from his refrigerator addresses they are completely safe, however, as soon as he spends any funds from one of the addresses, the address is no longer safe and must be replaced by a new IOTA payment address”. What this actually means is that each time you spend funds from an IOTA address, a part of its private key is exposed, making it possible for a bad actor to forge it’s signature and steal it’s funds. So, how do we deal with this “problem”? We have to assume that the hotel owner wants to spend his hard earned IOTA’s at one point, right? Well, one option would be for him to just replace the old refrigerator payment address with a new address whenever he wants to spend from the old address. A better alternative might be to simply generate a new address for every payment so that we could ignore the address reuse problem all together. Now that we have our new LCD in place, we also have the practical means of implementing this solution.
The second issue i want to discuss in this tutorial is how we manage the price of our refrigerator service with respect to the volatile IOTA market. Having a static IOTA price for our refrigerator service, say 1 MIOTA for 1 hour of service, might not be the best business model for our hotel owner. After all, the price he pays in USD for electricity and maintenance of his refrigerator service is pretty much static and decoupled from the day to day volatility of the IOTA market price. I think a more sustainable business model for our hotel owner would be to price his refrigerator service in USD, say 1 USD for 1 hour service, and instead convert the USD price to MIOTA at the beginning of each transaction. So how do we implement this feature? Again, our new LCD comes to the rescue. By using an API call to the popular coinmarketcap.com website we can lookup the current IOTA price in USD, convert our USD price to IOTA’s, and display the correct IOTA price on the LCD. Another issue that we need to take into account is that our price in USD also might change from time to time depending on external factors such as the price of electricity. So we have to make sure we have an easy method of updating the USD price, and at the same time make sure the guest get’s the time of service he paid for. This should all be possible with the use of some basic math.
It should be noted that the new Trinity wallet already have a built in feature for converting fiat currency to IOTA. So in that sense it might be good enough to just display the refrigerator price in fiat currency, and have Trinity take care of the fiat to IOTA conversion.