Lecture 8: Forks

• Download English-US transcript (PDF)

The following content is provided under a Creative Commons license.

Your support will help MIT OpenCourseWare continue to offer high-quality, educational resources for free.

To make a donation or to view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu. NEHA NARULA: Welcome back.

Today, we are going to talk about forks.

So I think you guys have had a guest lecture last week from Alin Tomescu, who talked about his project, Catena.

And one of the really interesting things about Catena is that he's trying to prevent a server from equivocating.

So he's trying to keep a server from being able to say one answer to some people and another answer to another person.

That's kind of the goal of this whole blockchain thing.

But there's actually something really complex that happens when we start to change what's happening in the network, and we start to change the software that's happening in the network.

And so this lecture is going to be about forks.

And I want you guys to feel free to raise your hands and ask questions during class, because this stuff is actually kind of non-intuitive sometimes.

So a blockchain is a chain of blocks which have previous hash pointers inside of them.

So a question-- can a block point to two previous blocks at the same time?

Anybody know the answer to this question?

No, exactly, that is the whole point.

There is exactly one spot in the block header for a previous hash block.

And so a block can only point to one previous block.

A single block cannot point to two previous blocks.

However, can this happen?

Can two different blocks point to the same previous block header?

Yes, yes, and this happens all the time.

Now, part of the reason that this happens all the time is because the way that blocks are found in the bitcoin network is completely probabilistic.

There are many people who are trying to find the next block at the same time.

And it's entirely possible that two different miners will get lucky in a time period that is within the time it takes for a block to get gossipped around the network.

And so, totally, two people can find the same block at the same time.

This is actually what's known as a fork.

And you can kind of see why.

We have a fork in the chain right here.

But what does it really mean when there's a fork in the chain?

I just told you that this is something that happens all the time.

And these cryptocurrency networks seem to keep running.

They seem to be keep going.

So perhaps it's not as bad as it seems, even though it seems to be violating one of the major tenets of what a blockchain is.

Well, it is kind of bad, actually, because when you have these two blocks here, is there anything that makes one the right blockchain over the other blockchain?

Just if this is one blockchain right here, and this is another blockchain right there, how is one supposed to distinguish between this?

Yeah?

AUDIENCE: The one with the most work.

NEHA NARULA: The one with the most work, OK, that's a great sort of way of thinking about it.

What if they have similar amounts of proof of work.

Then what?

AUDIENCE: The one that's accepted by the majority of the network.

NEHA NARULA: The one that's accepted by the majority of the network.

How do we know which one is accepted by the majority of the network?

It gets extended, OK, great.

So that's a really good way of looking at it.

Before we go into what that means, do people understand why if this state were to persist it would be a really bad situation?

One thing that we could have, given that there's two blocks, what that really means is that we have two versions of history.

We have two versions of the ledger if these two things are not the same.

Different coins might be spent on one side of the fork, versus on the other side of the fork.

In fact, the same coin might be spent in two different people on either sides of these forks.

And so over here, Alice might be spending her coin to Bob.

Over here, Alex might be spending that same coin-- and, remember, coins can only be spent once.

Even if Alice has other coins, she specifies which coin she's spending.

Alice might spend that coin over to Carol.

And so if Bob sees this, he thinks he got paid.

If Carol sees this, she thinks she got paid.

And we violated one of the fundamental tenets of the blockchain, which is not to double spend coins.

You can't create money out of nowhere. If these two things would persist, if we don't resolve this fork somehow, then we literally have two different versions of the same currency.

This is kind of as though I took the money in my pocket, my dollar bill, and I xeroxed them all, and managed to convince some people that the Xerox was also real.

This is the exact same thing as what's happening when you have these two things persist.

OK, so how do we fix it?

Well, which is the right one?

And just given what I've shown you right here, it is not clear which is the right one.

And like I also said, this happens all the time in the bitcoin network because the bitcoin network is probabilistic.

So the way that people figure out which one is the right one is they wait.

They wait and see which side gets extended.

And by the nature of probability, one side is going to eventually win out, and get extended more often than the other side.

It's very unlikely for two forks to randomly sort of probabilistically exist at roughly the same way for the same amount of time for very long.

Now, as someone said, you might look at this.

How do you distinguish between these two things?

There is this common idea that in blockchains we take the longest chain.

Longest is a little bit misleading actually.

It's not the longest chain.

It's the heaviest work chain.

So we pick the chain that has the most proof of work on it, even if that happens to have a smaller number of blocks.

Usually that's not the case.

That's not what happens.

The reason for that-- does anyone know why we take the heaviest chain instead of the longest chain? AUDIENCE: So that nobody can cheat and lower the level of difficulty.

NEHA NARULA: Right, so it's not very easy to do this.

But over time, someone could slowly decrease difficulty level, and then create a nice, really long chain with many low difficulty blocks, and then say, hey, I've got the longest chain.

I have the most number of blocks.

Despite the fact that your chain has more proof of work on it, you should all take my chain.

And they could do that with less than a majority of the hash power.

Now, this is not easy attack to do.

But it is a possible attack.

And so that's why we take the heaviest chain, which represents the most hash power in the system, the majority of the system.

So forks happen all the time.

Forks are normal.

The way that people who see forks decide which side of the fork to use, is they check and see which one has the most proof of work, the heaviest proof of work.

Now, one thing that's kind of cool, is, as you probably learned about two classes ago, even SPV nodes, even clients, can tell which chain has the most proof of work simply by looking at the headers, the block headers.

They can see what the difficulty is.

And they can measure for themselves which side of the chain has the most proof of work.

They don't even need all of the chain.

So this is a nice property of light clients, is that they can download all of the block headers and immediately tell which side of a fork has the most proof of work.

Great, we call the block that ends up-- so what do we do with this block?

Does anyone know what actually happens with this block?

Anybody?

OK, so this book is basically abandoned.

This block is just left.

It exists.

It points into the chain.

That's great.

In bitcoin, in particular, it's meaningless.

It doesn't mean anything.

Every transaction that was in that block is not considered to have happened.

So those transactions need to be replayed on the chain that ends up being the longest chain.

And this happens, like I said, all the time.

We call that block an orphan, because it doesn't have anyone.

It's kind of the wrong way around.

I mean, I think of this as a child.

But, whatever, this block doesn't have a parent.

But we call those blocks orphans.

And, again, remember, we pick the side of the chain that ends up having the most proof of work.

Now, we draw these figures in two different ways.

Sometimes we draw the figures like this, like there's this blockchain that exists out there, that is written down, and that everyone is sort of looking at.

There's one blockchain.

But this isn't a logical representation.

In reality, there are many, many, many, many different blockchains.

In fact, every node in the system has its own version of the blockchain.

And it's what those nodes are doing together that ends up deciding what the blockchain actually is.

So if these are nodes that are running the bitcoin protocol, and when I say nodes, what's the difference between a miner and a node? AUDIENCE: Nodes verify transactions, but miners push blocks.

NEHA NARULA: Exactly, so miners actually create blocks in the system.

Miners have write access to the blockchain.

They actually produce new blocks.

