Bitcoin: The Imperfect Solution

Before Bitcoin there had already been attempts to create forms of digital money, but they all faced serious hurdles. One of the major problems was to prevent double spending in a sensible manner. For a long time it seemed like the only solution would be some kind of centralized checking system that would at the same time be a central vulnerability.

Bitcoin's decentralized blockchain solved this problem quite elegantly and for the first time a monetary system without a central Achilles heel became possible. This is the core innovation of Bitcoin compared to its predecessors and what made it successful where others had failed.

Despite its technological breakthrough Bitcoin is not by any means a perfect solution to the problem of a decentral currency. Some items on a wish list for the perfect system are purely theoretical at this point or even outright science-fiction, other improvements are more tangible or already a reality in so called altcoins, variations of Bitcoin's system with their own networks. Many of them are merely a handful of code changes away from the original, no more than copycats intended to generate quick profits for their creators. Some select few have introduced meaningful changes and improvements though.

This overview outlines some of Bitcoin's shortcomings and possible solutions. Many improvements will likely be made to Bitcoin, but even if the protocol itself is quite flexible, it's not at all easy to make big changes that require a majority of the network to agree with them. At this point it's completely open whether Bitcoin will overcome these obstacles itself or if a superior altcoin will emerge and take over as the de facto cryptocurrency.

User Security

There have arguably been security problems for end users since personal computing and money processing first clashed together. But until Bitcoin had appeared there was always a third party (besides the user and the thief) involved, namely the money processor, and they carry a large part of the security burden. With Bitcoin everybody is essentially their own bank and payment processor in a single entity, this puts a much higher burden on the user to practice good security and the average end user is notoriously bad at anything that complicates the usage of a computer, especially security.

Additionally there are no payment reversals or insurances from a bank this time around. If a thief manages to divert coins, they are gone without recourse. This makes Bitcoin a very attractive target for malicious actors and the onus is now on each individual user to protect himself.

Bitcoin already allows to create multi signature schemes where a certain number of signatures from a larger pool are required to create a transaction. For example 2 out of 3 keys could be necessary to create a valid transfer. This mechanic opens up the possibility to effectively split the security burden among multiple parties or devices. A service can hold one of the necessary keys while the user holds one on his active device and another in a normally unused backup location. Thus the user can perform a transaction in conjunction with the service which provides additional security measures, like two-factor-authentication (2FA). A 2FA implementation works by design only with a remote service, since an authentication challenge can not be securely realized on the potentially compromised user device. In this scenario the user does not depend on the service either, since he can still perform transactions with his first and second (backup) key himself. The service on the other hand cannot maliciously use the entrusted key to create unwanted transactions by itself.

If such services were an integral part of Bitcoin clients, the security level for end users would already be much higher. No longer would a single compromised computer alone lead to the theft of coins.

Another possible security measure is to have the private keys on a separate device that is not used for the transaction processing, in fact ideally not for anything else. It could be an otherwise unused offline computer or a dedicated device for this specific purpose. Such a device, called Trezor, is being worked on currently. It's basically an ARM-based mini computer that fulfills no other function than holding Bitcoin private keys and performing the signing on externally created transactions. The unsigned transactions are generated on a computer that requires no special security setup and are then sent to the Trezor, which signs them and sends them back to the computer.

The key virtue of this approach is that the private keys never leave the external device, even if the computer that creates the transactions to be signed is compromised, the worst a malicious infection could do is to change the target address of the unsigned transaction. It's up to the user to verify that the output address has not been tampered with when he confirms the external signing.

Both approaches in effect acknowledge that securing a device is a hard problem, if not an impossible one. Using two or more independent devices to perform transactions is thus an imperfect circumvention of a problem that might not be perfectly solvable with a single device.


Bitcoin's automatic difficulty adjustments target an average block time of 10 minutes. When a transaction is mined into a block it gets a confirmation from the network and each additional block after that adds more confirmations to the transactions. By default transactions with 6 confirmations are considered fully confirmed, this is a completely arbitrary value though, the trust in the security of performed transaction is always a trade-off between convenience (less waiting time) and security (more confirmations and hence longer waiting times). Depending on the transferred sum, the required security level and the desired convenience, more or less confirmations might be a sensible choice.

