1
00:00:01,260 --> 00:00:06,090
So finally we'll talk about some built in
limitations to the Bitcoin protocol and

2
00:00:06,090 --> 00:00:08,310
why it's challenging to
actually improve them.

3
00:00:08,310 --> 00:00:12,400
There are a lot of hard-coded constants
that are implemented into the Bitcoin

4
00:00:12,400 --> 00:00:17,780
protocol, which were chosen when
Bitcoin was proposed in 2009, before

5
00:00:17,780 --> 00:00:21,939
we really had any idea that it might grow
into this globally important currency.

6
00:00:23,500 --> 00:00:27,980
So the most important limits are probably
the limits on the average time per block.

7
00:00:27,980 --> 00:00:29,880
The size of blocks.

8
00:00:29,880 --> 00:00:32,900
The number of signature
operations in a block and

9
00:00:32,900 --> 00:00:34,530
the divisibility of the currency.

10
00:00:35,660 --> 00:00:39,170
The limitations on the total number
of Bitcoins in existence as well as

11
00:00:39,170 --> 00:00:43,340
the structure of the mining rewards
are very likely to never be changed

12
00:00:43,340 --> 00:00:46,930
because the economic implications
of changing them are too great.

13
00:00:46,930 --> 00:00:51,030
Miners have invested a lot of real-world
resources into becoming miners

14
00:00:51,030 --> 00:00:55,100
assuming that Bitcoin rewards
would take a certain shape and

15
00:00:55,100 --> 00:01:00,540
that the limited supply of Bitcoins
would remain the way its been planned.

16
00:01:00,540 --> 00:01:04,520
So if you change that, that would have
large financial implications for people.

17
00:01:05,640 --> 00:01:09,670
So for that reason the community has
basically agreed that those values,

18
00:01:09,670 --> 00:01:12,830
whether or not they were wisely
chosen we're basically stuck with.

19
00:01:13,840 --> 00:01:18,410
Some other changes you'd like to make seem
like they would make everybody better off,

20
00:01:18,410 --> 00:01:22,400
things about Bitcoin that just weren't
quite properly designed at the beginning.

21
00:01:22,400 --> 00:01:24,260
But are also hard to change.

22
00:01:24,260 --> 00:01:28,010
The main aspect of Bitcoin that
people are worried about, and

23
00:01:28,010 --> 00:01:32,000
would probably like to change if they
had time to design it over again,

24
00:01:32,000 --> 00:01:34,840
are limits that effect
the throughput of this system.

25
00:01:34,840 --> 00:01:38,020
How many transactions can the Bitcoin
network process per second.

26
00:01:39,860 --> 00:01:43,360
So this limitation comes from the hard
coded limit on the size of blocks.

27
00:01:43,360 --> 00:01:45,309
Each block is limited to a million bytes.

28
00:01:46,880 --> 00:01:51,220
And each transaction has to be at least
250 bytes so if you divide through and

29
00:01:51,220 --> 00:01:54,675
the fact that blocks are found every
10 minutes, you're left with about

30
00:01:54,675 --> 00:01:58,130
7 transactions per second which is all
that the Bitcoin network can handle.

31
00:01:59,230 --> 00:02:02,090
And it seems like tweaking those
numbers would be very easy,

32
00:02:02,090 --> 00:02:05,090
it's just one constant in a file
somewhere that you'd have to change.

33
00:02:05,090 --> 00:02:08,100
It would actually be very hard
to change this in practice, for

34
00:02:08,100 --> 00:02:11,250
reasons that will become
clear in a few seconds.

35
00:02:11,250 --> 00:02:14,450
So how does 7 transactions
per second compare?

36
00:02:14,450 --> 00:02:16,840
Well, if you went down to
the offices of Visa and

37
00:02:16,840 --> 00:02:19,910
told them I'm proposing a new
payment system that can handle 7

