Unchained - What Does Cornell’s Emin Gun Sirer See As The Main Security Threats In Cryptocurrency? ‘Everything’

Episode Date: October 4, 2016

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.” Learn more about your ad choices. Visit megaphone.fm/adchoices

Welcome to Forbes Podcasts. Hi, everyone. Welcome to Unchained, a Forbes podcast produced by fractal recording. I'm your host, Laura Shin, a Forbes contributor covering blockchain, cryptocurrencies, and fintech. 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 on your preferred platform. It helps get the word out about Unchained.

For today's episode, I'm speaking with Emin Gunn Sear, 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 the adoption of cryptocurrencies and smart contracts. He also writes a popular blog at Hacking Distributed. Hi,

Good, welcome to the show. Thank you, Laura. Thank you very much for having me on. So tell me about your work and how you became involved in the cryptocurrency and blockchain space. Sure. So my involvement in this space goes back to, I guess, my graduate student years, when I was working with operating systems but I had an eye towards you know I always was fascinated by systems that that can self-configure that are sort of living things in and of themselves if you will and they also was exposed early on to Millicent which was one of the early microcommer systems and so that was back in the 90s early early in 2000s my research 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 that everybody behaves well. Your listeners probably have heard of leachers in torrents, right? So there are people who contribute or who participate in sort of taking, you know, whatever it is, sharing resources, but don't put up any resources themselves. They just leach on the system. This is an undesirable situation. You want to incentivize them to do the right thing for the community. And to that end, I built one of the earliest systems that uses proof of work.

It was a currency, a single currency, a real currency, called karma. And 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 was back in 2002, 2003. And so then I just 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, so flipped back and forth.

And so, you know, and meanwhile, Satoshi came up and came out 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 its value.

And so that got me and 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 could be fixed. There are regions where you cannot fix it. And from there, it's just sort of history. then I got pulled into more and more into blockchain and 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 my, that's how I got involved and that's sort of what's shaped my view coming into the system. And I'm so interested to know, you know, as somebody who I kind of developed your own, you know, a prior version of Bitcoin, I guess you could say. How did you first learn about it? And what were your thoughts when you learned about it? And also, when was that?

So I heard first, 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 white paper and you'll 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-Murti and James Aspenes had done some work on sort of continually solving proof-of-work puzzles. And so it immediately made me think of related work and you know and then the other thing you do is you check to see if

you're cited, right? And so you look at the white paper like, oh, Satoshi didn't know about my work, so that she ends up citing some other work related to spam deterrence. So the work that Satoshi 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 anyway, so you think about the kind of person that he might be. You, 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. So there's a

lot that draws you in and so that was my first reaction to it and and then of course you know can I game it now are there security holes and so forth and so so the can I game it question sort of got really serious for me with with Itai Ayal's appearance at Cornell it Thai Ayal is a postdoc here he's about to become a professor at the Tech Neon he's about to go to Israel and it I came here as a stock and you know in a spare time he was interested in in bitcoin his main task was something else related to consensus protocols of traditional consensus protocols but in his spare time he was interested in bitcoin and he came by one day and he said you know i think there there are some issues

with the the uh the consensus protocol in bitcoin and we i think we can game it and make more money than we should make and so so that got me going again and that led to the work known as selfish mining And 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? Ah, so IC3 is a much, much greater, bigger effort. So so far I described to you sort of how I got into this, and that's my group. That's a group of, I don't know, maybe eight people total. IC3 is an initiative at Cornell that we started.

I'm one of the co-directors. There are three co-directors. The other two are Elaine Shee and Ari Jules. And so what essentially happened is that 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 sugarcoat this. They got caught, you know, they just 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, right? 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. 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. And the excitement around this is immense. So maybe I'm veering off topic a little bit, but I'm so excited. excited about this. So, you know, all my colleagues, they write programs that, so let's leave aside the roboticists, they write programs that actually move things, but everybody else, they just manipulate pixels on a screen, right? You give them input, and you know, the program some input, it generates some output, you print it maybe, you know, 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, hey, 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. And 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 take you know start to pay attention so we now have a number of sponsors some of them fairly well known others very well knows smaller start-ups that are well-known within their communities so 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 that well okay so 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 Ethica. But it's a large concentration of people who work together on timely, interesting topics on blockchains.