Ideally instant transactions that are perfectly safe would be the perfect solution, but this is impossible due to the way the network builds trust through proof of work (mining). Some altcoins have considerably faster block times than Bitcoin, even in the range of seconds, which leads to more confirmations in the same amount of time.

This has several downsides though: Shorter intervals between blocks are a result of a lower target difficulty for the block mining. A lower difficulty means an increased likelihood that two or more miners create valid follow-up blocks for the blockchain. Only one will ultimately be added to the (longest) blockchain and all other valid blocks will be discarded, these blocks are called orphans. Orphaned blocks are essentially wasted resources, the miners' work was for nil, they wasted bandwidth and did nothing to secure the network despite doing the required proof of work.

Instant, fully trustable transactions are simply not possible in a decentralized system. Still, it's arguable that Bitcoin's 10 minute block interval is longer than it has to be to keep block orphaning reasonably low. On the other hand, since the network creates trust with work, the security margin can also be considered a function of time passed since a transaction's first inclusion in a block as this indicates more work has been done to establish the trust. With that in mind faster block times merely offer finer granularity of trust, but do not build trust faster.


All Bitcoin transactions are stored in a ledger, the blockchain, it is the central information storage of the network and the corner stone of its decentralized consensus system. Because new transactions are added all the time and there being (currently) no pruning mechanism, the blockchain is ever growing. At the time of this writing it is well beyond 10 GB and the speed at which its size is increasing accelerates with the growing number of users.

The hope is that computer storage capacity can keep up with Bitcoin's space requirements. There is also the assumption that so called SPV (simplified payment verification) thin clients will be increasingly popular among Bitcoin users. Thin clients don't store the whole blockchain by themselves, instead they relay on a sparse version of header data and remote servers to handle transactions with the Bitcoin network.

Still, full Bitcoin nodes are required to keep the network running and, besides the increasing storage requirements, new nodes first need to download the entire blockchain before they can start participating.

An ideal cryptocurrency would have minimal storage and bandwidth requirements. Ideally the needed size for the blockchain would be a product of all active addresses (those with non-zero balances) and a fixed amount of bytes per used address. Such a minimal blockchain would still grow for the foreseeable future, but there would be a limit to its growth at the point when the network has reached maximum adoption and the number of active addresses has likewise reached an equilibrium. This is quite different from the current state where no end to the growth is expected, even at a saturated adoption point.

The problem with pruning is how to reliably establish trust without a fixed origin point. All pruning proposals so far effectively still need unpruned seeds to initiate. It's possible that, if a fully prunable network remains unfeasible, only a relatively low number of full blockchains will be maintained in the future while the majority of the network will be based on seeded, pruned nodes. The seeds in this scenario could be institutions and enterprises for which even vast amounts of storage space are no concern and who have a vested interest in keeping the network alive.

Transaction Throughput

Currently the Bitcoin network can process a maximum of 7 transactions per second, that makes 604,800 transactions per day. If Bitcoin wants to have a future beyond a niche system, then that figure needs to increase dramatically or the network will crumble under the load. There are some difficulties though, an increased transaction throughput inevitably also increases storage and bandwidth requirements of the network. Especially the block size is limiting a factor for how many transactions can be included in a single block. Right now blocks have a hard coded upper limit, changing that limit is possible with a soft-fork. The current limit is pretty arbitrary too, there is no specific reason for it to be where it is.