38
00:02:19,910 --> 00:02:23,670
transactions per second, they would
probably tell you that's terrible, and

39
00:02:23,670 --> 00:02:25,920
then they would laugh and
throw you out the door.

40
00:02:25,920 --> 00:02:26,710
They've been working for

41
00:02:26,710 --> 00:02:31,760
a long time to build a payment network
that goes way bigger than this.

42
00:02:31,760 --> 00:02:34,340
So it's said that Visa handles,
on average,

43
00:02:34,340 --> 00:02:37,820
about 2,000 transactions per
second around the world.

44
00:02:37,820 --> 00:02:41,080
And the busiest time, so
think the Saturday before Christmas when

45
00:02:41,080 --> 00:02:44,240
everybody's out shopping and
swiping a credit card.

46
00:02:44,240 --> 00:02:48,360
The Visa network can handle about
10,000 transactions per second.

47
00:02:48,360 --> 00:02:51,280
And other payment card
networks are similarly big.

48
00:02:51,280 --> 00:02:54,961
You can also look at PayPal,
which is not as big or as old as Visa, but

49
00:02:54,961 --> 00:02:58,903
even PayPal can handle 100 transactions
per second at peak times, so

50
00:02:58,903 --> 00:03:01,177
in order of magnitude more than Bitcoin.

51
00:03:03,662 --> 00:03:06,766
Another limitation that people
are worried about in the long term is

52
00:03:06,766 --> 00:03:09,240
that the cryptography in Bitcoin is fixed.

53
00:03:09,240 --> 00:03:14,080
There's only a couple of hash algorithms
and there's only one signature algorithm

54
00:03:14,080 --> 00:03:19,600
which is Elliptic Curve DSA over
a specific elliptic curve called SECP256.

55
00:03:21,060 --> 00:03:24,160
And there's some concern that over
the lifetime of Bitcoin which people would

56
00:03:24,160 --> 00:03:27,900
like to be for a long time,
this algorithm might be broken.

57
00:03:27,900 --> 00:03:31,680
Cryptographers might come up with a clever
new attack that we haven't foreseen which

58
00:03:31,680 --> 00:03:33,120
makes this an insecure algorithm.

59
00:03:33,120 --> 00:03:35,970
And the same is true
of the hash functions.

60
00:03:35,970 --> 00:03:38,480
Hash functions in the last
decade have actually seen

61
00:03:38,480 --> 00:03:43,440
steady progress in cryptanalysis with
SHA-1 which is included in the Bitcoin

62
00:03:43,440 --> 00:03:46,370
already having some known
cryptographic weaknesses.

63
00:03:46,370 --> 00:03:50,069
So to change this, we would have to extend
the Bitcoin scripting language to support

64
00:03:50,069 --> 00:03:51,539
new cryptographic algorithms.

65
00:03:53,943 --> 00:03:57,371
So what would it look like to make
a change like this, where we just said,

66
00:03:57,371 --> 00:03:58,777
we had a problem in Bitcoin and

67
00:03:58,777 --> 00:04:01,730
we're going to release the new
version of the software.

68
00:04:01,730 --> 00:04:03,329
And everybody is going to have to switch.

69
00:04:04,560 --> 00:04:06,870
This is what we would call
a hard-forking change.

70
00:04:08,530 --> 00:04:13,210
So in practice, it's impossible to
assume that every node would upgrade.

71
00:04:13,210 --> 00:04:16,560
Some nodes in the network would fail
to get the new software, [COUGH] or

72
00:04:16,560 --> 00:04:17,500
fail to get it in time.

73
00:04:17,500 --> 00:04:19,860
And what would be
the implications of that?

74
00:04:21,300 --> 00:04:24,870
Well, let's take a look at a network here
where most of the nodes have upgraded, but

75
00:04:24,870 --> 00:04:25,890
there are a few that haven't.

76
00:04:25,890 --> 00:04:29,900
And now let's say one of
the new nodes says, hey,

