1
00:00:00,310 --> 00:00:03,010
Welcome to the third lecture
in our series on Bitcoin.

2
00:00:03,010 --> 00:00:06,210
This lecture is going to be
all about the mechanics of

3
00:00:06,210 --> 00:00:08,270
Bitcoin at a fairly low level.

4
00:00:08,270 --> 00:00:11,320
So whereas in the first two lectures,
we've talked at a relatively high level,

5
00:00:11,320 --> 00:00:16,090
in this lecture, we're going to be trying
to give it to you as real as possible.

6
00:00:16,090 --> 00:00:19,020
So we'll look at real data structures,

7
00:00:19,020 --> 00:00:23,590
real scripts, try to learn the details
in language of Bitcoin in a precise way

8
00:00:23,590 --> 00:00:28,140
to set up everything that we want to talk
about for the remainder of the course.

9
00:00:28,140 --> 00:00:30,880
So in some ways,
this will be the most challenging lecture,

10
00:00:30,880 --> 00:00:33,080
because a lot of details
are going to be flying at you.

11
00:00:35,220 --> 00:00:38,520
It's also one of the most real, where
you're really learning the specifics and

12
00:00:38,520 --> 00:00:40,760
the quirks that make Bitcoin what it is.

13
00:00:42,260 --> 00:00:44,640
So to recap where we left off last time,

14
00:00:45,720 --> 00:00:50,190
the Bitcoin consensus mechanism
gives us an append-only ledger.

15
00:00:50,190 --> 00:00:53,740
So a data structure that we can only
write to and once data is written,

16
00:00:53,740 --> 00:00:54,540
it's there forever.

17
00:00:55,600 --> 00:00:57,610
And there's a decentralized protocol for

18
00:00:57,610 --> 00:01:00,270
establishing consensus about
the value of that ledger.

19
00:01:01,870 --> 00:01:05,670
And the miners who perform that protocol
are validating transactions, so

20
00:01:05,670 --> 00:01:07,764
making sure that transactions
are well-formed,

21
00:01:07,764 --> 00:01:11,640
that there aren't double spends and that
this thing can function as a currency.

22
00:01:13,340 --> 00:01:14,320
Although it's kind of funny,

23
00:01:14,320 --> 00:01:18,940
because we assume that a currency
existed to motivate these miners.

24
00:01:18,940 --> 00:01:21,890
So in this lecture, we'll be looking
at the details of how we actually

25
00:01:21,890 --> 00:01:24,892
build that currency to make the miners
make this whole process happen.

26
00:01:24,892 --> 00:01:29,572
[MUSIC]

27
00:01:29,572 --> 00:01:32,605
All right, so we'll start by
looking at transactions in Bitcoin.

28
00:01:32,605 --> 00:01:35,195
Transactions are really
the fundamental building

29
00:01:35,195 --> 00:01:38,105
block which the whole currency
is going to be based on.

30
00:01:38,105 --> 00:01:40,675
So remember we have this ledger.

31
00:01:40,675 --> 00:01:45,595
The ledger is append-only, so as time goes
on we just add more and more units to it.

32
00:01:45,595 --> 00:01:50,185
We're going to take a simplified model
here, where instead of having blocks,

33
00:01:50,185 --> 00:01:54,520
we just have individual transactions
being added to the ledger one at a time.

34
00:01:54,520 --> 00:01:56,420
So how can we build a currency this way?

35
00:01:57,490 --> 00:01:59,310
So the first model you might think of,

36
00:01:59,310 --> 00:02:03,360
which is actually a lot of people's
mental model for how Bitcoin works,

37
00:02:03,360 --> 00:02:07,920
that we'll look at first,
is that you have an account-based system.

38
00:02:07,920 --> 00:02:10,620
So you can add some transactions
that create new coins and

39
00:02:10,620 --> 00:02:11,600
credit them to somebody.

40
00:02:11,600 --> 00:02:15,610
And then later you can transfer them,
and you just have the transaction that

41
00:02:15,610 --> 00:02:19,080
would say,
we're moving 17 coins from Alice to Bob.

42
00:02:19,080 --> 00:02:21,770
That will be signed by Alice
to authorize the transaction,

43
00:02:21,770 --> 00:02:24,390
and that's all the information
that would be contained.

44
00:02:25,870 --> 00:02:30,410
Now backing this up, there would be some
state that says that after Alice received

45
00:02:30,410 --> 00:02:35,030
25 coins in the first transaction, and
then transferred 17 coins to Bob in

46
00:02:35,030 --> 00:02:39,034
the second transaction, Alice would have
an account that is left with 8 Bitcoins.

