The issue with Bitcoin in commerce

By paul

First off, this is a very personal post, which is the result of working with Bitcoin on a technical level for several months. I am frustrated and to get this out of the way: Bitcoin is a deeply flawed technology and many of its limitations are well-documented. Nevertheless, there is an incredible desire for blockchain technology to be used in commerce. In 2018 it remained one of the most talked about topics in the industry and people are longing for a wider acceptance of it in real-world applications, regardless of how impractical it may be.

Early in 2018 we decided to adopt Bitcoin payments and to experiment with second layer technologies, such as the Lightning Network. And although the technology is interesting, there are some real-life issues with Bitcoin and second layer technologies that make it awkward to work with in the context of real business applications. Speaking of real business:

Bitcoin is a nightmare for accounting

Businesses around the world are required to abide by their governmentally prescribed accounting standards. For their own income statements & balance sheets, they must use the main legal tender, i.e. the primary accepted medium recognized by a legal system as means of payment (for the US this would be the US dollar). This is the case regardless of whether they accept Bitcoin payments as an additional payment method (or any other currency, for that matter). Regardless of whrether or not a government accepts Bitcoin payments, governments will require businesses to turn in legal documents and these in turn are bound by the legal tender. This implies that any business application touching the creation of vouchers and calculations relevant to accounting (invoices, balance sheets etc.), will ultimately have to convert payments and receipts to legal tender just so that it can comply with the law.

In preparing financial statements, each entity—whether a stand-alone entity, an entity with foreign operations (such as a parent) or a foreign operation (such as a subsidiary or branch)—determines its functional currency in accordance with paragraphs 9–14. The entity translates foreign currency items into its functional currency and reports the effects of such translation in accordance with paragraphs 20–37 and 50.

IAS 21 – The Effects of Changes in Foreign Exchange Rates

This of course is true for all foreign currencies and you can still accept foreign currencies internally as long as you provide your tax statements in the correct form. But because of its volatility, Bitcoin is exceptionally unsuited for the job.  The reason is simple: businesses must be able to keep their own assets value and potential gains constant or they risk losing money due to a drop or gain in exchange value. That is why it is common practice for businesses to pay a good amount to hedge the value of foreign currencies in larger sale contracts, despite the fact that currency exchange rates between major currencies (e.g. EUR/USD) are very non-volatile (compared to BTC).

The market price of Bitcoin in Dollar can fluctuate a lot

With Bitcoin, price changes are frequent and can result in a loss for either party. In 2017 we first saw a steep rise of the Bitcoin value from $930 to nearly $20,000, just to fall back to $3,500 in 2018. This is a nightmare for companies, as any change can result in a loss by selling or holding their assets in Bitcoin. Depending on the industry even a small change of the exchange rate can turn a sale unprofitable and easily ruin the company value over night.

Working with eleven decimal places is a no-go

The rules of accounting are written with currencies in mind which have at most two significant decimal places. Some currencies with very low values per unit might have less, but there is no currency where you are required to keep track of more. Sure, for some purposes   –    e.g. trading large amounts of low value goods like some commodities, screws or nails – you might have to consider the third or even fourth decimal place when calculating a price. But the government will still only require two decimal places in your tax documents.

That means that you can safely work with 3 decimal places in business applications to round for the end-users or accounting purposes without a significant loss of information. Now compare this to Bitcoin, which currently uses up to 11 decimal places (called “millisatoshi”). On top of that, there is no universally agreed upon number of decimal places which should be used for rounding. There really can’t be for a currency which jumps orders of magnitude in value in the span of only a couple of months.

To be able to show customers values that are at least somewhat understandable, you would have to continuously adapt the rounding rules which is not feasible from an accounting point of view. As a result, Bitcoin amounts are unpractical from a user perspective. Granted, you can use Bitcoin to exchange values, but that doesn’t make it a good experience. People dislike the use of decimals and are heavily biased towards digits.  This is not news to anyone who ever worked in retail – it makes a psychological difference whether you purchase a product for $13 or $12.99. What it means is that if systems were to entirely switch to Bitcoin prices as a currency, it would be a lot more difficult for customers to compare prices or evaluate their worth.

