1
00:00:01,140 --> 00:00:03,480
The following content is
provided under a Creative

2
00:00:03,480 --> 00:00:04,870
Commons license.

3
00:00:04,870 --> 00:00:07,080
Your support will help
MIT OpenCourseWare

4
00:00:07,080 --> 00:00:11,170
continue to offer high-quality,
educational resources for free.

5
00:00:11,170 --> 00:00:13,740
To make a donation or to
view additional materials

6
00:00:13,740 --> 00:00:17,700
from hundreds of MIT courses,
visit MIT OpenCourseWare

7
00:00:17,700 --> 00:00:18,580
at ocw.mit.edu.

8
00:00:22,840 --> 00:00:24,820
NEHA NARULA: Welcome back.

9
00:00:24,820 --> 00:00:29,860
Today, we are going
to talk about forks.

10
00:00:29,860 --> 00:00:34,330
So I think you guys have had
a guest lecture last week

11
00:00:34,330 --> 00:00:37,780
from Alin Tomescu, who talked
about his project, Catena.

12
00:00:37,780 --> 00:00:41,590
And one of the really
interesting things about Catena

13
00:00:41,590 --> 00:00:44,470
is that he's trying to prevent
a server from equivocating.

14
00:00:44,470 --> 00:00:46,840
So he's trying to keep
a server from being

15
00:00:46,840 --> 00:00:49,420
able to say one answer to
some people and another answer

16
00:00:49,420 --> 00:00:51,040
to another person.

17
00:00:51,040 --> 00:00:54,760
That's kind of the goal of
this whole blockchain thing.

18
00:00:54,760 --> 00:00:57,970
But there's actually
something really complex

19
00:00:57,970 --> 00:01:01,997
that happens when we
start to change what's

20
00:01:01,997 --> 00:01:03,580
happening in the
network, and we start

21
00:01:03,580 --> 00:01:05,980
to change the software that's
happening in the network.

22
00:01:05,980 --> 00:01:10,240
And so this lecture is
going to be about forks.

23
00:01:10,240 --> 00:01:13,450
And I want you guys to feel
free to raise your hands

24
00:01:13,450 --> 00:01:17,170
and ask questions during class,
because this stuff is actually

25
00:01:17,170 --> 00:01:19,330
kind of non-intuitive sometimes.

26
00:01:19,330 --> 00:01:24,370
So a blockchain is a chain of
blocks which have previous hash

27
00:01:24,370 --> 00:01:25,930
pointers inside of them.

28
00:01:25,930 --> 00:01:30,610
So a question-- can a block
point to two previous blocks

29
00:01:30,610 --> 00:01:33,282
at the same time?

30
00:01:33,282 --> 00:01:34,990
Anybody know the answer
to this question?

31
00:01:34,990 --> 00:01:36,820
No, exactly, that
is the whole point.

32
00:01:36,820 --> 00:01:40,300
There is exactly one
spot in the block header

33
00:01:40,300 --> 00:01:42,580
for a previous hash block.

34
00:01:42,580 --> 00:01:46,450
And so a block can only
point to one previous block.

35
00:01:46,450 --> 00:01:50,360
A single block cannot point
to two previous blocks.

36
00:01:50,360 --> 00:01:52,030
However, can this happen?

37
00:01:52,030 --> 00:01:55,360
Can two different blocks point
to the same previous block

38
00:01:55,360 --> 00:01:56,270
header?

39
00:01:56,270 --> 00:01:59,979
Yes, yes, and this
happens all the time.

40
00:01:59,979 --> 00:02:03,310
Now, part of the reason that
this happens all the time

41
00:02:03,310 --> 00:02:05,830
is because the way
that blocks are

42
00:02:05,830 --> 00:02:09,759
found in the bitcoin network
is completely probabilistic.

43
00:02:09,759 --> 00:02:11,470
There are many
people who are trying

44
00:02:11,470 --> 00:02:13,930
to find the next block
at the same time.

45
00:02:13,930 --> 00:02:16,930
And it's entirely possible
that two different miners

46
00:02:16,930 --> 00:02:20,140
will get lucky in
a time period that

47
00:02:20,140 --> 00:02:22,720
is within the time it takes
for a block to get gossipped

48
00:02:22,720 --> 00:02:23,770
around the network.

49
00:02:23,770 --> 00:02:26,380
And so, totally, two people
can find the same block

50
00:02:26,380 --> 00:02:27,370
at the same time.

51
00:02:27,370 --> 00:02:30,820
This is actually
what's known as a fork.

52
00:02:30,820 --> 00:02:31,990
And you can kind of see why.

53
00:02:31,990 --> 00:02:35,460
We have a fork in
the chain right here.

54
00:02:35,460 --> 00:02:37,990
But what does it
really mean when

55
00:02:37,990 --> 00:02:39,370
there's a fork in the chain?

56
00:02:39,370 --> 00:02:41,620
I just told you that
this is something

57
00:02:41,620 --> 00:02:43,300
that happens all the time.

58
00:02:43,300 --> 00:02:46,480
And these cryptocurrency
networks seem to keep running.

59
00:02:46,480 --> 00:02:48,130
They seem to be keep going.

60
00:02:48,130 --> 00:02:51,820
So perhaps it's not
as bad as it seems,

61
00:02:51,820 --> 00:02:53,320
even though it seems
to be violating

62
00:02:53,320 --> 00:02:57,250
one of the major tenets
of what a blockchain is.

63
00:02:57,250 --> 00:02:59,050
Well, it is kind
of bad, actually,

64
00:02:59,050 --> 00:03:02,650
because when you have
these two blocks here,

65
00:03:02,650 --> 00:03:06,040
is there anything that makes
one the right blockchain

66
00:03:06,040 --> 00:03:07,240
over the other blockchain?

67
00:03:07,240 --> 00:03:10,030
Just if this is one
blockchain right here,

68
00:03:10,030 --> 00:03:12,910
and this is another
blockchain right there,

69
00:03:12,910 --> 00:03:14,930
how is one supposed to
distinguish between this?

70
00:03:14,930 --> 00:03:15,430
Yeah?

71
00:03:15,430 --> 00:03:16,690
AUDIENCE: The one
with the most work.

72
00:03:16,690 --> 00:03:18,357
NEHA NARULA: The one
with the most work,

73
00:03:18,357 --> 00:03:22,215
OK, that's a great sort of
way of thinking about it.

74
00:03:22,215 --> 00:03:24,340
What if they have similar
amounts of proof of work.

75
00:03:24,340 --> 00:03:24,690
Then what?

76
00:03:24,690 --> 00:03:26,200
AUDIENCE: The one
that's accepted

77
00:03:26,200 --> 00:03:26,990
by the majority of the network.

78
00:03:26,990 --> 00:03:28,300
NEHA NARULA: The
one that's accepted

79
00:03:28,300 --> 00:03:29,050
by the majority of the network.

80
00:03:29,050 --> 00:03:30,640
How do we know which
one is accepted

81
00:03:30,640 --> 00:03:33,380
by the majority of the network?

82
00:03:33,380 --> 00:03:35,710
It gets extended, OK, great.

83
00:03:35,710 --> 00:03:39,910
So that's a really good
way of looking at it.

84
00:03:39,910 --> 00:03:43,090
Before we go into
what that means,

85
00:03:43,090 --> 00:03:46,390
do people understand why if
this state were to persist

86
00:03:46,390 --> 00:03:49,130
it would be a really
bad situation?

87
00:03:49,130 --> 00:03:50,792
One thing that we
could have, given

88
00:03:50,792 --> 00:03:52,750
that there's two blocks,
what that really means

89
00:03:52,750 --> 00:03:54,970
is that we have two
versions of history.

90
00:03:54,970 --> 00:03:56,530
We have two versions
of the ledger

91
00:03:56,530 --> 00:03:58,270
if these two things
are not the same.

92
00:03:58,270 --> 00:04:01,810
Different coins might be
spent on one side of the fork,

93
00:04:01,810 --> 00:04:04,270
versus on the other
side of the fork.

94
00:04:04,270 --> 00:04:08,260
In fact, the same coin might be
spent in two different people

95
00:04:08,260 --> 00:04:10,600
on either sides of these forks.

96
00:04:10,600 --> 00:04:13,810
And so over here, Alice might
be spending her coin to Bob.

97
00:04:13,810 --> 00:04:16,269
Over here, Alex might be
spending that same coin--

98
00:04:16,269 --> 00:04:19,143
and, remember, coins
can only be spent once.

99
00:04:19,143 --> 00:04:20,560
Even if Alice has
other coins, she

100
00:04:20,560 --> 00:04:22,610
specifies which
coin she's spending.

101
00:04:22,610 --> 00:04:25,410
Alice might spend that
coin over to Carol.

102
00:04:25,410 --> 00:04:27,790
And so if Bob sees this,
he thinks he got paid.

103
00:04:27,790 --> 00:04:30,520
If Carol sees this, she
thinks she got paid.

104
00:04:30,520 --> 00:04:33,790
And we violated one of
the fundamental tenets

105
00:04:33,790 --> 00:04:36,317
of the blockchain, which is
not to double spend coins.

106
00:04:36,317 --> 00:04:37,900
You can't create
money out of nowhere.

107
00:04:40,770 --> 00:04:43,980
If these two things
would persist,

108
00:04:43,980 --> 00:04:47,130
if we don't resolve
this fork somehow,

109
00:04:47,130 --> 00:04:50,190
then we literally have
two different versions

110
00:04:50,190 --> 00:04:53,890
of the same currency.

111
00:04:53,890 --> 00:04:56,350
This is kind of as
though I took the money

112
00:04:56,350 --> 00:05:00,820
in my pocket, my dollar
bill, and I xeroxed them all,

113
00:05:00,820 --> 00:05:04,150
and managed to convince some
people that the Xerox was also

114
00:05:04,150 --> 00:05:05,740
real.

115
00:05:05,740 --> 00:05:07,570
This is the exact
same thing as what's

116
00:05:07,570 --> 00:05:12,740
happening when you have
these two things persist.

117
00:05:12,740 --> 00:05:15,060
OK, so how do we fix it?

118
00:05:15,060 --> 00:05:19,800
Well, which is the right one?

119
00:05:19,800 --> 00:05:22,170
And just given what I've
shown you right here,

120
00:05:22,170 --> 00:05:24,300
it is not clear which
is the right one.

121
00:05:24,300 --> 00:05:26,957
And like I also said,
this happens all the time

122
00:05:26,957 --> 00:05:29,040
in the bitcoin network
because the bitcoin network

123
00:05:29,040 --> 00:05:30,740
is probabilistic.

124
00:05:30,740 --> 00:05:34,680
So the way that people figure
out which one is the right one

125
00:05:34,680 --> 00:05:36,250
is they wait.

126
00:05:36,250 --> 00:05:39,760
They wait and see which
side gets extended.

127
00:05:39,760 --> 00:05:42,180
And by the nature
of probability,

128
00:05:42,180 --> 00:05:45,360
one side is going to eventually
win out, and get extended

129
00:05:45,360 --> 00:05:46,890
more often than the other side.

130
00:05:46,890 --> 00:05:51,090
It's very unlikely for
two forks to randomly sort

131
00:05:51,090 --> 00:05:54,120
of probabilistically exist
at roughly the same way

132
00:05:54,120 --> 00:05:57,220
for the same amount
of time for very long.

133
00:05:57,220 --> 00:05:59,970
Now, as someone said,
you might look at this.

134
00:05:59,970 --> 00:06:02,940
How do you distinguish
between these two things?

135
00:06:02,940 --> 00:06:05,820
There is this common idea
that in blockchains we

136
00:06:05,820 --> 00:06:07,710
take the longest chain.

137
00:06:07,710 --> 00:06:10,530
Longest is a little bit
misleading actually.

138
00:06:10,530 --> 00:06:12,300
It's not the longest chain.

139
00:06:12,300 --> 00:06:15,030
It's the heaviest work chain.

140
00:06:15,030 --> 00:06:18,870
So we pick the chain that
has the most proof of work

141
00:06:18,870 --> 00:06:21,450
on it, even if that
happens to have

142
00:06:21,450 --> 00:06:22,830
a smaller number of blocks.

143
00:06:22,830 --> 00:06:24,010
Usually that's not the case.

144
00:06:24,010 --> 00:06:25,475
That's not what happens.

145
00:06:25,475 --> 00:06:26,850
The reason for
that-- does anyone

146
00:06:26,850 --> 00:06:29,250
know why we take the heaviest
chain instead of the longest

147
00:06:29,250 --> 00:06:29,750
chain?

148
00:06:32,960 --> 00:06:35,370
AUDIENCE: So that nobody
can cheat and lower

149
00:06:35,370 --> 00:06:37,602
the level of difficulty.

150
00:06:37,602 --> 00:06:39,810
NEHA NARULA: Right, so it's
not very easy to do this.

151
00:06:39,810 --> 00:06:41,550
But over time,
someone could slowly

152
00:06:41,550 --> 00:06:43,800
decrease difficulty
level, and then

153
00:06:43,800 --> 00:06:47,430
create a nice, really long
chain with many low difficulty

154
00:06:47,430 --> 00:06:50,820
blocks, and then say, hey,
I've got the longest chain.

155
00:06:50,820 --> 00:06:52,290
I have the most
number of blocks.

156
00:06:52,290 --> 00:06:54,990
Despite the fact that your chain
has more proof of work on it,

157
00:06:54,990 --> 00:06:56,250
you should all take my chain.

158
00:06:56,250 --> 00:06:59,400
And they could do that
with less than a majority

159
00:06:59,400 --> 00:07:01,142
of the hash power.

160
00:07:01,142 --> 00:07:02,600
Now, this is not
easy attack to do.

161
00:07:02,600 --> 00:07:03,767
But it is a possible attack.

162
00:07:03,767 --> 00:07:06,380
And so that's why we take
the heaviest chain, which

163
00:07:06,380 --> 00:07:11,210
represents the most hash power
in the system, the majority

164
00:07:11,210 --> 00:07:12,500
of the system.

165
00:07:12,500 --> 00:07:16,580
So forks happen all the time.

166
00:07:16,580 --> 00:07:19,440
Forks are normal.

167
00:07:19,440 --> 00:07:23,240
The way that people
who see forks decide

168
00:07:23,240 --> 00:07:25,940
which side of the
fork to use, is they

169
00:07:25,940 --> 00:07:29,060
check and see which one
has the most proof of work,

170
00:07:29,060 --> 00:07:30,740
the heaviest proof of work.

171
00:07:30,740 --> 00:07:32,780
Now, one thing
that's kind of cool,

172
00:07:32,780 --> 00:07:36,440
is, as you probably learned
about two classes ago,

173
00:07:36,440 --> 00:07:40,130
even SPV nodes,
even clients, can

174
00:07:40,130 --> 00:07:42,770
tell which chain has
the most proof of work

175
00:07:42,770 --> 00:07:46,159
simply by looking at the
headers, the block headers.

176
00:07:46,159 --> 00:07:47,690
They can see what
the difficulty is.

177
00:07:47,690 --> 00:07:48,890
And they can measure
for themselves

178
00:07:48,890 --> 00:07:51,015
which side of the chain
has the most proof of work.

179
00:07:51,015 --> 00:07:52,980
They don't even need
all of the chain.

180
00:07:52,980 --> 00:07:55,159
So this is a nice
property of light clients,

181
00:07:55,159 --> 00:07:57,740
is that they can download
all of the block headers

182
00:07:57,740 --> 00:08:00,230
and immediately tell
which side of a fork

183
00:08:00,230 --> 00:08:03,440
has the most proof of work.

184
00:08:03,440 --> 00:08:08,068
Great, we call the block
that ends up-- so what

185
00:08:08,068 --> 00:08:09,110
do we do with this block?

186
00:08:09,110 --> 00:08:13,330
Does anyone know what actually
happens with this block?

187
00:08:13,330 --> 00:08:15,940
Anybody?

188
00:08:15,940 --> 00:08:19,790
OK, so this book is
basically abandoned.

189
00:08:19,790 --> 00:08:21,980
This block is just left.

190
00:08:21,980 --> 00:08:23,150
It exists.

191
00:08:23,150 --> 00:08:24,740
It points into the chain.

192
00:08:24,740 --> 00:08:25,780
That's great.

193
00:08:25,780 --> 00:08:27,870
In bitcoin, in particular,
it's meaningless.

194
00:08:27,870 --> 00:08:29,450
It doesn't mean anything.

195
00:08:29,450 --> 00:08:32,870
Every transaction
that was in that block

196
00:08:32,870 --> 00:08:35,159
is not considered
to have happened.

197
00:08:35,159 --> 00:08:37,789
So those transactions
need to be replayed

198
00:08:37,789 --> 00:08:41,270
on the chain that ends up
being the longest chain.

199
00:08:41,270 --> 00:08:44,940
And this happens, like
I said, all the time.

200
00:08:44,940 --> 00:08:48,500
We call that block an orphan,
because it doesn't have anyone.

201
00:08:48,500 --> 00:08:50,060
It's kind of the
wrong way around.

202
00:08:50,060 --> 00:08:51,620
I mean, I think of
this as a child.

203
00:08:51,620 --> 00:08:53,980
But, whatever, this block
doesn't have a parent.

204
00:08:53,980 --> 00:08:56,030
But we call those
blocks orphans.

205
00:08:56,030 --> 00:08:58,730
And, again, remember,
we pick the side

206
00:08:58,730 --> 00:09:03,070
of the chain that ends up
having the most proof of work.

207
00:09:03,070 --> 00:09:07,403
Now, we draw these figures
in two different ways.

208
00:09:07,403 --> 00:09:09,070
Sometimes we draw the
figures like this,

209
00:09:09,070 --> 00:09:11,800
like there's this blockchain
that exists out there,

210
00:09:11,800 --> 00:09:15,790
that is written down, and that
everyone is sort of looking at.

211
00:09:15,790 --> 00:09:17,200
There's one blockchain.

212
00:09:17,200 --> 00:09:20,170
But this isn't a
logical representation.

213
00:09:20,170 --> 00:09:23,530
In reality, there are many,
many, many, many different

214
00:09:23,530 --> 00:09:24,160
blockchains.

215
00:09:24,160 --> 00:09:26,380
In fact, every
node in the system

216
00:09:26,380 --> 00:09:28,750
has its own version
of the blockchain.

217
00:09:28,750 --> 00:09:31,540
And it's what those
nodes are doing together

218
00:09:31,540 --> 00:09:34,610
that ends up deciding what
the blockchain actually is.

219
00:09:34,610 --> 00:09:39,130
So if these are nodes that are
running the bitcoin protocol,

220
00:09:39,130 --> 00:09:42,590
and when I say nodes,
what's the difference

221
00:09:42,590 --> 00:09:43,880
between a miner and a node?

222
00:09:49,640 --> 00:09:51,410
AUDIENCE: Nodes
verify transactions,

223
00:09:51,410 --> 00:09:55,320
but miners push blocks.