And who are some of the sponsors? The sponsor, let's see. So IBM is one of them. Intel is one of them. Let's see. 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 that are the three public ones, and they are our sponsoring of the gold-level sponsors of IC3. One of the big themes I see in your work is around the security of public blockchains, and certainly security has been a big issue this summer, both with the BitFanex hack,

and then also the security of smart contracts with the Dow hack. And 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? So 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, right? Bitcoin has become the universal bug bounty.

In the good old days, we used to sort of, you know, you'd find a, flaw in I don't know when I was a grad student I found a flaw in Java virtual machines both at Microsoft and Netscape and then you disclose and then they deny that they had a vulnerability and then you know if they're good they finally admit and they give you you know like a few thousand dollars or something and but that's not how it works anymore right 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

you know your your your cash is their bounty and uh this is clearly no firm infrastructure to base the rest of our financial infrastructure it's just not this is not how we build things imagine that you know that you've got this cool technology it's called a brick and uh except you know the ukrainian hackers can come in and make your entire you know skyscraper collapse by digging underneath it it's just you know we can't have this happen so um 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 flip side of it is, of course, server-side security, the security of the bitcoins that you place, necessarily

place in the hands of other people, although you shouldn't. But there are many, many, many legitimate circumstances where you kind of have to. And 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 server side. And so the scientific challenge facing us is can we do something better than the current state of affairs? And the current state of affairs is really dismal, right? So you lose your private keys, all your bitcoins are gone. And how often do you lose them? Well, it depends, right? There's 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 you know, I mislay discs all the time. I misplace stuff.

And, you know, and there are some very well-known people. I think a lot of your viewers might have heard of Christian Decker. He was, 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. An incredibly bright fellow and had incredible foresight. I mined a lot of coins early on and had about 10,000 bitcoins. And 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 them back, traced his machine back, took his, 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've done a bunch of work on something called vaults and covenants. And those can help people recover their own coins and only their own coins, in the case of a hack.

Yeah, I actually wanted you to describe those for the listeners. Sure. So, okay, so recently, last February, we published a paper called Covenants, and the core idea with Covenants is to enable people to put writers on how certain coins can be spent. And what's a writer? Essentially restrictions. And 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 volts. 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, look, 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, you know, whatever, some percent of it, 90 percent say.

I'm going to move it into a special vault. Vault is just like every other Bitcoin address. except it has two keys associated with it. You can use one key to un-volt the money. So any money that's in your vault, you would use the regular un-voting key to turn back and move back into your hot wallet. Okay, 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 un-voting key, and that unvoting process takes some time. It necessarily takes a certain designated amount of money. of time. You decide what that time ought to be yourself. So for my use cases, I think that would be typically, say, 24 hours, maybe 72 hours. I don't have any urgent purchases that I do with Bitcoin. So during that time frame, what you can do is you can actually override an unvoting 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 you know, amount of time, 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, you know, 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 unvalting period to say, no, no, no, no, this wasn't me. even though this person has the unvoting key just like I do, even though to the system he looks indistinguishable from me, it's actually not me. And I can prove that by producing this recovery key with which I override his transaction. And so that recovery key, which I keep in a separate safer place, if I were to produce it, I would be able to say, no, no, no, 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, it's all it is. It's the second key that says, no, no, 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. Volts 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. And how do you keep the recovery key safe? Ah, so you would keep it, you don't need it for any day-to-day operation.

You would just print it out and put it wherever you would, 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 the thesis. then what the vaults allow you to do in that terrible scenario is you can burn the money you essentially get to say look you know that person says move the money on vault the money to that location I'm telling you to burn the money and then the money is burned 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 if 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 blockchain 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 gonna get anything. And that can drastically shift the sort of the gameplay here. Because at the moment, every Bitcoin user is just a juicy target. Like every Ukrainian kid,

Why aren't they going in and attacking everybody else? And in fact, you know, we see these, I picked on Ukraine here because the story of Christian Decker involves a hack from Ukraine. But, you know, essentially, you've got hackers everywhere, and you've got all these juicy targets everywhere else, and so you're constantly seeing these attacks, and why shouldn't you? The expected outcome is positive.

You try, every hacker has a, you know, a portfolio of tricks they know. They just throw them at you, and with some probability, you know, 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. Yeah. So I love how, you know, this system that you just described changes the incentive mechanisms.