People think a lot about what the miners are, and what the miners can do.

And there's a lot of game theory thinking about the miners.

And, oh, what if they collude, but the hash power does this?

And sometimes we forget that nodes in the bitcoin network are actually incredibly important too, because it's the nodes in the bitcoin network that are now creating blocks.

And, to be clear, someone could be a miner and a node at the same time.

They're distinct roles.

The same entity could certainly run a node and be a miner.

But nodes are doing something really important as well, which is they're reading all of the blocks.

And they're deciding which side of a fork to take, and which blocks to accept and which blocks not to accept.

So let's say that these are all bitcoin nodes.

And this is what the blockchain looks like right now.

And we've used this figure multiple times.

Every block has a previous hash, which acts as a pointer to the previous block.

Every block has a set of transactions.

And every block has a nonce, such that when you take the hash of the block header, you end up with something that has a sufficient number of leading zeros.

It has valid proof of work. So let's say that this is the state of the system right now.

And then, we see this new block come along.

So what happens here is that a miner has produced this block, and has sent it out over the bitcoin network.

They've started gossiping the block around the bitcoin network.

And so every one of these nodes, hopefully, will eventually, if they're well connected, will see this block.

They're going to see the block at different times.

And they're each going to make an independent decision about the block.

So every node is going to decide when it sees this block what to do with it.

And there's basically two things it can do with it.

One, it can add it to its own local version of the blockchain.

And number two, it can reject it.

Does everyone see why that is?

So sure, every node is maintaining this local copy of a blockchain.

There is no single, global copy that everyone is referring to physically.

There's no single database running the blockchain.

Every node has its own local copy of the blockchain.

Every node is making its own local decisions about whether or not a block is valid, and about whether or not it's going to add that block to its own local copy of its blockchain. So the way that the node decides this is that it has a set of validation rules.

So it has its own set of rules, which are specified by the bitcoin protocol.

And it checks that block against its set of validation rules.

So every node, every bitcoin node, is constantly validating, constantly validating blocks.

Here are just some of the validation rules.

And we've talked about a lot of these sort of off and on during the class.

So first of all, there's a max block size.

And the way that this works is if at any point you fail one of these validation rules, you reject the block.

So first, the block has to be smaller than this variable max block size.

At the moment, max block size is set to 1 megabyte.

Every single transaction in the block also has to be valid.

And what does that mean?

Well, it needs to be formatted a certain way.

And it also means that when we concatenate the script pub key and the script sig together, and then run that through the interpreter to evaluate the script on the stack, it ends up returning true.

And if at any point, any transaction-- and not just any transaction, any input in any transaction, does not satisfy this, we reject the entire block. Another thing that each transaction needs to satisfy if it's valid, is if the transaction specifies an end lock time, than that end lock time needs to be greater than whatever is specified in the transaction.

That transaction is now is now far enough in the future that it can be satisfied.

The block as a whole needs to have valid proof of work.

So it needs to have a nonce, such that when you hash the block header, you end up with a hash that has a certain number of leading zeros.

And what's really interesting is the protocol also specifies exactly how many leading zeros there need to be, depending upon how many leading zeros there have been in blocks in the past. There cannot be any double spends.

So given the version of the blockchain that I, as a node, have, this better not be double spending any outputs.

There are some rules around what the block can have as its timestamp.

It cannot be more than-- if I see a block that has a timestamp that's more than two hours in the future from my own timestamp, I will reject it.

And if it isn't after some point that's the median of the previous block's timestamps, then I'll also reject it.

And, of course, the block needs to actually point to a block that I've seen before.

And as a node, I will keep around blocks which have a previous hash pointer that I don't know about.

But I'm not going to keep them around forever, because that's a potential Dos attack.

And in order for me to actually insert this block into my version of a blockchain, I need to know which block to put it after.

Note also, note what's not on here is that it needs to be the only block pointing to a previous block.

I'll keep around multiple blocks at the same level until I have some sense of which one is going to win out, because of the probabilistic nature of maybe this block I'm seeing is not going to end up being part of the blockchain.

Maybe it's going to be an orphan. So these validation rules are what are called consensus critical rules in the bitcoin network.

And what that means is that if you want to tweak these rules, if you want to change them, then you may end up changing which blocks nodes will accept, and which blocks nodes won't accept.

Now, something that's kind of interesting to note here is that the entire script interpreter in bitcoin is consensus critical.

Yes?

AUDIENCE: If you reduce the amount of transactions, does that reduce the size of the blocks as well?

NEHA NARULA: Yes, it can.

Yes, so you can definitely have a block-- so that's a great question actually.

So let's say that we had a block that was half a megabyte.

What would nodes do?

What do you think?

AUDIENCE: I think an advantageous miner would potentially process it faster.

NEHA NARULA: That's true. What would you as a node do.

If you're running the bitcoin protocol as it exists today, and it has the following set of rules, and I hand you a block that's half a megabyte, what would you do?

You would say OK, exactly, because the rule that I specified here just says the block has to be less than 1 megabyte.

It didn't say it has to be greater than anything.

And is half a megabyte less than 1 megabyte?

Yes, so you're going to pass the checks.

And you're going to accept the block. AUDIENCE: Is that a good thing for miners, so maybe remove the transactions from a potential block, because they want to process it faster?

NEHA NARULA: Sure, so the question is, should miners remove transactions from a block, or perhaps not put transactions in a block, because it seems like they could process a small block faster than a large block, right?

So that is very true.

Miners, if there are fewer transactions, they have fewer things to verify.

So they can check and see if the book is valid faster.

However, the fewer transactions, the fewer the transaction fees.

And so the less the miner will earn from the block. Yes?

AUDIENCE: And also, the energy put in, most of it mining, is like mining the block, not actually verifying.

NEHA NARULA: Yeah. So verifying transactions is nowhere near as CPU-intensive as it is to actually find the nonce and produce the proof of work.

However, miners should verify transactions before even starting that process.

And so if a miner didn't verify transactions, they would get a head start on the proof of work process.

So there's that sort of balance.

And, in fact, I think we've talked about this in this class before, there have been times in history where things have happened that have shown that miners actually haven't been verifying blocks.

They'll just mine on whatever.

It's caused some problems.

And they ended up losing a lot of money because they should have been verifying blocks.

Great.

So these rules are what are called consensus critical.

They are the rules that each node independently uses to decide whether or not they're going to accept the block.

Yes?

AUDIENCE: When you talk about nodes, you talk about SPDs, right?

NEHA NARULA: No.

I'm not talking about SPDs when I talk about nodes.

I'm actually talking about full nodes.

So I'm talking about nodes that are holding onto the entire bitcoin blockchain, that are looking at every block, every transaction.

AUDIENCE: So the difference between a miner and and a node are [INAUDIBLE]?

NEHA NARULA: A miner-- yeah, they're distinct roles.

So a miner is running this proof of work algorithm to try to find-- to produce blocks.

A full node does not write blocks.

It doesn't create new blocks.

It receives blocks, and then validates them, or not, and adds them to its local copy of the blockchain.