224
00:09:55,320 --> 00:09:57,540
NEHA NARULA: Exactly,
so miners actually

225
00:09:57,540 --> 00:09:59,640
create blocks in the system.

226
00:09:59,640 --> 00:10:02,880
Miners have write access
to the blockchain.

227
00:10:02,880 --> 00:10:06,420
They actually
produce new blocks.

228
00:10:06,420 --> 00:10:08,940
People think a lot about
what the miners are,

229
00:10:08,940 --> 00:10:10,150
and what the miners can do.

230
00:10:10,150 --> 00:10:12,120
And there's a lot of game theory
thinking about the miners.

231
00:10:12,120 --> 00:10:15,000
And, oh, what if they collude,
but the hash power does this?

232
00:10:15,000 --> 00:10:17,527
And sometimes we forget that
nodes in the bitcoin network

233
00:10:17,527 --> 00:10:19,110
are actually incredibly
important too,

234
00:10:19,110 --> 00:10:21,082
because it's the nodes
in the bitcoin network

235
00:10:21,082 --> 00:10:22,290
that are now creating blocks.

236
00:10:22,290 --> 00:10:24,040
And, to be clear,
someone could be a miner

237
00:10:24,040 --> 00:10:25,890
and a node at the same time.

238
00:10:25,890 --> 00:10:27,360
They're distinct roles.

239
00:10:27,360 --> 00:10:31,353
The same entity could certainly
run a node and be a miner.

240
00:10:31,353 --> 00:10:33,270
But nodes are doing
something really important

241
00:10:33,270 --> 00:10:35,850
as well, which is they're
reading all of the blocks.

242
00:10:35,850 --> 00:10:39,570
And they're deciding which
side of a fork to take,

243
00:10:39,570 --> 00:10:43,320
and which blocks to accept and
which blocks not to accept.

244
00:10:43,320 --> 00:10:46,770
So let's say that these
are all bitcoin nodes.

245
00:10:46,770 --> 00:10:49,860
And this is what the blockchain
looks like right now.

246
00:10:49,860 --> 00:10:53,670
And we've used this
figure multiple times.

247
00:10:53,670 --> 00:10:58,230
Every block has a previous
hash, which acts as a pointer

248
00:10:58,230 --> 00:11:01,050
to the previous block.

249
00:11:01,050 --> 00:11:03,390
Every block has a
set of transactions.

250
00:11:03,390 --> 00:11:06,180
And every block
has a nonce, such

251
00:11:06,180 --> 00:11:09,660
that when you take the
hash of the block header,

252
00:11:09,660 --> 00:11:12,450
you end up with something
that has a sufficient number

253
00:11:12,450 --> 00:11:13,290
of leading zeros.

254
00:11:13,290 --> 00:11:14,700
It has valid proof of work.

255
00:11:17,710 --> 00:11:21,270
So let's say that this is the
state of the system right now.

256
00:11:21,270 --> 00:11:25,890
And then, we see this
new block come along.

257
00:11:25,890 --> 00:11:29,700
So what happens here is that a
miner has produced this block,

258
00:11:29,700 --> 00:11:32,890
and has sent it out over
the bitcoin network.

259
00:11:32,890 --> 00:11:35,160
They've started gossiping
the block around the bitcoin

260
00:11:35,160 --> 00:11:35,820
network.

261
00:11:35,820 --> 00:11:38,910
And so every one of these nodes,
hopefully, will eventually,

262
00:11:38,910 --> 00:11:41,180
if they're well connected,
will see this block.

263
00:11:41,180 --> 00:11:43,890
They're going to see the
block at different times.

264
00:11:43,890 --> 00:11:48,000
And they're each going to
make an independent decision

265
00:11:48,000 --> 00:11:50,130
about the block.

266
00:11:50,130 --> 00:11:53,190
So every node is going
to decide when it sees

267
00:11:53,190 --> 00:11:56,460
this block what to do with it.

268
00:11:56,460 --> 00:11:59,110
And there's basically two
things it can do with it.

269
00:11:59,110 --> 00:12:03,360
One, it can add it to
its own local version

270
00:12:03,360 --> 00:12:05,250
of the blockchain.

271
00:12:05,250 --> 00:12:09,750
And number two,
it can reject it.

272
00:12:09,750 --> 00:12:13,110
Does everyone see why that is?

273
00:12:13,110 --> 00:12:16,890
So sure, every node is
maintaining this local copy

274
00:12:16,890 --> 00:12:17,610
of a blockchain.

275
00:12:17,610 --> 00:12:21,000
There is no single,
global copy that everyone

276
00:12:21,000 --> 00:12:22,290
is referring to physically.

277
00:12:22,290 --> 00:12:24,420
There's no single database
running the blockchain.

278
00:12:24,420 --> 00:12:27,030
Every node has its own local
copy of the blockchain.

279
00:12:27,030 --> 00:12:31,200
Every node is making its
own local decisions about

280
00:12:31,200 --> 00:12:34,020
whether or not a block is
valid, and about whether or not

281
00:12:34,020 --> 00:12:37,380
it's going to add that
block to its own local copy

282
00:12:37,380 --> 00:12:38,590
of its blockchain.

283
00:12:41,350 --> 00:12:44,170
So the way that the
node decides this

284
00:12:44,170 --> 00:12:48,670
is that it has a set
of validation rules.

285
00:12:48,670 --> 00:12:52,300
So it has its own set of
rules, which are specified

286
00:12:52,300 --> 00:12:55,300
by the bitcoin protocol.

287
00:12:55,300 --> 00:13:00,670
And it checks that block against
its set of validation rules.

288
00:13:00,670 --> 00:13:02,620
So every node,
every bitcoin node,

289
00:13:02,620 --> 00:13:05,860
is constantly validating,
constantly validating blocks.

290
00:13:05,860 --> 00:13:08,400
Here are just some of
the validation rules.

291
00:13:08,400 --> 00:13:11,170
And we've talked about a lot
of these sort of off and on

292
00:13:11,170 --> 00:13:12,500
during the class.

293
00:13:12,500 --> 00:13:15,610
So first of all, there's
a max block size.

294
00:13:15,610 --> 00:13:18,610
And the way that this
works is if at any point

295
00:13:18,610 --> 00:13:23,140
you fail one of these validation
rules, you reject the block.

296
00:13:23,140 --> 00:13:26,740
So first, the block has to be
smaller than this variable max

297
00:13:26,740 --> 00:13:27,880
block size.

298
00:13:27,880 --> 00:13:32,080
At the moment, max block
size is set to 1 megabyte.

299
00:13:32,080 --> 00:13:36,250
Every single transaction in
the block also has to be valid.

300
00:13:36,250 --> 00:13:37,855
And what does that mean?

301
00:13:37,855 --> 00:13:39,730
Well, it needs to be
formatted a certain way.

302
00:13:39,730 --> 00:13:43,870
And it also means that when
we concatenate the script pub

303
00:13:43,870 --> 00:13:46,630
key and the script sig
together, and then run that

304
00:13:46,630 --> 00:13:50,170
through the
interpreter to evaluate

305
00:13:50,170 --> 00:13:55,780
the script on the stack,
it ends up returning true.

306
00:13:55,780 --> 00:13:58,630
And if at any point, any
transaction-- and not just

307
00:13:58,630 --> 00:14:00,670
any transaction, any
input in any transaction,

308
00:14:00,670 --> 00:14:03,400
does not satisfy this, we
reject the entire block.

309
00:14:06,460 --> 00:14:08,410
Another thing that
each transaction

310
00:14:08,410 --> 00:14:13,390
needs to satisfy if it's valid,
is if the transaction specifies

311
00:14:13,390 --> 00:14:15,300
an end lock time,
than that end lock

312
00:14:15,300 --> 00:14:17,920
time needs to be greater
than whatever is specified

313
00:14:17,920 --> 00:14:19,000
in the transaction.

314
00:14:19,000 --> 00:14:22,900
That transaction is now is
now far enough in the future

315
00:14:22,900 --> 00:14:25,750
that it can be satisfied.

316
00:14:25,750 --> 00:14:29,200
The block as a whole needs
to have valid proof of work.

317
00:14:29,200 --> 00:14:30,580
So it needs to
have a nonce, such

318
00:14:30,580 --> 00:14:32,890
that when you hash
the block header,

319
00:14:32,890 --> 00:14:35,830
you end up with a hash that
has a certain number of leading

320
00:14:35,830 --> 00:14:36,940
zeros.

321
00:14:36,940 --> 00:14:40,930
And what's really interesting
is the protocol also

322
00:14:40,930 --> 00:14:45,190
specifies exactly how many
leading zeros there need to be,

323
00:14:45,190 --> 00:14:48,020
depending upon how many
leading zeros there have

324
00:14:48,020 --> 00:14:49,145
been in blocks in the past.

325
00:14:51,940 --> 00:14:53,560
There cannot be
any double spends.

326
00:14:53,560 --> 00:14:56,770
So given the version of the
blockchain that I, as a node,

327
00:14:56,770 --> 00:15:02,070
have, this better not be
double spending any outputs.

328
00:15:02,070 --> 00:15:04,060
There are some rules
around what the block

329
00:15:04,060 --> 00:15:06,070
can have as its timestamp.

330
00:15:06,070 --> 00:15:07,870
It cannot be more than--

331
00:15:07,870 --> 00:15:10,210
if I see a block that
has a timestamp that's

332
00:15:10,210 --> 00:15:12,820
more than two hours in the
future from my own timestamp,

333
00:15:12,820 --> 00:15:14,330
I will reject it.

334
00:15:14,330 --> 00:15:18,730
And if it isn't after
some point that's

335
00:15:18,730 --> 00:15:20,950
the median of the previous
block's timestamps,

336
00:15:20,950 --> 00:15:24,270
then I'll also reject it.

337
00:15:24,270 --> 00:15:28,980
And, of course, the block needs
to actually point to a block

338
00:15:28,980 --> 00:15:30,510
that I've seen before.

339
00:15:30,510 --> 00:15:32,280
And as a node, I
will keep around

340
00:15:32,280 --> 00:15:35,610
blocks which have a
previous hash pointer that I

341
00:15:35,610 --> 00:15:37,180
don't know about.

342
00:15:37,180 --> 00:15:39,690
But I'm not going to
keep them around forever,

343
00:15:39,690 --> 00:15:41,700
because that's a
potential Dos attack.

344
00:15:41,700 --> 00:15:45,690
And in order for me to
actually insert this block

345
00:15:45,690 --> 00:15:47,910
into my version
of a blockchain, I

346
00:15:47,910 --> 00:15:52,140
need to know which
block to put it after.

347
00:15:52,140 --> 00:15:55,260
Note also, note
what's not on here

348
00:15:55,260 --> 00:15:59,070
is that it needs to be
the only block pointing

349
00:15:59,070 --> 00:16:00,180
to a previous block.

350
00:16:00,180 --> 00:16:03,330
I'll keep around multiple
blocks at the same level

351
00:16:03,330 --> 00:16:06,390
until I have some sense of
which one is going to win out,

352
00:16:06,390 --> 00:16:07,920
because of the
probabilistic nature

353
00:16:07,920 --> 00:16:10,552
of maybe this block I'm
seeing is not going to end up

354
00:16:10,552 --> 00:16:11,760
being part of the blockchain.

355
00:16:11,760 --> 00:16:13,135
Maybe it's going
to be an orphan.

356
00:16:16,480 --> 00:16:21,810
So these validation
rules are what

357
00:16:21,810 --> 00:16:25,860
are called consensus critical
rules in the bitcoin network.

358
00:16:25,860 --> 00:16:30,000
And what that means is that if
you want to tweak these rules,

359
00:16:30,000 --> 00:16:32,430
if you want to
change them, then you

360
00:16:32,430 --> 00:16:36,450
may end up changing which
blocks nodes will accept,

361
00:16:36,450 --> 00:16:39,640
and which blocks
nodes won't accept.

362
00:16:39,640 --> 00:16:43,120
Now, something that's kind
of interesting to note here

363
00:16:43,120 --> 00:16:46,510
is that the entire script
interpreter in bitcoin

364
00:16:46,510 --> 00:16:48,680
is consensus critical.

365
00:16:48,680 --> 00:16:49,935
Yes?

366
00:16:49,935 --> 00:16:52,060
AUDIENCE: If you reduce
the amount of transactions,

367
00:16:52,060 --> 00:16:55,060
does that reduce the size
of the blocks as well?

368
00:16:55,060 --> 00:16:56,230
NEHA NARULA: Yes, it can.

369
00:16:56,230 --> 00:16:58,840
Yes, so you can
definitely have a block--

370
00:16:58,840 --> 00:17:00,650
so that's a great
question actually.

371
00:17:00,650 --> 00:17:04,030
So let's say that we had a
block that was half a megabyte.

372
00:17:04,030 --> 00:17:07,400
What would nodes do?

373
00:17:07,400 --> 00:17:09,500
What do you think?

374
00:17:09,500 --> 00:17:11,810
AUDIENCE: I think an
advantageous miner would

375
00:17:11,810 --> 00:17:14,307
potentially process it faster.

376
00:17:14,307 --> 00:17:15,348
NEHA NARULA: That's true.

377
00:17:17,983 --> 00:17:19,150
What would you as a node do.

378
00:17:19,150 --> 00:17:21,646
If you're running the bitcoin
protocol as it exists today,

379
00:17:21,646 --> 00:17:23,230
and it has the
following set of rules,

380
00:17:23,230 --> 00:17:25,420
and I hand you a block
that's half a megabyte,

381
00:17:25,420 --> 00:17:27,710
what would you do?

382
00:17:27,710 --> 00:17:29,950
You would say OK, exactly,
because the rule that I

383
00:17:29,950 --> 00:17:32,410
specified here just
says the block has

384
00:17:32,410 --> 00:17:34,150
to be less than 1 megabyte.

385
00:17:34,150 --> 00:17:36,730
It didn't say it has to
be greater than anything.

386
00:17:36,730 --> 00:17:39,580
And is half a megabyte
less than 1 megabyte?

387
00:17:39,580 --> 00:17:42,100
Yes, so you're going
to pass the checks.

388
00:17:42,100 --> 00:17:43,750
And you're going to
accept the block.

389
00:17:46,770 --> 00:17:49,890
AUDIENCE: Is that a good
thing for miners, so

390
00:17:49,890 --> 00:17:52,690
maybe remove the transactions
from a potential block,

391
00:17:52,690 --> 00:17:54,830
because they want to
process it faster?

392
00:17:54,830 --> 00:17:57,460
NEHA NARULA: Sure, so the
question is, should miners

393
00:17:57,460 --> 00:17:59,500
remove transactions
from a block,

394
00:17:59,500 --> 00:18:01,840
or perhaps not put
transactions in a block,

395
00:18:01,840 --> 00:18:04,570
because it seems like they could
process a small block faster

396
00:18:04,570 --> 00:18:06,730
than a large block, right?

397
00:18:06,730 --> 00:18:09,070
So that is very true.

398
00:18:09,070 --> 00:18:11,650
Miners, if there are
fewer transactions,

399
00:18:11,650 --> 00:18:13,030
they have fewer
things to verify.

400
00:18:13,030 --> 00:18:15,860
So they can check and see
if the book is valid faster.

401
00:18:15,860 --> 00:18:20,140
However, the fewer transactions,
the fewer the transaction fees.

402
00:18:20,140 --> 00:18:22,510
And so the less the miner
will earn from the block.

403
00:18:25,460 --> 00:18:26,370
Yes?

404
00:18:26,370 --> 00:18:31,250
AUDIENCE: And also, the energy
put in, most of it mining,

405
00:18:31,250 --> 00:18:33,390
is like mining the block,
not actually verifying.

406
00:18:33,390 --> 00:18:34,140
NEHA NARULA: Yeah.

407
00:18:36,080 --> 00:18:42,410
So verifying transactions is
nowhere near as CPU-intensive

408
00:18:42,410 --> 00:18:45,960
as it is to actually
find the nonce

409
00:18:45,960 --> 00:18:47,210
and produce the proof of work.

410
00:18:47,210 --> 00:18:51,800
However, miners should
verify transactions

411
00:18:51,800 --> 00:18:54,180
before even starting
that process.

412
00:18:54,180 --> 00:18:57,050
And so if a miner didn't
verify transactions,

413
00:18:57,050 --> 00:19:01,150
they would get a head start
on the proof of work process.

414
00:19:01,150 --> 00:19:02,600
So there's that sort of balance.

415
00:19:02,600 --> 00:19:06,140
And, in fact, I think we've
talked about this in this class

416
00:19:06,140 --> 00:19:07,940
before, there have
been times in history

417
00:19:07,940 --> 00:19:10,010
where things have happened that
have shown that miners actually

418
00:19:10,010 --> 00:19:11,590
haven't been verifying blocks.

419
00:19:11,590 --> 00:19:13,350
They'll just mine on whatever.

420
00:19:13,350 --> 00:19:14,630
It's caused some problems.

421
00:19:14,630 --> 00:19:16,370
And they ended up
losing a lot of money

422
00:19:16,370 --> 00:19:20,120
because they should have
been verifying blocks.

423
00:19:20,120 --> 00:19:21,230
Great.

424
00:19:21,230 --> 00:19:23,780
So these rules are what are
called consensus critical.

425
00:19:23,780 --> 00:19:26,240
They are the rules that
each node independently

426
00:19:26,240 --> 00:19:29,000
uses to decide
whether or not they're

427
00:19:29,000 --> 00:19:31,570
going to accept the block.

428
00:19:31,570 --> 00:19:32,490
Yes?

429
00:19:32,490 --> 00:19:33,990
AUDIENCE: When you
talk about nodes,

430
00:19:33,990 --> 00:19:36,633
you talk about SPDs, right?

431
00:19:36,633 --> 00:19:37,300
NEHA NARULA: No.

432
00:19:37,300 --> 00:19:40,390
I'm not talking about SPDs
when I talk about nodes.

433
00:19:40,390 --> 00:19:42,940
I'm actually talking
about full nodes.

434
00:19:42,940 --> 00:19:47,160
So I'm talking about
nodes that are holding

435
00:19:47,160 --> 00:19:49,440
onto the entire bitcoin
blockchain, that

436
00:19:49,440 --> 00:19:52,958
are looking at every
block, every transaction.

437
00:19:52,958 --> 00:19:54,750
AUDIENCE: So the
difference between a miner

438
00:19:54,750 --> 00:19:58,873
and and a node are [INAUDIBLE]?

439
00:19:58,873 --> 00:19:59,790
NEHA NARULA: A miner--

440
00:19:59,790 --> 00:20:01,230
yeah, they're distinct roles.

441
00:20:01,230 --> 00:20:05,220
So a miner is running this
proof of work algorithm

442
00:20:05,220 --> 00:20:06,620
to try to find--

443
00:20:06,620 --> 00:20:08,670
to produce blocks.

444
00:20:08,670 --> 00:20:10,680
A full node does
not write blocks.