47
00:02:40,080 --> 00:02:42,520
So, now after that transfer
from Alice to Bob,

48
00:02:42,520 --> 00:02:44,570
we can add some more
transactions to the ledger.

49
00:02:44,570 --> 00:02:47,190
We'll say that Bob pays
some Bitcoins to Charlie,

50
00:02:47,190 --> 00:02:52,090
Charlie pays some coins to Alice,
and at this point, each participant,

51
00:02:52,090 --> 00:02:54,890
Alice, Bob, and Charlie has an account
with a different value in it, and

52
00:02:54,890 --> 00:02:58,110
those values are going to mutate
each time we add a new transaction.

53
00:03:00,270 --> 00:03:04,560
Now the downside of this system, if we
add a new transaction at the bottom here,

54
00:03:04,560 --> 00:03:06,950
is that we have to remember
what the account balance is for

55
00:03:06,950 --> 00:03:11,400
each participant to figure out if
this transaction is valid or not.

56
00:03:11,400 --> 00:03:15,109
Does Alice have the 15 coins that she's
trying to transfer to David here?

57
00:03:16,390 --> 00:03:20,220
So sure enough,
looking at this just with your naked eye,

58
00:03:20,220 --> 00:03:24,290
it's fairly hard to tell,
to do the mental arithmetic to figure

59
00:03:24,290 --> 00:03:27,740
out if Alice has enough money
to transfer to David here.

60
00:03:27,740 --> 00:03:32,310
And in fact, to figure this out, you'd
have to look backwards in time forever to

61
00:03:32,310 --> 00:03:37,310
see every transaction affecting Alice and
whether or not her net balance at the time

62
00:03:37,310 --> 00:03:42,660
that she tries to transfer 15 coins
to David is greater than 15 coins.

63
00:03:42,660 --> 00:03:46,480
Okay, so to tell if this transaction
is valid or not, we have to figure out

64
00:03:46,480 --> 00:03:51,060
whether or not Alice has the 15 coins
that she's trying to transfer to David.

65
00:03:51,060 --> 00:03:53,830
And to figure that out,
we might have to look backwards

66
00:03:53,830 --> 00:03:58,750
forever to the beginning of time at every
transaction that's ever involved Alice.

67
00:03:58,750 --> 00:04:00,890
Every time Alice has sent or
received coins,

68
00:04:00,890 --> 00:04:04,510
we need to find all of those
transactions and add them up,

69
00:04:04,510 --> 00:04:07,960
to see if she really has the 15 coins
that she is trying to transfer to David.

70
00:04:07,960 --> 00:04:11,080
And of course, we can make this
a little bit more efficient with some

71
00:04:11,080 --> 00:04:15,288
data structures that track Alice's
balance after each transaction.

72
00:04:15,288 --> 00:04:17,950
But that's going to require a lot of extra

73
00:04:17,950 --> 00:04:20,150
housekeeping besides
the block chain itself.

74
00:04:21,170 --> 00:04:25,920
And that's why Bitcoin isn't based on
an account-based model, like this.

75
00:04:25,920 --> 00:04:30,610
Instead, Bitcoin uses a ledger that
just keeps track of transactions.

76
00:04:30,610 --> 00:04:31,770
So, how does that work?

77
00:04:31,770 --> 00:04:35,050
So, this is a transaction-based ledger,
which is very close to Bitcoin.

78
00:04:36,680 --> 00:04:41,930
So now, transactions explicitly specify a
number of inputs and a number of outputs.

79
00:04:41,930 --> 00:04:44,940
And transactions also each
have a unique identifier.

80
00:04:44,940 --> 00:04:48,820
So we'll start with transaction 1,
which has no inputs, because this is

81
00:04:48,820 --> 00:04:52,880
new currency being created, and
an output of 25 coins going to Alice.

82
00:04:52,880 --> 00:04:57,950
And again, since this is a transaction

83
00:04:57,950 --> 00:05:01,359
where new coins are being created,
there's no signature required here.

84
00:05:02,380 --> 00:05:06,500
Now, let's say that Alice wants to
send some of those coins over to Bob.

85
00:05:07,620 --> 00:05:12,080
Well, now she has to explicitly refer to
the previous transaction where these coins

86
00:05:12,080 --> 00:05:13,700
were coming from.

87
00:05:13,700 --> 00:05:20,870
So the input to this transaction will
be output index 0 from transaction 1,

88
00:05:20,870 --> 00:05:25,260
which we can see from the very
previous transaction in the log,

89
00:05:26,370 --> 00:05:29,310
was a transaction that
assigned 25 Bitcoins to Alice.

