Something is going on with the Bitcoin network. The entire theoretical (and ideological) foundation of Bitcoin is the assumption that there will be a very large number of nodes forming the world-wide Bticoin network [1, 2]. The consensus mechanism depends on the assumption that “honest nodes control a majority of CPU power” ([1], p.6), and the proof of work “is essentially one-CPU-one-vote.” ([1], p.3).
This assumption is not unreasonable given the large number of computers connected to the Internet, provided that “everyone plays” and most computers are about the same. The Bitcoin software is easily available and not especially difficult to install, and the “mining” payout and opportunity to charge transaction fees offers incentives to run the software.
However, in recent months we have seen some troubling indications that the Bitcoin network is neither uniformly distributed nor growing. These trends could spell disaster for Bitcoin. Bitcoin is the largest and healthiest cryptocurrency network—other coins are certainly suffering the same ailments.
First, Bitcoin mining has evolved rapidly, first expanding rapidly (as expected in the original concept), then being taken over by very large, specialized computation farms. The latter development has skewed the distribution of “CPU power”, effectively pushed out ordinary computers, and concentrating mining in relatively few hands. These developments have been followed by the steep and persistent drop in the exchange rates for BTC, which have put many miners (and other Bitcoin activities) out of business, further concentrating the CPU power. In principle, a sufficiently large concentration of mining power could undermine the consensus mechanism and render Bitcoin useless.
Second, the Bitcoin network needs many nodes to mirroring the blockchain, providing quick access and highly redundant validity checking. These non-mining nodes are basically a public service, and ideally this should cost very little to provide. However, as the Bitcoin blockchain has steadily grown (hundreds of MB per day), it has become harder for nodes to keep a copy, keep up with transactions, and serve queries to the network. It is reported that the number of nodes has not grown for many months (setting aside reconnaissance nodes). Again, if this segment of the network is too small, it will reduce the usability, and potentially become vulnerable to security attacks and disruption through natural or human events.
I note that a recent hoo-haw about a “Sybil attack” on this network illustrated the potential fragility of the Bitcoin network. One company injected a large number of “fake” nodes in order to collect intelligence. The network is still small enough that this perturbed behavior and accidentally entrapped some clueless software. While arguably legal, such behavior certainly does not raise confidence or improve the service of the Bitcoin network. But I suspect that a larger and more robust network would not even notice such “attacks”.
That this problem is serious can be seen from recent ideas for how to “fix” it. I already noted the “Blockchain in Space” idea, which seeks to create highly available nodes in low Earth orbit. If successful, this and similar efforts would help assure that the data is available.
Another notion is to create special purpose “plug in” processors at a reasonable cost. This reduces the complexity, difficulty, and expense of providing a node to the network, to encourage many people to run nodes. This is basically the terrestrial equivalent of the orbital system, with the typical 1:100,000 cost advantage for Earth based systems.
Other approaches seek to modify Bitcoin protocols in various ways (e.g. [3]). For example, Sidechains aim to create alternative blockchains hanging off the main blockchain, which would help limit the costs of the main blockchain. Another variant is the Lightning network, which aims to allow some transactions to be performed “on the side”, and on send the results to the main blockchain.
I would like to add that these scaling challenges are fairly standard fare for large scale computational systems. From the point of view of an engineer, Bitcoin is actually a (slightly) interesting software system: the software needs to carefully calibrate the computational difficulty (CPU, memory, bandwidth). The protocol cannot be too “efficient” or easy, it must be difficult enough that it is not possible to purchase sufficient computing power to completely dominate the system. At the same time, the computation needs to be tractable enough that vast numbers of computers will run the software. Therefore, the software has been designed and continues to be adjusted in order to hit a happy region, hard but not too hard.
Even more tricky, the Bitcoin “network” is a decentralized collection of volunteer computers which come and go, and which are not controlled or paid for by any central organization. This means that the “happy” goal is actually a moving target, since the constellation of participating computing hardware continues to change. Even in the few years that Bitcoin has operated we have seen the development of purpose built processors (ASICs), designed to implement the Bitcoin computations extremely efficiently. We also have seen a shift to hand held devices and cloud services, which means that users have little computing power in their own hands.
Furthermore, the socioeconomic constellation is also constantly shifting, which has direct impacts. The random jiggle of exchange rates dramatically alters the economics, as do the cross currents of legal and political developments.
The bottom line is that Bitcoin (and similar cryptocurrencies) cannot be a final, fixed design.
- Nakamoto, Satoshi, Bitcoin: A Peer-to-Peer Electronic Cash System. 2009. http://bitcoin.org/bitcoin.pdf
- Vigna, Paul and Michael J. Casey, The Age of Cryptocurrency: How Bitcoin and Digital Money Are Challenging the Global Economic Order, New York, St Martin’s Press, 2015.
- Bruce, J.D., The Mini-Blockchain Scheme. Cryptonite, 2014. http://cryptonite.info/files/mbc-scheme-rev2.pdf
Cryptocurrency Thursday
Robert McGrath's Blog 