445
00:20:10,680 --> 00:20:12,060
It doesn't create new blocks.

446
00:20:12,060 --> 00:20:15,390
It receives blocks, and
then validates them, or not,

447
00:20:15,390 --> 00:20:17,520
and adds them to its local
copy of the blockchain.

448
00:20:17,520 --> 00:20:20,920
A miner might also be
running a full node.

449
00:20:20,920 --> 00:20:21,420
Yes?

450
00:20:21,420 --> 00:20:23,070
AUDIENCE: Miners should
be running full nodes.

451
00:20:23,070 --> 00:20:24,487
NEHA NARULA: Yeah,
they should be.

452
00:20:24,487 --> 00:20:28,590
But it's not clear that that
happens, for the reasons

453
00:20:28,590 --> 00:20:31,500
we were talking about before.

454
00:20:31,500 --> 00:20:32,040
I'm sorry?

455
00:20:32,040 --> 00:20:41,230
AUDIENCE: You can force
miners to [INAUDIBLE]

456
00:20:41,230 --> 00:20:46,480
NEHA NARULA: OK, so let's go
back to this image right here.

457
00:20:46,480 --> 00:20:49,630
These nodes are all running
some version of the software.

458
00:20:49,630 --> 00:20:51,430
They see this transaction.

459
00:20:51,430 --> 00:20:55,990
And they say, yes, this looks
like a valid transaction to me.

460
00:20:55,990 --> 00:20:57,280
And note that they have to--

461
00:20:57,280 --> 00:20:58,060
or, sorry, block.

462
00:20:58,060 --> 00:20:59,260
They look at this block.

463
00:20:59,260 --> 00:21:00,968
Yes, this looks like
a valid block to me.

464
00:21:00,968 --> 00:21:02,860
And note that they kind
of have to evaluate

465
00:21:02,860 --> 00:21:06,340
that block with respect
to all of the other blocks

466
00:21:06,340 --> 00:21:07,330
that it's seen.

467
00:21:07,330 --> 00:21:10,480
No double spends, all of the
scripts eggs, the script pub

468
00:21:10,480 --> 00:21:15,400
keys, work out correctly, it's
the right size, et cetera,

469
00:21:15,400 --> 00:21:16,840
et cetera.

470
00:21:16,840 --> 00:21:21,760
And then once it's decided
that that's all OK,

471
00:21:21,760 --> 00:21:26,440
each node will independently
make the same decision

472
00:21:26,440 --> 00:21:30,010
to add that block
to its blockchain.

473
00:21:30,010 --> 00:21:32,830
So you can see here that
determinism is actually

474
00:21:32,830 --> 00:21:34,030
really important.

475
00:21:34,030 --> 00:21:35,410
It can't be the
case that there's

476
00:21:35,410 --> 00:21:37,098
any randomness in this process.

477
00:21:37,098 --> 00:21:38,890
It can't be the case
that sort of randomly,

478
00:21:38,890 --> 00:21:40,980
depending on the time of
day, one node will decide

479
00:21:40,980 --> 00:21:42,560
this is a valid
block, one node will

480
00:21:42,560 --> 00:21:43,810
decide it's not a valid block.

481
00:21:43,810 --> 00:21:46,660
That's not the greatest
situation to have happen.

482
00:21:46,660 --> 00:21:49,360
We want this to be as
deterministic as possible.

483
00:21:49,360 --> 00:21:51,430
We want them to all
independently arrive

484
00:21:51,430 --> 00:21:53,800
at the same decision.

485
00:21:53,800 --> 00:21:55,090
Great.

486
00:21:55,090 --> 00:21:57,340
So this is how validation works.

487
00:21:57,340 --> 00:21:58,960
This is what nodes do.

488
00:21:58,960 --> 00:22:01,840
Major problem,
though-- sometimes,

489
00:22:01,840 --> 00:22:04,780
we need to change
the validation rules.

490
00:22:04,780 --> 00:22:08,170
Sometimes, we need to
upgrade the software.

491
00:22:08,170 --> 00:22:10,450
I mean, software is
not a static thing.

492
00:22:10,450 --> 00:22:12,700
The software that these
nodes are running,

493
00:22:12,700 --> 00:22:14,140
there's going to be bugs.

494
00:22:14,140 --> 00:22:16,220
There might be security
vulnerabilities.

495
00:22:16,220 --> 00:22:20,120
We might want to
add new features.

496
00:22:20,120 --> 00:22:23,990
And so we're going to want to
change the validation rules.

497
00:22:23,990 --> 00:22:26,000
It's pretty much inevitable.

498
00:22:26,000 --> 00:22:29,540
And, yet, given the
nature of the system,

499
00:22:29,540 --> 00:22:33,170
we can't upgrade every
single node at the same time.

500
00:22:36,800 --> 00:22:40,850
So I think a useful analogy
here, something to think about,

501
00:22:40,850 --> 00:22:43,240
is actually browsers.

502
00:22:43,240 --> 00:22:47,350
So web browsers-- right now,
a lot of people run Chrome.

503
00:22:47,350 --> 00:22:48,940
But not everyone runs Chrome.

504
00:22:48,940 --> 00:22:50,800
And Chrome actually
has auto update

505
00:22:50,800 --> 00:22:53,860
where it will push
changes to your browser.

506
00:22:53,860 --> 00:22:56,080
Google will automatically
upgrade you.

507
00:22:56,080 --> 00:22:57,790
But the way the
browsers used to work

508
00:22:57,790 --> 00:23:00,082
is that you didn't
always have auto update.

509
00:23:00,082 --> 00:23:01,540
Or it would bother
you, and ask you

510
00:23:01,540 --> 00:23:04,560
if you were OK with
auto updating before.

511
00:23:04,560 --> 00:23:06,940
And people would say, I don't
deal with this right now.

512
00:23:06,940 --> 00:23:07,750
I'm in the middle of something.

513
00:23:07,750 --> 00:23:09,070
I don't want to auto
update my browser,

514
00:23:09,070 --> 00:23:10,570
and have to restart
the whole thing.

515
00:23:10,570 --> 00:23:12,400
And so what would
end up happening

516
00:23:12,400 --> 00:23:15,790
is you'd have significant
numbers of people on very

517
00:23:15,790 --> 00:23:17,800
different versions of browsers.

518
00:23:17,800 --> 00:23:20,140
And this was kind of a
disaster for the internet,

519
00:23:20,140 --> 00:23:24,340
because people who were
developing websites,

520
00:23:24,340 --> 00:23:25,810
they wouldn't have
any confidence

521
00:23:25,810 --> 00:23:27,185
that the majority
of their users,

522
00:23:27,185 --> 00:23:29,080
or a significant
majority of their users,

523
00:23:29,080 --> 00:23:31,130
had upgraded to
the new features.

524
00:23:31,130 --> 00:23:35,620
So they had to support all
these old versions of browsers.

525
00:23:35,620 --> 00:23:37,910
And it was a nightmare.

526
00:23:37,910 --> 00:23:43,120
So that's what we're dealing
with here in cryptocurrencies,

527
00:23:43,120 --> 00:23:45,640
except it's even worse.

528
00:23:45,640 --> 00:23:48,820
So you definitely cannot
guarantee that everyone will

529
00:23:48,820 --> 00:23:50,740
upgrade their software
at the same time.

530
00:23:50,740 --> 00:23:53,290
You can't guarantee
that everyone will even

531
00:23:53,290 --> 00:23:55,510
upgrade ever.

532
00:23:55,510 --> 00:23:57,460
And so the designers
of the software,

533
00:23:57,460 --> 00:23:59,680
when you want to create a
new version of software,

534
00:23:59,680 --> 00:24:03,732
you have to think really,
really carefully about it.

535
00:24:03,732 --> 00:24:05,690
So let's say that we're
in this situation right

536
00:24:05,690 --> 00:24:09,520
here, where these three nodes
are running V1 of the software.

537
00:24:09,520 --> 00:24:11,660
The developers
have worked out V2.

538
00:24:11,660 --> 00:24:14,180
V2 has some interesting
new features,

539
00:24:14,180 --> 00:24:15,920
which slightly
changed the validation

540
00:24:15,920 --> 00:24:18,230
rules about what a
node running V2 will

541
00:24:18,230 --> 00:24:21,840
consider valid or invalid.

542
00:24:21,840 --> 00:24:27,070
So now, when we see this new
block, and we ask the question,

543
00:24:27,070 --> 00:24:31,470
is this block valid, these nodes
might make different decisions.

544
00:24:31,470 --> 00:24:35,400
In particular, maybe the old
nodes will think it's valid.

545
00:24:35,400 --> 00:24:37,380
Great, passes all
the validation rules.

546
00:24:37,380 --> 00:24:39,480
I will append this
block to my blockchain.

547
00:24:39,480 --> 00:24:42,430
And the new node will
not think it's valid,

548
00:24:42,430 --> 00:24:44,910
and will say, garbage
block, fantastic.

549
00:24:44,910 --> 00:24:48,420
I will not append this
block to my blockchain.

550
00:24:48,420 --> 00:24:51,240
And what we end up
with when this happens

551
00:24:51,240 --> 00:24:53,730
is we have two different
versions of history.

552
00:24:53,730 --> 00:24:55,975
The nodes running the old
version of the software

553
00:24:55,975 --> 00:24:58,100
think that there are four
blocks in the blockchain.

554
00:24:58,100 --> 00:25:01,280
The nodes that are running the
new version of the software

555
00:25:01,280 --> 00:25:02,970
have decided that
that block is invalid.

556
00:25:02,970 --> 00:25:06,880
And they only have three
blocks in the blockchain.

557
00:25:06,880 --> 00:25:10,110
So what does this mean?

558
00:25:10,110 --> 00:25:12,530
First of all, is this like
the situation we saw before,

559
00:25:12,530 --> 00:25:15,527
where if we just wait
for enough proof of work

560
00:25:15,527 --> 00:25:16,610
this will sort itself out?

561
00:25:19,180 --> 00:25:22,020
What do you guys think?

562
00:25:22,020 --> 00:25:24,100
I'm seeing some people
shaking their heads.

563
00:25:24,100 --> 00:25:27,370
And, yes, this situation is
different than the situation

564
00:25:27,370 --> 00:25:29,320
we saw before,
because the situation

565
00:25:29,320 --> 00:25:32,720
we saw before, all the nodes
still had the same validation

566
00:25:32,720 --> 00:25:33,220
rules.

567
00:25:36,400 --> 00:25:40,630
They just saw the blocks
in different orders,

568
00:25:40,630 --> 00:25:42,240
or they got later, whatever.

569
00:25:42,240 --> 00:25:46,540
All of that can be resolved by
looking at the proof of work.

570
00:25:46,540 --> 00:25:50,170
Sometimes when this
happens, sometimes

571
00:25:50,170 --> 00:25:52,390
when nodes are actually
running different versions

572
00:25:52,390 --> 00:25:54,190
of validation
software, things can

573
00:25:54,190 --> 00:25:56,260
be resolved by just
looking at proof of work.

574
00:25:56,260 --> 00:25:58,900
But quite often,
actually, they can't.

575
00:25:58,900 --> 00:26:01,630
And so in this situation,
what might happen

576
00:26:01,630 --> 00:26:03,860
is another block comes along.

577
00:26:03,860 --> 00:26:07,000
So this is a different
block than this one.

578
00:26:07,000 --> 00:26:08,740
And this set of
nodes might decide

579
00:26:08,740 --> 00:26:11,410
that this is the next
block in the blockchain,

580
00:26:11,410 --> 00:26:16,630
whereas the blue nodes will
never, ever, ever validate

581
00:26:16,630 --> 00:26:18,040
this block.

582
00:26:18,040 --> 00:26:20,350
They will never decide
that this block is valid,

583
00:26:20,350 --> 00:26:22,600
given the version of the
software they are running.

584
00:26:22,600 --> 00:26:25,240
They will never
switch to a blockchain

585
00:26:25,240 --> 00:26:27,610
that has this block
in it, even if it

586
00:26:27,610 --> 00:26:29,710
has the most proof of work.

587
00:26:29,710 --> 00:26:31,990
So I think this is a
really important point.

588
00:26:31,990 --> 00:26:33,820
And I think it sort
of fundamentally

589
00:26:33,820 --> 00:26:36,130
gets to why miners
don't actually

590
00:26:36,130 --> 00:26:38,680
have as much power
in the system as one

591
00:26:38,680 --> 00:26:40,060
might think that they do.

592
00:26:40,060 --> 00:26:43,390
And the reason for that is that
the way bitcoin is designed

593
00:26:43,390 --> 00:26:48,190
is that a node will never accept
a chain with a single invalid

594
00:26:48,190 --> 00:26:49,880
transaction.

595
00:26:49,880 --> 00:26:52,430
If, according to
its set of rules,

596
00:26:52,430 --> 00:26:55,730
a single transaction is
invalid, it will completely

597
00:26:55,730 --> 00:26:56,720
ignore that chain.

598
00:26:56,720 --> 00:26:58,720
Doesn't matter if it has
the most proof of work.

599
00:27:00,980 --> 00:27:02,798
Does that make
sense to everyone?

600
00:27:05,870 --> 00:27:06,860
It's kind of intense.

601
00:27:06,860 --> 00:27:08,540
It's kind of crazy, right?

602
00:27:08,540 --> 00:27:11,060
Like, even if it has
mountains upon mountains

603
00:27:11,060 --> 00:27:12,740
of proof of work,
it will completely

604
00:27:12,740 --> 00:27:14,480
ignore that chain
because there's

605
00:27:14,480 --> 00:27:16,790
something invalid about it.

606
00:27:16,790 --> 00:27:20,450
So miners can mine
what they want.

607
00:27:20,450 --> 00:27:24,080
But they better mine
within the validation rules

608
00:27:24,080 --> 00:27:27,260
set of the economic
majority of the nodes.

609
00:27:27,260 --> 00:27:28,760
Otherwise, those
nodes are all going

610
00:27:28,760 --> 00:27:30,207
to ignore whatever they mine.

611
00:27:30,207 --> 00:27:32,290
And their money is not
going to be worth anything.

612
00:27:36,870 --> 00:27:37,590
Great.

613
00:27:37,590 --> 00:27:42,270
So in this situation, we end up
with two different blockchains.

614
00:27:42,270 --> 00:27:45,750
And we actually end up with
something quite irreconcilable,

615
00:27:45,750 --> 00:27:48,870
unless we change the
software again, somehow.

616
00:27:48,870 --> 00:27:51,570
And what we've ended up
with that's irreconcilable

617
00:27:51,570 --> 00:27:56,310
is we now have a block over
here, and a block over here.

618
00:27:56,310 --> 00:28:00,400
This node will never accept a
chain with this block in it.

619
00:28:00,400 --> 00:28:02,545
And so we've got two
different blockchains.

620
00:28:06,110 --> 00:28:11,060
So when this happens,
we call it a fork.

621
00:28:11,060 --> 00:28:13,650
Now, the word fork can be used
to mean many different things

622
00:28:13,650 --> 00:28:14,150
in software.

623
00:28:14,150 --> 00:28:16,903
For example, you fork
a project on GitHub.

624
00:28:16,903 --> 00:28:18,320
When you fork a
project on GitHub,

625
00:28:18,320 --> 00:28:20,840
you might make changes to it.

626
00:28:20,840 --> 00:28:24,140
This is a little bit different
because of the linearity

627
00:28:24,140 --> 00:28:26,090
of history here.

628
00:28:26,090 --> 00:28:29,450
When a fork happens
in a cryptocurrency,

629
00:28:29,450 --> 00:28:33,320
in particular a sort of a fork
that can't easily be resolved,

630
00:28:33,320 --> 00:28:34,700
that isn't just
going to, oh, one

631
00:28:34,700 --> 00:28:35,990
side has more proof
of work, OK, great

632
00:28:35,990 --> 00:28:37,820
we're all going to switch
to that other side.

633
00:28:37,820 --> 00:28:39,612
When you have a fork
that can't be resolved

634
00:28:39,612 --> 00:28:43,400
that easily then it's
actually a pretty big deal,

635
00:28:43,400 --> 00:28:45,082
because like we
were saying earlier

636
00:28:45,082 --> 00:28:47,540
we now have two versions of
history, two different versions

637
00:28:47,540 --> 00:28:48,170
of money.

638
00:28:48,170 --> 00:28:50,750
It's like I took the
dollar from my wallet,

639
00:28:50,750 --> 00:28:51,920
and I photocopied it.

640
00:28:51,920 --> 00:28:54,950
And now there's $2 where
there was only one.

641
00:28:54,950 --> 00:28:57,750
So maybe you like
this kind of dollars.

642
00:28:57,750 --> 00:28:59,700
Maybe you don't like
that kind of dollars.

643
00:28:59,700 --> 00:29:02,180
We've basically taken
this entire network

644
00:29:02,180 --> 00:29:05,090
that all sort of agreed on
what this form of money was,

645
00:29:05,090 --> 00:29:06,560
and we've divided it into two.

646
00:29:09,800 --> 00:29:12,740
So there's two
different kind of forks

647
00:29:12,740 --> 00:29:16,130
that people will talk about
mostly in this industry.

648
00:29:16,130 --> 00:29:20,420
But forking is actually much
more complicated than that.

649
00:29:20,420 --> 00:29:22,653
You can't just
talk about forks as

650
00:29:22,653 --> 00:29:24,320
in-- so the two
different kinds of forks

651
00:29:24,320 --> 00:29:26,045
are soft forks and hard forks.

652
00:29:26,045 --> 00:29:27,920
And I'm going to explain
what a soft work is,

653
00:29:27,920 --> 00:29:29,120
versus a hard fork.

654
00:29:29,120 --> 00:29:32,120
But, actually, that
delineation, it

655
00:29:32,120 --> 00:29:34,693
gets much more nuanced because
different things happen

656
00:29:34,693 --> 00:29:36,110
in a soft fork
versus a hard fork,

657
00:29:36,110 --> 00:29:40,890
depending upon who's
decided to adopt the rules.

658
00:29:40,890 --> 00:29:43,100
OK, so a soft fork--

659
00:29:43,100 --> 00:29:49,250
a soft fork is a fork which
is backwards compatible.

660
00:29:49,250 --> 00:29:52,640
So we have some rule set.

661
00:29:52,640 --> 00:29:56,900
And under that
rule set you apply

662
00:29:56,900 --> 00:30:03,660
that rule set to every
single possible one megabyte

663
00:30:03,660 --> 00:30:04,972
chunk of data.

664
00:30:04,972 --> 00:30:06,930
And we're going to end
up with some set of what

665
00:30:06,930 --> 00:30:09,840
are valid blocks.

666
00:30:09,840 --> 00:30:14,430
A soft fork is when you
add rules to the rule set,

667
00:30:14,430 --> 00:30:17,460
such that the set of valid
blocks actually shrinks.

668
00:30:20,850 --> 00:30:22,950
So what does that mean?