90
00:05:29,310 --> 00:05:33,660
And now there are two
outputs of this transaction.

91
00:05:33,660 --> 00:05:37,380
One of them is 17 coins to Bob, and
one of them is 8 coins to Alice.

92
00:05:37,380 --> 00:05:42,100
And of course this whole
thing is signed by Alice so

93
00:05:42,100 --> 00:05:44,680
that we know that Alice actually
wants to do this transaction.

94
00:05:45,800 --> 00:05:49,270
And now you might ask, why does Alice
have to send money to herself here?

95
00:05:50,500 --> 00:05:54,410
She's taken the 25 coins that were
assigned to her in transaction 1,

96
00:05:54,410 --> 00:05:59,500
she only wanted to pay 17 to Bob, and
she has to have a new output where

97
00:05:59,500 --> 00:06:03,970
8 coins are sent back to herself, possibly
to a different key, but to herself.

98
00:06:05,420 --> 00:06:09,030
So this is what's called a change address,
and the design here is that you

99
00:06:09,030 --> 00:06:13,310
always completely consume the output
of a previous transaction.

100
00:06:13,310 --> 00:06:17,860
So there's no way to say I only need
17 coins from that previous output.

101
00:06:17,860 --> 00:06:22,450
You have to say I'm using all 25
coins from the previous output, but,

102
00:06:22,450 --> 00:06:26,200
since you want to keep some, you just
have a second output that sends some of

103
00:06:26,200 --> 00:06:29,670
the coins back to yourself,
which is called a change address.

104
00:06:32,960 --> 00:06:37,510
Now, let's say that we keep going
with this system and now we add a new

105
00:06:37,510 --> 00:06:42,360
transaction and we ask ourselves again,
is this new transaction valid?

106
00:06:42,360 --> 00:06:46,170
Now, it's much easier to look at
the block chain and figure out whether or

107
00:06:46,170 --> 00:06:50,390
not this transaction is valid, because
we know exactly which input to look at.

108
00:06:50,390 --> 00:06:53,222
So we just need to go to transaction 2,
output 1, and

109
00:06:53,222 --> 00:06:57,360
verify that there's enough money there and
that it hasn't been sent already.

110
00:06:58,940 --> 00:07:02,720
And of course we can look back and
say yes,

111
00:07:02,720 --> 00:07:07,880
that second output of transaction
2 went to Alice with 8 coins.

112
00:07:07,880 --> 00:07:10,910
Therefore it's enough to cover
the outputs of this transaction.

113
00:07:12,800 --> 00:07:15,550
It's a finite backward scan to check for
the validity.

114
00:07:17,320 --> 00:07:19,830
And we implement this with hash pointers.

115
00:07:19,830 --> 00:07:22,310
So, again,
each transaction has a unique ID.

116
00:07:22,310 --> 00:07:25,100
In reality,
they're not serial numbers like this.

117
00:07:25,100 --> 00:07:26,910
It's the hash of the block.

118
00:07:26,910 --> 00:07:30,490
And each transaction actually
gets its specific ID as well,

119
00:07:30,490 --> 00:07:32,090
which is the hash of the transaction.

120
00:07:34,350 --> 00:07:37,750
And now it's basically just following
one pointer to figure out whether or

121
00:07:37,750 --> 00:07:41,610
not there's enough money to cover the
desired outputs in the new transaction.

122
00:07:43,220 --> 00:07:46,540
Now conceptually, you can say maybe
this isn't that much different than just

123
00:07:46,540 --> 00:07:49,780
maintaining a separate data structure,
which tracked account values for

124
00:07:49,780 --> 00:07:50,990
each person.

125
00:07:50,990 --> 00:07:54,440
But the nice thing is that now
this data structure is embedded

126
00:07:54,440 --> 00:07:56,270
within the data in the block chain itself.

127
00:07:58,790 --> 00:08:01,020
So some other things that we
could do quite easily here.

128
00:08:01,020 --> 00:08:02,170
We can merge value.

129
00:08:03,220 --> 00:08:06,350
So let's say there's two different
transactions that send some money to Bob.

130
00:08:06,350 --> 00:08:11,540
17 coins in transaction 1,
and 2 coins in transaction 2.

131
00:08:11,540 --> 00:08:15,630
Bob might say I'd like to have one
transaction I can spend later where I have

132
00:08:15,630 --> 00:08:16,250
all 19 coins.

133
00:08:16,250 --> 00:08:18,900
So this is pretty easy.

134
00:08:18,900 --> 00:08:23,780
You just create a new transaction that
has two inputs now, and only one output,

135
00:08:23,780 --> 00:08:27,810
so all of those coins go to Bob, and
you've combined the two previous

