Bitcoin is a “peer-to-peer electronic cash system” that gained certain acceptance as of early 2011. I review the system, mostly based on its description in the original article and the project's wiki. To the best of my understanding, the sentiment about this particular system is mostly groundless. The key three features of the system, namely (1) peer-to-peer architecture, (2) anonymousness, and (3) cryptographic security are only met if their definitions are somewhat relaxed. The key point of Bitcoin is eliminating double spending without resorting to trusted third parties. An actual system, if only any popular, will have de-facto third parties, but it is unclear, how reliably double-spending is eliminated.


The very basis of Bitcoin design assumes that every node needs to be aware of every transaction in the system just to prevent double-spending:

We need a way for the payee to know that the previous owners did not sign any earlier transactions... The only way to confirm the absence of a transaction is to be aware of all transactions.

Thus, every “full” node needs to maintain a dossier on every “coin” out there and, preferably, to keep the entire history of transactions. First of all, that is the opposite of scalability. Such a system is not “decentralized”, but more like a “replicated center” system, as there is an absolute necessity to gather all the existing data in a single point to make any meaningful operation. Partial knowledge does not work. The authors describe those full nodes as “super-peers” saying that

Bitcoin nodes could easily keep up with both VISA and MasterCard combined, using only fairly modest hardware (a couple of racks of machines using todays hardware)... the intention is to evolve it towards a more typical two-tier structure in which low powered client nodes connect to long-lived, high powered supernodes.

Thus, Bitcoin is only “peer-to-peer” in the sense of the British Peerage system. Bitcoin “commoners” must appeal to their “lords” who have sufficient means to judge on validity of transactions and to seal those transactions as valid, likely for a fee.


As all the transactions are necessarily broadcasted to every “peer”, matters of anonymity in Bitcoin are sort of tricky. The original paper suggests to employ a separate throw-away identity for every new transaction. As the classic formula says, security=1/usability. Because incoming and outgoing transactions may overlap, those throw-away identities might potentially be linked to one another using data mining techniques.

...a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner.

Thus, for perfect anonymity, both sender and receiver have to split every complex transaction among separate pairs of throw-away identities. But at this point, transactions stop being technically atomic, in addition to the fact that the system becomes quite complicated and heavyweight.


In cryptography, security is based on the right kind of asymmetries. If I encipher my message using strong crypto, then a snooping counter-party will need astronomic amounts of energy to perform brute-force deciphering. That effect holds for local Bitcoin calculations, but at the network level those hard pieces are connected using quite a dubious glue, namely a “distributed timestamp server” based on proof-of-work hash chains.

For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.

Thus, the system stays consistent, as long as “honest” nodes control a much-much bigger pool of computational power than attackers. Here the assymetry goes the wrong way: those “honest” nodes need to burn maximum amounts of energy continuously, round the clock, 24x365, just to keep the system afloat. Not green at all! Meanwhile, an attacker may only mobilize his CPU power temporarily to carry out his deeds. Another bad assymetry is that an attacker needs only to offer the same “coin” to multiple recipients simultaneously to attempt double-spending. Meanwhile, his victims need either to check the full transaction history and all the pending transactions (in the world), and/or wait sufficient time (10 min to 1 hour) till the transaction in question is reliably settled in the transaction history. The reason is, the system produces one transaction block every 10 minutes on average, but the last blocks may potentially be rolled back due to the CPU-voting-based consensus algorithm.

If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.

That algorithm also opens a venue for transaction chain forking attacks. Potentially, a CPU-rich well-connected peer may delay his newly created block till a competing block is received. Then, the delayed block may be concurrently released, thus creating a tie. A sufficiently CPU-rich attacker may perpetuate this tie indefinitely, potentially making the network to flip-flop between two branches of transaction history, with somewhat unclear consequences. Such a process will create side effects of mass transaction rollbacks, implicit status changes of pending transactions and coin creation/disappearance. The extent of havoc such an attacker may bring depends on the correctness of actual Bitcoin implementations operating in the wild. Blacklisting the attacker is tough, as the system is sort of anonymous. Blacklisting coins might create further repercussions.


As you might see, the claims laid by Bitcoin are far from definite. In terms of peertopeerness, privacy, security and usability it might actually turn worse than the present-day real-world legacy banking system. Here and now (Netherlands, 2011) I enjoy an instant, secure, privacy-preserving payment system which charges no fees for domestic transfers. With the SEPA initiative, that is likely extend to all of Europe. Sending money abroad (i.e. to Russia) still takes 2-3 days and incurs fees on the order of 1%, if done right. As the backend of the contemporary banking is definitely paperless, the real money is already e-money. Any competing e-e-money system needs to offer at least the same level of security, coverage, liquidity and privacy, which is hardly the case with Bitcoin at this moment.

Still, the marketing message of Bitcoin employs quite a strong anti-establishment sentiment. In that regard, it reminds a lot the story of BitTorrent. BitTorrent is technologically complicated, infrastructure-wise inefficient, much less usable than a regular Web download, etc. But it got popular anyway, mostly because of unreasonable greed and paranoia of incumbent oligopolistic players. Eventually, it paved the way to reasonable offers, such as iTunes, Netflix and Hulu. Honestly, I also wish somebody would disrupt VISA/MasterCard a little bit.

Victor Grishchenko, 12 May 2011