669
00:30:22,950 --> 00:30:24,960
We had a whole bunch
of rules before.

670
00:30:24,960 --> 00:30:26,880
Blocks have to be
less than 1 megabyte.

671
00:30:26,880 --> 00:30:28,355
Transactions all
have to be valid.

672
00:30:28,355 --> 00:30:30,480
It means that their scripts
certify, like validate,

673
00:30:30,480 --> 00:30:32,160
under the certain
script interpreter,

674
00:30:32,160 --> 00:30:34,103
et cetera, no double spends.

675
00:30:34,103 --> 00:30:36,520
Let's take one of the rules
that's actually pretty simple,

676
00:30:36,520 --> 00:30:40,050
which is that blocks have to
be less than one megabyte.

677
00:30:40,050 --> 00:30:42,000
Let's say that I
change that to blocks

678
00:30:42,000 --> 00:30:44,340
have to be less
than two megabytes.

679
00:30:44,340 --> 00:30:45,210
Is that a soft fork?

680
00:30:48,050 --> 00:30:48,633
AUDIENCE: Yes.

681
00:30:51,330 --> 00:30:53,830
NEHA NARULA: Oh, wow, there's
some actual dissent over this,

682
00:30:53,830 --> 00:30:54,370
right?

683
00:30:54,370 --> 00:30:59,415
OK, so someone who says
no, why is the answer no?

684
00:30:59,415 --> 00:31:01,790
AUDIENCE: Because you have
something that is now accepted

685
00:31:01,790 --> 00:31:03,470
that wasn't accepted before.

686
00:31:03,470 --> 00:31:06,590
NEHA NARULA: Right, so
remember, valid blocks

687
00:31:06,590 --> 00:31:09,578
before newly valid blocks
fit inside of this.

688
00:31:09,578 --> 00:31:11,120
Now, someone who
said yes it's a soft

689
00:31:11,120 --> 00:31:14,020
fork, why do you think that?

690
00:31:14,020 --> 00:31:17,758
AUDIENCE: All blocks
still have less than two.

691
00:31:17,758 --> 00:31:18,550
NEHA NARULA: Right.

692
00:31:18,550 --> 00:31:21,740
So it's actually
not a soft fork.

693
00:31:21,740 --> 00:31:23,530
And the reason that
it's not a soft fork

694
00:31:23,530 --> 00:31:31,220
is because a block that is
1.75 megabytes, previously,

695
00:31:31,220 --> 00:31:34,370
the old rule set, was invalid.

696
00:31:34,370 --> 00:31:37,360
New rule set, it's valid.

697
00:31:37,360 --> 00:31:40,600
But we just said everything
that's newly valid

698
00:31:40,600 --> 00:31:43,570
has to fit inside
what used to be valid.

699
00:31:43,570 --> 00:31:47,230
So a soft fork is restricting
the set of valid things.

700
00:31:47,230 --> 00:31:50,070
You can think of it as
expanding the set of rules

701
00:31:50,070 --> 00:31:55,755
that a block now
has to comply with.

702
00:31:55,755 --> 00:32:04,110
So a feature of this is
that if you don't upgrade--

703
00:32:04,110 --> 00:32:07,440
so V1 is the old rule software.

704
00:32:07,440 --> 00:32:08,970
V2 is the new rule software.

705
00:32:08,970 --> 00:32:12,060
If you don't upgrade,
you will continue

706
00:32:12,060 --> 00:32:14,970
to see the new blocks as valid.

707
00:32:14,970 --> 00:32:17,400
And this is actually
a very nice property,

708
00:32:17,400 --> 00:32:19,560
because, remember what
happened over here,

709
00:32:19,560 --> 00:32:21,810
we had this property where
the people on the blue side

710
00:32:21,810 --> 00:32:24,300
were just never,
ever going to accept

711
00:32:24,300 --> 00:32:26,220
one of these blockchains.

712
00:32:26,220 --> 00:32:33,130
And if it were the case
that this were a soft fork,

713
00:32:33,130 --> 00:32:37,030
the old side would never, ever--

714
00:32:37,030 --> 00:32:39,610
well, if this sorry,
if it were the case

715
00:32:39,610 --> 00:32:41,620
that this weren't a
soft work, the old nodes

716
00:32:41,620 --> 00:32:45,280
would never accept
this new stuff.

717
00:32:45,280 --> 00:32:47,440
So soft forks are really
nice, because they're

718
00:32:47,440 --> 00:32:49,000
backwards compatible.

719
00:32:49,000 --> 00:32:52,150
Old nodes will still see
the new blocks as valid.

720
00:32:52,150 --> 00:32:53,890
They won't reject them.

721
00:32:53,890 --> 00:32:56,440
If that chain gets a
ton of proof of work,

722
00:32:56,440 --> 00:32:59,440
then the old nodes will happily
switch over to that chain.

723
00:32:59,440 --> 00:33:01,690
So, what does that mean?

724
00:33:01,690 --> 00:33:05,100
So let's say that the black
nodes are the old rules,

725
00:33:05,100 --> 00:33:09,330
and the blue nodes are new
rules, new rule blocks.

726
00:33:09,330 --> 00:33:11,190
And, again, we have to
look at this from two

727
00:33:11,190 --> 00:33:12,420
different perspectives.

728
00:33:12,420 --> 00:33:14,210
There are the people
creating the blocks.

729
00:33:14,210 --> 00:33:16,290
And there are the people
reading the blocks.

730
00:33:16,290 --> 00:33:17,957
And sometimes those
are the same people.

731
00:33:17,957 --> 00:33:19,367
Sometimes, they're not.

732
00:33:19,367 --> 00:33:20,700
So we're looking at blocks here.

733
00:33:20,700 --> 00:33:22,700
So these are people who
are creating the blocks.

734
00:33:26,520 --> 00:33:28,710
And, again, both of
these sets of people

735
00:33:28,710 --> 00:33:31,170
might upgrade or not upgrade.

736
00:33:31,170 --> 00:33:34,947
So we might have miners who
are following the old rules

737
00:33:34,947 --> 00:33:36,780
and miners who were
following the new rules.

738
00:33:36,780 --> 00:33:38,340
Then we might have
validating nodes

739
00:33:38,340 --> 00:33:40,075
who are following the old
rules, and validating nodes who

740
00:33:40,075 --> 00:33:41,730
are following the new rules.

741
00:33:41,730 --> 00:33:43,570
And this is not even
talking about SPV yet.

742
00:33:43,570 --> 00:33:45,070
OK, we're just
talking about miners.

743
00:33:45,070 --> 00:33:47,800
And we're talking about nodes.

744
00:33:47,800 --> 00:33:51,380
So let's say some of the miners
upgrade to the new rules,

745
00:33:51,380 --> 00:33:54,340
but not all of the miners
upgrade to the new rules.

746
00:33:54,340 --> 00:33:57,400
The miners who didn't
upgrade to the new rules

747
00:33:57,400 --> 00:34:00,860
are going to continue
producing old rule blocks.

748
00:34:00,860 --> 00:34:04,510
They're going to continue
producing V1 version blocks.

749
00:34:04,510 --> 00:34:08,650
But if the majority of miners
upgrade to the new rules,

750
00:34:08,650 --> 00:34:13,300
remember, the new rule
people have new rules.

751
00:34:13,300 --> 00:34:16,750
So they have more restrictions
on the set of blocks

752
00:34:16,750 --> 00:34:18,820
that they will accept.

753
00:34:18,820 --> 00:34:22,558
So they might not see
that block as valid.

754
00:34:22,558 --> 00:34:24,850
So they're never going to
accept that chain, because it

755
00:34:24,850 --> 00:34:26,380
has invalid things in it.

756
00:34:26,380 --> 00:34:28,780
Once you've upgraded,
you might no longer

757
00:34:28,780 --> 00:34:30,455
accept the old chain as valid.

758
00:34:30,455 --> 00:34:32,080
And so what's going
to end up happening

759
00:34:32,080 --> 00:34:34,246
is something that looks
very much like the orphaning

760
00:34:34,246 --> 00:34:35,920
situation that was
happening before,

761
00:34:35,920 --> 00:34:38,800
where if the majority of
the hash powers, which

762
00:34:38,800 --> 00:34:42,639
is over here, this chain is
going to keep going bigger.

763
00:34:42,639 --> 00:34:45,429
These guys might keep trying
to produce old style blocks.

764
00:34:45,429 --> 00:34:47,770
But they just keep
getting orphaned off.

765
00:34:47,770 --> 00:34:50,980
It's actually like very much
in their economic interest

766
00:34:50,980 --> 00:34:54,010
to hurry up and upgrade, so
they're not wasting hash power

767
00:34:54,010 --> 00:34:54,850
on orphan blocks.

768
00:34:59,170 --> 00:35:01,120
Are there questions
about soft forks?

769
00:35:07,000 --> 00:35:08,470
Yes?

770
00:35:08,470 --> 00:35:10,750
AUDIENCE: So are
soft forks also used

771
00:35:10,750 --> 00:35:15,640
for changing software
other than validation?

772
00:35:15,640 --> 00:35:18,480
NEHA NARULA: Yes,
that's a great question.

773
00:35:18,480 --> 00:35:21,040
Are soft forks also used
for changing software other

774
00:35:21,040 --> 00:35:22,310
than validation?

775
00:35:22,310 --> 00:35:27,760
So we can certainly upgrade
more than just the validation

776
00:35:27,760 --> 00:35:30,400
parts of the bitcoin software.

777
00:35:30,400 --> 00:35:33,850
If it doesn't change the set of
blocks that would be accepted

778
00:35:33,850 --> 00:35:38,050
or not accepted, we don't
even bother calling it a fork.

779
00:35:38,050 --> 00:35:42,250
So let's say that we wanted to
change something about the peer

780
00:35:42,250 --> 00:35:45,790
to peer network, or the way
that things are stored on disk,

781
00:35:45,790 --> 00:35:48,340
or something like that.

782
00:35:48,340 --> 00:35:51,053
We would see that
a change like that,

783
00:35:51,053 --> 00:35:53,470
if it didn't change the set
of blocks that would have been

784
00:35:53,470 --> 00:35:56,710
accepted or not accepted,
if after the change

785
00:35:56,710 --> 00:35:59,230
a set of blocks accepted or
not accepted is the exact same,

786
00:35:59,230 --> 00:36:02,910
we don't call that a fork, a
change that induces a fork.

787
00:36:02,910 --> 00:36:05,410
It's only when the set of blocks
are accepted or wouldn't be

788
00:36:05,410 --> 00:36:06,760
accepted are actually changed.

789
00:36:06,760 --> 00:36:07,420
Yes?

790
00:36:07,420 --> 00:36:09,913
AUDIENCE: How often do updates
get pushed on the network?

791
00:36:09,913 --> 00:36:11,080
NEHA NARULA: Great question.

792
00:36:11,080 --> 00:36:13,270
How often do updates get
pushed on the network?

793
00:36:13,270 --> 00:36:16,870
So Bitcoin is at
version 0.16 right now.

794
00:36:16,870 --> 00:36:19,998
And 0.16 came out like
a week or two ago.

795
00:36:19,998 --> 00:36:22,540
And I think it's sort of been
on the order of a couple months

796
00:36:22,540 --> 00:36:26,320
between different
versions of Bitcoin.

797
00:36:26,320 --> 00:36:28,510
Other cryptocurrencies
release more frequently.

798
00:36:28,510 --> 00:36:30,940
Some release less frequently.

799
00:36:30,940 --> 00:36:33,310
Some do forks very,
very regularly.

800
00:36:33,310 --> 00:36:35,322
And we'll speak a
little bit about that.

801
00:36:35,322 --> 00:36:37,780
But the software is pretty much
constantly getting updated.

802
00:36:41,840 --> 00:36:42,600
Yeah?

803
00:36:42,600 --> 00:36:45,390
AUDIENCE: So in
practice, people are just

804
00:36:45,390 --> 00:36:47,680
updating their versions?

805
00:36:47,680 --> 00:36:50,360
NEHA NARULA: Yeah, so in
Bitcoin in particular,

806
00:36:50,360 --> 00:36:52,525
Bitcoin does not have
an auto update function.

807
00:36:52,525 --> 00:36:54,650
So in order to run the new
version of the software,

808
00:36:54,650 --> 00:36:56,030
you have to decide
that you're going

809
00:36:56,030 --> 00:36:57,655
to run the new version
of the software.

810
00:36:57,655 --> 00:37:00,620
Or there might be a way to
decide to turn auto update on.

811
00:37:00,620 --> 00:37:01,400
I can't remember.

812
00:37:01,400 --> 00:37:03,290
But the point is that
they try to leave it

813
00:37:03,290 --> 00:37:05,330
in their user's hands.

814
00:37:05,330 --> 00:37:05,830
Yes?

815
00:37:05,830 --> 00:37:07,810
AUDIENCE: How are
versions created?

816
00:37:07,810 --> 00:37:10,870
So if you like on the GitHub,
there are a ton of features,

817
00:37:10,870 --> 00:37:13,060
and sometimes they're
pushed forward.

818
00:37:13,060 --> 00:37:15,310
Is there a subreddit, where
they're like, OK, version?

819
00:37:18,690 --> 00:37:20,440
NEHA NARULA: OK, how
are versions created?

820
00:37:20,440 --> 00:37:22,928
It's actually very similar to
any other software project,

821
00:37:22,928 --> 00:37:24,970
where the people who work
on the software project

822
00:37:24,970 --> 00:37:28,950
get together, and decide
which pull requests are going

823
00:37:28,950 --> 00:37:30,200
to be part of the new version.

824
00:37:30,200 --> 00:37:31,700
So, yes, at some
point, they're just

825
00:37:31,700 --> 00:37:33,720
like, new version, release.

826
00:37:33,720 --> 00:37:34,220
Yeah?

827
00:37:37,130 --> 00:37:40,938
AUDIENCE: Do software get
released as updated versions?

828
00:37:40,938 --> 00:37:42,730
NEHA NARULA: Yes, soft
forks are definitely

829
00:37:42,730 --> 00:37:45,820
released as updated versions.

830
00:37:45,820 --> 00:37:48,250
So that's a great question.

831
00:37:48,250 --> 00:37:50,732
I think not every version
has a soft fork in it.

832
00:37:50,732 --> 00:37:52,690
But if there is a soft
fork, it will definitely

833
00:37:52,690 --> 00:37:53,950
be a new version.

834
00:37:53,950 --> 00:37:54,770
Yes?

835
00:37:54,770 --> 00:37:56,890
AUDIENCE: Why can't
this black miner

836
00:37:56,890 --> 00:38:00,200
not just look at the
version in the blue block

837
00:38:00,200 --> 00:38:01,450
and decide not to?

838
00:38:01,450 --> 00:38:04,840
NEHA NARULA: Because
it's not a blue block.

839
00:38:04,840 --> 00:38:09,110
So you're talking
about here, right?

840
00:38:11,920 --> 00:38:15,460
OK, so the nodes are
running different software.

841
00:38:15,460 --> 00:38:18,910
And then a block
comes along that--

842
00:38:21,630 --> 00:38:26,010
ideally, yes the block would
have a version number in it

843
00:38:26,010 --> 00:38:29,770
that specifies which
version of the software.

844
00:38:29,770 --> 00:38:33,920
And this is a very useful
field in the block header.

845
00:38:33,920 --> 00:38:38,050
But that's not really--

846
00:38:38,050 --> 00:38:39,860
so what it has a
different version?

847
00:38:39,860 --> 00:38:42,230
AUDIENCE: If it's
lower than mine--

848
00:38:42,230 --> 00:38:45,550
sorry, higher than mine,
then I don't do it.

849
00:38:45,550 --> 00:38:46,765
Then I won't update first.

850
00:38:46,765 --> 00:38:48,640
NEHA NARULA: What do
you mean by don't do it?

851
00:38:48,640 --> 00:38:50,500
You mean, you ignore it?

852
00:38:50,500 --> 00:38:52,840
AUDIENCE: No, I
[INAUDIBLE] myself,

853
00:38:52,840 --> 00:38:55,408
because I see that a higher
version is in circulation.

854
00:38:55,408 --> 00:38:56,950
NEHA NARULA: So that
would be one way

855
00:38:56,950 --> 00:38:59,450
of running the network, which
is if I ever see anything that

856
00:38:59,450 --> 00:39:01,750
indicates that there's
newer software out there,

857
00:39:01,750 --> 00:39:04,990
I just realize I'm old,
and that I need to update.

858
00:39:07,720 --> 00:39:10,720
I think that Bitcoin simply
made a different design

859
00:39:10,720 --> 00:39:15,710
decision, which was that older
nodes should still be able to--

860
00:39:15,710 --> 00:39:19,450
because think about nodes
that were sort of set it

861
00:39:19,450 --> 00:39:22,060
and forget it, they're
out there running.

862
00:39:22,060 --> 00:39:23,800
One tenant that
is absolutely true

863
00:39:23,800 --> 00:39:25,900
is that users will not upgrade.

864
00:39:25,900 --> 00:39:27,580
They will not all upgrade.

865
00:39:27,580 --> 00:39:28,460
It just won't happen.

866
00:39:28,460 --> 00:39:30,250
You will have old versions
of software running.

867
00:39:30,250 --> 00:39:32,620
And given that you will have old
versions of software running,

868
00:39:32,620 --> 00:39:34,720
I think it's a question
as to whether or not those

869
00:39:34,720 --> 00:39:36,370
nodes should still be
a part of the network,

870
00:39:36,370 --> 00:39:38,120
or whether you just
want to slice them off

871
00:39:38,120 --> 00:39:40,635
because they're not
running the latest version.

872
00:39:40,635 --> 00:39:42,010
And I think in
Bitcoin, they want

873
00:39:42,010 --> 00:39:43,940
those nodes to still be
a part of the network.

874
00:39:43,940 --> 00:39:46,630
They want people to be able to
make the active decision not

875
00:39:46,630 --> 00:39:48,350
to upgrade.

876
00:39:48,350 --> 00:39:52,680
Tadge actually, I think is still
running 0.13, or some older

877
00:39:52,680 --> 00:39:53,940
version of Bitcoin.

878
00:39:53,940 --> 00:39:55,050
Still works great.

879
00:39:55,050 --> 00:39:59,440
He can still validate
transactions totally fine.

880
00:39:59,440 --> 00:40:03,010
OK, so we just talked
about soft forks.

881
00:40:03,010 --> 00:40:05,510
And I think the important thing
to remember about soft works

882
00:40:05,510 --> 00:40:07,760
is that soft works are
backwards compatible.

883
00:40:07,760 --> 00:40:13,850
We also talked about an example
that is not a hard fork, which

884
00:40:13,850 --> 00:40:16,490
is if we decided that we
wanted to allow blocks that

885
00:40:16,490 --> 00:40:19,040
were less than two
megabytes, instead of less

886
00:40:19,040 --> 00:40:20,300
than one megabyte.