A miner might also be running a full node.

Yes?

AUDIENCE: Miners should be running full nodes.

NEHA NARULA: Yeah, they should be.

But it's not clear that that happens, for the reasons we were talking about before.

I'm sorry?

AUDIENCE: You can force miners to [INAUDIBLE] NEHA NARULA: OK, so let's go back to this image right here.

These nodes are all running some version of the software.

They see this transaction.

And they say, yes, this looks like a valid transaction to me.

And note that they have to-- or, sorry, block.

They look at this block.

Yes, this looks like a valid block to me.

And note that they kind of have to evaluate that block with respect to all of the other blocks that it's seen.

No double spends, all of the scripts eggs, the script pub keys, work out correctly, it's the right size, et cetera, et cetera.

And then once it's decided that that's all OK, each node will independently make the same decision to add that block to its blockchain.

So you can see here that determinism is actually really important.

It can't be the case that there's any randomness in this process.

It can't be the case that sort of randomly, depending on the time of day, one node will decide this is a valid block, one node will decide it's not a valid block.

That's not the greatest situation to have happen.

We want this to be as deterministic as possible.

We want them to all independently arrive at the same decision.

Great.

So this is how validation works.

This is what nodes do.

Major problem, though-- sometimes, we need to change the validation rules.

Sometimes, we need to upgrade the software.

I mean, software is not a static thing.

The software that these nodes are running, there's going to be bugs.

There might be security vulnerabilities.

We might want to add new features.

And so we're going to want to change the validation rules.

It's pretty much inevitable.

And, yet, given the nature of the system, we can't upgrade every single node at the same time. So I think a useful analogy here, something to think about, is actually browsers.

So web browsers-- right now, a lot of people run Chrome.

But not everyone runs Chrome.

And Chrome actually has auto update where it will push changes to your browser.

Google will automatically upgrade you.

But the way the browsers used to work is that you didn't always have auto update.

Or it would bother you, and ask you if you were OK with auto updating before.

And people would say, I don't deal with this right now.

I'm in the middle of something.

I don't want to auto update my browser, and have to restart the whole thing.

And so what would end up happening is you'd have significant numbers of people on very different versions of browsers.

And this was kind of a disaster for the internet, because people who were developing websites, they wouldn't have any confidence that the majority of their users, or a significant majority of their users, had upgraded to the new features.

So they had to support all these old versions of browsers.

And it was a nightmare.

So that's what we're dealing with here in cryptocurrencies, except it's even worse.

So you definitely cannot guarantee that everyone will upgrade their software at the same time.

You can't guarantee that everyone will even upgrade ever.

And so the designers of the software, when you want to create a new version of software, you have to think really, really carefully about it.

So let's say that we're in this situation right here, where these three nodes are running V1 of the software.

The developers have worked out V2.

V2 has some interesting new features, which slightly changed the validation rules about what a node running V2 will consider valid or invalid.

So now, when we see this new block, and we ask the question, is this block valid, these nodes might make different decisions.

In particular, maybe the old nodes will think it's valid.

Great, passes all the validation rules.

I will append this block to my blockchain.

And the new node will not think it's valid, and will say, garbage block, fantastic.

I will not append this block to my blockchain.

And what we end up with when this happens is we have two different versions of history.

The nodes running the old version of the software think that there are four blocks in the blockchain.

The nodes that are running the new version of the software have decided that that block is invalid.

And they only have three blocks in the blockchain.

So what does this mean?

First of all, is this like the situation we saw before, where if we just wait for enough proof of work this will sort itself out? What do you guys think?

I'm seeing some people shaking their heads.

And, yes, this situation is different than the situation we saw before, because the situation we saw before, all the nodes still had the same validation rules. They just saw the blocks in different orders, or they got later, whatever.

All of that can be resolved by looking at the proof of work.

Sometimes when this happens, sometimes when nodes are actually running different versions of validation software, things can be resolved by just looking at proof of work.

But quite often, actually, they can't.

And so in this situation, what might happen is another block comes along.

So this is a different block than this one.

And this set of nodes might decide that this is the next block in the blockchain, whereas the blue nodes will never, ever, ever validate this block.

They will never decide that this block is valid, given the version of the software they are running.

They will never switch to a blockchain that has this block in it, even if it has the most proof of work.

So I think this is a really important point.

And I think it sort of fundamentally gets to why miners don't actually have as much power in the system as one might think that they do.

And the reason for that is that the way bitcoin is designed is that a node will never accept a chain with a single invalid transaction.

If, according to its set of rules, a single transaction is invalid, it will completely ignore that chain.

Doesn't matter if it has the most proof of work. Does that make sense to everyone? It's kind of intense.

It's kind of crazy, right?

Like, even if it has mountains upon mountains of proof of work, it will completely ignore that chain because there's something invalid about it.

So miners can mine what they want.

But they better mine within the validation rules set of the economic majority of the nodes.

Otherwise, those nodes are all going to ignore whatever they mine.

And their money is not going to be worth anything. Great.

So in this situation, we end up with two different blockchains.

And we actually end up with something quite irreconcilable, unless we change the software again, somehow.

And what we've ended up with that's irreconcilable is we now have a block over here, and a block over here.

This node will never accept a chain with this block in it.

And so we've got two different blockchains. So when this happens, we call it a fork.

Now, the word fork can be used to mean many different things in software.

For example, you fork a project on GitHub.

When you fork a project on GitHub, you might make changes to it.

This is a little bit different because of the linearity of history here.

When a fork happens in a cryptocurrency, in particular a sort of a fork that can't easily be resolved, that isn't just going to, oh, one side has more proof of work, OK, great we're all going to switch to that other side.

When you have a fork that can't be resolved that easily then it's actually a pretty big deal, because like we were saying earlier we now have two versions of history, two different versions of money.

It's like I took the dollar from my wallet, and I photocopied it.

And now there's $2 where there was only one.

So maybe you like this kind of dollars.

Maybe you don't like that kind of dollars.

We've basically taken this entire network that all sort of agreed on what this form of money was, and we've divided it into two. So there's two different kind of forks that people will talk about mostly in this industry.

But forking is actually much more complicated than that.

You can't just talk about forks as in-- so the two different kinds of forks are soft forks and hard forks.

And I'm going to explain what a soft work is, versus a hard fork.

But, actually, that delineation, it gets much more nuanced because different things happen in a soft fork versus a hard fork, depending upon who's decided to adopt the rules.

OK, so a soft fork-- a soft fork is a fork which is backwards compatible.

So we have some rule set.

And under that rule set you apply that rule set to every single possible one megabyte chunk of data.

And we're going to end up with some set of what are valid blocks.

A soft fork is when you add rules to the rule set, such that the set of valid blocks actually shrinks. So what does that mean?

We had a whole bunch of rules before.

Blocks have to be less than 1 megabyte.

Transactions all have to be valid.

It means that their scripts certify, like validate, under the certain script interpreter, et cetera, no double spends.

Let's take one of the rules that's actually pretty simple, which is that blocks have to be less than one megabyte.

Let's say that I change that to blocks have to be less than two megabytes.