77
00:04:29,900 --> 00:04:31,910
I found this nifty great new block.

78
00:04:31,910 --> 00:04:36,030
Maybe it has some new signature
algorithm in one of the transactions

79
00:04:36,030 --> 00:04:38,988
using the new features that
we've added to Bitcoin.

80
00:04:38,988 --> 00:04:43,190
So block 4 has found this and
says, okay I'm going to update and

81
00:04:43,190 --> 00:04:44,630
say that's now the newest block.

82
00:04:44,630 --> 00:04:49,273
So I'm at block index 24,
the rest of the network is at 23.

83
00:04:49,273 --> 00:04:52,430
But I'm going to propagate
that to all of my peers

84
00:04:52,430 --> 00:04:54,820
using the normal block-flooding algorithm.

85
00:04:56,950 --> 00:05:01,900
So node 4 is going to send block 24
out to it's neighbors, nodes 3 and 2.

86
00:05:01,900 --> 00:05:05,460
Node 3 is going to get it and
say great, I got that one.

87
00:05:05,460 --> 00:05:09,840
I'll update my version of the block
chain to have that as the newest block.

88
00:05:09,840 --> 00:05:12,910
Whereas node 2 is going to say,
that's crazy.

89
00:05:12,910 --> 00:05:16,480
You have some operation code
that's disabled or reserved.

90
00:05:16,480 --> 00:05:17,660
I have to reject this block.

91
00:05:17,660 --> 00:05:20,462
I don't understand it, I can't accept it.

92
00:05:21,625 --> 00:05:25,673
And similarly when it gets over to node 6,
node 6 is also going to say,

93
00:05:25,673 --> 00:05:27,970
nope I can't accept that block either.

94
00:05:29,720 --> 00:05:33,450
And now your going to end up in a state
where the new nodes have one picture of

95
00:05:33,450 --> 00:05:38,930
the block chain and the old nodes have
all refused to accept this latest block.

96
00:05:38,930 --> 00:05:42,300
So the new nodes will go off and
work on a version of the block chain,

97
00:05:42,300 --> 00:05:44,950
including this new block
with the new fancy feature.

98
00:05:46,170 --> 00:05:50,190
And the old nodes will all be stuck
on an old version of the block chain.

99
00:05:50,190 --> 00:05:53,650
And unfortunately, they're never going to
catch up because until they upgrade their

100
00:05:53,650 --> 00:05:58,960
software, they'll keep rejecting all of
the blocks that are proposed by the nodes

101
00:05:58,960 --> 00:06:02,330
in the network that have upgraded
to the new version of the protocol.

102
00:06:03,920 --> 00:06:08,300
So the reason it's called a hard fork
is that the block chain will split,

103
00:06:08,300 --> 00:06:10,860
every node in the network will
be on one side of it based on

104
00:06:10,860 --> 00:06:15,170
which version of the protocol it's running
and they'll never join together again.

105
00:06:16,850 --> 00:06:21,140
And this is considered unacceptable by the
community that old nodes would effectively

106
00:06:21,140 --> 00:06:24,739
be cut out of the Bitcoin network if
they don't upgrade their software.

107
00:06:26,886 --> 00:06:31,054
So by contrast there's
an approach called soft forking,

108
00:06:31,054 --> 00:06:36,030
which tries to avoid creating
a permanent fork like this.

109
00:06:36,030 --> 00:06:40,570
The observation is that we can add
new features to the Bitcoin protocol

110
00:06:40,570 --> 00:06:44,850
if they only restrict the set of valid
transactions or the set of valid blocks.

111
00:06:45,890 --> 00:06:48,310
Because we want to avoid
this hard fork situation,

112
00:06:48,310 --> 00:06:51,880
we can try to add new features in a way
that would cause only a soft fork.

113
00:06:53,420 --> 00:06:57,420
So the key to making this happen is
that the new features can only make