All things considered the possible transaction throughput of the network can be and needs to be increased in the long run and this will inevitably also increase the load each single node has to carry. This is because each full Bitcoin node basically does all the work every other node is doing too. Due to the decentralized consensus system there is no mechanic to have only subsets of the network do a task (thin clients effectively don't work for the network), this is a barrier for Bitcoin's scalability.

Theoretically it might be possible to balance the workload the network needs to do similarly to how distributed hash tables (DHT) work. In this system, that is famously employed by the BitTorrent network, each node does not store the whole data set, instead a client only keeps a much smaller subset of the whole. Since everything is stored redundantly DHTs are relatively resilient to disappearing clients. This solution is not directly applicable to Bitcoin in itself, but if the Bitcoin network could use such a scheme, scalability would be greatly increased by virtue of massively reducing the demand on any single participating node.

Mining Decentralization

When Bitcoin started out, the mining was first done on CPUs, then GPUs became the go-to solution, followed by FPGAs and ultimately ASICs. ASICs are the endgame in terms of hardware evolution for mining, because nothing can ultimately be faster and more efficient than hardware that is custom made for specific algorithms. More generalized hardware will always be at a disadvantage to fully developed ASICs and due to the way the network's mining competition among all participants works, it was inevitable that all mining on non-ASIC hardware would eventually come to an end.

Since Bitcoin ASICs by their very nature fulfill only a very limited purpose, they are naturally a rarer breed than general purpose hardware, like CPUs and GPUs, that can be used for a wide range of applications. You can't buy Bitcoin mining ASICs at the next electronic store like you can regular computer parts. Yet, anyway. This and the fact that ever more powerful hardware is required to have a meaningful share of the mining cake has led to a creeping clustering of the mining network. “Clustering” because centralization is still another beast, but the concentration of effective mining power in fewer entities and pools is clearly eroding the completely decentralized state Bitcoin had been in at the beginning. Compounded with the growing hardware requirements to run a full node at all, we will see even more pronounced clustering effects in the near future.

It's foreseeable that the mining will become more and more industrialized as time goes on, we are actually already seeing this in action. The average user can't participate anymore, only enthusiasts willing to acquire expensive and relatively rare prosumer hardware will still be in the game and even then only by joining mining pools, which are themselves clustering tools. The majority of the network hashrate will be contributed by industrial and semi-professional ventures though, because only such entities will be able to provide the necessary funding and infrastructure to realize mining in a profitable manner.

All of this is an inevitable progression and while a perpetually, perfectly decentralized network, where everybody can contribute a roughly equal amount of mining power, might be more desirable, it's simply not enforceable on a technical level.

Some people falsely think that alternative hashing algorithms like scrypt, most famously used by Litecoin, are a solution to the centralization problem. Scrypt makes an implementation in ASICs much harder (and thus less profitable) due to the memory bandwidth requirements and the absence of ASICs would theoretically prevent the erosion of a completely decentralized mining network. While indeed harder to realize in the form of specialized chips, it's not at all impossible. In fact some of the first scrypt ASICs are currently pushing into the market, which not only shows the feasibility, but more importantly that it can be done profitably.

Scrypt might have succeeded in slowing down the transformation towards ASICs for altcoins, but it has not prevented it. If scrypt altcoins persist at all, then their endgame will look exactly like Bitcoin's in the long run: industrial scale mining and clusterization with negligible participation of average users.

Other algorithms seeking to keep mining CPU bound will ultimately fall prey to the same core principle: anything that can be done on a general purpose computer with a standard CPU, can be done more effectively on specialized systems. It might be hard and prohibitively expensive in the beginning, but if a cryptocurrency is successful there will inevitably be the point where it becomes profitable. If the currency doesn't rise to that point in terms of adoption and success, then it doesn't matter anyway.

Power Consumption

An often echoed complaint about Bitcoin is the supposedly “wasted” energy that goes into the mining process. What those critics seemingly fail to understand is that the energy is not wasted at all. The mining process, and thus the energy used for the proof of work, keeps the network running and secured. Without that used energy there would be no Bitcoin network, for that reason it is simply false to assume the used energy is wasted for nothing. Furthermore the fiat money system swallows a disproportionately larger amount of energy for its ongoing function.

There is an alternative to the proof of work (POW) algorithm used by Bitcoin though: proof of stake (POS). The idea is that instead of proving that work has been done to find hashes, nodes with an active balance get a chance to create the next block. The more coins a node holds the higher the likelihood that it “wins” a block and with it a reward. Besides the basic operational cost of a node there is only little additional power consumed in this mechanism for the block generation and it incentives running full nodes.

On the flipside POS is at the core a 'the rich get richer' mechanism. Those who already have the most coins are bound to get even more of them in the long run while all others are at a disadvantage as far as wealth acquisition goes in this system. As time goes by the distributive disparity will likely increase in a POS cryptocurrency, because it strongly discourages spending larger amounts of coins. POW on the other hand has no disincentives for spending and coin acquisition is independent of preexisting coins.

Still, from the standpoint of energy saving POS is certainly a very interesting mechanic and depending on how Bitcoin's network evolution plays out in the long run the energy consumption might really become a problem to the point where alternatives need to be considered.

Protocol Security

Bitcoin uses three core algorithms: SHA-256 and RIPEMD-160 (both hashing functions) as well as ECDSA (an elliptic curve signature algorithm) to sign transactions. Currently all three are considered safe for the time being, but if the history of cryptography shows anything, then that all crypto algorithms have weaknesses and the means to abuse them only grow bigger. One reason is more powerful hardware that allows to crack schemes that were considered safe when computers had but a fraction of the present processing capacities. The other reason are cryptanalytical advances that poke more and more holes into the mathematical frameworks of cryptographic schemes.

Bitcoin uses ECDSA signatures with a 256-bit length for transaction signing. Due to the nature of this asymmetric cryptographic scheme the actual security margin is roughly equivalent to a 128-bit symmetric key. This is still an astronomic figure and for all intents and purposes thought to be safe in the realm of conventional binary computing. There is a threat looming at the horizon though and that is quantum computing.

There is a specific quantum algorithm called Grover's algorithm that can essentially be used to compute the private key from a public key in an asymmetric signature scheme like ECDSA in little time. All it needs is a quantum computer that can compute enough qubits (quantum bits) at once. As of now such a quantum computer does not exist and will in all likelihood not exist for a few more decades. Quantum computing is still its infancy and the threat to conventional asymmetric encryption and signature schemes is purely theoretical at this point.

A Canadian company called D-Wave already builds computers that apparently use quantum effects to do their work (this is still hotly disputed though), but they still suffer from some severe limitations that prevent them from being considered quantum computers in the purest sense of the description. In their current construction they can be used efficiently only for certain kinds of optimization problems and are unable to execute the whole range of quantum algorithms, among them Grover's algorithm. In other words these possible precursors to true quantum computers are not a threat yet, but they are indeed important, fundamental research in this field and are paving the way to future quantum devices that will be a threat to Bitcoin, if Bitcoin is still around when they have materialized.

Bitcoin isn't alone in facing this future threat though, when Grover's algorithm becomes a reality, all conventional asymmetric security schemes currently in use will be rendered practically worthless, because they will be effectively crackable at the push of a button. For that reason there is already work being done in the field of post-quantum cryptography, cryptographical functions that are resistant to quantum algorithms. Like quantum computing itself, this research is young and due to the very nature of the problem largely theoretical. Still, there are some signature schemes that are thought to be quantum-safe, which means they can't be solved (cracked) any more efficiently with a quantum computer than they could be with a classical computer.

The good news is that the Bitcoin protocol is flexible enough to allow the replacement of the various used algorithms with a soft-fork. When quantum computing reaches a point, where it is a tangible threat to the elliptic curve mechanic used by Bitcoin, a quantum-safe algorithm can replace the ECDSA signature scheme. A downside of all the so far discussed post-quantum signature algorithms is that they require considerably more data to achieve the security level ECDSA currently provides. Elliptic curve signatures have a remarkably small footprint and are actually a major improvement over the previous generation of asymmetric cryptography, like RSA. If a replacement algorithm is ever integrated that requires longer keys, it will add to the already problematic growth of the blockchain.

Better solutions might be found in the coming decades though and there is one more reason that alleviates the problem of crackable public keys in general: The Bitcoin network has no knowledge of the public key belonging to an address until the moment coins are for the first time spent from it. Up to that point only the address itself, which is a hash of the public key, is known. The hash algorithms used by Bitcoin are not susceptible to quantum computing or other currently known reversal techniques and as such provide a strong protection for addresses that have never spent funds. Only when funds are sent from an address the public key becomes known and a deduction of the private key even remotely possible (assuming quantum computers or another threat to elliptic curves exist).

This can be easily circumnavigated by never reusing addresses in the first place. All current wallets send change coins to change addresses anyway, as long as users are not actively reusing addresses the presence of the public key for a formerly used address is irrelevant. This has some implications for the convenience of Bitcoin, e.g. constantly announcing the same receiving address for funds of any kind is inherently a bad idea, but it doesn't break Bitcoin per se.

All things considered and implementation flaws notwithstanding, Bitcoin's core algorithms are safe for the time being. When (or rather before) quantum computing arrives some day, hopefully viable alternatives can be implemented to carry Bitcoin even through the age of post-binary computers.

Bitcoin | Cryptocurrency

QR Code
QR Code bitcoin_the_imperfect_solution (generated for current page)