Is that a soft fork? AUDIENCE: Yes. NEHA NARULA: Oh, wow, there's some actual dissent over this, right?

OK, so someone who says no, why is the answer no?

AUDIENCE: Because you have something that is now accepted that wasn't accepted before.

NEHA NARULA: Right, so remember, valid blocks before newly valid blocks fit inside of this.

Now, someone who said yes it's a soft fork, why do you think that?

AUDIENCE: All blocks still have less than two.

NEHA NARULA: Right.

So it's actually not a soft fork.

And the reason that it's not a soft fork is because a block that is 1.75 megabytes, previously, the old rule set, was invalid.

New rule set, it's valid.

But we just said everything that's newly valid has to fit inside what used to be valid.

So a soft fork is restricting the set of valid things.

You can think of it as expanding the set of rules that a block now has to comply with.

So a feature of this is that if you don't upgrade-- so V1 is the old rule software.

V2 is the new rule software.

If you don't upgrade, you will continue to see the new blocks as valid.

And this is actually a very nice property, because, remember what happened over here, we had this property where the people on the blue side were just never, ever going to accept one of these blockchains.

And if it were the case that this were a soft fork, the old side would never, ever-- well, if this sorry, if it were the case that this weren't a soft work, the old nodes would never accept this new stuff.

So soft forks are really nice, because they're backwards compatible.

Old nodes will still see the new blocks as valid.

They won't reject them.

If that chain gets a ton of proof of work, then the old nodes will happily switch over to that chain.

So, what does that mean?

So let's say that the black nodes are the old rules, and the blue nodes are new rules, new rule blocks.

And, again, we have to look at this from two different perspectives.

There are the people creating the blocks.

And there are the people reading the blocks.

And sometimes those are the same people.

Sometimes, they're not.

So we're looking at blocks here.

So these are people who are creating the blocks. And, again, both of these sets of people might upgrade or not upgrade.

So we might have miners who are following the old rules and miners who were following the new rules.

Then we might have validating nodes who are following the old rules, and validating nodes who are following the new rules.

And this is not even talking about SPV yet.

OK, we're just talking about miners.

And we're talking about nodes.

So let's say some of the miners upgrade to the new rules, but not all of the miners upgrade to the new rules.

The miners who didn't upgrade to the new rules are going to continue producing old rule blocks.

They're going to continue producing V1 version blocks.

But if the majority of miners upgrade to the new rules, remember, the new rule people have new rules.

So they have more restrictions on the set of blocks that they will accept.

So they might not see that block as valid.

So they're never going to accept that chain, because it has invalid things in it.

Once you've upgraded, you might no longer accept the old chain as valid.

And so what's going to end up happening is something that looks very much like the orphaning situation that was happening before, where if the majority of the hash powers, which is over here, this chain is going to keep going bigger.

These guys might keep trying to produce old style blocks.

But they just keep getting orphaned off.

It's actually like very much in their economic interest to hurry up and upgrade, so they're not wasting hash power on orphan blocks. Are there questions about soft forks? Yes?

AUDIENCE: So are soft forks also used for changing software other than validation?

NEHA NARULA: Yes, that's a great question.

Are soft forks also used for changing software other than validation?

So we can certainly upgrade more than just the validation parts of the bitcoin software.

If it doesn't change the set of blocks that would be accepted or not accepted, we don't even bother calling it a fork.

So let's say that we wanted to change something about the peer to peer network, or the way that things are stored on disk, or something like that.

We would see that a change like that, if it didn't change the set of blocks that would have been accepted or not accepted, if after the change a set of blocks accepted or not accepted is the exact same, we don't call that a fork, a change that induces a fork.

It's only when the set of blocks are accepted or wouldn't be accepted are actually changed.

Yes?

AUDIENCE: How often do updates get pushed on the network?

NEHA NARULA: Great question.

How often do updates get pushed on the network?

So Bitcoin is at version 0.16 right now.

And 0.16 came out like a week or two ago.

And I think it's sort of been on the order of a couple months between different versions of Bitcoin.

Other cryptocurrencies release more frequently.

Some release less frequently.

Some do forks very, very regularly.

And we'll speak a little bit about that.

But the software is pretty much constantly getting updated. Yeah?

AUDIENCE: So in practice, people are just updating their versions?

NEHA NARULA: Yeah, so in Bitcoin in particular, Bitcoin does not have an auto update function.

So in order to run the new version of the software, you have to decide that you're going to run the new version of the software.

Or there might be a way to decide to turn auto update on.

I can't remember.

But the point is that they try to leave it in their user's hands.

Yes?

AUDIENCE: How are versions created?

So if you like on the GitHub, there are a ton of features, and sometimes they're pushed forward.

Is there a subreddit, where they're like, OK, version? NEHA NARULA: OK, how are versions created?

It's actually very similar to any other software project, where the people who work on the software project get together, and decide which pull requests are going to be part of the new version.

So, yes, at some point, they're just like, new version, release.

Yeah? AUDIENCE: Do software get released as updated versions?

NEHA NARULA: Yes, soft forks are definitely released as updated versions.

So that's a great question.

I think not every version has a soft fork in it.

But if there is a soft fork, it will definitely be a new version.

Yes?

AUDIENCE: Why can't this black miner not just look at the version in the blue block and decide not to?

NEHA NARULA: Because it's not a blue block.

So you're talking about here, right? OK, so the nodes are running different software.

And then a block comes along that-- ideally, yes the block would have a version number in it that specifies which version of the software.

And this is a very useful field in the block header.

But that's not really-- so what it has a different version?

AUDIENCE: If it's lower than mine-- sorry, higher than mine, then I don't do it.

Then I won't update first.

NEHA NARULA: What do you mean by don't do it?

You mean, you ignore it?

AUDIENCE: No, I [INAUDIBLE] myself, because I see that a higher version is in circulation.

NEHA NARULA: So that would be one way of running the network, which is if I ever see anything that indicates that there's newer software out there, I just realize I'm old, and that I need to update. I think that Bitcoin simply made a different design decision, which was that older nodes should still be able to-- because think about nodes that were sort of set it and forget it, they're out there running.

One tenant that is absolutely true is that users will not upgrade.

They will not all upgrade.

It just won't happen.

You will have old versions of software running.

And given that you will have old versions of software running, I think it's a question as to whether or not those nodes should still be a part of the network, or whether you just want to slice them off because they're not running the latest version.

And I think in Bitcoin, they want those nodes to still be a part of the network.

They want people to be able to make the active decision not to upgrade.

Tadge actually, I think is still running 0.13, or some older version of Bitcoin.

Still works great.

He can still validate transactions totally fine.

OK, so we just talked about soft forks.

And I think the important thing to remember about soft works is that soft works are backwards compatible.

We also talked about an example that is not a hard fork, which is if we decided that we wanted to allow blocks that were less than two megabytes, instead of less than one megabyte.

And so a 1.75 megabyte of block appears.

That is not a soft work.

What if we changed the rule to say that, instead of only accepting blocks that are less than one megabyte, we're only going to accept blocks that are less than half a megabyte.

