Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Here be dragons: Bitcoin and the internet of things

For any currency to be usable for IoT, there are some non-negotiable requirements:

  • Support for transactions, especially small ones
  • Stable store of value
  • Predictable low latency
  • Support for very high volumes of traffic

At first sight, bitcoin seems like an ideal choice for IoT. But if you look closer, bitcoin and other virtual currencies are deeply problematic.

There’s lots of information on how bitcoin works out there, but for our purposes it can be summarized as follows:

  • Bitcoin is a ledger of transactions.
  • So A decides that B now owns one of his bitcoins.
  • The change of ownership is put into a queue.
  • Lots of people working in lots of places take that queue and search for bitcoins.
  • When somebody finds a bitcoin, the change of ownership is baked in using a complicated hash that prevents people from changing older versions of the queue, and the hash it results in is used in the next batch of transactions.

Because many different people are processing the same queue at the same time, and the process never stops, it’s more or less impossible to make a retroactive change. The ledger is in multiple places and is updated constantly with changes which build on prior modifications.

These concepts are broadly similar to how high availability works in transaction processing systems, but there are some very important differences anyone looking to implement bitcoin for IoT needs to consider.

The first issue is latency. For a transaction to finish in bitcoin, we need to know that bitcoin (the ledger) has finished processing.

In IoT, credit card fraud and telecommunications operations, latency is measured in either milliseconds or microseconds. A typical transaction, such as checking someone’s mobile phone credit when connecting a call, will take from 350 microseconds to 3.5 milliseconds in the real world, depending on the circumstances.

Now consider that a transaction is not just a one-way “fire and forget” operation. It is an event whose outcome matters and is not known in advance. If we’re just recording usage, the end result may not matter. If we’re spending some resource, (for example, money), the outcome does matter as we may be told we can’t complete a call due to low minutes, complete a purchase due to low account balance and so on. This is where latency suddenly becomes very important. Until we get a yes or no response, the client’s application can’t do its job.

In an IoT context, where we’re making decisions at computer speed (milliseconds) not human speed (seconds), poor latency can render a good idea unworkable. As I write this, it takes 31 minutes for a bitcoin transaction to be confirmed, which makes it utterly useless for automated transactions. Bear in mind that if we’re trying to implement some kind of iterative micropayment approach, IoT devices could be spending money every couple of minutes, which means we either deny services until the payment goes through, or we could have a massive queue of transactions in the system and be carrying the risk they will start to fail. There’s also an issue with predictability. The transaction confirmation time can, in practice, be anything due to the way bitcoin works.

The second major issue is support for the anticipated traffic levels we will see in IoT. A single IoT application could easily generate well over 10,000 transactions per second (TPS). In comparison, Visa is capable of handling over 56,000 TPS globally. Bitcoin is limited to 7 TPS. Not 7,000 TPS, 7 TPS. Think about that. Not only is it implausible for real-time transaction processing for an IoT app, it also calls into question if bitcoin’s architecture is even relevant when we’re planning on hundreds of thousands of TPS.

This brings us to our next issue: small transactions. In April 2013, the developers of bitcoin introduced a limitation on what they referred to as “dust” transactions. Transactions less than $0.007 were no longer accepted. This in turn raises two problems. The first is that some IoT applications might plausibly need transactions that are 7/10 of a cent or less. The second is a broader governance issue. If the people who run the currency can decide to change the minimum transaction size with no notice, what’s to stop them for doing it again?

Finally, we come to stability. Bitcoin has weekly price swings of up to 60%. While it’s been an excellent platform for speculation, who could plausibly price a product or service in it when its value is continuously changing? Bear in mind that a lot of IoT plays will be operating on razor-thin margins that could be wiped out by a currency swing.

While it’s clear that IoT will require some form of micropayments architecture, the current state of bitcoin renders it more or less useless as an IoT payment mechanism. What’s equally disturbing is that as a consequence of bitcoin’s lack of central control — despite issues concerning latency and scalability being obvious to anyone who cared to look — no substantive progress has been made in resolving them. We could, at this point, start looking at other digital currencies, but that opens up a further rat’s nest of questions about convertibility and survivability. The internet of things presents enough of a challenge as it is without bringing bitcoin on board.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.