887
00:40:20,300 --> 00:40:25,500
And so a 1.75 megabyte
of block appears.

888
00:40:25,500 --> 00:40:27,220
That is not a soft work.

889
00:40:27,220 --> 00:40:29,790
What if we changed
the rule to say

890
00:40:29,790 --> 00:40:32,795
that, instead of only
accepting blocks that

891
00:40:32,795 --> 00:40:34,170
are less than one
megabyte, we're

892
00:40:34,170 --> 00:40:37,230
only going to accept blocks that
are less than half a megabyte.

893
00:40:37,230 --> 00:40:38,720
Is that a soft
work or hard fork?

894
00:40:43,310 --> 00:40:45,127
AUDIENCE: Soft fork.

895
00:40:45,127 --> 00:40:46,460
NEHA NARULA: That's a soft work.

896
00:40:46,460 --> 00:40:48,220
The reason that
that's a soft fork,

897
00:40:48,220 --> 00:40:50,890
is because a block that is
less than half a megabyte

898
00:40:50,890 --> 00:40:53,470
was also still less
than one megabyte.

899
00:40:53,470 --> 00:40:58,210
So it's still valid under
the old set of rules.

900
00:40:58,210 --> 00:41:01,275
So if the change made here was
now we want smaller blocks.

901
00:41:01,275 --> 00:41:02,900
So we're only going
to take blocks that

902
00:41:02,900 --> 00:41:05,030
are less than half a megabyte.

903
00:41:05,030 --> 00:41:07,237
That's fine.

904
00:41:07,237 --> 00:41:09,070
Everyone will still see
this chain as valid.

905
00:41:09,070 --> 00:41:10,800
This is still
backwards compatible.

906
00:41:10,800 --> 00:41:12,750
Just because your blocks
are 300 kilobytes now

907
00:41:12,750 --> 00:41:15,970
doesn't mean that
they violate a rule.

908
00:41:15,970 --> 00:41:18,945
AUDIENCE: Can I ask one last
question in relation to that?

909
00:41:18,945 --> 00:41:21,120
So what happens if I
want to do something

910
00:41:21,120 --> 00:41:26,160
with the old version,
and [INAUDIBLE]..

911
00:41:26,160 --> 00:41:28,840
And they realize, wow,
I love [INAUDIBLE]..

912
00:41:35,172 --> 00:41:36,630
NEHA NARULA: Right,
so what happens

913
00:41:36,630 --> 00:41:38,910
to all the previous
stuff in my chain, right?

914
00:41:38,910 --> 00:41:41,070
Now, ideally, the
way that the rules

915
00:41:41,070 --> 00:41:44,880
would be setup, the new rules,
is that they would take effect

916
00:41:44,880 --> 00:41:46,265
sometime in the future.

917
00:41:46,265 --> 00:41:47,640
So you wouldn't
apply those rules

918
00:41:47,640 --> 00:41:51,330
retroactively to the things that
you already put into the chain,

919
00:41:51,330 --> 00:41:53,400
because then you just
throw away all history.

920
00:41:53,400 --> 00:41:54,858
And that would be
kind of a bummer.

921
00:41:54,858 --> 00:41:56,335
Instead, you say,
after this block,

922
00:41:56,335 --> 00:41:57,960
we are only going to
accept blocks that

923
00:41:57,960 --> 00:41:59,310
are less than half a megabyte.

924
00:41:59,310 --> 00:42:01,227
AUDIENCE: So what happens
if after that block,

925
00:42:01,227 --> 00:42:05,963
so a majority of miners
are running old software.

926
00:42:05,963 --> 00:42:07,130
NEHA NARULA: Great question.

927
00:42:07,130 --> 00:42:08,315
AUDIENCE: [INAUDIBLE]

928
00:42:08,315 --> 00:42:09,690
NEHA NARULA: We'll
get into that.

929
00:42:09,690 --> 00:42:13,470
We'll get into what happens when
the majority, versus minority,

930
00:42:13,470 --> 00:42:16,050
of different parts of
the ecosystem decide

931
00:42:16,050 --> 00:42:19,720
to adopt the change, versus
not adopt the change.

932
00:42:19,720 --> 00:42:21,720
But first, we're going
to talk about hard forks.

933
00:42:21,720 --> 00:42:23,520
What is a hard fork?

934
00:42:23,520 --> 00:42:26,070
A hard fork is not
backwards compatible.

935
00:42:26,070 --> 00:42:28,470
And so a hard fork
is a fork where,

936
00:42:28,470 --> 00:42:31,200
if this was the
old set of rules,

937
00:42:31,200 --> 00:42:33,630
under the new set of
rules you actually accept

938
00:42:33,630 --> 00:42:36,180
more blocks than you would
have accepted before.

939
00:42:39,120 --> 00:42:44,720
So just to be clear,
under the new rules,

940
00:42:44,720 --> 00:42:47,960
you might produce a block,
which a node running

941
00:42:47,960 --> 00:42:51,410
under the old rules will reject.

942
00:42:51,410 --> 00:42:54,680
This is not
backwards compatible,

943
00:42:54,680 --> 00:43:00,440
because any chain that has
this new type of block in it

944
00:43:00,440 --> 00:43:03,485
will not be accepted by any
of the old nodes, full stop.

945
00:43:03,485 --> 00:43:05,360
It doesn't matter about
proof of work at all.

946
00:43:12,920 --> 00:43:18,940
OK, so the thing
with hard forks is

947
00:43:18,940 --> 00:43:21,920
that because they're not
backwards compatible,

948
00:43:21,920 --> 00:43:24,790
they're a little crazier and
a little bit sort of harder

949
00:43:24,790 --> 00:43:27,040
to manage in your network.

950
00:43:27,040 --> 00:43:31,030
Because if you do a hard fork
and not everyone upgrades,

951
00:43:31,030 --> 00:43:33,610
you might end up with two
chains, possibly forever.

952
00:43:36,240 --> 00:43:39,715
If we assume that those nodes
are not going to upgrade--

953
00:43:39,715 --> 00:43:41,840
and let's say they're not
upgrading because there's

954
00:43:41,840 --> 00:43:43,710
no one really maintaining them.

955
00:43:43,710 --> 00:43:46,338
Then they're not going
to upgrade in the future.

956
00:43:46,338 --> 00:43:48,380
And they're not going to
upgrade to a change that

957
00:43:48,380 --> 00:43:50,360
might fix what's going on here.

958
00:43:50,360 --> 00:43:53,540
They're just going to keep
doing their old time thing.

959
00:43:53,540 --> 00:43:57,350
Then with a hard
fork, these nodes

960
00:43:57,350 --> 00:44:01,723
are never going to
accept the new blocks.

961
00:44:01,723 --> 00:44:06,210
It doesn't matter what the
proof of work is on that chain.

962
00:44:06,210 --> 00:44:08,490
So hard forks
versus soft works--

963
00:44:08,490 --> 00:44:11,640
hard forks, as I keep stressing,
are not backwards compatible.

964
00:44:11,640 --> 00:44:12,210
Guess what?

965
00:44:12,210 --> 00:44:15,570
A fork can be a hard fork and
a soft work at the same time.

966
00:44:15,570 --> 00:44:18,120
Yay.

967
00:44:18,120 --> 00:44:21,510
Super confusing,
actually, because you

968
00:44:21,510 --> 00:44:23,490
can both restrict
the set of rules

969
00:44:23,490 --> 00:44:26,130
and expand the set of
rules at the same time.

970
00:44:26,130 --> 00:44:29,820
Basically, it means it's a new,
overlapping, but not entirely

971
00:44:29,820 --> 00:44:34,430
inclusive or not inclusive,
set of rules, very unfortunate.

972
00:44:34,430 --> 00:44:36,020
In fact, most things
should actually

973
00:44:36,020 --> 00:44:37,545
be both, to avoid
some of the things

974
00:44:37,545 --> 00:44:39,170
that I'm going to
show you in a minute.

975
00:44:39,170 --> 00:44:39,680
Yes?

976
00:44:39,680 --> 00:44:42,080
AUDIENCE: But then for
all useful purposes,

977
00:44:42,080 --> 00:44:43,820
isn't it just a hard
fork, because that

978
00:44:43,820 --> 00:44:45,968
means some nodes won't
be inside the blocks.

979
00:44:45,968 --> 00:44:47,510
NEHA NARULA: For
all useful purposes,

980
00:44:47,510 --> 00:44:51,215
it's not just a hard fork.

981
00:44:51,215 --> 00:44:52,090
Let me see if I can--

982
00:45:01,450 --> 00:45:03,550
The reason that it's
not just a hard fork--

983
00:45:08,373 --> 00:45:10,790
this is something that requires
a little bit more thought.

984
00:45:10,790 --> 00:45:12,110
It's not just a hard fork.

985
00:45:12,110 --> 00:45:14,070
But I will think about how
to explain this, and perhaps

986
00:45:14,070 --> 00:45:14,987
say something on this.

987
00:45:14,987 --> 00:45:16,022
Or, yeah?

988
00:45:16,022 --> 00:45:18,420
AUDIENCE: [INAUDIBLE]

989
00:45:35,078 --> 00:45:35,870
NEHA NARULA: It is.

990
00:45:35,870 --> 00:45:38,720
But he's asking, isn't
that just a hard fork?

991
00:45:38,720 --> 00:45:40,670
And it's not just a
hard fork, because I

992
00:45:40,670 --> 00:45:46,900
think old nodes will
do something different.

993
00:45:46,900 --> 00:45:52,100
Ah, OK, so there's two reasons
why it's not just a hard fork.

994
00:45:52,100 --> 00:45:53,970
One is because of reorgs.

995
00:45:53,970 --> 00:45:59,690
So different things will happen
as the majority of hash power

996
00:45:59,690 --> 00:46:04,280
starts to accept or
not accept the change,

997
00:46:04,280 --> 00:46:07,250
whether or not all nodes
will switch over or not.

998
00:46:07,250 --> 00:46:09,470
But if it's both a
hard and a soft work,

999
00:46:09,470 --> 00:46:11,570
they will never switch over.

1000
00:46:11,570 --> 00:46:18,050
But I think the question
is whether old nodes can

1001
00:46:18,050 --> 00:46:20,660
even still function.

1002
00:46:20,660 --> 00:46:24,590
So I think one way
to use combination

1003
00:46:24,590 --> 00:46:27,110
hard and soft works
is to actually stop

1004
00:46:27,110 --> 00:46:31,730
the old nodes from being
able to have blocks at all.

1005
00:46:31,730 --> 00:46:33,590
Like, you design
things in such a way,

1006
00:46:33,590 --> 00:46:37,430
that given a majority of
hash power moves over,

1007
00:46:37,430 --> 00:46:39,572
they're just going to
end up with nothing.

1008
00:46:39,572 --> 00:46:41,030
But this is a really
good question.

1009
00:46:41,030 --> 00:46:42,780
And we should go into
more detail on this.

1010
00:46:42,780 --> 00:46:46,230
And I will try to figure out
a way to get that to you guys.

1011
00:46:46,230 --> 00:46:50,140
OK, so who controls forks?

1012
00:46:54,390 --> 00:46:54,890
Yes?

1013
00:46:58,250 --> 00:46:58,750
Sorry?

1014
00:46:58,750 --> 00:46:59,792
AUDIENCE: The developers.

1015
00:46:59,792 --> 00:47:01,958
NEHA NARULA: OK, the
developers, which I didn't even

1016
00:47:01,958 --> 00:47:03,050
write down as a note here.

1017
00:47:03,050 --> 00:47:06,460
OK, do the Bitcoin
developers control forks?

1018
00:47:06,460 --> 00:47:09,635
Who thinks yes?

1019
00:47:09,635 --> 00:47:12,360
You're not even
raising your hand.

1020
00:47:12,360 --> 00:47:13,090
Who thinks no?

1021
00:47:16,267 --> 00:47:18,600
Determines whether or not a
fork is going to go through.

1022
00:47:18,600 --> 00:47:20,600
There's the Bitcoin
developers, who are actually

1023
00:47:20,600 --> 00:47:22,930
writing the software,
and who also

1024
00:47:22,930 --> 00:47:26,140
have a lot of influence
in the system,

1025
00:47:26,140 --> 00:47:28,360
because presumably they
understand it really well

1026
00:47:28,360 --> 00:47:30,160
if they're writing software.

1027
00:47:30,160 --> 00:47:33,073
So they can write some
software, and decide

1028
00:47:33,073 --> 00:47:34,240
that they want to do a fork.

1029
00:47:34,240 --> 00:47:36,820
Does that mean that the
fork is going to go through?

1030
00:47:36,820 --> 00:47:39,900
No, certainly not,
everyone can ignore them.

1031
00:47:39,900 --> 00:47:41,650
And there have been
situations in the past

1032
00:47:41,650 --> 00:47:43,870
where everyone ignored
them for quite a long time,

1033
00:47:43,870 --> 00:47:46,870
and argued about it, and
didn't push a fork through.

1034
00:47:46,870 --> 00:47:52,000
Well, miners are the ones who
actually create the blocks.

1035
00:47:52,000 --> 00:47:56,280
Are they the ones
who control forks?

1036
00:47:56,280 --> 00:47:57,900
I see a very strong
head shake no.

1037
00:47:57,900 --> 00:48:00,560
Why do you shake your head?

1038
00:48:00,560 --> 00:48:02,050
AUDIENCE: So if
the miners decide

1039
00:48:02,050 --> 00:48:04,500
to change what types of
blocks they're putting out,

1040
00:48:04,500 --> 00:48:05,615
they can do that.

1041
00:48:05,615 --> 00:48:08,000
But the nodes that are
actually validating it,

1042
00:48:08,000 --> 00:48:10,502
no one can say they're
not going to accept it.

1043
00:48:10,502 --> 00:48:11,460
NEHA NARULA: Very true.

1044
00:48:11,460 --> 00:48:15,810
So as we saw before, there
are times when nodes will not

1045
00:48:15,810 --> 00:48:18,420
accept a chain no matter
how much proof of work

1046
00:48:18,420 --> 00:48:19,473
it has on it.

1047
00:48:19,473 --> 00:48:21,390
I think that's a very
common misunderstanding.

1048
00:48:21,390 --> 00:48:24,720
The nodes run their
own validation rules.

1049
00:48:24,720 --> 00:48:28,830
And so if I'm running a
node, I can run whatever

1050
00:48:28,830 --> 00:48:30,450
validation rules I want.

1051
00:48:30,450 --> 00:48:34,050
And I can decide what
chain is the one that

1052
00:48:34,050 --> 00:48:38,250
aligns with my interests.

1053
00:48:38,250 --> 00:48:38,750
Yes?

1054
00:48:41,987 --> 00:48:43,570
AUDIENCE: If you're
doing a hard fork,

1055
00:48:43,570 --> 00:48:45,680
and you are
accepting new blocks,

1056
00:48:45,680 --> 00:48:48,220
and they just never mined any
blocks with those new rules.

1057
00:48:48,220 --> 00:48:49,130
NEHA NARULA: Exactly.

1058
00:48:49,130 --> 00:48:52,220
So there's certainly incentives
in many different directions.

1059
00:48:52,220 --> 00:48:55,832
If all the miners decided
to go to one side,

1060
00:48:55,832 --> 00:48:58,040
then I'm a full node with
my side of validation rules

1061
00:48:58,040 --> 00:48:59,390
who has no new blocks.

1062
00:48:59,390 --> 00:49:01,200
Great, what am I going to do?

1063
00:49:01,200 --> 00:49:03,060
How am I going to
make transactions?

1064
00:49:03,060 --> 00:49:04,670
How am I going to
spend my money?

1065
00:49:04,670 --> 00:49:08,170
Also, let's say all the
miners don't go to one side,

1066
00:49:08,170 --> 00:49:12,350
but most of them do, and most of
the nodes go to the other side.

1067
00:49:12,350 --> 00:49:13,853
Then what am I going to do?

1068
00:49:13,853 --> 00:49:15,020
Who's going to listen to me?

1069
00:49:15,020 --> 00:49:17,020
Who's going to trade with me?

1070
00:49:17,020 --> 00:49:21,610
Who's going to take the
coins on my side of the fork?

1071
00:49:21,610 --> 00:49:26,382
So I guess that's just to
say that it's complicated.

1072
00:49:26,382 --> 00:49:27,340
There's the developers.

1073
00:49:27,340 --> 00:49:28,132
There's the miners.

1074
00:49:28,132 --> 00:49:29,050
There's nodes.

1075
00:49:29,050 --> 00:49:32,070
There's the users who
determine the economic value

1076
00:49:32,070 --> 00:49:33,820
of these tokens, and
which side they think

1077
00:49:33,820 --> 00:49:36,100
is more valuable
or less valuable.

1078
00:49:36,100 --> 00:49:38,432
And we've seen this
happen with lots

1079
00:49:38,432 --> 00:49:39,890
of cryptocurrencies
multiple times.

1080
00:49:39,890 --> 00:49:40,973
And it's kind of exciting.

1081
00:49:40,973 --> 00:49:43,480
So Bitcoin has forked
multiple times.

1082
00:49:43,480 --> 00:49:47,590
And every time
it's forked so far,

1083
00:49:47,590 --> 00:49:50,500
it has created a whole
new version of the coin.

1084
00:49:50,500 --> 00:49:54,642
So it's been like a
pretty serious hard fork.

1085
00:49:54,642 --> 00:49:56,100
And so now, in
addition to Bitcoin,

1086
00:49:56,100 --> 00:50:01,050
there's Bitcoin Cash, Bitcoin
Gold, Bitcoin Diamond.

1087
00:50:01,050 --> 00:50:05,010
Ethereum also has fought.

1088
00:50:05,010 --> 00:50:09,000
In Ethereum's case, they
tried to take along everyone

1089
00:50:09,000 --> 00:50:10,020
with them.

1090
00:50:10,020 --> 00:50:11,490
And so the hard
fork was supposed

1091
00:50:11,490 --> 00:50:13,980
to be an upgrade to Ethereum.

1092
00:50:13,980 --> 00:50:15,450
But some people
decided they didn't

1093
00:50:15,450 --> 00:50:16,980
want to go along with it.

1094
00:50:16,980 --> 00:50:18,315
So there's Ethereum Classic.

1095
00:50:18,315 --> 00:50:19,190
And there's Ethereum.

1096
00:50:23,300 --> 00:50:26,660
Both of them have value.

1097
00:50:26,660 --> 00:50:30,830
So it's really unclear
who controls forks.

1098
00:50:30,830 --> 00:50:34,940
So now, let's talk about
hash rate and forks.

1099
00:50:34,940 --> 00:50:36,980
So nodes are pretty--

1100
00:50:36,980 --> 00:50:41,780
OK, what nodes will do is they
have a set of validation rules.

1101
00:50:41,780 --> 00:50:47,040
If a block validates under
their set of validation rules,

1102
00:50:47,040 --> 00:50:48,390
they will accept it.