114
00:06:57,420 --> 00:06:59,150
validation rules stricter.

115
00:06:59,150 --> 00:07:01,220
They can only limit of
the set of blocks or

116
00:07:01,220 --> 00:07:03,370
the set of transactions
that are considered valid.

117
00:07:04,400 --> 00:07:08,620
So the new nodes in the network will be
enforcing some new tighter set of rules.

118
00:07:08,620 --> 00:07:11,700
So we're relying on enough nodes
switching to the new version

119
00:07:11,700 --> 00:07:14,780
of the protocol that they'll be
able to enforce the new rules.

120
00:07:14,780 --> 00:07:17,811
Knowing that the old nodes wont
be able to enforce the new rules,

121
00:07:17,811 --> 00:07:19,562
because they haven't heard of them yet.

122
00:07:21,803 --> 00:07:26,753
There is a risk here, which is that old
nodes might be mining an invalid block,

123
00:07:26,753 --> 00:07:30,954
because they include some transaction
which used to be valid, but

124
00:07:30,954 --> 00:07:35,099
according to the new, more strict rules,
is not valid anymore.

125
00:07:36,800 --> 00:07:37,630
So that could be bad.

126
00:07:37,630 --> 00:07:40,390
Those nodes could waste a lot of
time mining a block that the new

127
00:07:40,390 --> 00:07:42,150
nodes will reject.

128
00:07:42,150 --> 00:07:45,510
But when they try to announce that new
block, the new nodes will reject it,

129
00:07:45,510 --> 00:07:49,610
the old nodes will at least figure out
that for some reason, even though I don't

130
00:07:49,610 --> 00:07:53,529
understand the reason, the rest of
the network has rejected my new block.

131
00:07:54,590 --> 00:07:58,692
Therefore, I should move on to the version
of the block chain that all of my peers

132
00:07:58,692 --> 00:08:00,980
have and it won't be a hard fork.

133
00:08:00,980 --> 00:08:05,530
They'll have a temporary fork by virtue of
the new block they tried to mine that was

134
00:08:05,530 --> 00:08:09,680
rejected by the network but they'll
recover and get back on to the main chain.

135
00:08:12,190 --> 00:08:14,860
So the classic example of
a change that was made

136
00:08:14,860 --> 00:08:17,260
via soft fork was pay to script hash.

137
00:08:17,260 --> 00:08:21,040
Which we introduced earlier in the section
discussing the scripting language.

138
00:08:22,660 --> 00:08:27,490
So the view of beta script
hash from old nodes and again

139
00:08:27,490 --> 00:08:31,980
pay to script hash was not present in
the first version of the Bitcoin protocol.

140
00:08:31,980 --> 00:08:34,290
They see the script as really simple.

141
00:08:34,290 --> 00:08:37,630
All it's doing is hashing
this one data value and

142
00:08:37,630 --> 00:08:41,680
checking to see if it's equal to
the value specified in the output script.

143
00:08:41,680 --> 00:08:46,718
The old nodes never do that second step
of verification in pay to script hash,

144
00:08:46,718 --> 00:08:51,292
where they then check to see that that
value before being hashed runs as

145
00:08:51,292 --> 00:08:52,396
a valid script.

146
00:08:55,263 --> 00:08:57,840
So what could we possibly
add with a soft fork?

147
00:08:58,930 --> 00:09:01,600
Pay to script hash was successful.

148
00:09:01,600 --> 00:09:06,900
It's also possible that new cryptographic
schemes could be added by a soft fork or

149
00:09:06,900 --> 00:09:11,800
that we could add some extra meta data
in blocks that had some meaning and

150
00:09:11,800 --> 00:09:14,840
the place you'd add this is
in the coin base parameter.

151
00:09:14,840 --> 00:09:19,420
So, today any value is accepted in
the coinbase parameter but we could in

152
00:09:19,420 --> 00:09:22,740
the future say that the coinbase
has to have some specific example.

