Some thoughts on Bitcoin as a long-term currency

I have been watching the development of Bitcoin since it started and found it fascinating. From a technical point of view the idea of cryptocurrency is intriguing. Even if perfect security can not be guaranteed, I’m not worried about Bitcoin’s long-term prospects from an algorithmic point of view. I think the real problems are economical.

I don’t doubt, as some have, that Bitcoin is a proper currency. Economics has a pretty low bar for a currency: 1) is a store of value, 2) accepted for transactions, 3) is a accounting unit, 4) in common use within a territory. If you read this carefully, you notice that cigarettes in the territory of a prison could also be considered a currency. The important difference to make is between private and public currencies.

There is a reason we run our economy on public currencies aka a currency controlled by a central bank usually bound to a set of fixed rules. It’s mostly lessons learned from economic history. Private currencies have a really bad track record in matters of stability. Before the American Federal Reserve was established in 1913, most currencies in the US were issued by private banks and therefore closer to private currencies. As those currencies were only influenced by the market, there value fluctuated wildly (by modern standards) and banking crisis were a regular occurrence (total of 6 in the US between 1880 and 1913). Public currencies were established to give stability by market intervention –  meaning the central bank countering upwards or downwards trends in demand – and they have in most regards been successful.

Bitcoin behaves very much like a private currency, it’s value is shaped mostly by market forces. There seemed to be a common misconception that only amount of currency units determine value of the currency (which seemed to have been one of the reason Bitcoin was created the way it is). In reality currency value is determined by both demand and supply. The supply of Bitcoins is effectively limited based on mining. Demand on the other hand can vary wildly based on the state of the economy or e.g. events on the stock market. The same factors are behind the large fluctuations in gold price over the last decades. And that was also the problem for the private currencies of the late 19th century: they were mostly based on gold and completely demand driven. Binding yourself to a fix supply increase like gold mining or crypto-algorithms is no guarantee for stability.

The fluctuation in value will make it hard to use Bitcoin for transactions, a problem commonly called currency risk. If you think about the typical larger business operating on contracts where delivery of goods and payment can be month apart, a large short-term fluctuation can be devastating. As the supply of Bitcoins will stop at some point in the future, demand is going to be the main factor for value. While value against other currencies is determined by market forces, long term value is determined between a person using Bitcoin as his primary currency and the economy he is part of. An economy usually increases in value by at least a couple of percent each year, Bitcoin itself will stay the same amount. That is great for the person as long as he has no debt in Bitcoins as debt would increase over time in relation to the economy as a whole. A business, which usually depends on debt to operate would not be willing to take a loan in Bitcoins. This is the real danger of deflation. It’s not a death sentence but will prevent Bitcoin from spreading throughout the economy.

In summary, I can currently not see how Bitcoin would be usable as a day to day currency, even a private one. It will very likely survive as a value store as it is well suited for that compared to say gold.

Should you run anything on physical hardware?

I frequently get into a discussion which goes something like this: I have this high-cpu service which would just work fine and fast on physical hardware but I’m running up the capacity of my VM. Why don’t we just run it on the physical hardware?

The first answer would be that virtual hardware has too many benefits to just easily go back to the physical world. VMs can be replicated, copied and deployed at will. If you also have a decent tool kit to deploy multiple VMs with respective configurations at once on demand, you can replace and fail over quickly. If you have a physical server, you need at least a fail over server – which will also be physical. You also have to pay a guy to fix it if it breaks. Is it really worth the additional money and time?

The second answer, and I think the more important one, is that you should really ask yourself if you are trying to solve a scale problem the wrong way. Sure, I know the occasional optimised C++ service with constant demand happily working for years on one server. But are you sure the demand will not increase in 3 month, 6 month time, beyond the physical capacity of the server? Are you then starting to beef up the server, spending more time and money? Maybe it’s time to look into a distributed architecture that can scale across multiple VMs and you solve the scaling problem before it become big and costly.


Should you ever delete something from the cloud?

At a recent CloudCamp I had a discussion about data retention in the cloud, the argument was that the size of “big data” would be significantly reduced if you delete the unimportant/unnecessary/trivial data.

Problem 1: The Filtering Job

If you want to avoid collecting any unimportant data, it has to be filtered when coming in. If that would be an easy job, some companies would not use big data solutions – it would be less cost and resource intensive to just put it into a SQLDB. One of the reasons that it is necessary to work with cloud and big data solutions is that it is easier/less resource consuming to process the data later when you want to analyse it then when you receive it.

Problem 2: The Purging Job

If you can’t reasonably filter that data, how about purging it? All boils down to storage cost vs purging cost. If it is simple and effective to purge, you could have done it via filtering. It it’s not, you either have to spend precious resources for purging calculation or hire people to evaluate and purge data. Either way, it’s most likely more expensive than some more hard drives.

Problem 3: The Future

What is unimportant? What do you not need? If you think just about now, it might be an easy questions. But requirements might change, Data needs to be reprocessed in a different light. Your company might do something completely different with the data in a year (happens more often than you think). So why delete something you might need in the future?