1103
00:50:48,390 --> 00:50:52,260
And if all the blocks validate
under their validation rules,

1104
00:50:52,260 --> 00:50:55,500
they will accept the chain
that those blocks are on.

1105
00:50:55,500 --> 00:50:57,720
And if there are two
different chains where

1106
00:50:57,720 --> 00:51:00,450
all the blocks validate
under their validation rules,

1107
00:51:00,450 --> 00:51:03,450
they'll take the one with
the heaviest proof of work.

1108
00:51:03,450 --> 00:51:06,780
That's what nodes do.

1109
00:51:06,780 --> 00:51:09,900
So heaviest proof of work
is clearly kind of important

1110
00:51:09,900 --> 00:51:13,560
here, if both sides
of a fork validate.

1111
00:51:13,560 --> 00:51:16,610
So if both sides of
a fork validate--

1112
00:51:16,610 --> 00:51:20,193
so we have to think about this
from the perspective of nodes

1113
00:51:20,193 --> 00:51:22,110
who upgrade to the new
software, and nodes who

1114
00:51:22,110 --> 00:51:24,300
don't upgrade to new software.

1115
00:51:24,300 --> 00:51:27,362
So it might be worth it
to try to kind of write

1116
00:51:27,362 --> 00:51:28,320
this down a little bit.

1117
00:51:42,300 --> 00:51:49,185
So we have the old rule
nodes, and the new rule nodes.

1118
00:51:53,760 --> 00:51:57,310
And let's just talk about
one kind of work for now.

1119
00:51:57,310 --> 00:52:02,830
Now, let's say less than
50% of the miners upgrade.

1120
00:52:05,430 --> 00:52:13,780
And let's say greater than
50% of the miners upgrade.

1121
00:52:13,780 --> 00:52:16,500
OK, so let's use
this chart, as we're

1122
00:52:16,500 --> 00:52:18,810
kind of trying to
reason about what's

1123
00:52:18,810 --> 00:52:24,420
going to happen in the ecosystem
for soft works and hard works.

1124
00:52:24,420 --> 00:52:30,462
So what happens if a soft fork
does not obtain more than 50%

1125
00:52:30,462 --> 00:52:31,170
of the hash rate?

1126
00:52:33,740 --> 00:52:35,440
So we've got the old rules.

1127
00:52:38,530 --> 00:52:40,488
We've got nodes.

1128
00:52:40,488 --> 00:52:41,530
Some nodes have upgraded.

1129
00:52:41,530 --> 00:52:43,720
Some nodes haven't upgraded.

1130
00:52:43,720 --> 00:52:47,820
Less than 50% of the
miners have upgraded.

1131
00:52:47,820 --> 00:52:50,223
So the old rule chain
is going to be longer,

1132
00:52:50,223 --> 00:52:51,890
because they're going
to continue mining

1133
00:52:51,890 --> 00:52:53,960
on the old rules.

1134
00:52:53,960 --> 00:52:55,877
By the way, sometimes
they don't ignore things

1135
00:52:55,877 --> 00:52:56,668
with the new rules.

1136
00:52:56,668 --> 00:52:57,500
Sometimes they do.

1137
00:52:57,500 --> 00:52:58,417
It's very complicated.

1138
00:52:58,417 --> 00:53:01,100
But let's just pretend right now
that they are ignoring things

1139
00:53:01,100 --> 00:53:02,810
with the new rules, because
they haven't upgraded,

1140
00:53:02,810 --> 00:53:03,810
and they don't see that.

1141
00:53:06,120 --> 00:53:09,270
Or, sorry, they would see
the new rules as valid.

1142
00:53:09,270 --> 00:53:12,150
But the majority of the
hashing power is over here.

1143
00:53:12,150 --> 00:53:13,337
So what's going to happen?

1144
00:53:18,590 --> 00:53:19,110
Yes?

1145
00:53:19,110 --> 00:53:20,527
AUDIENCE: The
benefits of the fork

1146
00:53:20,527 --> 00:53:25,260
aren't going to really be
useful much, because be there'll

1147
00:53:25,260 --> 00:53:29,800
be some blocks
with the new rules.

1148
00:53:29,800 --> 00:53:33,900
But the majority is just
not going to change.

1149
00:53:33,900 --> 00:53:39,300
NEHA NARULA: Right, so it kind
of depends on the soft fork.

1150
00:53:39,300 --> 00:53:44,340
So it depends on what the new
rule nodes think of old blocks.

1151
00:53:44,340 --> 00:53:49,960
If they think that old
blocks are still all valid,

1152
00:53:49,960 --> 00:53:55,270
then they're going to build
upon old blocks just fine,

1153
00:53:55,270 --> 00:53:56,710
because they think
they're valid.

1154
00:53:56,710 --> 00:54:00,200
If they think that old
blocks are no longer valid,

1155
00:54:00,200 --> 00:54:03,460
then they're going to try
to do their own chain.

1156
00:54:06,190 --> 00:54:09,250
But the majority of the hashing
power is with the old side.

1157
00:54:09,250 --> 00:54:12,300
So they're just going
to get reorged out.

1158
00:54:12,300 --> 00:54:12,900
Yes?

1159
00:54:12,900 --> 00:54:15,630
AUDIENCE: If it's a
soft fork, but they also

1160
00:54:15,630 --> 00:54:18,363
think all the blocks are
valid, how is it a fork at all?

1161
00:54:21,763 --> 00:54:23,180
NEHA NARULA: So
an example of this

1162
00:54:23,180 --> 00:54:30,950
is taking what was
an unused op code,

1163
00:54:30,950 --> 00:54:32,870
and now making it meaningful.

1164
00:54:32,870 --> 00:54:37,250
So it just so happens that
none of the old rule nodes

1165
00:54:37,250 --> 00:54:40,580
ever used this silly
unused op code.

1166
00:54:40,580 --> 00:54:42,410
Because they never
used it, they never

1167
00:54:42,410 --> 00:54:46,910
had any invalid
uses of the op code.

1168
00:54:46,910 --> 00:54:52,395
So the new nodes will
still accept old blocks,

1169
00:54:52,395 --> 00:54:54,270
because none of them
use this op code anyway.

1170
00:54:54,270 --> 00:54:57,720
But if they were to
use the new op code,

1171
00:54:57,720 --> 00:55:00,090
and they used it
as a no-op op code,

1172
00:55:00,090 --> 00:55:02,250
instead of what the
new rules are then

1173
00:55:02,250 --> 00:55:03,925
it would be an invalid block.

1174
00:55:03,925 --> 00:55:04,800
Does that make sense?

1175
00:55:07,790 --> 00:55:10,690
So you have to think
really carefully

1176
00:55:10,690 --> 00:55:13,300
about how you are
designing these upgrades

1177
00:55:13,300 --> 00:55:14,500
to your software.

1178
00:55:14,500 --> 00:55:16,112
You have to think
very carefully what

1179
00:55:16,112 --> 00:55:17,320
will happen to the old nodes.

1180
00:55:17,320 --> 00:55:19,540
What happens if 50% of the
miners take this thing?

1181
00:55:19,540 --> 00:55:22,360
Well, under the old rules,
was anyone actually using

1182
00:55:22,360 --> 00:55:24,310
this thing, that we
are now maintaining

1183
00:55:24,310 --> 00:55:26,170
must be used in a new way?

1184
00:55:26,170 --> 00:55:28,800
Or pay to script hash is a
good example of this as well.

1185
00:55:28,800 --> 00:55:31,510
Pay to script hash, technically,
looks like you're just

1186
00:55:31,510 --> 00:55:33,190
paying to a hash.

1187
00:55:33,190 --> 00:55:34,780
So old nodes will
see it, and say, OK,

1188
00:55:34,780 --> 00:55:36,610
if you can produce
a signature that

1189
00:55:36,610 --> 00:55:39,470
shows that this is valid,
blah, blah, whatever, whatever,

1190
00:55:39,470 --> 00:55:40,340
that's fine.

1191
00:55:40,340 --> 00:55:41,950
But nobody ever did that.

1192
00:55:41,950 --> 00:55:45,430
Nobody ever did that
in a way that was

1193
00:55:45,430 --> 00:55:46,930
meaningful under the new rules.

1194
00:55:46,930 --> 00:55:48,100
No one ever used it.

1195
00:55:48,100 --> 00:55:51,490
So all the old things will
still validate, simply

1196
00:55:51,490 --> 00:55:53,260
because no one ever
did anything that

1197
00:55:53,260 --> 00:55:55,510
was under the subset
of the new rules.

1198
00:55:55,510 --> 00:55:57,370
Sorry, this is very
kind of complicated.

1199
00:55:57,370 --> 00:56:03,670
So what we have here is that
if old rule blocks are still

1200
00:56:03,670 --> 00:56:06,130
valid, the software
will get reorged out.

1201
00:56:06,130 --> 00:56:14,350
So no fork there, no fork there.

1202
00:56:14,350 --> 00:56:16,070
You're just not
really going to end up

1203
00:56:16,070 --> 00:56:18,590
with stuff in the blockchain.

1204
00:56:18,590 --> 00:56:23,460
If old rule blocks
are now invalid,

1205
00:56:23,460 --> 00:56:28,050
then we're going to
end up with two chains.

1206
00:56:28,050 --> 00:56:30,050
Do people see why this is?

1207
00:56:30,050 --> 00:56:35,390
Because the new
rule people are not

1208
00:56:35,390 --> 00:56:41,360
going to accept any chain that
has an invalid thing in it.

1209
00:56:41,360 --> 00:56:44,940
So they're not
going to reorg out.

1210
00:56:44,940 --> 00:56:46,580
They are going to continue.

1211
00:56:46,580 --> 00:56:49,220
And they are going to
have their own chain.

1212
00:56:49,220 --> 00:56:52,040
And they're going to
ignore all of the blocks

1213
00:56:52,040 --> 00:56:54,650
on the other chain, which they
deem to be the invalid chain.

1214
00:56:54,650 --> 00:56:55,160
Yes?

1215
00:56:55,160 --> 00:56:57,013
AUDIENCE: Is this the
case for Bitcoin Cash?

1216
00:56:57,013 --> 00:56:59,180
NEHA NARULA: No, it's not
the case for Bitcoin Cash.

1217
00:56:59,180 --> 00:57:01,130
It's actually the
case for something

1218
00:57:01,130 --> 00:57:04,580
called a user-activated
soft fork, which the bitcoin

1219
00:57:04,580 --> 00:57:07,490
community threatened to do
when the miners wouldn't

1220
00:57:07,490 --> 00:57:09,320
do a soft fork they
wanted them to do.

1221
00:57:09,320 --> 00:57:11,900
They said, fine, you miners
won't do the software

1222
00:57:11,900 --> 00:57:13,400
that we want you to do.

1223
00:57:13,400 --> 00:57:16,190
So, normally, people
don't like the situation.

1224
00:57:16,190 --> 00:57:17,750
So you don't want
this to happen.

1225
00:57:17,750 --> 00:57:20,600
So, normally, soft
forks are written such

1226
00:57:20,600 --> 00:57:24,440
that if you don't get 95%
of the miners to sign,

1227
00:57:24,440 --> 00:57:27,002
on the soft fork
never activates.

1228
00:57:27,002 --> 00:57:29,210
So that's the way that,
traditionally, soft works are

1229
00:57:29,210 --> 00:57:30,680
done in the Bitcoin ecosystem.

1230
00:57:30,680 --> 00:57:31,740
What does that mean?

1231
00:57:31,740 --> 00:57:34,790
It means 5.001%
of the hash power

1232
00:57:34,790 --> 00:57:36,590
can stop a soft fork
from going through.

1233
00:57:39,347 --> 00:57:41,180
So usually, things are
written in such a way

1234
00:57:41,180 --> 00:57:43,590
that you really want to
guarantee this two chain

1235
00:57:43,590 --> 00:57:44,780
thing never happens.

1236
00:57:44,780 --> 00:57:47,660
We see hash power
is kind of voting.

1237
00:57:47,660 --> 00:57:49,850
And if you can get
95% of the hash power

1238
00:57:49,850 --> 00:57:52,340
to agree with the soft fork,
then only will the soft fork

1239
00:57:52,340 --> 00:57:53,240
activate.

1240
00:57:53,240 --> 00:57:56,960
And the way that miners do this
is they signal in their block

1241
00:57:56,960 --> 00:58:00,590
headers that they are going
to adopt the soft fork.

1242
00:58:00,590 --> 00:58:03,590
And then the software is
usually programmed in such a way

1243
00:58:03,590 --> 00:58:06,530
that it looks at some sliding
window of block headers

1244
00:58:06,530 --> 00:58:08,515
to determine whether
95% of the hash power

1245
00:58:08,515 --> 00:58:10,640
has decided that they're
going to go along with it.

1246
00:58:10,640 --> 00:58:15,360
And it only activates
once that's the case.

1247
00:58:15,360 --> 00:58:18,100
So doing protocol
upgrades is really hard.

1248
00:58:18,100 --> 00:58:19,290
It's not a trivial matter.

1249
00:58:19,290 --> 00:58:22,200
You don't just push some code.

1250
00:58:22,200 --> 00:58:24,030
So usually, it's
the case that you

1251
00:58:24,030 --> 00:58:28,080
want to wait for a significant
majority of the mining power

1252
00:58:28,080 --> 00:58:30,740
to indicate support
for the soft fork.

1253
00:58:30,740 --> 00:58:32,490
And, by the way, they
can indicate support

1254
00:58:32,490 --> 00:58:34,200
without actually
running the soft fork.

1255
00:58:34,200 --> 00:58:36,330
This happens all the time.

1256
00:58:36,330 --> 00:58:40,410
But you want to wait
for significant support

1257
00:58:40,410 --> 00:58:42,180
from the mining
community before actually

1258
00:58:42,180 --> 00:58:43,830
activating the soft fork.

1259
00:58:43,830 --> 00:58:47,397
What happened recently
with something

1260
00:58:47,397 --> 00:58:49,480
called Segregated Witness,
which we'll talk about,

1261
00:58:49,480 --> 00:58:52,410
which was a soft fork to Bitcoin
to introduce new functionality

1262
00:58:52,410 --> 00:58:56,310
that the miners opposed, was
the community actually said,

1263
00:58:56,310 --> 00:58:57,120
forget it.

1264
00:58:57,120 --> 00:58:59,100
We are going to start
running the new rules.

1265
00:58:59,100 --> 00:59:00,330
We're going to ignore you.

1266
00:59:00,330 --> 00:59:02,810
We don't care what the majority
of the hash power does.

1267
00:59:02,810 --> 00:59:05,970
We are going to go ahead
and create this two chain

1268
00:59:05,970 --> 00:59:09,540
situation, and follow the
chain with the new rules.

1269
00:59:09,540 --> 00:59:14,020
Interestingly, this
actually worked.

1270
00:59:14,020 --> 00:59:16,740
I think it was like 80 plus
percent of the hash power

1271
00:59:16,740 --> 00:59:19,380
was not in favor
of the soft fork.

1272
00:59:19,380 --> 00:59:23,490
And the users managed to create
this kind of detente where they

1273
00:59:23,490 --> 00:59:25,770
forced everyone to go along
with what they wanted,

1274
00:59:25,770 --> 00:59:26,975
super interesting.

1275
00:59:29,610 --> 00:59:32,670
They had no actual way to vote.

1276
00:59:32,670 --> 00:59:36,510
It was entirely
sort of via Twitter.

1277
00:59:36,510 --> 00:59:38,390
AUDIENCE: [INAUDIBLE]

1278
00:59:51,840 --> 00:59:54,090
NEHA NARULA: Yes, so this
is one of the major reasons,

1279
00:59:54,090 --> 00:59:55,882
and I think some of
the strongest evidence,

1280
00:59:55,882 --> 00:59:57,900
that miners have nowhere
near as much power

1281
00:59:57,900 --> 01:00:00,600
as you actually think they
do in these ecosystems.

1282
01:00:00,600 --> 01:00:02,850
Certainly have power, and
part of the power they

1283
01:00:02,850 --> 01:00:06,300
have is to do what's
called an evil soft fork,

1284
01:00:06,300 --> 01:00:08,682
which I'm not going to
talk about in this class,

1285
01:00:08,682 --> 01:00:10,140
but I think we
probably should talk

1286
01:00:10,140 --> 01:00:12,360
about at some point in time.

1287
01:00:12,360 --> 01:00:15,000
OK, great.

1288
01:00:15,000 --> 01:00:15,520
Let's see.

1289
01:00:15,520 --> 01:00:20,740
OK, if the soft fork
is greater than 50%,

1290
01:00:20,740 --> 01:00:26,020
old rule blocks will follow the
new rule blocks automatically.

1291
01:00:26,020 --> 01:00:29,830
So we get soft fork successful.

1292
01:00:29,830 --> 01:00:34,390
We do not have two chains,
because these will simply

1293
01:00:34,390 --> 01:00:36,730
be orphaned and abandoned.

1294
01:00:36,730 --> 01:00:40,360
And, in fact, there's actually
pressure for the miners

1295
01:00:40,360 --> 01:00:43,060
to move over to the new rules
so that their blocks aren't

1296
01:00:43,060 --> 01:00:44,094
abandoned.

1297
01:00:46,880 --> 01:00:48,680
Yes?

1298
01:00:48,680 --> 01:00:54,270
AUDIENCE: So [INAUDIBLE]
making it easier

1299
01:00:54,270 --> 01:00:58,130
mine, are those
considered types of forks?

1300
01:00:58,130 --> 01:00:59,930
NEHA NARULA: It depends.

1301
01:00:59,930 --> 01:01:01,880
So the question is
around difficulty,

1302
01:01:01,880 --> 01:01:04,580
and the number of leading zeros
required in the proof of work.

1303
01:01:04,580 --> 01:01:05,910
That changes all the time.

1304
01:01:05,910 --> 01:01:07,430
There's a formula
which determines

1305
01:01:07,430 --> 01:01:09,500
what that number should be.

1306
01:01:09,500 --> 01:01:11,210
So, no, it doesn't
require a fork.

1307
01:01:11,210 --> 01:01:15,920
But if you want to change the
formula, that would be a fork.

1308
01:01:15,920 --> 01:01:19,687
Requiring more proof of
work would be a soft work.

1309
01:01:19,687 --> 01:01:21,770
Requiring less proof of
work would be a hard fork.

1310
01:01:25,160 --> 01:01:27,110
OK, now let's talk
about hard forks.

1311
01:01:27,110 --> 01:01:30,650
So what happens if
a hard fork doesn't

1312
01:01:30,650 --> 01:01:33,032
obtain 50% of the hash rate?

1313
01:01:38,984 --> 01:01:40,741
AUDIENCE: [INAUDIBLE]

1314
01:01:43,450 --> 01:01:45,660
NEHA NARULA: It depends, again.

1315
01:01:45,660 --> 01:01:50,460
It depends on if the old
rule blocks are still valid.

1316
01:01:50,460 --> 01:01:52,530
So we're doing a hard fork.