153
00:09:23,870 --> 00:09:26,690
One idea that's been proposed
is that in each new block

154
00:09:26,690 --> 00:09:31,720
coinbase contains Merkle root of
the entire set of unspent transactions.

155
00:09:31,720 --> 00:09:36,230
It would only result in
a soft fork because old nodes

156
00:09:36,230 --> 00:09:39,925
might mine a block that didn't have the
required new coin base parameter that got

157
00:09:39,925 --> 00:09:41,620
rejected by the network, but

158
00:09:41,620 --> 00:09:45,350
they would catch up and join the main
chain that the network is mining.

159
00:09:47,400 --> 00:09:49,500
Other changes might require a hard fork.

160
00:09:49,500 --> 00:09:52,660
That would be if we wanted to
add new op codes to Bitcoin.

161
00:09:52,660 --> 00:09:58,000
Change the limits on block or
transaction size or do a lot of bug fixes.

162
00:09:58,000 --> 00:10:01,985
So for example the bug I showed earlier
where the multisig instruction pops

163
00:10:01,985 --> 00:10:06,680
an extra value off the stack that
would actually require a hard fork.

164
00:10:06,680 --> 00:10:10,310
And that's the reason why even though it's
an annoying bug that people wish wasn't

165
00:10:10,310 --> 00:10:14,360
there anymore, it's much easier to
just leave the bug in the protocol and

166
00:10:14,360 --> 00:10:18,670
have people work around it, rather than
have a hard fork change to Bitcoin.

167
00:10:20,180 --> 00:10:24,280
So, all of these hard forking changes,
even though they would be nice,

168
00:10:24,280 --> 00:10:27,780
are very unlikely to happen, at least
within the current climate of Bitcoin.

169
00:10:29,740 --> 00:10:34,060
But a lot of these ideas have been
tested out and proved to be successful.

170
00:10:34,060 --> 00:10:37,180
And alternative currencies,
which start over from scratch.

171
00:10:37,180 --> 00:10:40,870
And we'll be talking about those in
a lot more detail in our lecture on all

172
00:10:40,870 --> 00:10:41,550
Altcoins.

173
00:10:42,830 --> 00:10:45,190
So I spent a lot of time
talking about details today.

174
00:10:45,190 --> 00:10:49,270
I know this has been a long lecture
with a lot of technical detail.

175
00:10:49,270 --> 00:10:51,372
Very hard to absorb it all at once so

176
00:10:51,372 --> 00:10:54,996
like I said I would certainly
recommend you can go online and

177
00:10:54,996 --> 00:10:59,870
see some of this stuff and practice see
what blocks and transactions look like.

178
00:10:59,870 --> 00:11:03,714
It took me a couple of times looking at
them before I really had a good sense of

179
00:11:03,714 --> 00:11:07,209
what was going on but I think
the practical examples do really help.

180
00:11:08,970 --> 00:11:12,030
In the next lecture, given all
these mechanics we've introduced,

181
00:11:12,030 --> 00:11:14,690
we're going to look at
the human side of things.

182
00:11:14,690 --> 00:11:17,260
because after all,
human beings aren't Bitcoin nodes, and

183
00:11:17,260 --> 00:11:21,490
you're never going to run a Bitcoin node
in your head, so how do you as a human

184
00:11:21,490 --> 00:11:25,260
actually interact with this network
to get it to be usable as a currency?

185
00:11:25,260 --> 00:11:27,670
How do you find a node to
tell about your transaction?

186
00:11:27,670 --> 00:11:30,380
How do you get Bitcoins in exchange for
cash?

187
00:11:30,380 --> 00:11:32,550
How do you store your Bitcoins?

188
00:11:32,550 --> 00:11:34,470
So all of these questions are crucial for

189
00:11:34,470 --> 00:11:38,490
making a currency that will actually work
for people, as opposed to just software.