In the privacy technologies grad seminar that I taught last semester, Bitcoin proved to be the most popular topic among students. Two groups did very different and equally interesting final projects on Bitcoin and cryptocurrencies; more on that below.
More broadly, we’re seeing a huge demand for learning the computer science underlying Bitcoin, both at Princeton and elsewhere. But research papers on Bitcoin don’t make for great teaching materials. Identifying the core ideas, building them up in logical progression, and connecting them to other areas of computer science is a challenging task.
Over the summer, I teamed up with Joe Bonneau, Ed Felten, and Andrew Miller to do just that. We’ve produced a lecture series which will start going online soon. While we spend some time in the lectures on the specifics of Bitcoin, much of our discussion is about the underlying principles which apply to cryptocurrencies in general. Steven Goldfeder and other students are working with us to produce homeworks, programming assignments, and a textbook, which will together comprise a complete online course. We’ll announce it here when it launches.
I’m teaching a version of the course at Princeton as a grad seminar this semester. To my knowledge, this is the first time a course on Bitcoin and cryptocurrency technologies has been taught. I’m looking forward to seeing the final projects that students will do.
I would encourage all CS departments to offer a course on Bitcoin. It’s a topic that students already have a high level of interest in, and it ties together ideas from many areas of computer science — algorithms, cryptography and security, distributed systems, game theory, and programming languages. It also lets you make a few forays into economics, law, and policy. Even if Bitcoin as a currency goes away, these ideas stand on their own and are here to stay.
Here are the two Bitcoin projects from my previous course that I mentioned earlier:
Aaron Doll, Shaheed Chagani, Michael Kranch, and Vaidhyanath Murti built a tool called btctrackr (code, report) that finds clusters in Bitcoin addresses. They build on techniques in the Fistful of Bitcoins paper. The tool lets the user test which of her addresses can be linked to each other, and thus, how much anonymity she has.
Andrew Kim, Daryl Sng, and Soyeon Yu wrote a paper examining the feasibility of a state attack on Bitcoin. Much of their work focuses on analyzing the cost of a 51% attack. They write:
Our calculations suggest that amassing sufficient computing power to launch a 51% attack with the existing technology would cost between US$128 million and US$145 million. Energy costs could be as low as US$106,000 to US$136,000 each day if the mining occurred in a low-cost electricity state in the US or China. Another important factor is the likely growth rate in the Bitcoin hash rate relative to the cost of equipment. Drawing from Professor Michael B. Taylor’s work and estimates, our calculations found that a computing-power based attack could cost US$3 billion in ten years. While all of these costs are not trivial, they are figures that remain within reach of governments like China and the US.
If a state decided to amass the computing power to launch a 51% attack, its main hurdle would likely be the supply of mining hardware, which is finite and might not be sufficient to double the computing power. Additionally, existing ASIC manufacturers could block the large-scale purchase of mining hardware if such an order were detected and raised suspicions. That said, states could take measures to divide their purchase among multiple false online actors. Alternatively, it could produce its own ASICs through state-owned enterprises or expropriate current ASIC production capacity within its borders. Although a sudden influx of new computing power could provoke suspicion and cause demand to change the rules, introducing new rules requires building consensus. This could take more time than it requires for a state to secretly hoard the computing power. A state may only need to accumulate the computer power necessary by stealth and only execute the attack successfully once to reduce faith in Bitcoin’s reliability.
Our calculations help to demonstrate that Bitcoin’s security and viability are not purely derived from its decentralized architecture and technical robustness. With that, the Bitcoin community has not paid enough attention to the potential for a state to sponsor a destabilizing attack on Bitcoin. The proponents of Bitcoin must be aware of the fact that the state, from which it requires recognition and perhaps even protection, can itself threaten the currency as an attacker. The reality of Bitcoin’s vulnerability to state attacks should be included in this debate.
As far as I know, people are still not ready for this type of currencies or any other form of currencies in a distopian perspective. Or maybe I’m just watching too much movies? Great post!
@Daniel Hatfield
By which criteria do you think people are not ready for Bitcoins?
Bitcoinmillionaire – #1 Bitcoin Education App
http://www.bitcoinmillionaire-app.com
I taught it as part of a graduate course in security last year, and was planning to produce a textbook after teaching it again this year.
> If a state decided to amass the computing power to launch a 51% attack, its main hurdle would likely be the supply of mining hardware …
Or, a state actor could task one of its cyber offense teams to take over two or three of the largest miners (http://4.bp.blogspot.com/-UfjWy4WG0dA/VBf6Tjs87rI/AAAAAAAAAhc/0OyF-xGHCYk/s1600/1.pie.16092014.png). The cost would be, I guess a few thousand dollars, to account for the employee’s time, lost revenue from other projects, or the cost of burning a 0-day?
No, because attacking a pool operator doesn’t equate to controlling all the miners that mine in that pool.
Arvind:
Unless I’m wrong, a pool operator *would* have the ability to perform attacks from the so-called “51% attack” category, such as rollback-to-double-spend. That’s because in the current pooling protocols, the pool operator determines what transactions to include and what block to base off of. Perhaps in the future if the big mining pools used the p2pool protocol, or other defenses against that, then this would cease being the case.
Please correct me if I’m wrong.
Oh, and I should have mentioned a recent real live example of the sort of attack that might be able to achieve Dominant Mining status (e.g. “51%”) at a much lower cost than manufacturing a ton of ASICs: the famous Bitcoin BGP Hijack:
news article: http://www.wired.com/2014/08/isp-bitcoin-theft/
details: http://www.secureworks.com/cyber-threat-intelligence/threats/bgp-hijacking-for-cryptocurrency-profit/
Regards,
Zooko
Right, but as soon as a pool is revealed to be malicious (which, in the case of large pools, would be immediately after an attack started), participants would leave the pool. So this attack is categorically different from one where an adversary controls 51% of mining capacity. To characterize/quantify the impact of this attack, we need to know several things:
I wouldn’t be surprised if the answer to #3 were less than 6, which means that the short-term damage would be minimal. Bitcoin’s exchange rate already appears to incorporate the belief that all service providers are hackable (Moore and Christin), so I would suspect that the long-term damage would also be small.
At any rate, these are two very, very different attacks.
We taught one this summer. It was great to bring in some of the anthropological evidence to the technical side:
https://summer.uci.edu/courses/sectiondetail.aspx?serialid=37010&session=S1
I taught such a class late last year. Admittedly, not at a University, although I prepared for it much as I would a series of academic lectures. I wrote up the first couple of lectures here: http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/