Unregulated currencies aren’t practical

Another fundamental issue comes from Bitcoin’s greatest strength: it is unregulated. That doesn’t mean that Bitcoin is unregulated in a sense that no common law applies, but rather that because Bitcoin hasn’t become a legal tender by any government, it hasn’t gone through the various levels of standardization yet. It may sound absurd, but the reality is that for this reason alone, many things cannot be taken for granted that otherwise would apply:

Bitcoin doesn’t have a currency code

Yes, there is a Unicode character, but that doesn’t mean that a real currency code has been introduced. The most commonly used “BTC” is not likely to be adopted by the International Organization for Standardization (ISO), as currency codes are regulated according to the country code where it was first used as legal tender (USD = US dollar, GBP = Great Britain Pound Sterling etc.). “BT”, however, is already taken as a country code by Bhutan, which hasn’t adopted Bitcoin as a legal tender and is unlikely be the first. So BTC is not likely to be a candidate for ISO. The next equivalent “XBT” is more likely to be accepted by ISO, but doesn’t seem to be recognized by customers as a currency code for Bitcoin. Nobody can decide what the currency code is going to be as long as the debate is going on. This matters, because programming languages and framework like ours often rely currency codes to identify currencies. As the currency code is pending, programmers will have to live with workarounds.

Bitcoin is not safe.

Around 36% of all Bitcoin issued is lost – forever. This is not a small pill to swallow. The reason is that all Bitcoin you ever own will be stored in a private wallet, with a private key, on someones hard-drive. Whenever people forget either the wallet sequence or the key the money will be gone and there is no way to recover.

On top of that, it is basically impossible to revert an erroneous transaction. Businesses are run by people and errors happen all the time, including transferring money in wrong amounts or to the wrong accounts. With our banking system, its almost always possible to get your money back (at least if the error is noticed within a day or two and you can give a plausible explanation why the transaction should be reverted). With Bitcoin, the money is gone unless the recipient is honest enough to transfer the money back (which also means high transaction fees for both of you).

Bitcoin is slow

It deserves mentioning again how slow Bitcoin truly is. The average confirmation time, the time it takes to process a transaction, was an overwhelming 55,500 seconds in 2017/2018. The reason is that Bitcoin on average only handles around 1 MB of data to be written to the blockchain every 10 minutes.  This remained the case even after the initial cap of 1 MB has been lifted. That is an incredibly small amount of data, which means the number of transactions is very restricted. Considering that the average transaction size is currently measured at ~500byte, this translates to ~2000 transactions every ten minutes, or less than 4 transactions per second.

Average Confirmation Time of a Bitcoin Transaction in Minutes over the last 2 years

This may be well enough for small-scale operations, but it is hard to imagine what would happen if Bitcoin was the legal tender globally and only 4 people got to make a purchase every second. There are more children being born each seconds than Bitcoin transactions can occur. At the same time, it has a peculiar impact on transactions themselves: as more and more people are demanding their transactions to be processed, the processing time has become a scarce resource. For this reason, transaction fees have skyrocketed. In 2017, during an explosion of Bitcoin prices, transaction fees increased to an average of over $55. It has slowed down again since, but will repeat itself whenever transaction numbers increase. This is a growing issue, as more and more people use Bitcoin payments, transactions will only take longer and cost more to process.

So where does it leave us?

Bitcoins problems are well-known in the scene and there are solutions in the work that may improve or work-around some of its bigger architectural flaws. The biggest problem with Bitcoin at the moment, however, comes from its inner workings, the slow performance and overall bad design choice. Some of which, like the performance, can be improved but it is for these reasons that Bitcoin is not a good choice as either a primary base for business application, nor as a good payment method (at least at the moment).

The question is going to be, if second-layers improvements can be enough to solve the issues, or if the added complexity will keep Bitcoin from ever becoming a standard in the business world.