And that's another big theme that I see in your work. You know, 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? And, you know, 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? Yeah, that's a good question. I thought a little bit about this. And, you know, 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 is you kind of eyeball the situation and you're like, you know, if I were malicious, what would I do? And then, you know, 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, you know, 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. On occasion, though, not on occasion, but in many cases, it's actually the new systems we build are motivated by problems, adversarial problems that we've identified. So, yeah, so there's an interplay between the two, and there are two hats I wear. And, you know, when I wear my adversarial hat, you're essentially just probing every single thing you can about the protocols.

essentially you're doing a big search the search space is immensely big right at this point in the protocol what if I were now I'm expected to send the 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 through those circumstances and and when you're doing so there are so so so many that it's it's not always feasible to do it automatically with the help of a computer so so verification of these systems is difficult. So a trained eye can typically sort of navigate that space and, you know, and find the cases that are going to lead to a compromise.

With Amex Platinum, you have access to over 1,400 airport lounges worldwide. So your experience before takeoff is a taste of what's to come. That's the powerful backing of Amex. Conditions apply. And 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? That's um this is the the big big question right um so I think this before we tackle this little let's talk a little bit about the Dow because I think it's a good running example. Um so what's happened with the Dow was um as I think many of your your listeners know about the collapse there.

But before the collapse, me and my colleagues, Vlad Zamfir and Dino Mark, looked into the code of the Dow, and we issued a call for a moratorium saying, look, this is a fascinating contract. It's amassed an enormous amount of money, $220 million, success beyond anybody dreamed of, but it's vulnerable.

It is not adequate for, you know, doing the task, it's set out to do. In particular, it's set out to sort of make funding decisions on behalf of its investors and to make those decisions with the help of a voting scheme. Well, the voting scheme is gainable. They're like umpteen different ways. I think we ended up counting nine separate issues with it by which the DAO could be subverted and not carry out its task of finding the optimal, optimal asset allocation. Let's see, so what are some general techniques for writing correct programs?

Is one question. And 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 functions and they're supposed to not crash. And I don't know about you guys, but I see mine crash fairly often, right? blue screen of death, everyone's had it at least once in their lifetime and some of us many, many, many times. So when it comes to smart contracts, it's much more dire.

Like there's 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. And essentially, it's kind of odd, right? A lot of people think it's like they kind of view themselves as that famous justice, who said, you know, 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 to 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. And a lot of people think that that's the answer. that this is sort of the golden standard, it is by no means a golden standard. It is, it's, it's, 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 we 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. Okay, 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 checks in it to ensure that that doesn't have an etc. But the actual spec for the Dow is much more high level, right? the spec in English is the Tao 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 Tao. The complexity of the system is really

high, and as of now, I don't know of anybody who has the core science, the fundamentals, 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. And what is, can you define recursive call for the listeners? Oh, sure. Okay. So what happened is the Dow hacker ended up, it was actually the 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 on Ethereum. So the DAO on occasion allows the call. Okay, so here's what you can do with the DAO.

You can invoke a DAO function to transfer some funds to a sub-DOW, a child DAO, that you control. And in that process of transferring funds, the DAO invokes a function that you provide. So if in that function you call the DAO back, then you can get the DAO to go into a loop. It's like inception, right? So you call the DAO, it calls your code to transfer the funds for your code to receive them, in essence.

And when you're receiving them, you call the DAO again. And because of the way the DAO code was structured, it's sort of oblivious about what it's doing, what'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. And 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 out of the Dow to a child of the Dow. And so that was an enormous, enormous hack, heist, whatever you want to call it,

or some people would call it just use and not abuse even. But whatever it was, it ended up transferring a lot of money out of the DAO, making everyone poorer and teaching the entire Ethereum community about this one feature that everybody had forgotten about, whereby, you know, contracts could be exploited. So this is a problematic issue, but these kinds of issues, we can make headway towards eliminating them. So Ethereum is very young and, you know, 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. And tell us what your stance was on that and how you came to that decision.

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. 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 benefited Ethereum as a whole. And sinking so much money into this hole in the ground where the hacker 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 forward at your options. you've got two options. You can burn the cash and say the hacker earns this money. Or you can say, well, 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 advantage of one feature that essentially was forgotten by the community. And this is, 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 blockchains do not stand on their own. They all serve a function. Distribute systems only prosper to the extent that they serve a societal need. And a currency system can only do that which its community wants. If it's not doing that, then, doing that, then it's something else. It's a fetish. It's not the case that I am, you know, there are people out there who just love a blockchain. They just love a bunch of, you know, proofs of work, a bunch of crypto puzzles that depend on each other. I call these people blockchain fetishists. And blockchain 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?