Is that a soft work or hard fork? AUDIENCE: Soft fork.

NEHA NARULA: That's a soft work.

The reason that that's a soft fork, is because a block that is less than half a megabyte was also still less than one megabyte.

So it's still valid under the old set of rules.

So if the change made here was now we want smaller blocks.

So we're only going to take blocks that are less than half a megabyte.

That's fine.

Everyone will still see this chain as valid.

This is still backwards compatible.

Just because your blocks are 300 kilobytes now doesn't mean that they violate a rule.

AUDIENCE: Can I ask one last question in relation to that?

So what happens if I want to do something with the old version, and [INAUDIBLE]..

And they realize, wow, I love [INAUDIBLE].. NEHA NARULA: Right, so what happens to all the previous stuff in my chain, right?

Now, ideally, the way that the rules would be setup, the new rules, is that they would take effect sometime in the future.

So you wouldn't apply those rules retroactively to the things that you already put into the chain, because then you just throw away all history.

And that would be kind of a bummer.

Instead, you say, after this block, we are only going to accept blocks that are less than half a megabyte.

AUDIENCE: So what happens if after that block, so a majority of miners are running old software.

NEHA NARULA: Great question.

AUDIENCE: [INAUDIBLE] NEHA NARULA: We'll get into that.

We'll get into what happens when the majority, versus minority, of different parts of the ecosystem decide to adopt the change, versus not adopt the change.

But first, we're going to talk about hard forks.

What is a hard fork?

A hard fork is not backwards compatible.

And so a hard fork is a fork where, if this was the old set of rules, under the new set of rules you actually accept more blocks than you would have accepted before. So just to be clear, under the new rules, you might produce a block, which a node running under the old rules will reject.

This is not backwards compatible, because any chain that has this new type of block in it will not be accepted by any of the old nodes, full stop.

It doesn't matter about proof of work at all. OK, so the thing with hard forks is that because they're not backwards compatible, they're a little crazier and a little bit sort of harder to manage in your network.

Because if you do a hard fork and not everyone upgrades, you might end up with two chains, possibly forever. If we assume that those nodes are not going to upgrade-- and let's say they're not upgrading because there's no one really maintaining them.

Then they're not going to upgrade in the future.

And they're not going to upgrade to a change that might fix what's going on here.

They're just going to keep doing their old time thing.

Then with a hard fork, these nodes are never going to accept the new blocks.

It doesn't matter what the proof of work is on that chain.

So hard forks versus soft works-- hard forks, as I keep stressing, are not backwards compatible.

Guess what?

A fork can be a hard fork and a soft work at the same time.

Yay.

Super confusing, actually, because you can both restrict the set of rules and expand the set of rules at the same time.

Basically, it means it's a new, overlapping, but not entirely inclusive or not inclusive, set of rules, very unfortunate.

In fact, most things should actually be both, to avoid some of the things that I'm going to show you in a minute.

Yes?

AUDIENCE: But then for all useful purposes, isn't it just a hard fork, because that means some nodes won't be inside the blocks.

NEHA NARULA: For all useful purposes, it's not just a hard fork.

Let me see if I can-- The reason that it's not just a hard fork-- this is something that requires a little bit more thought.

It's not just a hard fork.

But I will think about how to explain this, and perhaps say something on this.

Or, yeah?

AUDIENCE: [INAUDIBLE] NEHA NARULA: It is.

But he's asking, isn't that just a hard fork?

And it's not just a hard fork, because I think old nodes will do something different.

Ah, OK, so there's two reasons why it's not just a hard fork.

One is because of reorgs.

So different things will happen as the majority of hash power starts to accept or not accept the change, whether or not all nodes will switch over or not.

But if it's both a hard and a soft work, they will never switch over.

But I think the question is whether old nodes can even still function.

So I think one way to use combination hard and soft works is to actually stop the old nodes from being able to have blocks at all.

Like, you design things in such a way, that given a majority of hash power moves over, they're just going to end up with nothing.

But this is a really good question.

And we should go into more detail on this.

And I will try to figure out a way to get that to you guys.

OK, so who controls forks? Yes? Sorry?

AUDIENCE: The developers.

NEHA NARULA: OK, the developers, which I didn't even write down as a note here.

OK, do the Bitcoin developers control forks?

Who thinks yes?

You're not even raising your hand.

Who thinks no? Determines whether or not a fork is going to go through.

There's the Bitcoin developers, who are actually writing the software, and who also have a lot of influence in the system, because presumably they understand it really well if they're writing software.

So they can write some software, and decide that they want to do a fork.

Does that mean that the fork is going to go through?

No, certainly not, everyone can ignore them.

And there have been situations in the past where everyone ignored them for quite a long time, and argued about it, and didn't push a fork through.

Well, miners are the ones who actually create the blocks.

Are they the ones who control forks?

I see a very strong head shake no.

Why do you shake your head?

AUDIENCE: So if the miners decide to change what types of blocks they're putting out, they can do that.

But the nodes that are actually validating it, no one can say they're not going to accept it.

NEHA NARULA: Very true.

So as we saw before, there are times when nodes will not accept a chain no matter how much proof of work it has on it.

I think that's a very common misunderstanding.

The nodes run their own validation rules.

And so if I'm running a node, I can run whatever validation rules I want.

And I can decide what chain is the one that aligns with my interests.

Yes? AUDIENCE: If you're doing a hard fork, and you are accepting new blocks, and they just never mined any blocks with those new rules.

NEHA NARULA: Exactly.

So there's certainly incentives in many different directions.

If all the miners decided to go to one side, then I'm a full node with my side of validation rules who has no new blocks.

Great, what am I going to do?

How am I going to make transactions?

How am I going to spend my money?

Also, let's say all the miners don't go to one side, but most of them do, and most of the nodes go to the other side.

Then what am I going to do?

Who's going to listen to me?

Who's going to trade with me?

Who's going to take the coins on my side of the fork?

So I guess that's just to say that it's complicated.

There's the developers.

There's the miners.

There's nodes.

There's the users who determine the economic value of these tokens, and which side they think is more valuable or less valuable.

And we've seen this happen with lots of cryptocurrencies multiple times.

And it's kind of exciting.

So Bitcoin has forked multiple times.

And every time it's forked so far, it has created a whole new version of the coin.

So it's been like a pretty serious hard fork.

And so now, in addition to Bitcoin, there's Bitcoin Cash, Bitcoin Gold, Bitcoin Diamond.

Ethereum also has fought.

In Ethereum's case, they tried to take along everyone with them.

And so the hard fork was supposed to be an upgrade to Ethereum.

But some people decided they didn't want to go along with it.

So there's Ethereum Classic.

And there's Ethereum. Both of them have value.

So it's really unclear who controls forks.

So now, let's talk about hash rate and forks.

So nodes are pretty-- OK, what nodes will do is they have a set of validation rules.

If a block validates under their set of validation rules, they will accept it.

And if all the blocks validate under their validation rules, they will accept the chain that those blocks are on.

And if there are two different chains where all the blocks validate under their validation rules, they'll take the one with the heaviest proof of work.