136
00:08:27,810 --> 00:08:30,750
transactions into one that
Bob can then spend later.

137
00:08:32,640 --> 00:08:35,110
Similarly, we can do joint
payments pretty easily.

138
00:08:36,560 --> 00:08:40,500
So let's say that Carol and
Bob both want to pay David.

139
00:08:40,500 --> 00:08:43,360
We can have a transaction with two
inputs that are actually owned by two

140
00:08:43,360 --> 00:08:48,020
different people, and combine the value
and pay all 8 coins to David.

141
00:08:49,390 --> 00:08:53,130
And the only extra thing here is that,
since the two

142
00:08:53,130 --> 00:08:56,020
outputs that are being claimed here
are owned by two different people,

143
00:08:56,020 --> 00:08:59,050
we're going to need two separate
signatures, one by Carol and one by Bob.

144
00:09:01,880 --> 00:09:05,710
So conceptually, that's really all there
is to it, to a Bitcoin transaction.

145
00:09:05,710 --> 00:09:09,280
And let's look at what it
looks like at the low level.

146
00:09:09,280 --> 00:09:12,240
So again, one of the goals of this
lecture is going to be to show you

147
00:09:12,240 --> 00:09:16,880
the real data structure,
the real deal of what Bitcoin looks like.

148
00:09:16,880 --> 00:09:19,230
And, here it is.

149
00:09:19,230 --> 00:09:23,750
Now this isn't exactly what
a Bitcoin transaction looks like.

150
00:09:23,750 --> 00:09:27,140
This is a representation of
it that is pretty printed.

151
00:09:27,140 --> 00:09:29,430
It looks kind of like JSON.

152
00:09:29,430 --> 00:09:34,140
In reality, there's a compact binary
format that this gets compiled down to

153
00:09:34,140 --> 00:09:36,050
that's not human readable, but

154
00:09:36,050 --> 00:09:40,490
this is very close to the actual
low level transaction.

155
00:09:42,720 --> 00:09:44,070
So there's three parts.

156
00:09:44,070 --> 00:09:48,169
There's some metadata, there's a series
of inputs, and a series of outputs.

157
00:09:49,820 --> 00:09:52,170
So we'll start with the metadata.

158
00:09:52,170 --> 00:09:55,740
So there's some housekeeping information,
which is the size of the transaction,

159
00:09:55,740 --> 00:09:58,950
the number of inputs and the number of
outputs, pretty straightforward stuff.

160
00:10:00,200 --> 00:10:03,215
There's the hash of the entire
transaction, which as I said,

161
00:10:03,215 --> 00:10:07,720
will serve as a unique ID for the
transaction to let us do hash pointers.

162
00:10:07,720 --> 00:10:12,950
And then there's this funny lock_time
parameter, which I'll come back to later.

163
00:10:15,460 --> 00:10:19,980
The transaction inputs is just an array
of inputs that all have the same form.

164
00:10:22,680 --> 00:10:26,060
The inputs specify a previous
transaction specifically, so

165
00:10:26,060 --> 00:10:30,740
they have the hash of the previous
transaction, or a hash pointer to it, and

166
00:10:30,740 --> 00:10:34,040
the index of which output from that
transaction you're actually claiming.

167
00:10:35,090 --> 00:10:36,580
And then there's the signature.

168
00:10:36,580 --> 00:10:40,364
So remember that we have to sign to show
that we actually have the ability to claim

169
00:10:40,364 --> 00:10:42,237
those previous transaction outputs.

170
00:10:44,813 --> 00:10:48,801
And now the outputs have just two things,
they have a value, so

171
00:10:48,801 --> 00:10:51,360
each output can have a different value,

172
00:10:51,360 --> 00:10:55,820
the sum of the all the outputs has to
less than the sum of all the inputs.

173
00:10:57,640 --> 00:11:00,300
And then there's this funny thing that

174
00:11:00,300 --> 00:11:02,910
looks like what we want to
be the recipient address.

175
00:11:02,910 --> 00:11:06,250
So each output is supposed to
go to a specific person or

176
00:11:06,250 --> 00:11:08,730
to a specific public key.

177
00:11:08,730 --> 00:11:12,850
And there is some stuff in there that
looks like the hash of a public key.

178
00:11:12,850 --> 00:11:14,400
But there's also some other stuff.

179
00:11:16,000 --> 00:11:17,840
It looks like a script.

180
00:11:17,840 --> 00:11:21,515
And in fact, it is a script, and
we'll talk more about that very soon.

181
00:11:21,515 --> 00:11:22,015
[MUSIC]