And in the case of Ethereum, the community clearly wanted it to fork. It's like it was 86% 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. And 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. 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. And 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 blockchains? Sure.

So that was interesting. So once the community decided to fork, the initial idea was, well, let's do a soft fork. And 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 blockchain. Let's freeze the Tao. 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. And initially when I thought about it, I thought, well, okay, that's not so bad. You can implement this. But I received a message and email from a student with whom I had actually interacted nine months prior or six months prior. He was 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 blockchains, da, da, da, da. And I encouraged 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 was, well, he'd just finished high school, and he was doing an internship at Consensus in New York City. And he said, well, Professor Serer, 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? 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 Dow, and then they have to toss it out. So normally a big invariant in systems like Ethereum is the transactions have to pay gas for their operations. The more computation you do, the more gas you pay. And in this case, you could get the miners to do enormous computations and pay nothing. And you could do this all day long, forever, 724, 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 softwork was scheduled to go out. And everyone was slated to do it, and suddenly the opinion changed, and everyone was like, no, of course we don't want a denial of service attack. Of course we do not want the softwork

if it's going to end up hurting Ethereum more. And I think it was, you know, I thought it was an enormous success story by these, well, I should have mentioned, it wasn't just the student, the one student, Jaden Hess, but also his friend, River, and River Kiefer. So River and Jaden were the ones who came up with this, essentially, and they did it in a, you know, they just got in, right, it's kind of like in the movies, right before the clock's about to expire. And I think they did an enormous service by keeping Ethereum from getting bogged down by attacks. Had the softwork 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 $1 billion to $900 million.

And, you know, for a second or so, I was like, well, you know, that wasn't so good we lost you know 10 percent there but i kind of view our work as having preserved 90 percent of the of the value of the coin and it really would have gone down to zero had it been open to such a such a blatant vulnerability so um so i think calling off the soft fork was uh was a was a very good outcome and i'm glad we got it done in the nick of time so in terms of the outcomes that maybe didn't go or it 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, happens. 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 Dow. and then there's Ether Classic, which did not. So what do you think it will happen to Ether Classic going forward? So that's a good question. Let's maybe talk a little bit about what happened with that split, right?

So before the split, as you pointed out, I had written this blog post saying, look, you know, the game theory says there will be one dominant fork, but there will be a minority fork if it's subsidized. So if there is somebody throwing money at it to succeed, then it's, can linger on. And so at a high level, there's a, you know, 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 brothers saying all sorts of things about the 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 huge, hugely awesome outcome. And that's much better than having to fight it out with some hacker, playing core wars, you know, hacker on hacker, kind of like they write some code, you write some code, you try to keep them from transferring their funds. And 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, 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.

people who started this process. And 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. And 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. And 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 consensus protocols going on, but it's kind of like a file system person getting upset at, I don't know, at distributed naming service or something. Yes, the protocols used under the covers are very similar, they're completely different functions. And yes, there are tokens and yes, there are people who speculate in them, you know, but that's the speculation, is that what we want to do? That's not what we want to do. That is not what societyally good outcome is not to enable speculators.

But aren't they converging slightly in the sense? 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, you know, intends to bring kind of like the smart contract capability of Ethereum to Bitcoin. And so, you know, maybe now Bitcoin and Ethereum seem rather different, but there is a way where you could look down the line and say, well, they could be more somewhere in the future. 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 to 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 as the established dominant player there. And so, you know, to sort of look at a competitive 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.

And 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, terrible line of reasoning to say, well, multiple years down the line, I might be in the same space as you. So I'm now going to take an adversarial position. I'm going to try to hamper your, you know, whatever it is, your progress. There's going to be strife.

These are not good things. I don't think we should engage in them. So speaking of infighting, I also did want to ask you about the scaling of public blockchains, which has been, as you mentioned, a big point of contention of Bitcoin. How do you think developers can best accomplish this, though, particularly for these public blockchains where they have these sort of grand visions of what they would be able to do for the world? 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 do we? scale Bitcoin? Well, there's only one answer. You scale it on chain. That's the only answer I know of because of the way the question is framed. And just for listeners, so how do you define scaling on chain? 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. And so if you want Bitcoin to sort of be Bitcoin and scale up, well, you've got to improve that number somehow.

