Cornell University computer science professor Emin Gun Sirer, an influential figure in the cryptocurrency and blockchain space, describes his ideas for improving security in the space, his skepticism about how to scale these networks, and how the last time financial institutions invested in their systems appears to be for Y2K. He also tells us how growing up in an environment where he saw a lot of scams helps him find problems in code, explains why Bitcoin is the “universal bug bounty,” and reveals how two high school students saved burgeoning cryptocurrency network Ethereum “like in the movies — just before the clock was going to expire.”
Show Notes
https://www.forbes.com/sites/laurashin/2016/10/04/what-does-cornells-emin-gun-sirer-see-as-the-main-security-threats-in-cryptocurrency-everything/#23de9bf9380dTranscript
Female Speaker:
Welcome to Forbes Podcasts.
Laura Shin:
Hi, everyone. Welcome to Unchained a Forbes Podcast produced by Fractal Recording. I’m your host, Laura Shin, a Forbes contributor covering block chain, cryptocurrencies and fin tech. Thanks for tuning in. If you’ve been listening to the show and like what you’ve been hearing, please review, rate, and subscribe to the show in your preferred platform. It helps get the word out about Unchained. For today’s episode, I’m speaking with Emin Gun Sirer, Associate Professor of Computer Science at Cornell University who works on operating systems, networking and distributed systems. He is extremely active in the cryptocurrency community. He and his team have written several influential white papers and even blog posts that have changed the trajectory of cryptocurrencies.
They’ve also been behind some improvements to the code in Bitcoin and Ethereum. He’s also co-director of the Initiative for Cryptocurrencies and Contracts, an initiative put together by professors at Cornell, Cornell Tech, Berkeley, and other universities to help advance to adoption of cryptocurrencies and smart contracts. He also writes a popular blog at Hacking Distributed.
Hi, Gun. Welcome to the show.
Emin Gun Sirer:
Thank you, Laura. Thank you very much for having me on.
Laura Shin:
So tell me about your work and how you became involved in the cryptocurrency and block chain space.
Emin Gun Sirer:
Sure. So my involvement in this space goes back to I guess my graduate student years when I was wrking on operating systems. You know, I always was fascinated by systems that can self-configure, that are sort of living things in and of themselves, if you will. I also was exposed early on to Millicent, which was one of the early microcommerce systems. So that was back in the ‘90s. Early in 2000s, when I became a professor, my research took a turn towards peer to peer systems and I did a bunch of things in that space that I won’t bore you with but in almost every system we built there was a problem of incentivization. It’s very difficult in a peer to peer setting to make sure everybody behaves well.
Your listeners probably have heard of leechers in torrents, right. So there are people who participate in sort of taking whatever it is sharing resources but don’t put up any resources themselves. They just leech on the system. This is an undesirable situation. You want to incentivize them to do the right thing for the community. To that end, I built one of the earliest systems that uses proof of work. It was a single currency, a real currency called Karma. So it was widely cited. It’s academically very well-known but I did not sort of proselytize it beyond academics. So it wasn’t adopted. This is back in 2002, 2003 and so then I kind of sat on that work for a while that my interests veered off to other topics. I went back to my roots on operating systems, sort of flipped back and forth.
So meanwhile, Sitoshi came up with a very cool idea and a breakthrough in how he uses proof of work and combines it with a bunch of other things and not only those technical things but he also built a community and with any currency system that is really key. That is what gives it it’s value. So that’s got my interest back in cryptocurrencies. I took a closer look at Bitcoin and we then did the work on selfish mining where we discovered that you could misbehave and end up making more money than your fair share. We came up with a fix for selfish mining to the extent that it would be fixed. There are regions where you cannot fix it and from there it’s just sort of history.
I got pulled more and more into block chain and cryptocurrencies and have been working on this topic since. It’s a fertile space and there’s a lot of excitement in it and rightfully so. There’s so much to do and so many exciting computer science problems. So that’s how I got involved and that’s sort of what’s shaped my view coming into this system.
Laura Shin:
I’m so interested to know, as somebody who kind of developed your own prior version of Bitcoin I guess you could say, how did you first learn about it and what were your thoughts and also when was that?
Emin Gun Sirer:
I first heard about Bitcoin around 2010, 2011 and one of the first things you do when you hear about something like this is you download the whitepaper and you look at sort of what the core idea is and the core idea seemed really interesting. It had been previously discussed in some depth by some other people. You know, Arvind Krishna Marti and James _____ 5.05 had done some work on sort of continually solving proof of work puzzles. So it’s immediately made me think of related work.
You know, then the other thing you do is you check to see if you’re cited and then you look at the white paper like Sitoshi didn’t know about my work. Sitoshi ends up citing some other work related to span deterrents. So the work that Sitoshi cites, it uses proof of work as well but it’s not a currency. So if you read that white paper there’s a bunch of stuff that’s missing. So you think about the kind of person he might be. Of course, get pulled into the human story. A pseudonymous person, is it a single person, is it multiple people, is there something more behind it? How did the currency get started? How much money did one put up to prop up the currency in its initial days and so forth?
So there’s a lot that draws you in and so that was my first reaction to it and then of course can I game it? Are there security holes and so forth? So the can I game it question got really serious for me with Itai _____ 6.15 appearance at Cornell. Itai _____ 6.18 is a postdoc here. He’s about to become a professor at the Technion. He’s about to go to Israel. Itai came here as a postdoc. You know, in his spare time he was interested in Bitcoin. His main task was something else related to Consensys protocols or traditional Consensys protocols. But in his spare time, he was interested in Bitcoin. He came by one day and he said, you know, I think there are some issues with the Consensys protocol in Bitcoin and I think we can game it and make more money than we should make. So that got me going again and that led to the work known as selfish mining.
Laura Shin:
That sort of leads us to the work that you guys are doing with IC3. What does IC3 do and how did it come to be?
Emin Gun Sirer:
So IC3 is a much, much greater, bigger effort. So far, I described to you sort of how I got into this and that’s my group. That’s a group of maybe eight people totally. IC3 is an initiative at Cornell that we started. I am one of the co-directors. There are three co-directors. The other two are Elaine Shi and Ari Juels. So what essentially happened is the three of us got together and we all were supremely excited about cryptocurrencies and we could see certain trends in action. One big trend of course is the financial industry needs some help. There’s no way to sugar coat this. They got caught. They just got caught way behind the main game. Their systems are aging. They haven’t really done any investment in their infrastructure for, I would say, about 16 years and the last time they did any investment was for the Y2K bug.
So they are way behind the times. They’re struggling with simple things like auditability, with being able to reconcile ledgers, keeping ledgers in sync, being able to transparently prove to regulators that they did not misbehave and so forth. There are lots of issues facing them and so it was clear to us that the finance industry had to take a close look at the way they did things. It was also clear to us that there’s a big social movement saying, hey, we need other systems for managing money. And of course, there’s the whole issue of smart contracts. One of the next big steps to come after Bitcoin. So there are all sorts of fancy things you can build, new instruments you can build, new systems you can build that manage money.
The excitement around this is immense, so maybe I’m veering off topic a little bit but I’m so excited about this. You know, all my colleagues, they write programs that…let’s leave aside the roboticists. They write programs that actually move things but everybody else, they just manipulate pixels on a screen. You give them input and they program some input that generates some output. You print it maybe, that’s the extent of what you do, but with smart contracts you’ve got programs that manage money flows. That’s an amazing new capability and nobody knows how to write these things. It’s really easy to get things wrong, so we thought we have to do something to provide structure to this space, to provide some entity that will organize the efforts in this space and we got some of our friends together. We wrote a proposal to NSF and NSF very kindly funded us to quite a good level. So now we have a fairly strong initiative with industry support. So once you have something that creates the backbone of an organization then you have industry start to pay attention.
So we now have a number of sponsors, some of them fairly well-known, others smaller startups that are well-known within their communities. So it’s a wonderful situation. The sum total number of people I think is somewhere between 50 to 60, maybe more at IC3. I would say at least 14 or 15 have PhDs. So this I think is the largest concentration of academics under one roof. Not literal roof because some of us are at Berkeley, some of us are in New York City, some of us are in Ithaca. But it’s a large concentration of people who work together on timely, interesting topics on block chains.
Laura Shin:
And who are some of the sponsors?
Emin Gun Sirer:
So IBM is one of them, Intel is one of them. Chain is obviously one of them and there are a bunch of others in the works that we’re working on. So those are the three public ones and they are the gold level sponsors of IC3.
Laura Shin:
One of the big themes I see in your work is around the security of public block chains. Certainly, security has been a big issue this summer both with the Bitfinex hack and then also the security with smart contracts with the Dow hack. So I’m curious, what do you see as the main security threats in the cryptocurrency space and what are some of your proposals for resolving them?
Emin Gun Sirer:
That’s such a great question. Where to start? So what is the main security threat? Everything. When you have so much value, everything you’ve got is essentially a bounty. Bitcoin has become the universal bug bounty. In the good old days, we used to sort of…you’d find the flaw. When I was a grad student I found a flaw in Java Virtual Machines both at Microsoft and at Netscape. Then you disclose and then they deny that they had a vulnerability and if they’re good they finally admit and they give you a few thousand dollars or something. But that’s not how it works anymore.
So there are a bunch of people who are constantly looking for bugs and the moment they find one they infiltrate your system, they take your Bitcoin, they become rich and your cash is their bounty. This is clearly no firm infrastructure to base the rest of our financial infrastructure. This is not how we build things. Imagine that you’ve got this cool technology, it’s called a brick and except Ukrainian hackers can come in and make your entire skyscraper collapse by digging underneath it. It’s just we can’t have this happen.
So the security issues facing Bitcoin I would divide into two different categories. At the very highest level I would say client side security is a real issue. It has always been and the flipside of it is of course server side security, the security of the Bitcoins that you necessarily place in the hands of other people, although you shouldn’t, but there are many, many legitimate circumstances where you kind of have to. In those circumstances, sadly, you typically end up giving up all control and currently end up becoming vulnerable to all sorts of attacks from the service side.
So the scientific challenge facing us is can we do something better than the current state of affairs? The current state of affairs is really dismal. So you lose your private keys, all your Bitcoins are gone and how often do you lose them? Well, it depends. There was the guy who tossed out his disc and it could happen to me. I kind of think of myself as a semi-sophisticated user but I mislay discs all the time, I misplace stuff and there are some very well-known people. I think a lot of your viewers might have heard of Christian Decker. I think he was adopter number seven or so of Bitcoin. It was very, very early on. He was a grad student in Switzerland. I was on his PhD committee and he just got his doctorate about six months ago, incredibly bright fellow and had incredible foresight, mined a lot of coins early on and had about 10 thousand Bitcoins.
Guess what happened. One day, he discovered that his Bitcoins had gone missing and it wasn’t an unsophisticated setup. It was behind two firewalls and somehow people had traced his machine back and took his coins. So question here is can we do better and I believe we can. So I can expand on that later on if you like.
We have done a bunch of work on something called vaults and covenants. Those can help people recover their own coins and only their own coins in the case of a hack.
Laura Shin:
Yeah. I actually wanted you to describe those for the listeners.
Emin Gun Sirer:
Sure. So recently, las February, we published a paper called Covenants and the core idea with Covenants is to enable people to put riders on how certain coins can be spent. What’s a rider? Essentially restrictions. What does this allow you to do? Well, it allows you to implement all sorts of things in general but I want to focus on one thing, which is this idea called Vaults. So what you can do with Vaults based on Covenants is essentially designate some of your money as cold storage. Essentially, what you do is you say I have my wallet right now and I normally would spend out of it and everything would be in it and life would be fine, but I know that most of it I’m not going to need. So I’m going to take some percent of it, 90 percent say. I’m going to move it into a special vault. A vault is just like every other Bitcoin address except it has two keys associated with it. You can use one key to unvault the money.
So any money that’s in your vault you would use the regular unvaulting key to turn back and move back into your hot wallet. So suppose I decide for whatever reason I’m going to spend all my Bitcoins. Well, I’m going to have to take my money out of my vault so I use my unvaulting key and that unvaulting process takes some time. It necessarily takes a certain designated amount of time. You decide what that time ought to be yourself. So for my use cases I think that would be typically 24 hours, maybe 72 hours. I don’t have any urgent purchases that I do with Bitcoin. So during that timeframe what you can do is you can actually override an unvaulting operation with the second key. We call that the recovery key. So what does that mean? In the usual use case, it means that you just put your money in the vault. You then take it out. You have to wait a little bit, however much you designated it to be and then after that time you just use it out of your hot wallet and everything’s great. But much more importantly, suppose I’m at the beach or whatever and I’m hanging out and somebody hacks into my machine and they start moving my funds.
Then I have the duration of that unvaluting period to say no, no, no this wasn’t me. Even though this person has the unvaulting key just like I do, even though to the system he looks indistinguishable from me it’s actually not me. I can prove that by producing this recovery key with which I override his transaction. So that recovery key, which I keep in a separate safer place if I were to produce it I would be able to say you don’t get to take this money out. I get to revert this money back into my hot wallet. So this I think is a fairly simple idea. It takes a while to describe how it works but deep down all it is, is a second key that says stop this with some restrictions. That’s why these covenants are there, these riders in place so that nobody, no merchant can be fooled about these transactions. Vaults are vaults and they’re separate from hot wallets, so it’s not the case that I would be able to buy something from you and I would use the recovery key to get my money back. That’s not how it works at all.
Laura Shin:
How do you keep the recovery key safe?
Emin Gun Sirer:
You don’t need it for any day to day operation. You would just print it out and put it wherever you put incredibly safe things. If you were to have your recovery key also compromised that’s the worst possible scenario. Then you’re in this deep bind. There is absolutely nothing distinguishing you from the thief. Then what the vaults allow you to do in that terrible scenario, the disaster case scenario is you can burn the money. You essentially get to say, look, that person says move the money, unvault the money to that location, I’m telling you to burn the money. Then the money is burnt and what that does is it takes away from the thief any potential for a positive outcome. He can hack all he wants into your systems but if your money is in a vault it’s really safe. He’s not going to get any of it if you actually intervene in a timely fashion.
So we envision that there will be services that actually watch the block chain for you and can intervene. So this I think is a pretty cool idea because all of a sudden you’ve taken away the universal bug bounty. These people can come in and hack all they want but they’re not going to get anything. That can drastically shift the game play here because at the moment every Bitcoin user is just a juicy target. Every Ukrainian kid, why aren’t they going in and attacking everybody else? In fact, I picked on Ukraine here because the story of Christian Decker involves a hack from the Ukraine.
Essentially, you’ve got hackers everywhere and you’ve got all these juicy targets everywhere else so you’re constantly seeing these attacks and why shouldn’t you? The expected outcome is positive. You try. Every hacker has a portfolio of tricks they know. They just throw them at you and with some probability they will get in and they will make money. With vaults even if they get in they make no money so now they’re going to have to move to a different target and that’s a great outcome.
Laura Shin:
I love how this system that you just described changes the incentive mechanisms. That’s another big theme that I see in your work. You often look at kind of how perverse incentives can arise where they’re not intended and I’m so curious, how do you work out these different scenarios. How can you be sure that you’ve covered them all and how do you think creators of smart contracts can write code that creates the incentives that they actually intend?
Emin Gun Sirer:
That’s a good question. I thought a little bit about this and there is no structured answer I can give you. There is no sort of playbook. It helps to have grown up in an environment where I saw a lot of scams, so that’s essentially what you do. You eyeball the situation and you’re like if I were malicious what would I do. Then things usually fall apart fairly rapidly I don’t know. But it takes a certain kind of adversarial thinking. Some people have this in spades and some others are different, they’re more constructive thinkers. I tend to think of myself mostly as a constructive person actually so most of my work is about building new systems.
In many cases, the new systems we build are motivated by adversarial problems that we’ve identified so there’s an interplay between the two and there are two hats I wear. When I wear my adversarial hat you’re essentially just probing every single thing you can about a protocol essentially you’re doing a big search. The search space is immensely bit. At this point in the protocol I’m expected to send message X but what if I don’t? What if I delay it? What if I send message Y? What if I change a field and so forth?
So you have to think though those circumstances and when doing so there are so many that it’s not always feasible to do it automatically with the help of a computer. So verification of these systems is difficult. So a trained eye can typically sort of navigate that space and find the cases that are going to lead to a compromise.
Laura Shin:
So what suggestions would you give to creators of smart contracts so that way their programs end up really executing what they intend them to execute?
Emin Gun Sirer:
This is the big, big question. So I think before we tackle this let’s talk a little bit about the Dow because I think it’s a good running example. So what happened with the Dow was, as I think many of your listeners know about the collapse there, but before the collapse me and my colleagues Vlad Znafier and Dino Mark looked into the code of the Dow and we issued a call for a moratorium saying this is a fascinating contract. It’s amassed an enormous amount of money, 220 million dollars, success beyond anybody dreamed of. But it’s vulnerable. It is not adequate for doing the task it set out to do. In particular, it set out to sort of make funding decisions on behalf of its investors and to make to decisions with the help of a voting scheme. Well, the voting scheme is gameable. There are umpteen different ways. I think we ended up counting nine separate issues with it by which the Dow could be subverted and not carry out its task of finding the optimal asset allocation.
So what are some general techniques for writing correct programs is one question. I think this is an open research issue. It’s one of the grand challenges facing computer science today. So if you think about your desktop programs, right, they’re supposed to carry out function and they’re supposed to not crash. I don’t know about you guys but I see mine crash fairly often. Blue screen of death. Everyone’s had it at least once in their lifetime and some of us many, many times. So when it comes to smart contracts it is much more dire. There is real money at stake, sometimes a lot of money at stake and the bugs can be subtle. So in this whole game or war really there are a couple of tools that are useful.
So generically speaking, it’s incredibly useful to have a spec. If you don’t have a specification of what you want to do then you’re just navigating blind. You’re going to get to wherever you get to and that’s going to be your destination. If code is law then there is no greater truth than what you’ve got and if it’s got bugs in it then you’re screwed. Essentially, a lot of people think they kind of view themselves as that famous justice who said pornography, I know it when I see it. Well, you know a bug when you see it but if you don’t have a spec how is anybody else going to agree with you? So the very first thing is to have a spec not only the prove to others that this was unintended but to also document for yourself what it is that you want to do.
The second level up from a spec is a formal proof that the code you have matches the spec you’ve got. A lot of people think that that’s the end all, that this is sort of the golden standard. It is by no means a golden standard. It can in fact be misleading to have a formal proof because there can easily be flaws in the spec and there can easily be properties of your code that you want it to have but are not embodied in your spec. So if we were to go back to the Dow case. The current technology with have for specifying things formally can specify basic what we call safety properties. So what’s a safety property? Well, the code will not divide by zero. So that’s an easy thing to check. Relatively speaking, I can go through the code and prove to myself that all the divisions will be made by numbers greater than zero or I can put the check in it to ensure that that doesn’t happen, etcetera.
The actual spec for the Dow is much more high level. The spec in English is the Dow shall reflect the voting preferences of its constituents. Now, I don’t know how to write that in logic, in first order logic or in any amended logic that I’m aware of. It’s very difficult to specify what that means especially when you’ve got concurrent votes and so forth that are happening in the Dow. The complexity of the system is really high. As of now, I don’t know of anybody who has the core science, the fundamentals to even be able to express the spec let alone prove it. So there is a very long road ahead of us with a lot of core science that’s needed to make sure that smart contracts are trustworthy.
But basic stuff of the kind that the hacker initially exploited to break into the Dow contract. Those we can hope to sort of keep under control, so he ended up taking advantage of a recursive call error and essentially that stemmed from the entire community not understanding that these recursive calls were there and could be problematic.
Laura Shin:
Can you define recursive call for the listeners?
Emin Gun Sirer:
Sure. What happened is the Dow hacker or hackers were very sophisticated so they ended up using multiple exploits. The initial exploit that they used took advantage of a little known feature in Solidity, the language that is used to program smart contracts in Ethereum. So the Dow on occasion allows the…so here’s what you can do with the Dow. You can invoke a Dow function to transfer some funds to a sub-Dow, a child Dow that you control and in that process of transferring funds the Dow invokes a function that you provide. So if in that function you call the Dow back then you can get the Dow to go into a loop. It’s like inception. So you call the Dow, it calls your code to transfer the funds for your code to receive them in essence. When you’re receiving them you call the Dow again and because of the way the Dow code was structured it’s sort of oblivious about what it’s doing, what it’s in the middle of doing, and it ended up saying, oh, okay, you want to transfer some funds? Okay, I’ll call you again and so it calls you again and you call it again and so forth. Instead of making one call you could or the hacker did end up making a gazillion calls, some total of which ended up transferring about 50 to 60 million dollars out of the Dow to a child of the Dow.
So that was an enormous, enormous hack, heist, whatever you want to call it. Some people would call it just use not abuse even. But whatever it was, it ended up transferring a lot of money out of the Dow, making everyone poorer and teaching the entire Ethereum community about this one feature that everybody had forgotten about whereby contracts could be exploited. So this is a problematic issue but these kinds of issues we can make headway towards eliminating them.
Laura Shin:
So Ethereum is very young and there were differences of opinion on how to resolve this issue and obviously we have the one side of the community that believes that immutability is an extremely important characteristic and they were against kind of rolling back the network to be able to return the funds to the people who had lost them, but that is what the majority of the community ended up doing. Tell us what your stance was on that and how you came to that decision.
Emin Gun Sirer:
So let’s see, I was mostly neutral in the beginning but looking at what was happening at this, it seemed like the Dow investors were essentially consisted of a lot of people who had sort of committed to Ethereum as a platform, they wanted to see Ethereum succeed, they saw the Dow as an investment vehicle that was going to make the community richer, that would invest in things that benefitted Ethereum as a whole. Sinking so much money into this hole in the ground where the hackers stood and burning it seemed at odds with what the community wanted. So the situation then was actually quite dire if you look at what happened the day of the hack. You look at your options and you’ve got two options.
You can burn the cash and say the hacker earns this money or you can say we’re going to claw it back and we’re going to make the hacker poorer and we’re going to revert this one transaction that was unintended and took at advantage of one feature that essentially was forgotten by the community. Both options are pretty bad. In fact, both options are pretty terrible but given these two terrible options it seemed like the fork option was better in the sense that it led to greater utility, greater happiness for the community.
You have to remember that cryptocurrencies and block chains do not stand on their own. They all serve a function. Distributed systems only prosper to the extent that they serve a societal need. A currency system can only do that which its community wants. If it’s not doing that then it’s something else, it’s a fetish. There are people out there who just love a block chain. They just love a bunch of proofs of work, a bunch of crypto puzzles that depend on each other. I call these people block chain fetishists. Block chain fetishism is not going to get us to a good community. I think what is important is at the end of the day, where does the value go, what does the community want it to do?
In the case of Ethereum, the community clearly wanted it to fork. It’s like it was 86 percent or more I think at the last poll that I looked at that wanted the hack to be undone and revert the funds from the hacker. So then there was an issue of whether to fork it soft or fork it hard and then there was of course the fork itself and the aftermath involving Ethereum Classic.
Laura Shin:
So before we get into that I actually just wanted to ask you about the soft fork because you had written a blog post that outlined a way that the soft fork could be attacked. As a result of that blog post the Ethereum community changed its mind. So can you tell the story of what happened and how in general you see your role in these public block chains?
Emin Gun Sirer:
Sure. So that was interesting. Once the community decided to fork the initial idea was let’s do a soft fork. What’s a soft fork in this case? Let’s have the miners evaluate smart contracts and if the smart contract ends up touching the Dow then let’s not add it to the Ethereum block chain. Let’s freeze the Dow. Everything related to the Dow we freeze to buy ourselves time. This is an incredibly sensible idea. It feels like it would be my first reaction, too, and it was my first reaction. Initially, I thought that’s not so bad. You can implement this, but I received an email from a student with whom I had actually interacted nine months prior or six months prior. When I first interacted with him he was a high school student and he had written to me out of the blue and he said I’m very excited about block chains. I encourage him to apply to Cornell and he had applied to Cornell in the meantime. He had been accepted to Cornell but he was still in high school and he just finished high school and he was doing an internship at Consensys in New York City. He said, Professor Sirer, wouldn’t it be the case that if we were to do a soft fork then the network would be vulnerable to an enormous attack? Wouldn’t it be the case that somebody could flood it with transactions that cost almost nothing to generate and are very expensive to evaluate for the miners. The miners would have to execute them for potentially a long time only to discover at the very end that this thing touches the down and then they have to toss it out.
So normally a big variant in systems like Ethereum is the transactions have to pay gas for their operations. The more computation you do the more gas you pay. In this case, you could get the miners to do enormous computations and pay nothing and you could do this all day long forever, 7/24 just bogging the entire thing down, and therefore this was an enormous denial of service vulnerability. So we wrote our blog post. It ended up coming out maybe two-and-a-half days before the soft fork was scheduled to go out. Everyone was slated to do it and suddenly the opinion changed and everyone was like of course we don’t want a denial of service attack. Of course we do not want the soft fork if it’s going to end up hurting Ethereum more. I think it was an enormous success story.
I should have mentioned it wasn’t just the one student. Jayden Hess but also his friend River Kiefer. So River and Jayden were the ones who came up with this essentially and they did it in a…it’s kind of like in the movies, right before the clock’s about to expire. I think they did an enormous service by keeping Ethereum from getting bogged down by attacks. Had the soft fork gone forward we would have been looking at a disaster scenario. We would have seen attackers come out full force, attack the system. It would have easily crashed and burned to zero. As it is, with our announcement, Ethereum’s valuation went from one billion to 900 million and for a second or so I thought that wasn’t so good. We lost 10 percent there but I kind of view our work as having preserved 90 percent of the value of the coin and it really would have gone down to zero had it been open to such a blatant vulnerability. I think calling off the soft fork was a very good outcome and I’m glad we got it done in the nick of time.
Laura Shin:
So in terms of outcomes that didn’t happen in such an ideal manner, let’s talk about the hard fork. You had written a blog post that laid out several of your fears around the hard fork and one was that the minority fork might survive and that of course happened so Ethereum split into what is Ethereum, which is the part of the network that did roll back so as to return the funds invested in the Down. Then there’s Ether Classic, which did not. So what do you think will happen to Ether Classic going forward?
Emin Gun Sirer:
That’s a good question. Let’s maybe talk a little bit about what happened with that split. So before the split, as you pointed out, I had written this blog post saying the game theory says there will be one dominant fork but there will be a minority fork if it’s subsidized. If there is somebody throwing money at it to succeed then it can linger on. So at a high level there’s a lot of noise that came out, in fact the trolls were out in full force. Twitter was full of everybody and their brother saying all sorts of things about how the fork went, but from my perspective the fork actually was a huge success. It ended up doing what it intended to do. It ended up reverting the funds. Everybody who put their Ether in to the Dow got their Ether back.
That is a hugely awesome outcome and that’s much better than having to fight it out with some hacker, playing core wars, hacker on hacker kind of like they write some code, you write some code, you try to keep them from transferring their funds. That game would have been an unending source of strife and a huge loss of value for everybody who participated. The community would have turned away a lot of the early adopters. So I think Ethereum would have really, really taken a huge hit if not just died if the money had not been reverted.
So as far as Ether is concerned the fork was a huge success. Now, the fork gave rise to an opportunity for people who were not vested in Ethereum to step in and behind the scenes I saw some of this. There were some people trying to buy up old coins and I know exactly who they are and it was interesting the initial people who started this process. It was a malicious effort. It was essentially money that wanted Ethereum to die, that falsely saw Ethereum as a competitor with other cryptocurrencies, particularly with Bitcoin. I think this is a false view. I don’t think these two currencies compete. I have a very simple litmus test for it. If you think about Bitcoin and Bitcoiners and if you look at what they do, they typically worry about merchants. If you think about Ethereum people they think about applications. It’s just night and day. It’s water and oil. These two things are very, very, very different.
Sure, there’s the same kinds of Consensys protocols going on but it’s kind of like a file system person getting upset at distributed naming service or something. Yes, the protocols used under the covers are very similar. They’re completely different functions. Yes, there are tokens. Yes, there are people who speculate in them but the speculation is that wat we want to do? That’s not what we want to do. That’s not what we want to do. That is not what…a societally good outcome is not to enable speculators.
Laura Shin:
But aren’t they converging slightly? Well, maybe converging isn’t the word but there are ways in which they’re becoming more similar. For instance, we have Root Stock being developed on Bitcoin, which intends to bring kind of like the smart contract capability of Ethereum to Bitcoin and so maybe now Bitcoin and Ethereum seem rather different but there is a way where you could look down the line and say they could be more similar in the future.
Emin Gun Sirer:
Potentially that’s true, but what you see happening there is Bitcoin deciding to branch out of its actual function. Bitcoin’s function currently is value transfer and Ethereum’s function right now is computation. These are two separate domains. The fact that Bitcoin wants now obviously go into the Ethereum space that’s fine. That’s nice but that’s going to take a bunch of years and I don’t know that it will happen in the same form as Ethereum. Ethereum already is the established dominant player there.
So to sort of look at a potential perceived competitor down the line and to get sort of obsessive about it that’s kind of weird. That is not, at least, how I work. I don’t know that that’s good, that is infighting between…you know, we’ve seen the infighting between Bitcoin factions. It’s not been good for Bitcoin and infighting between Bitcoin and Ethereum and other cryptocurrencies is also not going to be good for the entire space. So I think that’s a terrible line of reasoning to say multiple years down the line I might be in the same space as you so I’m not going to take an adversarial position. I’m going to try to hamper your progress. There’s going to be strife. These are not good things. I don’t think we should engage in them.
Laura Shin:
So speaking of infighting I also did want to ask you about the scaling of public block chains, which has been, as you mentioned a big point of contention with Bitcoin. How do you think developers can best accomplish this though? You know, particularly for these public block chains where they have these sort of grand visions of what they would be able to do for the world.
Emin Gun Sirer:
So there are lots of issues on the table when it comes to scaling Bitcoin. So if we were to look at it narrowly, which is how do we scale Bitcoin there’s only one answer. You scale it on chain. That’s the only answer I know of because of the way the question was framed.
Laura Shin:
Just for listeners, how do you define scaling on chain?
Emin Gun Sirer:
Scaling on chain to me means the chain must grow in some fashion to accommodate more than three-and-a-half transactions per second. So currently, the chain works by issuing about one block every 10 minutes and that block is one megabytes big. So that comes out to three-and-a-half transactions per second and that’s the max Bitcoin can do. So if you want Bitcoin to sort of be Bitcoin and scale up you’ve got to improve that number somehow. When I say on chin I mean without changing the fundamental structure of Bitcoin itself and that fundamental structure to me and in my world view and I think almost all of your listeners will share this is one base on Sitoshi’s initial vision outlined in the white paper. It’s a bunch of blocks that reference each other and build a block chain. So that’s the only way forward.
Now, the way the chain is generated will need to change for us to be able to do that. So we may have to have bigger blocks but there is a limit to how big you can make the blocks and get scale. So you can’t make them a thousand times bigger then that would cause all sorts of problems, but we want to make the number of transactions at least a thousand times if not hundred thousand times larger so how do we get there? So my group has done some work on protocols that retain the entire Bitcoin structure, just change some mechanistic issues on the wire about how the blocks are generated. The protocol here is called Bitcoin NG, Bitcoin Next Generation.
It essentially is a way to generate the exact same block chain as outlines in the white paper but in a slightly different fashion and issuing it in a slightly different manner so as to keep the pipeline full and to generate many more transactions per second than would be allowed by one megabyte blocks every 10 minutes. So that’s one way. There are other techniques, X thin blocks is one, compact blocks is another, etcetera. There are also sort of layer two solutions.
I’m a little skeptical about layer two solutions. So layer two solutions are one of the most famous ones is called the lightning network. Essentially, what these do is they build a credit network on top of Bitcoin so for example, Laura, I know you at least a little bit and I know you sufficiently to front say 100 dollars on your behalf to someone around here. So if you ever wanted to transfer some money and I happen to know that person you could ask me and I’ll give that person some money out of my own pocket and you n and will settle later. Perhaps I want to transfer some money to somebody who happens to live near you and this can go back and forth and without having to hit the underlying block chain, the Bitcoin block chain the two of us can have a back and forth of money transfers and thus get some scale.
There are a bunch of problems with this. The main one of course is we’re not doing Bitcoin at this point. The lightning network, even though it uses the same syntax for transactions as Bitcoin, even though it uses a similar sort of style of addressing it is not the Bitcoin network that we’re transferring the funds over. We’re now transferring the funds over a credit network and doing so has a whole lot of issues of its own. So first of all you might say what are these issues? First of all, we don’t know what the performance of this network is because we don’t know what this network looks like. I happen to know you and there’s an edge between us but I don’t know a bunch of other people and the people you know that you want to transfer money to, who are they, etcetera. Can we really create these paths and what is their capacity? So that’s an open question.
So the performance and the scale you’re going to get with a layer two solution is unclear, nobody knows what that’s going to look like. Anybody who tells you they know the answer to this is flat out lying. We don’t know the human interaction patterns. I know I have a lot of friends on Facebook. I don’t know how many of them I’d actually front money for by the way and how much that would be. So that particular credit network hasn’t emerged in any form or any medium that I know of. So that is an enormously big problem. It’s a big unknown and we’re not going to settle this until it emerges and anybody who says that this is going to solve our problems is essentially making a blind faith assumption that when this thing arrives it’s going to solve these problems.
The second issue of course is the protocols haven’t been developed yet. So finding these routes is difficult. Finding these routes in a privacy preserving manner is new territory. I haven’t seen any protocols I would put my faith in, and I certainly don’t want some random joe to discover that I happen to know you, that you and I have a credit relationship. Why should they? I have a bunch of credit relationships with a lot of merchants and nobody should know who those merchants are. Why should you know who my best friends are, what their credit limits are? So it’s going to be fairly difficult to design a decentralized, peer to peer protocol that’s going to preserve privacy and guarantee anonymity to participants and this just…I haven’t seen it yet so we’re going blind into the lightning network assuming that these challenges can be solved and I haven’t seen them solved yet.
So these are two problems and also a major problem is the user experience. So it’s hard enough with Bitcoin to get somebody else to use it. It’s like I sent some transaction, where is it going? It got stuck. The failer scenarios are really complicated. Everybody understands credit cards. You sort of give somebody your credential is just a terrible idea. You can get access to a lot of my money if you know my credit card number. So credit cards are bad but at least they’re simple and that’s a key feature. Bitcoin sadly is not simple. It’s very hard. Try explaining to an audience how Bitcoin works. I’ve done this to many general audiences by now. I’ve briefed all sorts of people in government on Bitcoin and it takes at least 20 minutes to describe how Bitcoin works.
Now you add on top of this how lightning works it’s going to be at least an hour and then the user experience of what can go wrong. You know, my transaction is lost. Where do I look for it? Where is it? Where could it be? What state is the payment channel in? This is kind of it’ll just explode and get very, very complicated. So I think these three fundamental issues are currently unsolved and the first one of course is unsolvable until deployment.
So putting one’s blind faith into layer two solutions I currently see as quite optimistic and not the path of a prudent technologist.
Laura Shin:
When you look at the space and not just Bitcoin but the whole space of cryptocurrencies, smart contracts, all of this stuff that’s enabled by this type of technology what do you think is the most cutting edge or promising technology or project that you’re seeing right now?
Emin Gun Sirer:
So there is a lot of work going on, on all sorts of fronts. It’s hard to sort of…it’s very difficult to answer that question. So there is a lot of work happening at the forefront of Consensys protocols. I want to put aside Bitcoin for a second. So the Bitcoin use case is special and it requires its own special treatment, but there is a lot of exciting work on deploying block chain protocols for different scenarios. These are not competing with Bitcoin in any shape or form and with Ethereum for that matter. But essentially, providing to financial institutions new tools and techniques and there’s a lot of exciting work on that front. My group is doing some of it. Joe _____ 52.57 at Stanford, Arvin Narianan at Princeton and Brian Ford at DPFL. So these are some of the groups that are looking at new Consensys protocols and / or new techniques. I think there is quite fascinating work happening in the fin tech space that is independent of anything that might happen with Bitcoin and has essentially nothing to do with it. You could apply these techniques to all sorts of things that have nothing to do with money actually and I think some of the exciting use cases have very little to do with money. So there is that.
On the Bitcoin front there is interesting…or Bitcoin-like value transfer systems front there is interesting work happening on confidentiality. So in the early days of Bitcoin it was billed as an anonymous system. That narrative got reverted to pseudonymous as people figured out that these addresses were leaking information and I think as of today very few people would actually advise you to use Bitcoin as it is. You know, if you want to actually retain some privacy you would need to do at least something like Coin Join or something of that kind to hide what’s going on otherwise your employer can easily see where your money is going and that is not a good outcome.
So Z Cash is a promising protocol I think in providing confidentiality. There are other competing protocols that people are pushing. Now, there are a bazillion other efforts as well. There are lots and lots of alt coins as you all know and most of them offer no value whatsoever but some of them have interesting features here and there.
Laura Shin:
Well, this has been such a fascinating discussion. Thank you so much. Where could our listeners find more of your work or contact you in the future?
Emin Gun Sirer:
So they can see me rant about various different topics at Hackingdistributed.com and that’s where I do most of my sort of pontification about things related to cryptocurrencies. I also have a Twitter account that’s hard to…I’ll spell it out. It’s ElittteH4XOR. They’re welcome to come and follow me there. It’s in jest by the way the name. So that’s where I do my pontification. We also have the IC3 webpage. That’s where we do our serious academic work and that is Initc3.org.
Laura Shin:
Well, thanks so much for coming and the show.
Emin Gun Sirer:
Thank you very much, Laura, for having me.
Laura Shin:
Thanks for joining us today. If you’re interested in learning more about Gun check out the show notes, which are available on my Forbes page, Forbes.com/slights/LauraShin and if you’ve been enjoying the podcast please remember to review, rate, and subscribe to it to help others find out about it. Thanks again for listening.
Female Speaker:
You just enjoyed a Forbes Podcast. To learn more about our other shows, visit Forbes.com/podcasts. Thank you.