1317
01:01:52,530 --> 01:01:56,700
We're changing the
set of valid blocks.

1318
01:01:56,700 --> 01:02:01,200
If blocks are still valid
under the old rules,

1319
01:02:01,200 --> 01:02:05,790
then we're going to end up
with a situation like this.

1320
01:02:05,790 --> 01:02:07,920
If old rule blocks
are still valid

1321
01:02:07,920 --> 01:02:10,800
according to the new rule
nodes, then the new rule nodes

1322
01:02:10,800 --> 01:02:12,020
will just follow along.

1323
01:02:12,020 --> 01:02:17,880
OK, so basically no
work happening here,

1324
01:02:17,880 --> 01:02:22,940
because the new rule nodes
are going to produce blocks.

1325
01:02:22,940 --> 01:02:26,790
They're not going to have
enough of the hash power.

1326
01:02:26,790 --> 01:02:31,950
And so they're not going
to be considered valid

1327
01:02:31,950 --> 01:02:33,750
by the other set.

1328
01:02:33,750 --> 01:02:37,770
So they're going
to end up following

1329
01:02:37,770 --> 01:02:40,590
along with the old rule nodes.

1330
01:02:40,590 --> 01:02:41,152
Yes?

1331
01:02:41,152 --> 01:02:43,360
AUDIENCE: Again, isn't the
whole point of a hard fork

1332
01:02:43,360 --> 01:02:47,090
that you're expanding the
set of things that are valid?

1333
01:02:47,090 --> 01:02:51,498
So aren't all old blocks going
to be valid in a hard fork?

1334
01:02:51,498 --> 01:02:53,540
NEHA NARULA: Not if it's
a combination hard fork,

1335
01:02:53,540 --> 01:02:54,040
soft fork.

1336
01:02:54,040 --> 01:02:56,075
So maybe I should
split this up into

1337
01:02:56,075 --> 01:02:57,450
whether or not
it's a combination

1338
01:02:57,450 --> 01:02:59,160
hard fork, soft fork, or not.

1339
01:02:59,160 --> 01:03:02,820
OK, so what happens if a hard
fork doesn't obtain greater

1340
01:03:02,820 --> 01:03:05,463
than 50% of the hash rate?

1341
01:03:05,463 --> 01:03:06,630
What's going to happen then?

1342
01:03:12,606 --> 01:03:15,600
AUDIENCE: We'll be
mining to the old rules.

1343
01:03:15,600 --> 01:03:18,570
NEHA NARULA: Yes, we're going
to end up with two chains.

1344
01:03:18,570 --> 01:03:21,978
This is going to have chain--

1345
01:03:21,978 --> 01:03:23,520
whatever, the point
is, there's going

1346
01:03:23,520 --> 01:03:26,040
to be an old chain
and a new chain.

1347
01:03:26,040 --> 01:03:32,590
The old nodes are never going
to accept the new nodes blocks.

1348
01:03:32,590 --> 01:03:37,940
And we're going to end up
with two chains forever.

1349
01:03:37,940 --> 01:03:40,490
And this has happened
multiple times.

1350
01:03:43,290 --> 01:03:45,840
Are there questions
about hard forks?

1351
01:03:50,790 --> 01:03:51,700
Yes?

1352
01:03:51,700 --> 01:03:53,992
AUDIENCE: Are there ways for
the hard fork to make life

1353
01:03:53,992 --> 01:03:57,757
really difficult for
the smaller chain?

1354
01:03:57,757 --> 01:04:00,090
NEHA NARULA: Are there ways
for a hard work to make life

1355
01:04:00,090 --> 01:04:02,250
really difficult for
the smaller chain?

1356
01:04:02,250 --> 01:04:03,450
That is a good question.

1357
01:04:03,450 --> 01:04:04,385
I think it depends.

1358
01:04:08,840 --> 01:04:11,180
So there's multiple ways
to make life difficult.

1359
01:04:11,180 --> 01:04:14,220
I think what you're
asking is not,

1360
01:04:14,220 --> 01:04:17,085
what if the hard fork becomes
more popular and more people

1361
01:04:17,085 --> 01:04:19,460
decide to move over to it,
and abandon the smaller chain?

1362
01:04:19,460 --> 01:04:22,279
That's one way in which life
could be more difficult.

1363
01:04:22,279 --> 01:04:24,590
But another way that life
could be more difficult

1364
01:04:24,590 --> 01:04:29,690
is if the hard fork somehow made
the previous chain no longer

1365
01:04:29,690 --> 01:04:33,240
a productive chain to be on.

1366
01:04:33,240 --> 01:04:37,760
And I think that the primary
way that that would happen

1367
01:04:37,760 --> 01:04:39,680
would not actually
be a hard fork,

1368
01:04:39,680 --> 01:04:42,860
but would be a combination
hard fork, soft fork.

1369
01:04:42,860 --> 01:04:46,430
But there are definitely
ways for miners

1370
01:04:46,430 --> 01:04:51,410
to play with hard forks and soft
forks in such a way that-- see,

1371
01:04:51,410 --> 01:04:54,260
this is actually kind
of ideal in some ways.

1372
01:04:54,260 --> 01:04:58,182
This is like, OK, we disagree
on what the rules should be.

1373
01:04:58,182 --> 01:04:59,390
I want some new set of rules.

1374
01:04:59,390 --> 01:05:01,220
You don't want some
new set of rules.

1375
01:05:01,220 --> 01:05:03,380
Fine, let's just
split the ecosystem.

1376
01:05:03,380 --> 01:05:05,330
You guys go your way.

1377
01:05:05,330 --> 01:05:06,500
I'll go my way.

1378
01:05:06,500 --> 01:05:08,570
We'll have two different coins.

1379
01:05:08,570 --> 01:05:10,670
Life will be great.

1380
01:05:10,670 --> 01:05:13,100
What's kind of not
so nice is when

1381
01:05:13,100 --> 01:05:17,240
one side tries to coerce
the other side to go along,

1382
01:05:17,240 --> 01:05:20,810
which is kind of what a
greater than 50% soft fork is.

1383
01:05:20,810 --> 01:05:22,820
You're kind of
coercing the other side

1384
01:05:22,820 --> 01:05:28,270
to go along, because they
have no way of opting out.

1385
01:05:28,270 --> 01:05:33,610
And there are ways that miners
can make the side of the chain

1386
01:05:33,610 --> 01:05:37,420
with less harsh power
basically useless.

1387
01:05:40,270 --> 01:05:42,190
This is totally
something miners can do.

1388
01:05:42,190 --> 01:05:44,020
People talk about
it occasionally.

1389
01:05:44,020 --> 01:05:45,970
It just doesn't seem
like they figured out

1390
01:05:45,970 --> 01:05:48,338
that they can do it, or
they haven't tried to do it.

1391
01:05:48,338 --> 01:05:48,880
I don't know.

1392
01:05:48,880 --> 01:05:49,750
Maybe they don't want to do it.

1393
01:05:49,750 --> 01:05:50,350
I'm not sure.

1394
01:05:50,350 --> 01:05:52,613
It would be pretty
disruptive to the ecosystem.

1395
01:05:56,320 --> 01:06:00,610
OK, so question-- we've
talked about what happens here

1396
01:06:00,610 --> 01:06:02,620
from the perspective
of full nodes,

1397
01:06:02,620 --> 01:06:05,230
and from the
perspective of miners.

1398
01:06:05,230 --> 01:06:07,120
What happens from the
perspective of people

1399
01:06:07,120 --> 01:06:09,170
with wallets who
might be running SPV?

1400
01:06:14,122 --> 01:06:14,830
What do we think?

1401
01:06:17,770 --> 01:06:21,950
Depends on which node
they're connected to.

1402
01:06:21,950 --> 01:06:27,750
So one problem with SPV is
that they don't actually

1403
01:06:27,750 --> 01:06:29,880
get the blocks.

1404
01:06:29,880 --> 01:06:32,340
So they don't actually
validate blocks.

1405
01:06:32,340 --> 01:06:36,060
All they validate
is proof of work.

1406
01:06:36,060 --> 01:06:38,310
Some changes that
make a block invalid

1407
01:06:38,310 --> 01:06:41,940
might show up in the header.

1408
01:06:41,940 --> 01:06:44,880
But a lot of changes that
might make a block invalid,

1409
01:06:44,880 --> 01:06:49,184
or new blocks valid, don't
show up in the header.

1410
01:06:52,140 --> 01:06:55,680
So given what we've learned
about how SPV works,

1411
01:06:55,680 --> 01:06:59,750
what happens when
there's a fork?

1412
01:06:59,750 --> 01:07:03,710
So let's go back and take a
look at what SPV wallets see.

1413
01:07:03,710 --> 01:07:04,880
They see the block headers.

1414
01:07:04,880 --> 01:07:06,770
You have to download
all the headers, which

1415
01:07:06,770 --> 01:07:10,340
includes the nines
for the proof of work,

1416
01:07:10,340 --> 01:07:12,620
the Merkle root for the
transaction, timestamp,

1417
01:07:12,620 --> 01:07:13,910
stuff like that.

1418
01:07:13,910 --> 01:07:16,820
They also get Merkle
paths for the transactions

1419
01:07:16,820 --> 01:07:19,880
that they've told the node
they're interested in.

1420
01:07:23,010 --> 01:07:25,950
So what would happen if there
were a soft work or hard fork?

1421
01:07:25,950 --> 01:07:28,035
What would happen to an SPV?

1422
01:07:33,840 --> 01:07:36,430
They don't really have
a say in the situation.

1423
01:07:36,430 --> 01:07:39,570
They aren't really
participating in validation.

1424
01:07:39,570 --> 01:07:42,270
They're not
participating in mining.

1425
01:07:42,270 --> 01:07:45,240
And they're kind of at
the mercy of whatever

1426
01:07:45,240 --> 01:07:48,900
node that they are talking to.

1427
01:07:48,900 --> 01:07:51,120
And, in fact, if they try
to talk to multiple nodes,

1428
01:07:51,120 --> 01:07:53,220
they might get multiple
different answers.

1429
01:07:53,220 --> 01:07:57,279
And they don't really know which
answer is the right answer.

1430
01:07:57,279 --> 01:08:01,180
And this could get really
tricky and complicated.

1431
01:08:01,180 --> 01:08:03,570
Now, I think probably
it's fair to say

1432
01:08:03,570 --> 01:08:07,140
that the majority of the Bitcoin
ecosystem, in terms of users,

1433
01:08:07,140 --> 01:08:10,590
actually does not run
their own full nodes.

1434
01:08:10,590 --> 01:08:13,590
They interact with
the Bitcoin network,

1435
01:08:13,590 --> 01:08:17,220
at best, through SPV, and
at worst through a trusted

1436
01:08:17,220 --> 01:08:19,740
third party like Coinbase.

1437
01:08:19,740 --> 01:08:24,600
So what does the ecosystem
have to say or do about

1438
01:08:24,600 --> 01:08:27,300
whether or not forks are
accepted or not accepted?

1439
01:08:35,920 --> 01:08:36,420
Yeah?

1440
01:08:36,420 --> 01:08:37,880
AUDIENCE: They don't
really have to.

1441
01:08:37,880 --> 01:08:39,630
NEHA NARULA: They don't
really have a say.

1442
01:08:39,630 --> 01:08:44,000
They kind of I would say at
like a meta level, in that users

1443
01:08:44,000 --> 01:08:48,559
can pressure Coinbase to start
following Bitcoin Cash which

1444
01:08:48,559 --> 01:08:50,660
is a hard fork of bitcoin.

1445
01:08:50,660 --> 01:08:54,080
They kind of have a say
at an economic level,

1446
01:08:54,080 --> 01:08:58,160
in that if Coinbase starts
accepting Bitcoin Cash,

1447
01:08:58,160 --> 01:09:00,140
then the price of
Bitcoin Cash will go up.

1448
01:09:00,140 --> 01:09:02,040
And so that's kind
of a big deal.

1449
01:09:02,040 --> 01:09:04,130
But in terms of like
a protocol level,

1450
01:09:04,130 --> 01:09:09,290
in terms of accepting or
rejecting transactions,

1451
01:09:09,290 --> 01:09:11,450
they don't really have
a say because they

1452
01:09:11,450 --> 01:09:17,165
can't see enough to
determine whether or not

1453
01:09:17,165 --> 01:09:19,790
they're interested in following
a fork or not following a fork.

1454
01:09:19,790 --> 01:09:22,010
In fact, it's even
worse than that.

1455
01:09:22,010 --> 01:09:23,510
There were multiple
situations where

1456
01:09:23,510 --> 01:09:25,880
we ended up with two chains.

1457
01:09:25,880 --> 01:09:29,899
So an SPV wallet might think
that they received money

1458
01:09:29,899 --> 01:09:32,270
on one chain, and they
didn't receive money

1459
01:09:32,270 --> 01:09:34,840
on the other chain.

1460
01:09:34,840 --> 01:09:41,200
So very bad things can happen
to wallets and to SPV clients

1461
01:09:41,200 --> 01:09:42,160
during a fork.

1462
01:09:42,160 --> 01:09:45,309
And it's incredibly disruptive.

1463
01:09:45,309 --> 01:09:50,240
And people who create software
on the behalf of users--

1464
01:09:50,240 --> 01:09:52,359
so not even running SPV,
but like the Coinbase's

1465
01:09:52,359 --> 01:09:54,950
of the world, and the
exchanges of the world--

1466
01:09:54,950 --> 01:09:57,130
they have to do a
fair amount of work

1467
01:09:57,130 --> 01:10:02,770
to make sure that they aren't
going to lose users' money when

1468
01:10:02,770 --> 01:10:03,850
there's a fork.

1469
01:10:03,850 --> 01:10:07,900
And the exchanges, and the
Coinbase's of the world,

1470
01:10:07,900 --> 01:10:09,840
have screwed this
up in the past.

1471
01:10:09,840 --> 01:10:13,330
There's been money lost.

1472
01:10:13,330 --> 01:10:16,420
There are ways to
safely design your fork

1473
01:10:16,420 --> 01:10:18,850
so that it's less
likely that wallets

1474
01:10:18,850 --> 01:10:21,970
will do the wrong thing.

1475
01:10:21,970 --> 01:10:24,400
But I think we're kind
of just figuring out how

1476
01:10:24,400 --> 01:10:26,260
to really do that effectively.

1477
01:10:26,260 --> 01:10:28,055
AUDIENCE: [INAUDIBLE]

1478
01:10:37,780 --> 01:10:40,270
NEHA NARULA: Yeah, so this
is kind of pretty bad,

1479
01:10:40,270 --> 01:10:42,970
because if Bitcoin
is really going

1480
01:10:42,970 --> 01:10:44,480
to undergo a hard
fork or soft fork,

1481
01:10:44,480 --> 01:10:45,730
everybody is paying attention.

1482
01:10:45,730 --> 01:10:48,188
If Ethereum is going to do it,
everyone's paying attention.

1483
01:10:48,188 --> 01:10:50,110
But there's so many
altcoins out there.

1484
01:10:50,110 --> 01:10:52,720
And, yeah, there's
so much opportunity

1485
01:10:52,720 --> 01:10:55,030
for people to take advantage
of the disarray that

1486
01:10:55,030 --> 01:10:57,340
happens when a fork happens.

1487
01:10:57,340 --> 01:11:00,940
So I think we're right in the
middle of trying to figure out

1488
01:11:00,940 --> 01:11:06,880
best practices for handling
forks safely, and also,

1489
01:11:06,880 --> 01:11:11,260
giving users some way of
choosing what side of a fork

1490
01:11:11,260 --> 01:11:16,150
that they want, because
there's this sort of thought

1491
01:11:16,150 --> 01:11:21,340
that eventually there will
be economic pressure to--

1492
01:11:21,340 --> 01:11:25,360
for a long time, people thought
that if Bitcoin hard forked,

1493
01:11:25,360 --> 01:11:28,750
one side would win, and the
other side would go to zero.

1494
01:11:28,750 --> 01:11:32,050
And now, we've seen that
that is absolutely not true.

1495
01:11:32,050 --> 01:11:34,570
In fact, when
Bitcoin hard forked,

1496
01:11:34,570 --> 01:11:38,410
sometimes the total market cap
of one side plus the other side

1497
01:11:38,410 --> 01:11:41,440
is bigger than the total market
cap of what Bitcoin used to be.

1498
01:11:41,440 --> 01:11:44,140
So money is literally
created out of nowhere.

1499
01:11:44,140 --> 01:11:46,780
So hard forking
is very lucrative.

1500
01:11:46,780 --> 01:11:49,880
It literally gives every
Bitcoin user more money.

1501
01:11:49,880 --> 01:11:53,440
So if you own Bitcoin
within the past--

1502
01:11:53,440 --> 01:11:55,570
like, if you owned
Bitcoin a year ago,

1503
01:11:55,570 --> 01:11:58,628
you probably have like
four other coins right now.

1504
01:11:58,628 --> 01:11:59,170
I don't know.

1505
01:11:59,170 --> 01:12:01,293
You should go sell them,
or sell the Bitcoin,

1506
01:12:01,293 --> 01:12:03,460
and buy the other coins,
or whatever you want to do.

1507
01:12:03,460 --> 01:12:05,080
But the point is,
you have more money

1508
01:12:05,080 --> 01:12:07,160
than you might have
even known that you had,

1509
01:12:07,160 --> 01:12:09,309
because someone has
done these forks.

1510
01:12:09,309 --> 01:12:11,320
Don't even like get
started about the tax

1511
01:12:11,320 --> 01:12:12,390
consequences of this.

1512
01:12:12,390 --> 01:12:14,552
It's very confusing,
extraordinarily confusing.

1513
01:12:14,552 --> 01:12:16,510
And people are trying to
figure out what to do,

1514
01:12:16,510 --> 01:12:18,530
because you didn't
ask for this fork.

1515
01:12:18,530 --> 01:12:20,590
Like, I as a holder
of Bitcoin, didn't

1516
01:12:20,590 --> 01:12:24,370
decide that I wanted
Bitcoin Cash to be a thing.

1517
01:12:24,370 --> 01:12:26,500
I didn't accept Bitcoin Cash.

1518
01:12:26,500 --> 01:12:29,710
But now, the same private keys I
used to control my Bitcoin also

1519
01:12:29,710 --> 01:12:32,340
control the same
amount of Bitcoin Cash.

1520
01:12:32,340 --> 01:12:33,430
It's kind of crazy.

1521
01:12:33,430 --> 01:12:35,559
Let's talk about
forks in practice.

1522
01:12:35,559 --> 01:12:37,052
So soft forks in
practice-- there

1523
01:12:37,052 --> 01:12:38,260
have been lots of soft forks.

1524
01:12:38,260 --> 01:12:39,340
Soft forks are very useful.

1525
01:12:39,340 --> 01:12:40,340
Soft forks are helpful.

1526
01:12:40,340 --> 01:12:42,652
This is the major way that
people upgrade software.