That's what nodes do.

So heaviest proof of work is clearly kind of important here, if both sides of a fork validate.

So if both sides of a fork validate-- so we have to think about this from the perspective of nodes who upgrade to the new software, and nodes who don't upgrade to new software.

So it might be worth it to try to kind of write this down a little bit. So we have the old rule nodes, and the new rule nodes. And let's just talk about one kind of work for now.

Now, let's say less than 50% of the miners upgrade. And let's say greater than 50% of the miners upgrade.

OK, so let's use this chart, as we're kind of trying to reason about what's going to happen in the ecosystem for soft works and hard works.

So what happens if a soft fork does not obtain more than 50% of the hash rate? So we've got the old rules. We've got nodes.

Some nodes have upgraded.

Some nodes haven't upgraded.

Less than 50% of the miners have upgraded.

So the old rule chain is going to be longer, because they're going to continue mining on the old rules.

By the way, sometimes they don't ignore things with the new rules.

Sometimes they do.

It's very complicated.

But let's just pretend right now that they are ignoring things with the new rules, because they haven't upgraded, and they don't see that. Or, sorry, they would see the new rules as valid.

But the majority of the hashing power is over here.

So what's going to happen? Yes?

AUDIENCE: The benefits of the fork aren't going to really be useful much, because be there'll be some blocks with the new rules.

But the majority is just not going to change.

NEHA NARULA: Right, so it kind of depends on the soft fork.

So it depends on what the new rule nodes think of old blocks.

If they think that old blocks are still all valid, then they're going to build upon old blocks just fine, because they think they're valid.

If they think that old blocks are no longer valid, then they're going to try to do their own chain. But the majority of the hashing power is with the old side.

So they're just going to get reorged out.

Yes?

AUDIENCE: If it's a soft fork, but they also think all the blocks are valid, how is it a fork at all? NEHA NARULA: So an example of this is taking what was an unused op code, and now making it meaningful.

So it just so happens that none of the old rule nodes ever used this silly unused op code.

Because they never used it, they never had any invalid uses of the op code.

So the new nodes will still accept old blocks, because none of them use this op code anyway.

But if they were to use the new op code, and they used it as a no-op op code, instead of what the new rules are then it would be an invalid block.

Does that make sense? So you have to think really carefully about how you are designing these upgrades to your software.

You have to think very carefully what will happen to the old nodes.

What happens if 50% of the miners take this thing?

Well, under the old rules, was anyone actually using this thing, that we are now maintaining must be used in a new way?

Or pay to script hash is a good example of this as well.

Pay to script hash, technically, looks like you're just paying to a hash.

So old nodes will see it, and say, OK, if you can produce a signature that shows that this is valid, blah, blah, whatever, whatever, that's fine.

But nobody ever did that.

Nobody ever did that in a way that was meaningful under the new rules.

No one ever used it.

So all the old things will still validate, simply because no one ever did anything that was under the subset of the new rules.

Sorry, this is very kind of complicated.

So what we have here is that if old rule blocks are still valid, the software will get reorged out.

So no fork there, no fork there.

You're just not really going to end up with stuff in the blockchain.

If old rule blocks are now invalid, then we're going to end up with two chains.

Do people see why this is?

Because the new rule people are not going to accept any chain that has an invalid thing in it.

So they're not going to reorg out.

They are going to continue.

And they are going to have their own chain.

And they're going to ignore all of the blocks on the other chain, which they deem to be the invalid chain.

Yes?

AUDIENCE: Is this the case for Bitcoin Cash?

NEHA NARULA: No, it's not the case for Bitcoin Cash.

It's actually the case for something called a user-activated soft fork, which the bitcoin community threatened to do when the miners wouldn't do a soft fork they wanted them to do.

They said, fine, you miners won't do the software that we want you to do.

So, normally, people don't like the situation.

So you don't want this to happen.

So, normally, soft forks are written such that if you don't get 95% of the miners to sign, on the soft fork never activates.

So that's the way that, traditionally, soft works are done in the Bitcoin ecosystem.

What does that mean?

It means 5.001% of the hash power can stop a soft fork from going through. So usually, things are written in such a way that you really want to guarantee this two chain thing never happens.

We see hash power is kind of voting.

And if you can get 95% of the hash power to agree with the soft fork, then only will the soft fork activate.

And the way that miners do this is they signal in their block headers that they are going to adopt the soft fork.

And then the software is usually programmed in such a way that it looks at some sliding window of block headers to determine whether 95% of the hash power has decided that they're going to go along with it.

And it only activates once that's the case.

So doing protocol upgrades is really hard.

It's not a trivial matter.

You don't just push some code.

So usually, it's the case that you want to wait for a significant majority of the mining power to indicate support for the soft fork.

And, by the way, they can indicate support without actually running the soft fork.

This happens all the time.

But you want to wait for significant support from the mining community before actually activating the soft fork.

What happened recently with something called Segregated Witness, which we'll talk about, which was a soft fork to Bitcoin to introduce new functionality that the miners opposed, was the community actually said, forget it.

We are going to start running the new rules.

We're going to ignore you.

We don't care what the majority of the hash power does.

We are going to go ahead and create this two chain situation, and follow the chain with the new rules.

Interestingly, this actually worked.

I think it was like 80 plus percent of the hash power was not in favor of the soft fork.

And the users managed to create this kind of detente where they forced everyone to go along with what they wanted, super interesting. They had no actual way to vote.

It was entirely sort of via Twitter.

AUDIENCE: [INAUDIBLE] NEHA NARULA: Yes, so this is one of the major reasons, and I think some of the strongest evidence, that miners have nowhere near as much power as you actually think they do in these ecosystems.

Certainly have power, and part of the power they have is to do what's called an evil soft fork, which I'm not going to talk about in this class, but I think we probably should talk about at some point in time.

OK, great.

Let's see.

OK, if the soft fork is greater than 50%, old rule blocks will follow the new rule blocks automatically.

So we get soft fork successful.

We do not have two chains, because these will simply be orphaned and abandoned.

And, in fact, there's actually pressure for the miners to move over to the new rules so that their blocks aren't abandoned. Yes?

AUDIENCE: So [INAUDIBLE] making it easier mine, are those considered types of forks?

NEHA NARULA: It depends.

So the question is around difficulty, and the number of leading zeros required in the proof of work.

That changes all the time.

There's a formula which determines what that number should be.

So, no, it doesn't require a fork.

But if you want to change the formula, that would be a fork.

Requiring more proof of work would be a soft work.

Requiring less proof of work would be a hard fork. OK, now let's talk about hard forks.

So what happens if a hard fork doesn't obtain 50% of the hash rate? AUDIENCE: [INAUDIBLE] NEHA NARULA: It depends, again.

It depends on if the old rule blocks are still valid.

So we're doing a hard fork.

We're changing the set of valid blocks.

If blocks are still valid under the old rules, then we're going to end up with a situation like this.

If old rule blocks are still valid according to the new rule nodes, then the new rule nodes will just follow along.

OK, so basically no work happening here, because the new rule nodes are going to produce blocks.