Now, and that when I say on chain, I mean without changing the fundamental structure of Bitcoin itself. And that fundamental structure to me and in my worldview, and I think almost all of your listeners will share this, is one based on Satoshi's initial vision, outlined in the white paper. It's a bunch of blocks that reference each other and build a blockchain. 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 might have to have bigger blocks. But there is a limit to how big you can make the blocks and can get scale. So you can't make them a thousand times bigger than that would cause all sorts of problems.

But we want to make the number of transactions about at least 1,000 times, if not 100,000 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. And it essentially is a way to generate the exact same blockchain as outlined 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, you know, extant, block. blocks is one, compact blocks is another, etc. And they're also sort of layer two solutions. I'm a little skeptical about layer two solutions. So layer two solutions are solutions, 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, you know, I know you at least a little bit, and I know you sufficiently to front, say $100 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 and I will settle later. And perhaps I want to transfer some money to somebody who happens to live near you, and this can go back and forth, and we can sort of, without having to hit the main blockchain,

the underlying blockchain, the Bitcoin blockchain, the two of us can have a back and forth of money transfers and thus get some scale. But the problem, 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, well, 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 that I know that you want to transfer money to, who are they, etc. Can we really create these paths and what is their capacity? So that's an open question.

And 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. We don't know. You know, 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 is going to solve these problems. The second issue, of course, is the protocols haven't been developed yet. So finding these routes is difficult.

And finding these routes in a privacy-preserving manner, it's new territory. I don't know if I haven't seen any protocols I would put my faith in. And I certainly don't want, in, 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 people, 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 it's just, you know, I haven't seen it yet. So we're going blind into into, into the Lightning Network, assuming that these challenges can be solved, and I haven't seen them solved yet. So these are two problems. The third one, and also a major problem, is the user experience. So it's hard enough with Bitcoin to get somebody else to use it, right? It's like, oh, I sent some

transaction, where is it going, it got stuck. The failure scenarios are really complicated. Everybody understands credit cards, right? You sort of give somebody your credential, it's just a terrible idea, right so you know you can get a lot of access to a lot of my money if you know my credit card number so credit cards are are bad but at least they're simple and that's a key feature so 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 just going to be at least an hour. And then the user experience of what can go wrong, you know, my transaction is lost. Well, where do I look for it? Where is it? Where could it be? Well, you know, what state is the payment channel in? You know, this is kind of, it'll just explode and get very, 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. Well, when you look at the space and not just Bitcoin, but just the whole space of cryptocurrencies, smart contracts, you know, all of the 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? 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's a lot of work happening at the forefront of consensus protocols. And 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's a lot of exciting work on deploying blockchain protocols for different scenarios. These are not competing with Bitcoin in any shape or form, but but and with Ethereum for that matter. But essentially providing to financial institutions new tools and techniques and there's a lot of exciting exciting work on that front. My group is doing some of it.

Joe Bono at Stanford, Arvin Narayanan at Princeton and Brian Ford in at EPF So these are some of the groups that are looking at new consensus protocols and or new techniques. And I think there is quite fascinating work happening in the fintech space that is independent of anything that might happen with Bitcoin. And it's 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's 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, you know, 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're doing so, 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 Zcash is a promising protocol, I think, in providing confidentiality.

There are other competing protocols that people are pushing. And 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. So, but some of them are, you know, they have interesting features here and there. Well, this has been such a fascinating discussion. Thank you so much. Where can our listeners find more of your work or contact you in the future? So they can see me rant about various different topics at hackingdistributea.com.

And that's where I do most of my sort of pontification about things related to cryptocurrencies. and I also have a Twitter account. It's hard to, well, I'll spell it out as Elite Haxor, EL33T H4XOR. So they're welcome to come and follow me there. It's in jest, by the way, the name. And so that's where I do my pontification. We also have the IC3 web page.

That's where we do our serious academic work. work, and that is initc3.org. Well, thanks so much for coming on the show. Thank you very much, Laura, for having me. Thanks for joining us today. If you're interested in hearing or learning more about GUN, check out the show notes, which are available on my Forbes page, Forbes.com slash slights slash Laura Shin. 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. Thank you.