1527
01:12:42,652 --> 01:12:44,110
And, again, the
way that they do it

1528
01:12:44,110 --> 01:12:46,870
is they try to make sure
95%, or some huge majority

1529
01:12:46,870 --> 01:12:48,130
of the miners, are on board.

1530
01:12:48,130 --> 01:12:50,740
And that way, it's sort
of like as non-disruptive

1531
01:12:50,740 --> 01:12:52,880
to the ecosystem as possible.

1532
01:12:52,880 --> 01:12:55,830
So pay to script
has was a soft fork.

1533
01:12:55,830 --> 01:12:57,830
The introduction of
Segwit was a soft fork.

1534
01:12:57,830 --> 01:12:59,740
In operation, check
sequence verify

1535
01:12:59,740 --> 01:13:02,150
was added as a soft fork.

1536
01:13:02,150 --> 01:13:04,750
So that's kind of why they're
all these like unused ops

1537
01:13:04,750 --> 01:13:05,680
out there.

1538
01:13:05,680 --> 01:13:09,820
In case we want to use one
of them for something new,

1539
01:13:09,820 --> 01:13:12,760
we can do that with a soft fork.

1540
01:13:12,760 --> 01:13:15,340
Hard forks in practice--

1541
01:13:15,340 --> 01:13:19,370
there's lots of new Bitcoins,
Bitcoin Cash, Gold, Diamond,

1542
01:13:19,370 --> 01:13:20,500
like I said.

1543
01:13:20,500 --> 01:13:23,582
Ethereum went through a
really interesting hard fork.

1544
01:13:23,582 --> 01:13:25,540
And there's some
cryptocurrencies that actually

1545
01:13:25,540 --> 01:13:27,445
hard fork quite frequently.

1546
01:13:27,445 --> 01:13:29,320
For instance, I learned
the Monero hard forks

1547
01:13:29,320 --> 01:13:30,330
about every six months.

1548
01:13:30,330 --> 01:13:33,120
Vertcoin, how many hard
forks have you guys done?

1549
01:13:33,120 --> 01:13:33,840
Three?

1550
01:13:33,840 --> 01:13:35,350
Three hard forks.

1551
01:13:35,350 --> 01:13:39,640
So, despite the way that
I said that hard forks are

1552
01:13:39,640 --> 01:13:44,620
very disruptive, if you can
get all the nodes to upgrade,

1553
01:13:44,620 --> 01:13:46,150
it's not really a big problem.

1554
01:13:46,150 --> 01:13:48,850
So for cryptocurrencies where
the nodes are really well

1555
01:13:48,850 --> 01:13:52,180
connected, or they auto
update, or things like that,

1556
01:13:52,180 --> 01:13:55,540
hard forks are much
less disruptive.

1557
01:13:55,540 --> 01:13:59,540
So let's talk about the
Ethereum hard fork for a moment.

1558
01:13:59,540 --> 01:14:03,640
So this happened two years ago--

1559
01:14:03,640 --> 01:14:04,335
a year ago?

1560
01:14:04,335 --> 01:14:06,460
I can't remember when this
happened, two years ago,

1561
01:14:06,460 --> 01:14:08,800
I think, almost.

1562
01:14:08,800 --> 01:14:11,148
And so what happened
was we haven't

1563
01:14:11,148 --> 01:14:12,690
talked a lot about
Ethereum, so we'll

1564
01:14:12,690 --> 01:14:15,110
be coming to explain Ethereum
in much greater detail.

1565
01:14:15,110 --> 01:14:18,220
But the point is Ethereum
had a smart contract

1566
01:14:18,220 --> 01:14:19,280
which had a bug in it.

1567
01:14:22,510 --> 01:14:26,920
And someone hacked the contract,
and started siphoning off ether

1568
01:14:26,920 --> 01:14:28,900
from the contract.

1569
01:14:28,900 --> 01:14:32,450
So the Ethereum team all
got together, and decided,

1570
01:14:32,450 --> 01:14:34,950
we're going to
rectify this wrong.

1571
01:14:34,950 --> 01:14:36,103
Now, rectifying the wrong--

1572
01:14:36,103 --> 01:14:37,770
I mean, I already
said it's a hard fork.

1573
01:14:37,770 --> 01:14:44,250
But why is rectifying this wrong
a hard fork not a soft fork?

1574
01:14:44,250 --> 01:14:47,110
AUDIENCE: Because you
want to change history.

1575
01:14:47,110 --> 01:14:49,620
NEHA NARULA: Because you
want to change history.

1576
01:14:49,620 --> 01:14:51,690
That's an interesting
way of putting it.

1577
01:14:51,690 --> 01:14:53,160
And the way that
we change history

1578
01:14:53,160 --> 01:14:56,490
is not by actually going back
in time and editing history,

1579
01:14:56,490 --> 01:14:58,290
unless you are
Accenture I guess,

1580
01:14:58,290 --> 01:15:00,090
which creates
editable blockchains.

1581
01:15:00,090 --> 01:15:02,160
But the way that
we edit history,

1582
01:15:02,160 --> 01:15:05,130
is we add something to
the blockchain which

1583
01:15:05,130 --> 01:15:08,760
indicates that we're going to
undo, or change, or rollback

1584
01:15:08,760 --> 01:15:12,360
or somehow create
an operation, that

1585
01:15:12,360 --> 01:15:14,100
does something that
effectively undoes

1586
01:15:14,100 --> 01:15:15,390
what happened in the past.

1587
01:15:20,330 --> 01:15:22,309
So the Ethereum
developer got together.

1588
01:15:22,309 --> 01:15:26,210
And they originally tried to do
this as a soft fork, actually.

1589
01:15:26,210 --> 01:15:28,640
So it could have
been a soft fork.

1590
01:15:28,640 --> 01:15:30,680
And the way that the soft
work would have worked

1591
01:15:30,680 --> 01:15:32,900
is that it just
would have ignored

1592
01:15:32,900 --> 01:15:39,045
all of the transactions
that were sort of--

1593
01:15:39,045 --> 01:15:40,670
I can't remember
exactly how it worked.

1594
01:15:40,670 --> 01:15:42,950
But, basically, the
general idea was, ignore

1595
01:15:42,950 --> 01:15:48,440
all of the transactions that
might spend the hacker's money.

1596
01:15:48,440 --> 01:15:52,070
Ignore the transaction
where people gave money

1597
01:15:52,070 --> 01:15:55,670
to the hacker, what ultimately
became the hacker, which

1598
01:15:55,670 --> 01:15:56,960
is a new rule.

1599
01:15:56,960 --> 01:15:59,300
Now, you're shrinking the
set of acceptable blocks.

1600
01:15:59,300 --> 01:16:01,160
And the problem
was they realized

1601
01:16:01,160 --> 01:16:03,680
that if they did this
as a soft fork, then

1602
01:16:03,680 --> 01:16:06,740
they were inadvertently
creating an attack

1603
01:16:06,740 --> 01:16:11,030
vector, because people
could now spam the network

1604
01:16:11,030 --> 01:16:13,670
and potentially waste the
resources of the miners--

1605
01:16:13,670 --> 01:16:16,160
very challenging to do soft
forks and hard forks correctly.

1606
01:16:16,160 --> 01:16:17,750
So they decided,
OK, you know what?

1607
01:16:17,750 --> 01:16:20,180
We're just going to
do it as a hard fork.

1608
01:16:20,180 --> 01:16:25,230
When this block comes
about, block 1,920,000,

1609
01:16:25,230 --> 01:16:29,840
we are going to simply
transfer around 12 million

1610
01:16:29,840 --> 01:16:35,152
either from the hacker's
account into this other account,

1611
01:16:35,152 --> 01:16:37,610
this other contract, which is
going to give the money back,

1612
01:16:37,610 --> 01:16:40,630
where people can
reclaim their money.

1613
01:16:40,630 --> 01:16:45,070
So literally just
hardcoded in this transfer.

1614
01:16:45,070 --> 01:16:50,620
85% of the hash power in
Ethereum went along with it.

1615
01:16:50,620 --> 01:16:53,080
So that means 15% didn't.

1616
01:16:53,080 --> 01:16:55,420
And that means that there
are two currencies now.

1617
01:16:55,420 --> 01:16:58,390
There is Ethereum,
and Ethereum Classic.

1618
01:16:58,390 --> 01:17:01,900
And they persist to this
day, almost two years later.

1619
01:17:01,900 --> 01:17:05,230
And when I looked this
morning, it was about a 30 to 1

1620
01:17:05,230 --> 01:17:08,020
ratio between Ethereum
and Ethereum Classic.

1621
01:17:08,020 --> 01:17:08,910
Yes?

1622
01:17:08,910 --> 01:17:10,368
AUDIENCE: So Ethereum
Classic says,

1623
01:17:10,368 --> 01:17:13,422
we are not OK with you
guys undoing this hack.

1624
01:17:13,422 --> 01:17:15,130
NEHA NARULA: Exactly,
so Ethereum Classic

1625
01:17:15,130 --> 01:17:17,800
says, we're not messing with
people's accounts like that.

1626
01:17:17,800 --> 01:17:19,180
No, no, no.

1627
01:17:19,180 --> 01:17:21,370
What happened happened,
fair and square.

1628
01:17:21,370 --> 01:17:24,340
We are not changing history.

1629
01:17:24,340 --> 01:17:27,277
And so in Ethereum Classic,
the hacker has money.

1630
01:17:27,277 --> 01:17:29,110
On Ethereum, the hacker
does not have money.

1631
01:17:31,940 --> 01:17:32,623
Yes?

1632
01:17:32,623 --> 01:17:37,390
AUDIENCE: [INAUDIBLE]
one specific contract.

1633
01:17:37,390 --> 01:17:40,750
So the argument is we shouldn't
be fixing people's mistakes.

1634
01:17:40,750 --> 01:17:42,630
They should learn--

1635
01:17:42,630 --> 01:17:45,480
Was this analogous
to the Parity?

1636
01:17:45,480 --> 01:17:47,900
NEHA NARULA: Yes.

1637
01:17:47,900 --> 01:17:50,570
So here they decided,
there was a bug

1638
01:17:50,570 --> 01:17:52,220
in someone's smart contract.

1639
01:17:52,220 --> 01:17:53,517
It was exploited.

1640
01:17:53,517 --> 01:17:55,350
We're going to give
people their money back.

1641
01:17:55,350 --> 01:17:57,680
This happened again
with a different type

1642
01:17:57,680 --> 01:18:01,160
of smart contract in a different
way a couple months ago.

1643
01:18:01,160 --> 01:18:05,570
And they decided-- well, they
could still decide to do it.

1644
01:18:05,570 --> 01:18:08,390
But so far, they decided not
to give everyone's money back.

1645
01:18:08,390 --> 01:18:10,520
So there's about 90 million
or something dollars

1646
01:18:10,520 --> 01:18:13,820
worth of ether that's locked
up in these contracts,

1647
01:18:13,820 --> 01:18:15,500
due to a bug.

1648
01:18:15,500 --> 01:18:18,410
And in the case of the DAO,
they decided, let's do it.

1649
01:18:18,410 --> 01:18:23,610
In the case of this Parity bug,
they decided, let's not do it.

1650
01:18:23,610 --> 01:18:26,570
And if you talk to the
Ethereum Foundation people,

1651
01:18:26,570 --> 01:18:28,160
they'll talk about governance.

1652
01:18:28,160 --> 01:18:30,980
And they'll say, well, we
feel like this made sense

1653
01:18:30,980 --> 01:18:31,790
for these reasons.

1654
01:18:31,790 --> 01:18:33,707
But this doesn't make
sense for these reasons.

1655
01:18:33,707 --> 01:18:35,867
But it's still it's
a set of people

1656
01:18:35,867 --> 01:18:37,700
getting together and
deciding whether or not

1657
01:18:37,700 --> 01:18:38,559
to give money back.

1658
01:18:38,559 --> 01:18:40,850
Yeah?

1659
01:18:40,850 --> 01:18:41,980
AUDIENCE: [INAUDIBLE]

1660
01:18:44,747 --> 01:18:46,830
NEHA NARULA: No, it's not
the Ethereum Foundation.

1661
01:18:46,830 --> 01:18:49,220
The Ethereum Foundation was
not a fan of Ethereum Classic.

1662
01:18:49,220 --> 01:18:50,270
It's a separate group of people.

1663
01:18:50,270 --> 01:18:51,200
AUDIENCE: [INAUDIBLE]

1664
01:18:52,700 --> 01:18:55,535
NEHA NARULA: No, actually,
so it turned out,

1665
01:18:55,535 --> 01:18:57,410
interestingly enough--
and this was something

1666
01:18:57,410 --> 01:18:59,750
that I saw at a
conference that looked

1667
01:18:59,750 --> 01:19:01,688
into who were the
contributors to all

1668
01:19:01,688 --> 01:19:03,230
of these different
forks, when trying

1669
01:19:03,230 --> 01:19:04,190
to understand governance?

1670
01:19:04,190 --> 01:19:06,315
It actually turns out that
no one from the Ethereum

1671
01:19:06,315 --> 01:19:08,210
Foundation works on
Ethereum Classic.

1672
01:19:08,210 --> 01:19:10,250
And no one who used
to work on Bitcoin

1673
01:19:10,250 --> 01:19:12,860
works on Bitcoin Cash,
Gold, or Diamond.

1674
01:19:12,860 --> 01:19:15,180
So it's entirely
new sets of people.

1675
01:19:15,180 --> 01:19:15,680
Yes?

1676
01:19:15,680 --> 01:19:18,680
AUDIENCE: The former lead
developer of Bitcoin core

1677
01:19:18,680 --> 01:19:21,490
is working on Bitcoin Cash.

1678
01:19:21,490 --> 01:19:23,120
NEHA NARULA: He's not actually.

1679
01:19:23,120 --> 01:19:25,250
You're talking about
Gavin Andreessen?

1680
01:19:25,250 --> 01:19:28,443
Yeah, I don't think he actually
makes commits to Bitcoin Cash.

1681
01:19:28,443 --> 01:19:30,260
AUDIENCE: In a
general sense, he's

1682
01:19:30,260 --> 01:19:32,530
contributing on GitHub,
not specifically

1683
01:19:32,530 --> 01:19:33,980
to any implementations.

1684
01:19:33,980 --> 01:19:37,648
But to protocol,
block-level exchanges.

1685
01:19:37,648 --> 01:19:38,690
NEHA NARULA: Interesting.

1686
01:19:38,690 --> 01:19:39,200
Yes?

1687
01:19:39,200 --> 01:19:40,190
AUDIENCE: [INAUDIBLE]

1688
01:19:44,983 --> 01:19:46,400
NEHA NARULA: It
depends on how you

1689
01:19:46,400 --> 01:19:48,050
define contribute, certainly.

1690
01:19:48,050 --> 01:19:51,260
This is a really interesting
example of a hard fork.

1691
01:19:51,260 --> 01:19:54,500
In summary, just
to wrap up here,

1692
01:19:54,500 --> 01:19:56,510
forks are extremely challenging.

1693
01:19:56,510 --> 01:20:00,620
Upgrading software in
decentralized cryptocurrencies

1694
01:20:00,620 --> 01:20:03,030
is extremely challenging.

1695
01:20:03,030 --> 01:20:05,510
And so the lesson that I want
you to take from this is,

1696
01:20:05,510 --> 01:20:08,210
unless you need what a
decentralized cryptocurrency

1697
01:20:08,210 --> 01:20:12,530
has to offer, you will probably
be better off not using

1698
01:20:12,530 --> 01:20:13,890
a decentralized cryptocurrency.

1699
01:20:13,890 --> 01:20:15,140
They are very hard to update.

1700
01:20:15,140 --> 01:20:16,580
They're very hard to upgrade.

1701
01:20:16,580 --> 01:20:18,680
There are frequently bugs.

1702
01:20:18,680 --> 01:20:22,490
And so I think that forks and
the challenges around forks

1703
01:20:22,490 --> 01:20:28,880
are an excellent reason not to
do this when you don't have to.

1704
01:20:28,880 --> 01:20:31,160
And also, what's really
interesting, I think,

1705
01:20:31,160 --> 01:20:35,059
is that your traditional
consensus systems

1706
01:20:35,059 --> 01:20:37,130
don't address this
problem at all,

1707
01:20:37,130 --> 01:20:40,160
because your traditional
distributed consensus

1708
01:20:40,160 --> 01:20:42,740
systems don't have any
notion of what nodes

1709
01:20:42,740 --> 01:20:44,390
are going to find
valid, or not valid,

1710
01:20:44,390 --> 01:20:46,045
or changing the
rules of validity.

1711
01:20:46,045 --> 01:20:47,420
And so these
problems really only

1712
01:20:47,420 --> 01:20:50,090
arise when you start
to have these validity

1713
01:20:50,090 --> 01:20:52,070
rules that you're
dealing with, and you

1714
01:20:52,070 --> 01:20:53,952
have nodes that might
take one set of rules,

1715
01:20:53,952 --> 01:20:55,910
and nodes that might take
another set of rules.

1716
01:20:55,910 --> 01:20:58,460
The consensus mechanism
here ultimately

1717
01:20:58,460 --> 01:21:01,580
becomes irrelevant if you
don't agree with the validity

1718
01:21:01,580 --> 01:21:02,210
of the blocks.

1719
01:21:02,210 --> 01:21:05,270
It doesn't matter that
a majority of hash power

1720
01:21:05,270 --> 01:21:07,120
said that this is
the blockchain.

1721
01:21:07,120 --> 01:21:08,870
It doesn't matter if
a majority of signers

1722
01:21:08,870 --> 01:21:10,052
say this is the blockchain.

1723
01:21:10,052 --> 01:21:12,260
If you don't agree that the
things in that blockchain

1724
01:21:12,260 --> 01:21:14,030
are valid, you're
going to ignore that.

1725
01:21:14,030 --> 01:21:14,990
Majority be damned.

1726
01:21:14,990 --> 01:21:19,270
So it's very different
than distributed consensus.

1727
01:21:19,270 --> 01:21:22,059
Okay, and so real quick,
last thing...

1728
01:21:22,059 --> 01:21:26,200
on Wednesday we will have another guest
lecturer. Her name is Sharon Goldberg.

1729
01:21:26,200 --> 01:21:29,080
She's a professor at Boston University
and she's worked on a lot of really

1730
01:21:29,080 --> 01:21:32,590
interesting things. In particular,
something really cool that she's worked

1731
01:21:32,590 --> 01:21:37,840
on is using the peer-to-peer network to
create attacks in Bitcoin, and then very

1732
01:21:37,840 --> 01:21:41,800
recently she nor co-authors released a
paper on peer-to-peer network attacks in

1733
01:21:41,800 --> 01:21:44,920
Ethereum. And so she's gonna be here
to talk about the peer-to-peer networks

1734
01:21:44,920 --> 01:21:51,000
behind these things and to share some of
the research that she's done.