They're not going to have enough of the hash power.

And so they're not going to be considered valid by the other set.

So they're going to end up following along with the old rule nodes.

Yes?

AUDIENCE: Again, isn't the whole point of a hard fork that you're expanding the set of things that are valid?

So aren't all old blocks going to be valid in a hard fork?

NEHA NARULA: Not if it's a combination hard fork, soft fork.

So maybe I should split this up into whether or not it's a combination hard fork, soft fork, or not.

OK, so what happens if a hard fork doesn't obtain greater than 50% of the hash rate?

What's going to happen then? AUDIENCE: We'll be mining to the old rules.

NEHA NARULA: Yes, we're going to end up with two chains.

This is going to have chain-- whatever, the point is, there's going to be an old chain and a new chain.

The old nodes are never going to accept the new nodes blocks.

And we're going to end up with two chains forever.

And this has happened multiple times. Are there questions about hard forks? Yes?

AUDIENCE: Are there ways for the hard fork to make life really difficult for the smaller chain?

NEHA NARULA: Are there ways for a hard work to make life really difficult for the smaller chain?

That is a good question.

I think it depends. So there's multiple ways to make life difficult.

I think what you're asking is not, what if the hard fork becomes more popular and more people decide to move over to it, and abandon the smaller chain?

That's one way in which life could be more difficult.

But another way that life could be more difficult is if the hard fork somehow made the previous chain no longer a productive chain to be on.

And I think that the primary way that that would happen would not actually be a hard fork, but would be a combination hard fork, soft fork.

But there are definitely ways for miners to play with hard forks and soft forks in such a way that-- see, this is actually kind of ideal in some ways.

This is like, OK, we disagree on what the rules should be.

I want some new set of rules.

You don't want some new set of rules.

Fine, let's just split the ecosystem.

You guys go your way.

I'll go my way.

We'll have two different coins.

Life will be great.

What's kind of not so nice is when one side tries to coerce the other side to go along, which is kind of what a greater than 50% soft fork is.

You're kind of coercing the other side to go along, because they have no way of opting out.

And there are ways that miners can make the side of the chain with less harsh power basically useless. This is totally something miners can do.

People talk about it occasionally.

It just doesn't seem like they figured out that they can do it, or they haven't tried to do it.

I don't know.

Maybe they don't want to do it.

I'm not sure.

It would be pretty disruptive to the ecosystem. OK, so question-- we've talked about what happens here from the perspective of full nodes, and from the perspective of miners.

What happens from the perspective of people with wallets who might be running SPV? What do we think? Depends on which node they're connected to.

So one problem with SPV is that they don't actually get the blocks.

So they don't actually validate blocks.

All they validate is proof of work.

Some changes that make a block invalid might show up in the header.

But a lot of changes that might make a block invalid, or new blocks valid, don't show up in the header. So given what we've learned about how SPV works, what happens when there's a fork?

So let's go back and take a look at what SPV wallets see.

They see the block headers.

You have to download all the headers, which includes the nines for the proof of work, the Merkle root for the transaction, timestamp, stuff like that.

They also get Merkle paths for the transactions that they've told the node they're interested in. So what would happen if there were a soft work or hard fork?

What would happen to an SPV? They don't really have a say in the situation.

They aren't really participating in validation.

They're not participating in mining.

And they're kind of at the mercy of whatever node that they are talking to.

And, in fact, if they try to talk to multiple nodes, they might get multiple different answers.

And they don't really know which answer is the right answer.

And this could get really tricky and complicated.

Now, I think probably it's fair to say that the majority of the Bitcoin ecosystem, in terms of users, actually does not run their own full nodes.

They interact with the Bitcoin network, at best, through SPV, and at worst through a trusted third party like Coinbase.

So what does the ecosystem have to say or do about whether or not forks are accepted or not accepted? Yeah?

AUDIENCE: They don't really have to.

NEHA NARULA: They don't really have a say.

They kind of I would say at like a meta level, in that users can pressure Coinbase to start following Bitcoin Cash which is a hard fork of bitcoin.

They kind of have a say at an economic level, in that if Coinbase starts accepting Bitcoin Cash, then the price of Bitcoin Cash will go up.

And so that's kind of a big deal.

But in terms of like a protocol level, in terms of accepting or rejecting transactions, they don't really have a say because they can't see enough to determine whether or not they're interested in following a fork or not following a fork.

In fact, it's even worse than that.

There were multiple situations where we ended up with two chains.

So an SPV wallet might think that they received money on one chain, and they didn't receive money on the other chain.

So very bad things can happen to wallets and to SPV clients during a fork.

And it's incredibly disruptive.

And people who create software on the behalf of users-- so not even running SPV, but like the Coinbase's of the world, and the exchanges of the world-- they have to do a fair amount of work to make sure that they aren't going to lose users' money when there's a fork.

And the exchanges, and the Coinbase's of the world, have screwed this up in the past.

There's been money lost.

There are ways to safely design your fork so that it's less likely that wallets will do the wrong thing.

But I think we're kind of just figuring out how to really do that effectively.

AUDIENCE: [INAUDIBLE] NEHA NARULA: Yeah, so this is kind of pretty bad, because if Bitcoin is really going to undergo a hard fork or soft fork, everybody is paying attention.

If Ethereum is going to do it, everyone's paying attention.

But there's so many altcoins out there.

And, yeah, there's so much opportunity for people to take advantage of the disarray that happens when a fork happens.

So I think we're right in the middle of trying to figure out best practices for handling forks safely, and also, giving users some way of choosing what side of a fork that they want, because there's this sort of thought that eventually there will be economic pressure to-- for a long time, people thought that if Bitcoin hard forked, one side would win, and the other side would go to zero.

And now, we've seen that that is absolutely not true.

In fact, when Bitcoin hard forked, sometimes the total market cap of one side plus the other side is bigger than the total market cap of what Bitcoin used to be.

So money is literally created out of nowhere.

So hard forking is very lucrative.

It literally gives every Bitcoin user more money.

So if you own Bitcoin within the past-- like, if you owned Bitcoin a year ago, you probably have like four other coins right now.

I don't know.

You should go sell them, or sell the Bitcoin, and buy the other coins, or whatever you want to do.

But the point is, you have more money than you might have even known that you had, because someone has done these forks.

Don't even like get started about the tax consequences of this.

It's very confusing, extraordinarily confusing.

And people are trying to figure out what to do, because you didn't ask for this fork.

Like, I as a holder of Bitcoin, didn't decide that I wanted Bitcoin Cash to be a thing.

I didn't accept Bitcoin Cash.

But now, the same private keys I used to control my Bitcoin also control the same amount of Bitcoin Cash.

It's kind of crazy.

Let's talk about forks in practice.

So soft forks in practice-- there have been lots of soft forks.

Soft forks are very useful.

Soft forks are helpful.

This is the major way that people upgrade software.

And, again, the way that they do it is they try to make sure 95%, or some huge majority of the miners, are on board.

And that way, it's sort of like as non-disruptive to the ecosystem as possible.

So pay to script has was a soft fork.

The introduction of Segwit was a soft fork.

In operation, check sequence verify was added as a soft fork.

So that's kind of why they're all these like unused ops out there.

In case we want to use one of them for something new, we can do that with a soft fork.

Hard forks in practice-- there's lots of new Bitcoins, Bitcoin Cash, Gold, Diamond, like I said.

Ethereum went through a really interesting hard fork.

And there's some cryptocurrencies that actually hard fork quite frequently.

For instance, I learned the Monero hard forks about every six months.

Vertcoin, how many hard forks have you guys done?

Three?

Three hard forks.

So, despite the way that I said that hard forks are very disruptive, if you can get all the nodes to upgrade, it's not really a big problem.

So for cryptocurrencies where the nodes are really well connected, or they auto update, or things like that, hard forks are much less disruptive.

So let's talk about the Ethereum hard fork for a moment.

So this happened two years ago-- a year ago?

I can't remember when this happened, two years ago, I think, almost.

And so what happened was we haven't talked a lot about Ethereum, so we'll be coming to explain Ethereum in much greater detail.

But the point is Ethereum had a smart contract which had a bug in it. And someone hacked the contract, and started siphoning off ether from the contract.

So the Ethereum team all got together, and decided, we're going to rectify this wrong.

Now, rectifying the wrong-- I mean, I already said it's a hard fork.

But why is rectifying this wrong a hard fork not a soft fork?

AUDIENCE: Because you want to change history.

NEHA NARULA: Because you want to change history.

That's an interesting way of putting it.

And the way that we change history is not by actually going back in time and editing history, unless you are Accenture I guess, which creates editable blockchains.

But the way that we edit history, is we add something to the blockchain which indicates that we're going to undo, or change, or rollback or somehow create an operation, that does something that effectively undoes what happened in the past. So the Ethereum developer got together.

And they originally tried to do this as a soft fork, actually.

So it could have been a soft fork.

And the way that the soft work would have worked is that it just would have ignored all of the transactions that were sort of-- I can't remember exactly how it worked.

But, basically, the general idea was, ignore all of the transactions that might spend the hacker's money.

Ignore the transaction where people gave money to the hacker, what ultimately became the hacker, which is a new rule.

Now, you're shrinking the set of acceptable blocks.

And the problem was they realized that if they did this as a soft fork, then they were inadvertently creating an attack vector, because people could now spam the network and potentially waste the resources of the miners-- very challenging to do soft forks and hard forks correctly.

So they decided, OK, you know what?

We're just going to do it as a hard fork.

When this block comes about, block 1,920,000, we are going to simply transfer around 12 million either from the hacker's account into this other account, this other contract, which is going to give the money back, where people can reclaim their money.

So literally just hardcoded in this transfer.

85% of the hash power in Ethereum went along with it.

So that means 15% didn't.

And that means that there are two currencies now.

There is Ethereum, and Ethereum Classic.

And they persist to this day, almost two years later.

And when I looked this morning, it was about a 30 to 1 ratio between Ethereum and Ethereum Classic.

Yes?

AUDIENCE: So Ethereum Classic says, we are not OK with you guys undoing this hack.

NEHA NARULA: Exactly, so Ethereum Classic says, we're not messing with people's accounts like that.

No, no, no.

What happened happened, fair and square.

We are not changing history.

And so in Ethereum Classic, the hacker has money.

On Ethereum, the hacker does not have money. Yes?

AUDIENCE: [INAUDIBLE] one specific contract.

So the argument is we shouldn't be fixing people's mistakes.

They should learn-- Was this analogous to the Parity?

NEHA NARULA: Yes.

So here they decided, there was a bug in someone's smart contract.

It was exploited.

We're going to give people their money back.

This happened again with a different type of smart contract in a different way a couple months ago.

And they decided-- well, they could still decide to do it.

But so far, they decided not to give everyone's money back.

So there's about 90 million or something dollars worth of ether that's locked up in these contracts, due to a bug.

And in the case of the DAO, they decided, let's do it.

In the case of this Parity bug, they decided, let's not do it.

And if you talk to the Ethereum Foundation people, they'll talk about governance.

And they'll say, well, we feel like this made sense for these reasons.

But this doesn't make sense for these reasons.

But it's still it's a set of people getting together and deciding whether or not to give money back.

Yeah?

AUDIENCE: [INAUDIBLE] NEHA NARULA: No, it's not the Ethereum Foundation.

The Ethereum Foundation was not a fan of Ethereum Classic.

It's a separate group of people.

AUDIENCE: [INAUDIBLE] NEHA NARULA: No, actually, so it turned out, interestingly enough-- and this was something that I saw at a conference that looked into who were the contributors to all of these different forks, when trying to understand governance?

It actually turns out that no one from the Ethereum Foundation works on Ethereum Classic.

And no one who used to work on Bitcoin works on Bitcoin Cash, Gold, or Diamond.

So it's entirely new sets of people.

Yes?

AUDIENCE: The former lead developer of Bitcoin core is working on Bitcoin Cash.

NEHA NARULA: He's not actually.

You're talking about Gavin Andreessen?

Yeah, I don't think he actually makes commits to Bitcoin Cash.

AUDIENCE: In a general sense, he's contributing on GitHub, not specifically to any implementations.

But to protocol, block-level exchanges.

NEHA NARULA: Interesting.

Yes?

AUDIENCE: [INAUDIBLE] NEHA NARULA: It depends on how you define contribute, certainly.

This is a really interesting example of a hard fork.

In summary, just to wrap up here, forks are extremely challenging.

Upgrading software in decentralized cryptocurrencies is extremely challenging.

And so the lesson that I want you to take from this is, unless you need what a decentralized cryptocurrency has to offer, you will probably be better off not using a decentralized cryptocurrency.

They are very hard to update.

They're very hard to upgrade.

There are frequently bugs.

And so I think that forks and the challenges around forks are an excellent reason not to do this when you don't have to.

And also, what's really interesting, I think, is that your traditional consensus systems don't address this problem at all, because your traditional distributed consensus systems don't have any notion of what nodes are going to find valid, or not valid, or changing the rules of validity.

And so these problems really only arise when you start to have these validity rules that you're dealing with, and you have nodes that might take one set of rules, and nodes that might take another set of rules.

The consensus mechanism here ultimately becomes irrelevant if you don't agree with the validity of the blocks.

It doesn't matter that a majority of hash power said that this is the blockchain.

It doesn't matter if a majority of signers say this is the blockchain.

If you don't agree that the things in that blockchain are valid, you're going to ignore that.

Majority be damned.

So it's very different than distributed consensus.

Okay, and so real quick, last thing...

on Wednesday we will have another guest lecturer. Her name is Sharon Goldberg.

She's a professor at Boston University and she's worked on a lot of really interesting things. In particular, something really cool that she's worked on is using the peer-to-peer network to create attacks in Bitcoin, and then very recently she nor co-authors released a paper on peer-to-peer network attacks in Ethereum. And so she's gonna be here to talk about the peer-to-peer networks behind these things and to share some of the research that she's done.