1
00:00:00,850 --> 00:00:03,220
The following content is
provided under a Creative

2
00:00:03,220 --> 00:00:04,610
Commons license.

3
00:00:04,610 --> 00:00:06,820
Your support will help
MIT OpenCourseWare

4
00:00:06,820 --> 00:00:10,910
continue to offer high quality
educational resources for free.

5
00:00:10,910 --> 00:00:13,480
To make a donation or to
view additional materials

6
00:00:13,480 --> 00:00:17,440
from hundreds of MIT courses,
visit MIT OpenCourseWare

7
00:00:17,440 --> 00:00:18,313
at ocw.mit.edu.

8
00:00:24,012 --> 00:00:24,720
PROFESSOR: Sorry.

9
00:00:24,720 --> 00:00:28,010
I have a bit of a sore
throat, hoarse voice.

10
00:00:28,010 --> 00:00:30,090
I was talking a
lot this weekend.

11
00:00:30,090 --> 00:00:30,590
OK.

12
00:00:30,590 --> 00:00:33,140
Also, today we're going to
do transaction malleability,

13
00:00:33,140 --> 00:00:35,390
segregated witness,
and I'm endorsing

14
00:00:35,390 --> 00:00:38,360
an ICO for the first
time ever publicly,

15
00:00:38,360 --> 00:00:40,280
and it's Anne's intermittent
cookie offering.

16
00:00:40,280 --> 00:00:41,447
So if you guys want cookies.

17
00:00:43,960 --> 00:00:46,810
It's an airdrop and
you just get them.

18
00:00:54,740 --> 00:01:00,780
so it's my first
ICO I'm endorsing.

19
00:01:00,780 --> 00:01:01,280
OK.

20
00:01:01,280 --> 00:01:04,640
So malleability.

21
00:01:04,640 --> 00:01:06,950
So malleability is
the ability to deform

22
00:01:06,950 --> 00:01:08,900
under pressure formateer.

23
00:01:08,900 --> 00:01:11,090
And so bitcoin is modeled
off of gold, which

24
00:01:11,090 --> 00:01:12,350
is the most malleable metal.

25
00:01:12,350 --> 00:01:14,300
You can make gold
leaf and stuff.

26
00:01:14,300 --> 00:01:19,290
So clearly we need to design
bitcoin to be malleable.

27
00:01:19,290 --> 00:01:20,630
No, I'm joking.

28
00:01:20,630 --> 00:01:21,130
OK.

29
00:01:21,130 --> 00:01:26,870
Actually in the context
of cryptography,

30
00:01:26,870 --> 00:01:28,880
it's not super hard
definition, but it

31
00:01:28,880 --> 00:01:31,730
started with Cipher text, where
if you can modify a Cipher

32
00:01:31,730 --> 00:01:36,770
text and that modification will
carry over into the plain text

33
00:01:36,770 --> 00:01:38,000
when it's encrypted.

34
00:01:38,000 --> 00:01:40,880
It also applies to sort of
messages and signatures.

35
00:01:40,880 --> 00:01:43,710
In our case, signatures
can be malleable,

36
00:01:43,710 --> 00:01:46,220
which means you can
change the signature

37
00:01:46,220 --> 00:01:48,660
and it's still a
valid signature.

38
00:01:48,660 --> 00:01:53,660
So given a signature
S1 on message M1,

39
00:01:53,660 --> 00:01:58,130
you modify the signature
to S2 or S prime

40
00:01:58,130 --> 00:01:59,960
and it still signs
the same message.

41
00:01:59,960 --> 00:02:02,450
It still validates as true.

42
00:02:02,450 --> 00:02:04,790
So when we were
defining signatures

43
00:02:04,790 --> 00:02:08,509
this wasn't really an
attack we'd considered.

44
00:02:08,509 --> 00:02:12,320
There's still a signature and
you can't forge a signature,

45
00:02:12,320 --> 00:02:14,960
but you can dot
an I or something

46
00:02:14,960 --> 00:02:17,190
and the signature is
slightly different.

47
00:02:17,190 --> 00:02:19,650
You can't create one yourself,
but given a valid signature

48
00:02:19,650 --> 00:02:23,700
you can make a slightly
different valid signature.

49
00:02:23,700 --> 00:02:27,950
And that's how it works in
the bitcoin signing algorithm.

50
00:02:27,950 --> 00:02:30,200
But there's all sorts
of different contexts

51
00:02:30,200 --> 00:02:34,160
where malleability
exists in cryptography.

52
00:02:34,160 --> 00:02:35,900
And then part of
it is things still

53
00:02:35,900 --> 00:02:38,250
have to work for
whatever definition.

54
00:02:38,250 --> 00:02:42,327
So if you malleates a signature
and it no longer validates,

55
00:02:42,327 --> 00:02:43,910
well, that's sort
of a trivial, like--

56
00:02:43,910 --> 00:02:46,550
yeah, sure, you can do
that to any bunch of bytes.

57
00:02:46,550 --> 00:02:48,645
You can just flip some of
them and the whole thing

58
00:02:48,645 --> 00:02:49,520
doesn't work anymore.

59
00:02:49,520 --> 00:02:50,690
That's easy.

60
00:02:50,690 --> 00:02:53,717
But properties where
it still works.

61
00:02:53,717 --> 00:02:55,550
So this leads to some
weird stuff in bitcoin

62
00:02:55,550 --> 00:02:59,060
where you can
change a transaction

63
00:02:59,060 --> 00:03:01,550
and it's still valid.

64
00:03:01,550 --> 00:03:04,400
And that's generally
not what you want.

65
00:03:04,400 --> 00:03:05,870
If you've got some
kind of contract

66
00:03:05,870 --> 00:03:09,542
or some kind of payment
and you write a check,

67
00:03:09,542 --> 00:03:11,750
you don't want someone to
be able to modify the check

68
00:03:11,750 --> 00:03:13,700
and still be able to cash it.

69
00:03:13,700 --> 00:03:18,080
And I don't really use checks
much, but they draw the line.

70
00:03:18,080 --> 00:03:20,870
Like $100 and then
they draw a line

71
00:03:20,870 --> 00:03:23,960
so someone doesn't write and
$0.99 or something after.

72
00:03:23,960 --> 00:03:26,870
Not that that's like the
greatest attack ever.

73
00:03:26,870 --> 00:03:30,320
Or $100 and then someone
puts like $1,000.

74
00:03:30,320 --> 00:03:31,730
I don't know.

75
00:03:31,730 --> 00:03:33,560
But it's sort of like
that where someone

76
00:03:33,560 --> 00:03:35,120
can change the
thing you sign, can

77
00:03:35,120 --> 00:03:38,120
change the thing you are
agreeing to after the fact,

78
00:03:38,120 --> 00:03:42,000
and it's still valid and it
does something you don't expect.

79
00:03:42,000 --> 00:03:43,150
OK.

80
00:03:43,150 --> 00:03:47,670
So a review of the
transaction format,

81
00:03:47,670 --> 00:03:50,160
which should be probably
in people's minds

82
00:03:50,160 --> 00:03:53,660
if you were looking at the
homework, the problem set.

83
00:03:53,660 --> 00:03:56,310
And one thing to focus
on is that the outputs

84
00:03:56,310 --> 00:03:58,860
don't look like the inputs.

85
00:03:58,860 --> 00:04:02,190
These are fundamentally
different things.

86
00:04:02,190 --> 00:04:08,640
The outputs specify a
transaction ID and the inputs,

87
00:04:08,640 --> 00:04:12,790
and then the outputs specify
a script and an amount.

88
00:04:12,790 --> 00:04:16,100
There's another 4 byte field
here that doesn't matter.

89
00:04:16,100 --> 00:04:20,220
So basically you're spending
from a transaction and a sort

90
00:04:20,220 --> 00:04:24,510
of row and you're spending too
just this arbitrary pub key,

91
00:04:24,510 --> 00:04:26,790
but you're not
spending from a pub key

92
00:04:26,790 --> 00:04:29,780
and you're not spending
to a transaction.

93
00:04:29,780 --> 00:04:32,500
You don't identify your
transaction itself here.

94
00:04:38,410 --> 00:04:42,500
Almost every website that
shows blockchains is it

95
00:04:42,500 --> 00:04:43,970
gets this wrong.

96
00:04:43,970 --> 00:04:45,670
So if you look at
like, I don't know,

97
00:04:45,670 --> 00:04:51,390
blockchain.info is
probably the most popular

98
00:04:51,390 --> 00:04:54,190
and you just look
at a transaction.

99
00:04:54,190 --> 00:04:55,410
They don't have it anymore.

100
00:04:55,410 --> 00:04:55,910
OK.

101
00:04:55,910 --> 00:04:58,600
So you look at a block and
then you look at a transaction

102
00:04:58,600 --> 00:05:00,460
in the block.

103
00:05:00,460 --> 00:05:01,200
We're going.

104
00:05:01,200 --> 00:05:01,700
No.

105
00:05:01,700 --> 00:05:02,200
No.

106
00:05:02,200 --> 00:05:03,102
No, not yet.

107
00:05:03,102 --> 00:05:03,822
There we go OK.

108
00:05:03,822 --> 00:05:05,030
So you look at a transaction.

109
00:05:05,030 --> 00:05:06,860
Yeah, it shows.

110
00:05:06,860 --> 00:05:10,070
This address is sending
to these two addresses.

111
00:05:10,070 --> 00:05:12,810
And blockchain.info is
particularly egregious

112
00:05:12,810 --> 00:05:15,650
and that there may actually
be more than one input and two

113
00:05:15,650 --> 00:05:19,455
outputs in this transaction.

114
00:05:19,455 --> 00:05:21,860
They hide change transactions.

115
00:05:21,860 --> 00:05:26,640
So it looks like, hey, this
address had some money in it

116
00:05:26,640 --> 00:05:28,233
and it sent it to
these two addresses.

117
00:05:28,233 --> 00:05:30,150
And if I click, oh, where
did this money come?

118
00:05:30,150 --> 00:05:33,990
It come from
18eecz, and it shows

119
00:05:33,990 --> 00:05:36,300
here's the bitcoin
address, and, oh, it's

120
00:05:36,300 --> 00:05:42,180
got multiple transactions this
addresses has been involved in.

121
00:05:42,180 --> 00:05:44,580
This is not how bitcoin works.

122
00:05:44,580 --> 00:05:48,120
They are running their
own database and sort

123
00:05:48,120 --> 00:05:53,730
of making up this view of the
network, which is incorrect.

124
00:05:53,730 --> 00:05:56,790
Transactions don't
send from an address,

125
00:05:56,790 --> 00:06:00,960
they send from another
transactions previous output.

126
00:06:00,960 --> 00:06:03,240
And this is very confusing
because in the case,

127
00:06:03,240 --> 00:06:05,900
let's say in this
transaction, there is a--

128
00:06:05,900 --> 00:06:06,810
what is it?

129
00:06:09,440 --> 00:06:11,555
767 something.

130
00:06:14,880 --> 00:06:19,777
So it says, yeah, it's
coming from 18ee whatever,

131
00:06:19,777 --> 00:06:22,110
and if I click on it I get
three different transactions.

132
00:06:22,110 --> 00:06:25,470
There is a specific
transaction that 18ee

133
00:06:25,470 --> 00:06:28,250
was involved in that is being
spent from in this transaction.

134
00:06:28,250 --> 00:06:31,240
I can look it up because I
have an actual full node.

135
00:06:31,240 --> 00:06:37,730
So if I say get raw transaction
and I put it in here

136
00:06:37,730 --> 00:06:43,410
and I can see, OK, it
was spending from c838.

137
00:06:43,410 --> 00:06:46,870
It was spending from this
transaction, not just

138
00:06:46,870 --> 00:06:47,710
an address.

139
00:06:47,710 --> 00:06:52,210
So I mean if you're coming at
this sort of new it's like, OK,

140
00:06:52,210 --> 00:06:55,450
fine, why do you keep
talking about this?

141
00:06:55,450 --> 00:06:58,010
But if you've been working on
these things, a lot of people,

142
00:06:58,010 --> 00:07:01,373
myself included, for
like six months a year

143
00:07:01,373 --> 00:07:03,040
I looked at these
websites and I'm like,

144
00:07:03,040 --> 00:07:06,490
oh, this is how it works and
then six months in or something

145
00:07:06,490 --> 00:07:09,100
looking for code, and
I'm like, wait, huh?

146
00:07:09,100 --> 00:07:12,070
This code is wrong, but no,
this is the bitcoin code

147
00:07:12,070 --> 00:07:13,780
that actually is running.

148
00:07:13,780 --> 00:07:16,060
And so it's a weird thing
to sort of get used to.

149
00:07:16,060 --> 00:07:17,935
Like no, you're not
spending from an address.

150
00:07:17,935 --> 00:07:20,440
You don't show the address at
all when you spend from it,

151
00:07:20,440 --> 00:07:22,170
you spend from a
specific output.

152
00:07:22,170 --> 00:07:22,750
OK.

153
00:07:22,750 --> 00:07:24,460
So that leads to
some weird issues.

154
00:07:27,810 --> 00:07:30,250
Specifically, what gets signed?

155
00:07:30,250 --> 00:07:33,160
So to some extent you're
signing the whole transaction.

156
00:07:33,160 --> 00:07:34,820
You sign.

157
00:07:34,820 --> 00:07:36,070
You want to sign everything.

158
00:07:36,070 --> 00:07:38,200
When you're saying I'm
sending money from here,

159
00:07:38,200 --> 00:07:40,810
I'm sending it to here,
you want to make sure

160
00:07:40,810 --> 00:07:43,870
that your signature covers
the entire transaction so

161
00:07:43,870 --> 00:07:47,538
that people can't add stuff
after or remove stuff.

162
00:07:47,538 --> 00:07:49,330
So you want to sign
the inputs and outputs.

163
00:07:49,330 --> 00:07:51,460
But the inputs
contain signatures

164
00:07:51,460 --> 00:07:53,850
and you can't sign
the signature.

165
00:07:53,850 --> 00:07:55,630
That doesn't make any sense.

166
00:07:55,630 --> 00:07:58,003
The signature is the thing
you're putting on at the end.

167
00:07:58,003 --> 00:07:58,920
So it's sort of weird.

168
00:07:58,920 --> 00:08:00,790
You've got this document
and you have a little line

169
00:08:00,790 --> 00:08:02,200
at the bottom for the signature.

170
00:08:02,200 --> 00:08:05,560
But should the signatures be
maybe a separate page that

171
00:08:05,560 --> 00:08:07,420
refers to the previous page?

172
00:08:07,420 --> 00:08:10,450
It's actually kind of a
weird confusing problem.

173
00:08:10,450 --> 00:08:16,390
So in practice, in bitcoin,
what Satoshi did in 2009,

174
00:08:16,390 --> 00:08:18,190
you take the whole
transaction, but you

175
00:08:18,190 --> 00:08:19,740
remove the signature fields.

176
00:08:19,740 --> 00:08:21,010
You basically zero them out.

177
00:08:21,010 --> 00:08:22,750
Just put a zero
there and then you

178
00:08:22,750 --> 00:08:27,610
sign that sort of
signatureless transaction.

179
00:08:27,610 --> 00:08:33,000
And then you put that
signature in after the fact.

180
00:08:33,000 --> 00:08:37,070
And so that means if you change
any bit of the stuff that gets

181
00:08:37,070 --> 00:08:42,250
signed other than the signature,
the signature will break.

182
00:08:42,250 --> 00:08:43,250
So does that make sense?

183
00:08:45,760 --> 00:08:48,080
You have these
empty lines kind of,

184
00:08:48,080 --> 00:08:51,440
and the idea is you empty them
out, you make them blank lines,

185
00:08:51,440 --> 00:08:54,530
and then you take that whole
message, hash it, including

186
00:08:54,530 --> 00:08:58,520
the empty parts, and then
paste in those signatures

187
00:08:58,520 --> 00:08:59,450
after you've signed.

188
00:09:04,490 --> 00:09:06,680
You don't empty out every
line, the line that you're

189
00:09:06,680 --> 00:09:08,480
specifically putting
the signature in,

190
00:09:08,480 --> 00:09:10,820
you actually put a
different few bytes

191
00:09:10,820 --> 00:09:13,970
in there, which leads
to other problems

192
00:09:13,970 --> 00:09:16,700
that I can maybe
mention if I've done.

193
00:09:16,700 --> 00:09:18,110
So this seems OK.

194
00:09:18,110 --> 00:09:21,260
It's like well, look, I can't
sign the signatures, sure,

195
00:09:21,260 --> 00:09:24,500
but if you change any bit
of the stuff I'm signing,

196
00:09:24,500 --> 00:09:26,070
the signatures now break.

197
00:09:26,070 --> 00:09:28,670
So this seems perfectly safe.

198
00:09:28,670 --> 00:09:30,650
No one can change the
amounts I'm sending.

199
00:09:30,650 --> 00:09:33,400
No one can change where
I'm sending it to.

200
00:09:33,400 --> 00:09:35,780
No one can change
where I'm sending from.

201
00:09:35,780 --> 00:09:39,330
All these things get covered
in my signature, so I'm good.

202
00:09:39,330 --> 00:09:40,560
Problem.

203
00:09:40,560 --> 00:09:43,800
The transaction ID, the way
you refer to transactions

204
00:09:43,800 --> 00:09:46,020
is the hash of the whole thing.

205
00:09:46,020 --> 00:09:50,070
The txid does not zero
out the signature fields.

206
00:09:50,070 --> 00:09:53,310
So the identity of the
transaction itself, the way

207
00:09:53,310 --> 00:09:57,180
to point to and indicate
where you're spending from,

208
00:09:57,180 --> 00:10:00,150
that includes the signatures.

209
00:10:00,150 --> 00:10:02,850
So that also seems
like, well, that's OK.

210
00:10:02,850 --> 00:10:05,280
When I point to
something I'm indicating

211
00:10:05,280 --> 00:10:09,620
the whole transaction, the
whole signed transaction.

212
00:10:09,620 --> 00:10:12,770
But the problem is
that can change.

213
00:10:12,770 --> 00:10:15,590
The signature itself
may be malleable,

214
00:10:15,590 --> 00:10:17,700
and in bitcoin it is.

215
00:10:17,700 --> 00:10:20,070
There's third party
malleability problems.

216
00:10:20,070 --> 00:10:22,480
So the simplest one
was leading zeros

217
00:10:22,480 --> 00:10:24,830
where all these
things are numbers.

218
00:10:24,830 --> 00:10:26,900
You could say, OK,
someone's got a signature.

219
00:10:26,900 --> 00:10:30,180
It's this big, long
string of bytes.

220
00:10:30,180 --> 00:10:32,180
I'm just going to put
zeros in the front.

221
00:10:32,180 --> 00:10:34,750
I'm going to put a zero
byte in the front of it,

222
00:10:34,750 --> 00:10:36,290
and that doesn't
change the meaning.

223
00:10:36,290 --> 00:10:40,310
If someone says, I'm
sending you $1,000

224
00:10:40,310 --> 00:10:42,255
and I put a 0 front
of the one and 1,000.

225
00:10:42,255 --> 00:10:43,700
Well, it's still 1,000.

226
00:10:43,700 --> 00:10:47,190
However, for the purpose
of a hash function,

227
00:10:47,190 --> 00:10:48,590
if you have a zero
byte in front,

228
00:10:48,590 --> 00:10:51,380
that changes the whole hash.

229
00:10:51,380 --> 00:10:54,140
And so they got rid
of this pretty early.

230
00:10:54,140 --> 00:10:56,630
They sort of made
it so that you had

231
00:10:56,630 --> 00:10:58,220
to have the exact right number.

232
00:10:58,220 --> 00:10:59,660
You can't have
any leading zeros.

233
00:10:59,660 --> 00:11:03,060
But the first one was just,
oh, I put a 0 in the front.

234
00:11:03,060 --> 00:11:06,260
The harder one is
called low s, where part

235
00:11:06,260 --> 00:11:10,080
of the ecdsa signature scheme.

236
00:11:10,080 --> 00:11:11,930
I showed before that
it's this curve that's

237
00:11:11,930 --> 00:11:15,070
symmetric about the x-axis.

238
00:11:15,070 --> 00:11:16,690
Whether the thing
you're indicating

239
00:11:16,690 --> 00:11:19,840
is on top of the curve or
it's sort of reflection

240
00:11:19,840 --> 00:11:22,660
on the bottom, it's
valid either way.

241
00:11:22,660 --> 00:11:24,220
So for any given
signature, there's

242
00:11:24,220 --> 00:11:26,080
another signature
that will be valid.

243
00:11:26,080 --> 00:11:29,730
You just sort of flip it,
make it negative or positive.

244
00:11:29,730 --> 00:11:32,440
So now there's a standard,
OK, you need to have high s.

245
00:11:32,440 --> 00:11:34,960
Low s signatures
should be invalid.

246
00:11:34,960 --> 00:11:38,540
Both of these are really
tricky because they're

247
00:11:38,540 --> 00:11:40,010
third party malleability.

248
00:11:40,010 --> 00:11:43,130
Anyone can just listen on the
network, see a transaction,

249
00:11:43,130 --> 00:11:44,540
change the signature.

250
00:11:44,540 --> 00:11:46,820
And in doing so they
will change the txid,

251
00:11:46,820 --> 00:11:49,250
which is how all the software
refers to transactions.

252
00:11:49,250 --> 00:11:52,470
So it looks like
a new transaction

253
00:11:52,470 --> 00:11:53,868
to most of the software.

254
00:11:53,868 --> 00:11:55,410
And the transactions
are still valid.

255
00:11:55,410 --> 00:11:57,350
The signatures are still
valid and you're not

256
00:11:57,350 --> 00:11:59,510
sure which one will get in.

257
00:11:59,510 --> 00:12:02,390
There's also first party
malleability, or in some cases

258
00:12:02,390 --> 00:12:04,130
second party if you're
doing transactions

259
00:12:04,130 --> 00:12:06,890
with multiple people signing.

260
00:12:06,890 --> 00:12:10,540
So I'm not going to go back into
the elliptic curve signature

261
00:12:10,540 --> 00:12:12,260
algorithms, but
there is a nonce.

262
00:12:12,260 --> 00:12:13,850
There's randomness
that you inject

263
00:12:13,850 --> 00:12:17,000
into the signing process.

264
00:12:17,000 --> 00:12:18,080
It's not deterministic.

265
00:12:18,080 --> 00:12:21,320
It's not that given a
message and my private key.

266
00:12:21,320 --> 00:12:23,000
I always compute
the same signature.

267
00:12:23,000 --> 00:12:24,457
No, that's not how it works.

268
00:12:24,457 --> 00:12:26,040
There are signature
schemes like that,

269
00:12:26,040 --> 00:12:29,510
but in the case of the elliptic
curve stuff that bitcoin uses,

270
00:12:29,510 --> 00:12:33,310
you have to make up a random
number to make each signature,

271
00:12:33,310 --> 00:12:35,360
and no one knows what
that random number is.

272
00:12:35,360 --> 00:12:38,240
So you could make up
different random numbers.

273
00:12:38,240 --> 00:12:40,110
You can make as many
signatures as you want.

274
00:12:40,110 --> 00:12:44,600
So given a message
and your private key,

275
00:12:44,600 --> 00:12:47,083
you can make arbitrary
number of signatures

276
00:12:47,083 --> 00:12:48,500
that are all
different signatures,

277
00:12:48,500 --> 00:12:52,040
but they're all
valid signatures.

278
00:12:52,040 --> 00:12:56,180
There is a sort of standard
for how to make them

279
00:12:56,180 --> 00:12:58,340
the right way not randomly.

280
00:12:58,340 --> 00:13:01,580
It's basically take the
hash of your private key

281
00:13:01,580 --> 00:13:04,280
and the message being signed.

282
00:13:04,280 --> 00:13:07,040
Put them together,
hash that, and use that

283
00:13:07,040 --> 00:13:10,155
as your random number because
then the idea is well,

284
00:13:10,155 --> 00:13:12,260
it's got secret
information in it

285
00:13:12,260 --> 00:13:14,833
as well as the message
specific information in it.

286
00:13:14,833 --> 00:13:17,000
So no one's going to be
able to guess what it is so,

287
00:13:17,000 --> 00:13:18,940
and it's still kind
of message dependent

288
00:13:18,940 --> 00:13:21,410
so it'll change each time.

289
00:13:21,410 --> 00:13:24,870
So there is that, but
that's something you can do.

290
00:13:24,870 --> 00:13:27,680
It's a really good
idea because if you

291
00:13:27,680 --> 00:13:30,650
use a non-random k,
if someone can guess k

292
00:13:30,650 --> 00:13:32,820
or if your random number
generator's broken,

293
00:13:32,820 --> 00:13:34,070
they can steal all your money.

294
00:13:34,070 --> 00:13:38,550
They can figure out
your private key.

295
00:13:38,550 --> 00:13:40,780
So you don't want to be
dependent on generating

296
00:13:40,780 --> 00:13:41,530
randomness.

297
00:13:41,530 --> 00:13:45,270
A nice way to model it is, OK,
have some initial event where

298
00:13:45,270 --> 00:13:47,800
you're putting in random
numbers and you're storing them

299
00:13:47,800 --> 00:13:51,040
and then from then on you want
everything to be deterministic,

300
00:13:51,040 --> 00:13:53,890
then you don't have to rely
on random number generators.

301
00:13:53,890 --> 00:13:55,810
So it's really a good
idea to use this.

302
00:13:55,810 --> 00:13:57,355
And I use it in my software.

303
00:13:57,355 --> 00:13:59,690
Most things use this
kind of standard.

304
00:13:59,690 --> 00:14:02,410
However, you can't verify that
anyone's actually using it.

305
00:14:02,410 --> 00:14:03,610
It's purely internal.

306
00:14:03,610 --> 00:14:06,430
It's a internal way for you
to make your own signatures,

307
00:14:06,430 --> 00:14:08,890
but no one can actually--

308
00:14:08,890 --> 00:14:09,530
can you prove?

309
00:14:09,530 --> 00:14:10,042
No.

310
00:14:10,042 --> 00:14:12,250
I'm not going to say you
can't prove you're using it,

311
00:14:12,250 --> 00:14:16,590
but not in any
reasonable fashion.

312
00:14:16,590 --> 00:14:17,090
Yeah.

313
00:14:17,090 --> 00:14:19,110
So no one knows if
you're doing it.

314
00:14:19,110 --> 00:14:21,257
So this is an attack
where you can say, OK,

315
00:14:21,257 --> 00:14:23,590
I'm going to make a whole
bunch of different signatures.

316
00:14:23,590 --> 00:14:25,215
They're all going to
be valid, but that

317
00:14:25,215 --> 00:14:28,540
will mean I've got a whole
bunch of different transactions

318
00:14:28,540 --> 00:14:31,900
that are doing the same thing.

319
00:14:31,900 --> 00:14:34,440
So maybe the question is,
what does this really do?

320
00:14:34,440 --> 00:14:35,640
Does this really hurt?

321
00:14:35,640 --> 00:14:39,460
If someone dots an eye on your
check, it's the same amount.

322
00:14:39,460 --> 00:14:42,150
It's going to the same place.

323
00:14:42,150 --> 00:14:44,290
Who cares.

324
00:14:44,290 --> 00:14:46,160
Outputs are the same.

325
00:14:46,160 --> 00:14:48,090
Inputs it's pointing
to are the same.

326
00:14:48,090 --> 00:14:50,120
It's just this sort
of annoying thing.

327
00:14:50,120 --> 00:14:52,320
OK, I tweaked it and
I changed the txid.

328
00:14:52,320 --> 00:14:53,620
No big deal.

329
00:14:53,620 --> 00:14:58,100
Well, in some ways,
yeah, it's no big deal,

330
00:14:58,100 --> 00:15:01,060
but a lot of wallets
didn't deal with this well.

331
00:15:01,060 --> 00:15:04,510
So let's say you're running a
wallet, you make a transaction

332
00:15:04,510 --> 00:15:09,850
and you sign and you
broadcast transaction 2d5cac

333
00:15:09,850 --> 00:15:14,650
and it never gets confirmed, and
instead someone out there flips

334
00:15:14,650 --> 00:15:19,450
a bit, changes your
transaction to 9cba3e

335
00:15:19,450 --> 00:15:21,550
and that gets confirmed,
and your wallet just

336
00:15:21,550 --> 00:15:25,825
says, yeah, this transaction
you sent never got confirmed.

337
00:15:25,825 --> 00:15:27,250
There's wallets that did that.

338
00:15:27,250 --> 00:15:29,070
Most of them have
fixed it by now.

339
00:15:29,070 --> 00:15:31,120
But if you're thinking
of transaction IDs

340
00:15:31,120 --> 00:15:36,360
as the identity txid, this is
the name of the transaction.

341
00:15:36,360 --> 00:15:40,420
I create it, I'm watching it
to see when it gets confirmed,

342
00:15:40,420 --> 00:15:42,850
and I'm not looking for
some malleated version.

343
00:15:42,850 --> 00:15:45,190
I'm just watching this
thing that I created, never

344
00:15:45,190 --> 00:15:46,720
gets in a block.

345
00:15:46,720 --> 00:15:48,670
Weird, and it's just
stuck in the wallet.

346
00:15:48,670 --> 00:15:51,100
So there are definitely
wallets, and I think

347
00:15:51,100 --> 00:15:52,550
everyone's fixed it by now.

348
00:15:52,550 --> 00:15:54,310
But a couple years
ago, definitely wallets

349
00:15:54,310 --> 00:15:57,310
that would have these problems.

350
00:15:57,310 --> 00:15:58,660
It's a wallet problem.

351
00:15:58,660 --> 00:16:01,210
Your money got to
the right place.

352
00:16:01,210 --> 00:16:04,630
You just need to sort of either
delete stuff in your wallet

353
00:16:04,630 --> 00:16:07,210
or upgrade the software or
tell it to somehow forget

354
00:16:07,210 --> 00:16:08,680
about this transaction
and actually

355
00:16:08,680 --> 00:16:10,270
look on the blockchain
for everything

356
00:16:10,270 --> 00:16:12,100
similar to your transaction.

357
00:16:12,100 --> 00:16:16,280
But it did do some damage.

358
00:16:16,280 --> 00:16:19,540
So, I don't know, 2014 the Mt.

359
00:16:19,540 --> 00:16:20,800
Gox thing where Mt.

360
00:16:20,800 --> 00:16:24,190
Gox got hacked supposedly
and lost all the money,

361
00:16:24,190 --> 00:16:26,350
they blamed transaction
malleability,

362
00:16:26,350 --> 00:16:28,340
which was kind of interesting.

363
00:16:28,340 --> 00:16:33,070
There may have been an attack
on Mt Gox that used transaction

364
00:16:33,070 --> 00:16:35,380
malleability.

365
00:16:35,380 --> 00:16:41,540
The attack probably was
this, which was log into Mt.

366
00:16:41,540 --> 00:16:47,900
Gox, withdraw some coins,
modify the txid to this,

367
00:16:47,900 --> 00:16:50,600
and then it gets confirmed,
you get your coins,

368
00:16:50,600 --> 00:16:52,077
and then log into Mt.

369
00:16:52,077 --> 00:16:53,660
Gox and say, hey,
this never happened.

370
00:16:53,660 --> 00:16:55,280
My withdrawal
didn't work and then

371
00:16:55,280 --> 00:16:57,572
their system would automatically
issue a new withdrawal

372
00:16:57,572 --> 00:16:58,820
transaction.

373
00:16:58,820 --> 00:17:01,520
And so you could just start
taking all the money out

374
00:17:01,520 --> 00:17:03,717
and your balance on
the system's like,

375
00:17:03,717 --> 00:17:05,300
well, we keep trying
to send you money

376
00:17:05,300 --> 00:17:07,200
and it keeps never
getting confirmed.

377
00:17:07,200 --> 00:17:09,260
And so we keep making new ones.

378
00:17:09,260 --> 00:17:11,869
I don't know to what extent
that that actually happened.

379
00:17:14,555 --> 00:17:16,430
It couldn't have been
the whole thing for Mt.

380
00:17:16,430 --> 00:17:17,182
Gox definitely.

381
00:17:17,182 --> 00:17:19,099
There's still a lot of
uncertainty about that.

382
00:17:19,099 --> 00:17:21,268
But it's indicative.

383
00:17:21,268 --> 00:17:23,060
If you write your own
software and it's not

384
00:17:23,060 --> 00:17:26,270
accounting for these things,
you may be losing money

385
00:17:26,270 --> 00:17:29,030
once people say, hey, this
didn't work, make a new one,

386
00:17:29,030 --> 00:17:31,790
and then you keep doing that
and losing a ton of money.

387
00:17:31,790 --> 00:17:36,080
But that's pretty
sloppy practice.

388
00:17:36,080 --> 00:17:37,130
Another issue.

389
00:17:37,130 --> 00:17:42,440
If you're spending from
a unconfirmed change

390
00:17:42,440 --> 00:17:44,090
output or an
unconfirmed output--

391
00:17:44,090 --> 00:17:47,690
so you make a transaction, you
send the two different outputs,

392
00:17:47,690 --> 00:17:48,890
you've got a txid.

393
00:17:48,890 --> 00:17:51,440
And you're sending five
coins to this person

394
00:17:51,440 --> 00:17:53,650
and three coins
back to yourself.

395
00:17:53,650 --> 00:17:55,610
That three coins back
to yourself output,

396
00:17:55,610 --> 00:17:58,070
you might want to use
it again pretty quickly.

397
00:17:58,070 --> 00:18:00,560
Sometimes this happens.

398
00:18:00,560 --> 00:18:05,390
And so you've got a
change output that's

399
00:18:05,390 --> 00:18:07,610
from transaction 1, 7feec1.

400
00:18:07,610 --> 00:18:12,380
So you're going to now spend
that change output, however

401
00:18:12,380 --> 00:18:14,870
the txid of transaction
one changes.

402
00:18:14,870 --> 00:18:17,300
So you're saying
where you're spending

403
00:18:17,300 --> 00:18:19,847
from is no longer valid.

404
00:18:19,847 --> 00:18:21,680
And this is a big problem
because now you've

405
00:18:21,680 --> 00:18:24,380
signed a transaction that you
think is going to be valid,

406
00:18:24,380 --> 00:18:26,900
but the money you thought
you were spending sort of

407
00:18:26,900 --> 00:18:29,270
moves out from under you.

408
00:18:29,270 --> 00:18:31,460
And so that transaction's
no longer valid.

409
00:18:31,460 --> 00:18:32,780
tx2 is now invalid.

410
00:18:32,780 --> 00:18:34,610
It refers to something
which can never

411
00:18:34,610 --> 00:18:38,390
be confirmed because there's
a different transaction that's

412
00:18:38,390 --> 00:18:41,300
almost the same, but they're
mutually exclusive that

413
00:18:41,300 --> 00:18:42,840
did get confirmed.

414
00:18:42,840 --> 00:18:43,340
OK.

415
00:18:43,340 --> 00:18:45,690
So this is bad.

416
00:18:48,870 --> 00:18:50,430
It doesn't seem that bad.

417
00:18:50,430 --> 00:18:53,100
And so for years in
bitcoin this was a problem

418
00:18:53,100 --> 00:18:55,260
that while it dealt
with, software and people

419
00:18:55,260 --> 00:18:58,890
would be like, oh yeah, you
have to backup your keys,

420
00:18:58,890 --> 00:19:01,530
delete your whole database,
and rethink the blockchain

421
00:19:01,530 --> 00:19:04,045
and then it'll find
the right transactions.

422
00:19:04,045 --> 00:19:06,930
Kind of hacky work
arounds like that where

423
00:19:06,930 --> 00:19:09,782
it didn't happen too much.

424
00:19:09,782 --> 00:19:11,640
It wasn't a great attack.

425
00:19:11,640 --> 00:19:12,570
You can annoy people.

426
00:19:12,570 --> 00:19:14,490
You don't get any money.

427
00:19:14,490 --> 00:19:18,055
So wasn't a huge deal,
but it was annoying.

428
00:19:18,055 --> 00:19:19,680
But the idea is you
can always re-sign.

429
00:19:19,680 --> 00:19:20,888
You've got your private keys.

430
00:19:20,888 --> 00:19:25,030
If the money you are receiving
sort of shifts around

431
00:19:25,030 --> 00:19:27,030
and changes its location,
well it's still yours.

432
00:19:27,030 --> 00:19:28,860
You just need to re-sign.

433
00:19:28,860 --> 00:19:31,320
But what if you can't re-sign?

434
00:19:31,320 --> 00:19:36,910
So the case of multisig where
in most cases when you're

435
00:19:36,910 --> 00:19:40,480
doing transactions if you just
have one key, it's just you,

436
00:19:40,480 --> 00:19:41,560
that's fine.

437
00:19:41,560 --> 00:19:43,570
In the case of
multisig usually you're

438
00:19:43,570 --> 00:19:46,210
all friends to some
extent and you're

439
00:19:46,210 --> 00:19:51,160
all in the same organization or
multiple devices that you own.

440
00:19:51,160 --> 00:19:54,472
But you can have sort
of adversarial multisig

441
00:19:54,472 --> 00:19:55,930
where you're
assigning transactions

442
00:19:55,930 --> 00:19:58,390
with people who are you're
sort of cooperating with them,

443
00:19:58,390 --> 00:20:00,610
but you may not
really trust them,

444
00:20:00,610 --> 00:20:03,712
or they might be potentially
attackers, things like that.

445
00:20:03,712 --> 00:20:05,920
You can definitely sort of
extend your multisig model

446
00:20:05,920 --> 00:20:07,785
into that.

447
00:20:07,785 --> 00:20:09,910
And there could be multisig
pre-signed transactions

448
00:20:09,910 --> 00:20:12,610
where, OK, we've got
this two of three output

449
00:20:12,610 --> 00:20:15,820
address, this
output that exists,

450
00:20:15,820 --> 00:20:18,520
and one of the two or three
has pre-signed a transaction

451
00:20:18,520 --> 00:20:20,650
and hands it over to me
and then they disappear.

452
00:20:20,650 --> 00:20:24,400
And they say, oh OK, well I'm
going to now sign my side.

453
00:20:24,400 --> 00:20:28,510
But if malleability occurs and
the transaction ID changes,

454
00:20:28,510 --> 00:20:33,430
that signature is no longer
valid, signing something

455
00:20:33,430 --> 00:20:34,848
that's not there anymore.

456
00:20:34,848 --> 00:20:37,140
So this is very important in
payment channels lightning

457
00:20:37,140 --> 00:20:41,780
network stuff that I'll
get to in a few days.

458
00:20:41,780 --> 00:20:44,530
And so it wasn't so
much that malleability

459
00:20:44,530 --> 00:20:47,650
was like a showstopper bug
and everyone was losing tons

460
00:20:47,650 --> 00:20:50,140
of money, it was that
it was preventing

461
00:20:50,140 --> 00:20:52,480
kind of new, cool
things from happening

462
00:20:52,480 --> 00:20:55,420
because there were a
lot of problems with,

463
00:20:55,420 --> 00:20:58,570
OK, let's make this
construction where we put money

464
00:20:58,570 --> 00:21:01,420
into a multisig account and
then I sign like a refund

465
00:21:01,420 --> 00:21:05,620
transaction that's got a lock
time before I actually fund it

466
00:21:05,620 --> 00:21:08,090
and things like that where
you couldn't reliably do it

467
00:21:08,090 --> 00:21:10,720
because if either party
modified their signature,

468
00:21:10,720 --> 00:21:13,540
they could break the whole thing
and they could have a tax where

469
00:21:13,540 --> 00:21:15,457
it's like, OK, we're
doing something together.

470
00:21:15,457 --> 00:21:16,780
Oh look, it's got stuck.

471
00:21:16,780 --> 00:21:19,220
Well both of our coins
got stuck in this place.

472
00:21:19,220 --> 00:21:19,720
Hmm.

473
00:21:19,720 --> 00:21:22,130
Now it's sort of a hostage
situation and you can say,

474
00:21:22,130 --> 00:21:25,660
well, I think I should get 1
and 1/2 and you should get 1.5.

475
00:21:25,660 --> 00:21:27,610
It's like wait,
we both wanted 1.

476
00:21:27,610 --> 00:21:29,770
So there is a tax
that could happen.

477
00:21:29,770 --> 00:21:31,572
And so this malleability
was a problem

478
00:21:31,572 --> 00:21:33,280
for people trying to
do new, cool things.

479
00:21:35,890 --> 00:21:37,240
So how do you fix this?

480
00:21:37,240 --> 00:21:37,740
Any ideas?

481
00:21:40,270 --> 00:21:41,770
Non-malleable signatures?

482
00:21:41,770 --> 00:21:45,970
So the one we did for
the first homework.

483
00:21:45,970 --> 00:21:48,970
Does anyone have an idea about
why the lamport signatures were

484
00:21:48,970 --> 00:21:52,930
non-malleable, like
from problems at one?

485
00:21:57,530 --> 00:22:00,330
Yes, it was right.

486
00:22:00,330 --> 00:22:01,540
But yeah, they weren't.

487
00:22:04,350 --> 00:22:06,610
There's no randomness for one.

488
00:22:06,610 --> 00:22:08,957
I'm pretty sure if you flip
any of the bits it's not

489
00:22:08,957 --> 00:22:09,540
going to work.

490
00:22:09,540 --> 00:22:12,210
So lamport signatures are
an example where, yeah, it's

491
00:22:12,210 --> 00:22:13,540
non-malleable.

492
00:22:13,540 --> 00:22:18,390
You can't produce multiple
different signatures

493
00:22:18,390 --> 00:22:20,550
on the same message.

494
00:22:20,550 --> 00:22:22,050
So that's good.

495
00:22:22,050 --> 00:22:24,540
The thing is many
useful signature schemes

496
00:22:24,540 --> 00:22:25,250
are malleable.

497
00:22:25,250 --> 00:22:27,750
So to just say no, you have to
use a non-malleable signature

498
00:22:27,750 --> 00:22:30,000
scheme, it's not a great
answer to the question.

499
00:22:33,302 --> 00:22:35,260
I'm pretty sure there's
some weird malleability

500
00:22:35,260 --> 00:22:37,250
stuff in RSA.

501
00:22:37,250 --> 00:22:40,840
A lot of the systems
have randomness in there

502
00:22:40,840 --> 00:22:43,030
and they're malleable.

503
00:22:43,030 --> 00:22:46,270
So an idea that I
had like 2014 and I

504
00:22:46,270 --> 00:22:51,640
was sort of going for was just
don't sign your inputs at all,

505
00:22:51,640 --> 00:22:52,967
only sign your outputs.

506
00:22:52,967 --> 00:22:55,300
So you don't actually specify
where you're sending money

507
00:22:55,300 --> 00:22:56,830
from in your signature.

508
00:22:56,830 --> 00:22:59,530
You do have to still
specify in your transaction

509
00:22:59,530 --> 00:23:01,540
because people need
to know, but you

510
00:23:01,540 --> 00:23:04,280
say I'm only going to
sign off on the outputs.

511
00:23:04,280 --> 00:23:07,990
The endorsement of
my inputs is implicit

512
00:23:07,990 --> 00:23:10,150
because the keys match.

513
00:23:10,150 --> 00:23:11,830
So I don't actually
sign off on which

514
00:23:11,830 --> 00:23:16,737
key I'm sending from to
something that's redundant.

515
00:23:16,737 --> 00:23:18,320
You know I'm sending
from these inputs

516
00:23:18,320 --> 00:23:20,195
because the keys match
up and the signature's

517
00:23:20,195 --> 00:23:22,210
valid for this key.

518
00:23:22,210 --> 00:23:23,970
I really like this idea still.

519
00:23:23,970 --> 00:23:24,970
I think it's really fun.

520
00:23:24,970 --> 00:23:26,830
You can do a lot of
cool stuff with it.

521
00:23:26,830 --> 00:23:28,780
It's also dangerous.

522
00:23:28,780 --> 00:23:31,630
It allows signatures
to be replayed,

523
00:23:31,630 --> 00:23:33,880
which is sort of one of
the big points of having

524
00:23:33,880 --> 00:23:37,720
utxo's because if you
send two outputs--

525
00:23:41,590 --> 00:23:44,860
I have address one.

526
00:23:44,860 --> 00:23:46,620
I send two outputs.

527
00:23:46,620 --> 00:23:52,780
So I've got output one,
output two, and this one

528
00:23:52,780 --> 00:23:55,780
has five coins, this
one has three coins,

529
00:23:55,780 --> 00:23:58,630
and they're both
the same address,

530
00:23:58,630 --> 00:24:01,330
both the same public key, and
then I want to spend them.

531
00:24:01,330 --> 00:24:03,190
And if I use this sort
of signature scheme

532
00:24:03,190 --> 00:24:06,430
where I don't actually sign
which input I'm spending from,

533
00:24:06,430 --> 00:24:07,790
it can be used on either.

534
00:24:07,790 --> 00:24:11,122
So maybe I'm not
aware of this 5-1 yet,

535
00:24:11,122 --> 00:24:13,330
or it just hasn't happened
yet, or I haven't seen it,

536
00:24:13,330 --> 00:24:15,790
and I say, yeah, I'm going
to make a signature sending

537
00:24:15,790 --> 00:24:18,730
three coins over
here and then someone

538
00:24:18,730 --> 00:24:22,410
can malleate the transaction
without touching the signature,

539
00:24:22,410 --> 00:24:25,050
and pointing over
here, and the signature

540
00:24:25,050 --> 00:24:26,550
wouldn't apply to either.

541
00:24:26,550 --> 00:24:29,430
And then this is a really
good deal for the miners

542
00:24:29,430 --> 00:24:32,430
because now I'm spending five
coins and only outputting three

543
00:24:32,430 --> 00:24:35,280
and the miners get the
two coins difference.

544
00:24:35,280 --> 00:24:36,990
And so that's pretty dangerous.

545
00:24:36,990 --> 00:24:40,750
And also, even if they're
the same I just say, hey,

546
00:24:40,750 --> 00:24:43,780
I'm sending three coins
to you and then as

547
00:24:43,780 --> 00:24:46,090
soon as the receiver
sees this output,

548
00:24:46,090 --> 00:24:47,470
oh, it'll also work here.

549
00:24:47,470 --> 00:24:50,020
I'm going to take
another three coins.

550
00:24:50,020 --> 00:24:54,970
So this is mitigated by
not reusing addresses,

551
00:24:54,970 --> 00:24:58,960
but people reuse addresses.

552
00:24:58,960 --> 00:25:00,910
So it is dangerous.

553
00:25:00,910 --> 00:25:03,672
I think in the context of
multisig you can reliably

554
00:25:03,672 --> 00:25:05,380
say like, OK, we're
not reusing addresses

555
00:25:05,380 --> 00:25:07,963
because these addresses are the
combination of multiple people

556
00:25:07,963 --> 00:25:09,148
working together.

557
00:25:09,148 --> 00:25:10,690
But it would allow
really cool things

558
00:25:10,690 --> 00:25:14,013
where you could sort of work
backwards, compute a public key

559
00:25:14,013 --> 00:25:16,180
that you could prove no one
knew the private key to,

560
00:25:16,180 --> 00:25:17,555
but you could
still sign with it.

561
00:25:17,555 --> 00:25:19,540
Like really weird crazy stuff.

562
00:25:19,540 --> 00:25:23,930
Anyway, people were
still talking about it

563
00:25:23,930 --> 00:25:24,690
a week or two ago.

564
00:25:24,690 --> 00:25:26,690
Like, oh, we could do
these cool things with it.

565
00:25:26,690 --> 00:25:29,690
But it's dangerous and so
it's like we're not sure

566
00:25:29,690 --> 00:25:31,520
if it's worth it.

567
00:25:31,520 --> 00:25:32,020
OK.

568
00:25:32,020 --> 00:25:34,810
Any questions about this
transaction malleability

569
00:25:34,810 --> 00:25:36,400
so far?

570
00:25:36,400 --> 00:25:36,900
OK.

571
00:25:36,900 --> 00:25:39,020
So any ideas of
what you actually

572
00:25:39,020 --> 00:25:42,127
do to fix malleability?

573
00:25:45,710 --> 00:25:46,760
Nobody?

574
00:25:46,760 --> 00:25:48,800
OK.

575
00:25:48,800 --> 00:25:51,590
we'll find out in one minute.

576
00:25:51,590 --> 00:25:53,660
Segregated Witness.

577
00:25:53,660 --> 00:25:56,730
I don't think it's a good name.

578
00:25:56,730 --> 00:26:02,850
Separate signatures would be a
much easier to understand name.

579
00:26:02,850 --> 00:26:04,908
So Peter Wuille who is
really good at bitcoin

580
00:26:04,908 --> 00:26:06,450
and makes all these
cool things, he's

581
00:26:06,450 --> 00:26:08,920
not the best at naming things.

582
00:26:08,920 --> 00:26:10,960
Makes lots of cool
stuff, but just makes

583
00:26:10,960 --> 00:26:12,210
whatever weird technical name.

584
00:26:14,910 --> 00:26:16,740
So it's a pretty
straightforward idea.

585
00:26:16,740 --> 00:26:22,460
The idea is when you're
signing a transaction you hash

586
00:26:22,460 --> 00:26:26,330
a bunch of data design, but you
don't include the signatures

587
00:26:26,330 --> 00:26:28,040
in the data you're
hashing to sign them

588
00:26:28,040 --> 00:26:29,210
because that wouldn't
make any sense.

589
00:26:29,210 --> 00:26:29,710
You can't.

590
00:26:31,788 --> 00:26:34,080
Do the same thing when you're
referring to transactions

591
00:26:34,080 --> 00:26:36,100
themselves as txids.

592
00:26:36,100 --> 00:26:38,852
So in the exact same way
that when you're signing,

593
00:26:38,852 --> 00:26:40,560
you hash the data
without the signatures.

594
00:26:40,560 --> 00:26:42,420
When you're pointing
to a transaction

595
00:26:42,420 --> 00:26:44,490
to say I'm spending
from there, also

596
00:26:44,490 --> 00:26:46,680
don't include the
signature data.

597
00:26:46,680 --> 00:26:51,292
Just take the hash of the
data without the signatures.

598
00:26:55,530 --> 00:26:56,030
Yeah.

599
00:26:56,030 --> 00:26:57,980
You just sort of
have this pointer.

600
00:26:57,980 --> 00:27:00,860
You've got a pointer
of previous input

601
00:27:00,860 --> 00:27:03,750
and you've got the outputs, but
the signatures aren't in there.

602
00:27:03,750 --> 00:27:06,750
So the idea is the signature can
change and the transaction ID

603
00:27:06,750 --> 00:27:07,250
doesn't.

604
00:27:10,900 --> 00:27:12,860
But what about
backwards compatibility?

605
00:27:12,860 --> 00:27:14,600
So this is a great idea.

606
00:27:14,600 --> 00:27:15,670
Why not go for it?

607
00:27:15,670 --> 00:27:20,380
But how do you make it backwards
compatible so that old software

608
00:27:20,380 --> 00:27:23,230
can still work with it?

609
00:27:23,230 --> 00:27:26,880
This seems like a
soft fork is I'm

610
00:27:26,880 --> 00:27:29,910
adding new rules to
the system I'm putting

611
00:27:29,910 --> 00:27:33,070
further restrictions on.

612
00:27:33,070 --> 00:27:35,260
This seems like just a change.

613
00:27:35,260 --> 00:27:38,372
It seems like, look,
I'm now defining

614
00:27:38,372 --> 00:27:39,580
something in a different way.

615
00:27:39,580 --> 00:27:41,980
I'm removing the
signatures from the txid.

616
00:27:41,980 --> 00:27:45,220
How do we make this not
appear to be a hard fork?

617
00:27:45,220 --> 00:27:46,312
Hard fork's easy.

618
00:27:46,312 --> 00:27:48,520
You just say, look, we're
changing the entire system.

619
00:27:48,520 --> 00:27:52,350
From now on txids
don't have signatures.

620
00:27:52,350 --> 00:27:58,520
So any ideas how you do this
in a backwards compatible way

621
00:27:58,520 --> 00:27:59,930
or just give up hard fork?

622
00:28:03,834 --> 00:28:09,520
AUDIENCE: Adding restrictions
that screw with [INAUDIBLE]..

623
00:28:09,520 --> 00:28:13,830
PROFESSOR: So you can't
change old transactions,

624
00:28:13,830 --> 00:28:15,900
but having both at the
same time is tricky.

625
00:28:18,453 --> 00:28:20,120
So the idea is it
would have been easier

626
00:28:20,120 --> 00:28:21,470
to start off this way.

627
00:28:21,470 --> 00:28:24,293
If Satoshi had just started this
way, it would have went great.

628
00:28:24,293 --> 00:28:25,210
He didn't think of it.

629
00:28:25,210 --> 00:28:27,607
It wasn't a super
obvious thing that--

630
00:28:27,607 --> 00:28:28,940
so you can do it as a soft fork.

631
00:28:28,940 --> 00:28:32,150
The way you do it is
you make new outputs

632
00:28:32,150 --> 00:28:34,580
which don't require
any signatures at all

633
00:28:34,580 --> 00:28:37,640
and then you just don't
have any signatures.

634
00:28:37,640 --> 00:28:38,690
This seems kind of silly.

635
00:28:38,690 --> 00:28:41,630
Signatures are pretty important,
otherwise any arbitrary person

636
00:28:41,630 --> 00:28:43,700
could just take all the money.

637
00:28:43,700 --> 00:28:46,490
But you redefine things in a
way that new people know about

638
00:28:46,490 --> 00:28:48,380
and old people don't.

639
00:28:48,380 --> 00:28:51,140
So this is actually what a
segwit output looks like.

640
00:28:51,140 --> 00:28:55,300
The output script is just a
zero and then a pubkey hash,

641
00:28:55,300 --> 00:28:58,300
and then the sig script,
the field for a signature

642
00:28:58,300 --> 00:28:59,500
is just nothing.

643
00:28:59,500 --> 00:29:03,030
You just don't put
a signature there.

644
00:29:03,030 --> 00:29:05,370
And then when you're
running the stack

645
00:29:05,370 --> 00:29:08,430
you end up with a pubkey hash
on the top of the stack, which

646
00:29:08,430 --> 00:29:12,270
is some number and
the interpreter

647
00:29:12,270 --> 00:29:15,480
looks at a number
that's non-zero as true.

648
00:29:15,480 --> 00:29:17,053
Like in C or things like that.

649
00:29:17,053 --> 00:29:17,970
And the bitcoins move.

650
00:29:17,970 --> 00:29:19,080
It's great.

651
00:29:19,080 --> 00:29:21,990
Someone was joking that you
could potentially make this

652
00:29:21,990 --> 00:29:27,160
into a hard fork, because what
if the pubkey hash was zero,

653
00:29:27,160 --> 00:29:30,868
and you found a pubkey that
hashed to zero and then you

654
00:29:30,868 --> 00:29:33,410
signed signed with it and then
segwit would accept it but old

655
00:29:33,410 --> 00:29:35,440
nodes wouldn't.

656
00:29:35,440 --> 00:29:38,040
Actually, that doesn't
work, but it's sort of--

657
00:29:38,040 --> 00:29:42,420
Anyway, if you're running
the regular bitcoin software,

658
00:29:42,420 --> 00:29:45,570
you see this and no signature,
and you're like yeah,

659
00:29:45,570 --> 00:29:47,010
this doesn't need a signature.

660
00:29:47,010 --> 00:29:48,720
It's just a hash.

661
00:29:48,720 --> 00:29:50,260
I don't know what this is.

662
00:29:50,260 --> 00:29:51,690
Fine, the coins move.

663
00:29:51,690 --> 00:29:54,600
It evaluates to true.

664
00:29:54,600 --> 00:29:57,600
But the new version
of the software

665
00:29:57,600 --> 00:29:59,777
sort of adds a restriction
to this kind of output.

666
00:29:59,777 --> 00:30:00,360
It says, look.

667
00:30:00,360 --> 00:30:02,490
If you see this,
this is a template.

668
00:30:02,490 --> 00:30:05,850
This doesn't actually mean
put a zero on the stack

669
00:30:05,850 --> 00:30:07,680
and put a pubkey
hash on the stack.

670
00:30:07,680 --> 00:30:09,690
It means something else.

671
00:30:09,690 --> 00:30:13,920
Now, it means this is a pubkey
hash and look for a signature.

672
00:30:13,920 --> 00:30:16,583
But look for a signature
in a different place.

673
00:30:16,583 --> 00:30:18,000
Don't actually put
it in the place

674
00:30:18,000 --> 00:30:19,500
you're supposed
to put signatures,

675
00:30:19,500 --> 00:30:20,640
put it in a new place.

676
00:30:20,640 --> 00:30:24,940
And don't tell the old
software about this place.

677
00:30:24,940 --> 00:30:30,000
We add a new field to
the transaction inputs.

678
00:30:30,000 --> 00:30:33,610
It's sort of in the inputs,
but they put it at the end.

679
00:30:33,610 --> 00:30:35,110
It's kind of weird.

680
00:30:35,110 --> 00:30:37,240
Logically, it's in the input.

681
00:30:37,240 --> 00:30:42,120
It's the same, but physically
it's not, which is silly.

682
00:30:42,120 --> 00:30:44,262
I don't like that aspect of it.

683
00:30:44,262 --> 00:30:46,720
But the idea is there's this
new field in the inputs called

684
00:30:46,720 --> 00:30:49,270
the witness field,
and in cryptography,

685
00:30:49,270 --> 00:30:53,320
witness sort of means
signature in this case anyway.

686
00:30:53,320 --> 00:30:56,300
It's a little bit more general.

687
00:30:56,300 --> 00:30:57,920
But the old software
never sees it.

688
00:30:57,920 --> 00:31:00,410
So the idea for here's the
old transaction format.

689
00:31:00,410 --> 00:31:04,790
You've got your tx id and
index, 36 bytes sort of pointer

690
00:31:04,790 --> 00:31:06,470
to what you're
spending, and then

691
00:31:06,470 --> 00:31:11,060
a signature which is 100 bytes,
and then this stays the same.

692
00:31:11,060 --> 00:31:12,350
And the new tx format.

693
00:31:12,350 --> 00:31:14,100
The idea is, yeah,
the signatures field

694
00:31:14,100 --> 00:31:14,930
is still there.

695
00:31:14,930 --> 00:31:16,370
You just leave it empty.

696
00:31:16,370 --> 00:31:17,880
So you're not putting
any signature.

697
00:31:17,880 --> 00:31:19,880
It doesn't look like you
need to put a signature

698
00:31:19,880 --> 00:31:21,680
to the old software.

699
00:31:21,680 --> 00:31:23,510
And then you have
this third thing,

700
00:31:23,510 --> 00:31:28,130
which is witness, which is the
same as signature basically.

701
00:31:28,130 --> 00:31:29,480
Slightly different format.

702
00:31:29,480 --> 00:31:31,760
And technically, they
put them all together

703
00:31:31,760 --> 00:31:33,802
and put it at the end,
which is kind of annoying.

704
00:31:33,802 --> 00:31:36,140
But anyway, logically
this is how they do it.

705
00:31:36,140 --> 00:31:39,350
They make a new version
of the transaction format.

706
00:31:39,350 --> 00:31:43,160
So the old version looks
like empty signatures.

707
00:31:43,160 --> 00:31:45,050
The new version
looks like here's

708
00:31:45,050 --> 00:31:46,702
this useless empty
signature field,

709
00:31:46,702 --> 00:31:48,410
and here's where the
real signatures are.

710
00:31:51,310 --> 00:31:53,820
And you omit this
to the old nodes.

711
00:31:53,820 --> 00:31:58,710
So when people ask for
witness transactions,

712
00:31:58,710 --> 00:32:01,507
when people know
about this new system,

713
00:32:01,507 --> 00:32:02,590
yeah, you give it to them.

714
00:32:02,590 --> 00:32:06,450
So they say hey, yeah, I'm
hip to this new segwit thing.

715
00:32:06,450 --> 00:32:08,070
Give me a segwit transaction.

716
00:32:08,070 --> 00:32:10,680
And you're like, OK, here's
the witnesses at the end.

717
00:32:10,680 --> 00:32:12,833
But when they don't
seem to know about this

718
00:32:12,833 --> 00:32:14,250
and they're running
older software

719
00:32:14,250 --> 00:32:16,250
and they say, hey, just
give me the transaction,

720
00:32:16,250 --> 00:32:18,400
you give it to them
without the witness at all.

721
00:32:18,400 --> 00:32:20,340
It still looks valid to--

722
00:32:20,340 --> 00:32:22,170
either one looks valid.

723
00:32:22,170 --> 00:32:28,380
However, the new people, they
know that if you see this,

724
00:32:28,380 --> 00:32:31,120
it does not mean push a
zero, push up pubkey has.

725
00:32:31,120 --> 00:32:33,120
There is a new rule that
no, this is a template.

726
00:32:33,120 --> 00:32:34,110
This is segwit.

727
00:32:34,110 --> 00:32:38,890
I need a signature, and I need
it to be in the witness field.

728
00:32:38,890 --> 00:32:44,250
So if a new node gets a
transaction without a witness

729
00:32:44,250 --> 00:32:47,580
that they know needs a witness,
they will declare it invalid.

730
00:32:47,580 --> 00:32:49,710
But the old nodes won't
be able to distinguish.

731
00:32:49,710 --> 00:32:52,260
They'll say, well, it looks like
no signature is needed here.

732
00:32:52,260 --> 00:32:53,250
OK.

733
00:32:53,250 --> 00:32:56,447
So you're sort of
tricking the old software

734
00:32:56,447 --> 00:32:58,530
into accepting things that
they shouldn't actually

735
00:32:58,530 --> 00:33:00,060
accept in some cases.

736
00:33:00,060 --> 00:33:02,250
There may not be a
valid signature that

737
00:33:02,250 --> 00:33:03,990
goes into the
segwit transaction,

738
00:33:03,990 --> 00:33:07,490
but old software will
still think it's OK.

739
00:33:07,490 --> 00:33:10,440
So this is how you make
it into a softfork.

740
00:33:10,440 --> 00:33:11,190
It's kind of ugly.

741
00:33:11,190 --> 00:33:11,962
But, yeah.

742
00:33:11,962 --> 00:33:12,920
Do you have a question?

743
00:33:12,920 --> 00:33:13,526
AUDIENCE: Yeah.

744
00:33:13,526 --> 00:33:14,568
Is this still implicitly?

745
00:33:14,568 --> 00:33:17,702
So when the signature
is zero, [INAUDIBLE]..

746
00:33:20,650 --> 00:33:28,150
PROFESSOR: No, because it's
based on the output script.

747
00:33:28,150 --> 00:33:31,870
You could make you a
different output script that

748
00:33:31,870 --> 00:33:34,570
would have a signature that
no signature requirement,

749
00:33:34,570 --> 00:33:37,630
and it would still work
even with this new system.

750
00:33:37,630 --> 00:33:39,240
So it's just based on--

751
00:33:39,240 --> 00:33:42,750
we changed the definition
of an output script.

752
00:33:42,750 --> 00:33:44,980
So have this sort of template.

753
00:33:44,980 --> 00:33:46,060
You can still do weird--

754
00:33:46,060 --> 00:33:49,750
like you could put
without a zero in front.

755
00:33:49,750 --> 00:33:51,900
You could put just
a pubkey hash,

756
00:33:51,900 --> 00:33:53,380
and that's not
defined in segwit.

757
00:33:53,380 --> 00:33:54,580
That's not defined anywhere.

758
00:33:54,580 --> 00:33:57,250
It would just be, OK,
yeah, it evaluates

759
00:33:57,250 --> 00:33:58,480
to true without a signature.

760
00:33:58,480 --> 00:34:00,090
Anyone can spend it.

761
00:34:00,090 --> 00:34:03,460
And you could do that--

762
00:34:03,460 --> 00:34:06,532
that would have to be a
non-segwit transaction.

763
00:34:06,532 --> 00:34:08,199
The only way to use
a segwit transaction

764
00:34:08,199 --> 00:34:12,500
is to have the special
format for the output script.

765
00:34:12,500 --> 00:34:14,620
Any other questions
about network stuff?

766
00:34:14,620 --> 00:34:20,480
Yeah, and this
solves malleability

767
00:34:20,480 --> 00:34:22,010
in a pretty good way.

768
00:34:22,010 --> 00:34:24,157
For the old software,
the old nodes,

769
00:34:24,157 --> 00:34:25,699
well, they can't
change the signature

770
00:34:25,699 --> 00:34:26,699
because there isn't one.

771
00:34:26,699 --> 00:34:29,120
There's nothing to malleate.

772
00:34:29,120 --> 00:34:31,070
And from the new
node's perspective,

773
00:34:31,070 --> 00:34:33,949
yes, the signature can
change, but that doesn't

774
00:34:33,949 --> 00:34:35,449
affect the transaction ID.

775
00:34:35,449 --> 00:34:38,090
Both old and new
nodes still agree

776
00:34:38,090 --> 00:34:40,489
on the exact same
transaction ID.

777
00:34:40,489 --> 00:34:46,320
The transaction ID does not
include the witness field.

778
00:34:46,320 --> 00:34:48,520
So when you're
calculating a transaction,

779
00:34:48,520 --> 00:34:50,260
you include all
this for backwards.

780
00:34:50,260 --> 00:34:52,052
And if there's this
actual signature there,

781
00:34:52,052 --> 00:34:54,060
that gets into that the txid.

782
00:34:54,060 --> 00:34:55,860
But if you're using
empty signature

783
00:34:55,860 --> 00:34:58,820
and only using witness, then
it doesn't get into the txid

784
00:34:58,820 --> 00:35:00,470
at all.

785
00:35:00,470 --> 00:35:03,110
So both old and
new software agree,

786
00:35:03,110 --> 00:35:06,530
and that's important, because
if they didn't the merkle routes

787
00:35:06,530 --> 00:35:07,320
would look wrong.

788
00:35:07,320 --> 00:35:09,528
You take all the txids, put
them into a merkle route,

789
00:35:09,528 --> 00:35:10,800
put that in the header.

790
00:35:10,800 --> 00:35:13,790
And that's really important
that everyone agrees on that.

791
00:35:13,790 --> 00:35:16,010
So they do work
together, So that's cool.

792
00:35:19,620 --> 00:35:21,360
So this is kind of interesting.

793
00:35:21,360 --> 00:35:24,750
You've got two
different old version,

794
00:35:24,750 --> 00:35:28,050
new version operating at the
same time on the network.

795
00:35:28,050 --> 00:35:30,180
And they agree on
a lot of stuff,

796
00:35:30,180 --> 00:35:32,475
but they also sort of
disagree on some things.

797
00:35:32,475 --> 00:35:35,970
So they agree on outputs
of the transactions,

798
00:35:35,970 --> 00:35:38,485
and they agree on
which inputs there are.

799
00:35:38,485 --> 00:35:40,110
But they have a
slightly different view

800
00:35:40,110 --> 00:35:41,152
of what these inputs are.

801
00:35:41,152 --> 00:35:42,940
Some of them think,
no signatures here.

802
00:35:42,940 --> 00:35:45,065
Some of them think, yeah,
there's a signature here.

803
00:35:45,065 --> 00:35:46,170
That's weird.

804
00:35:46,170 --> 00:35:48,150
They don't agree on
how things got spent.

805
00:35:48,150 --> 00:35:51,090
What are some other things that
these two different classes

806
00:35:51,090 --> 00:35:52,724
of nodes would not agree on?

807
00:35:55,470 --> 00:35:56,740
Any ideas?

808
00:35:56,740 --> 00:36:00,310
So you understand how they
see different transactions.

809
00:36:00,310 --> 00:36:02,660
What are some other
aspects that may

810
00:36:02,660 --> 00:36:05,470
be sort of interesting
for this consensus system

811
00:36:05,470 --> 00:36:08,160
that we have different views on?

812
00:36:08,160 --> 00:36:09,170
I forget what I put.

813
00:36:09,170 --> 00:36:11,660
I put two things.

814
00:36:11,660 --> 00:36:13,604
Any?

815
00:36:13,604 --> 00:36:15,560
Hint.

816
00:36:15,560 --> 00:36:20,360
Biggest argument
since 2010 in bitcoin.

817
00:36:20,360 --> 00:36:23,320
What do these two different
classes of nodes not agree on?

818
00:36:26,603 --> 00:36:28,010
Yeah.

819
00:36:28,010 --> 00:36:29,420
AUDIENCE: Size?

820
00:36:29,420 --> 00:36:31,050
PROFESSOR: Well, the
transaction size.

821
00:36:31,050 --> 00:36:31,550
Yeah.

822
00:36:31,550 --> 00:36:34,640
So they both see two
different transactions.

823
00:36:34,640 --> 00:36:36,890
One of them sees it with
these signatures, one of them

824
00:36:36,890 --> 00:36:38,030
sees it without.

825
00:36:38,030 --> 00:36:40,160
They don't agree on how
big the transaction is.

826
00:36:40,160 --> 00:36:41,920
They agree on the txid.

827
00:36:41,920 --> 00:36:44,583
They agree on where the money is
going, where it's coming from,

828
00:36:44,583 --> 00:36:46,250
but they have completely
different views

829
00:36:46,250 --> 00:36:50,190
of how big this transaction is
in terms of number of bytes.

830
00:36:50,190 --> 00:36:55,780
So this is really interesting,
For many, many years

831
00:36:55,780 --> 00:36:58,300
since 2010, everyone's
been arguing.

832
00:36:58,300 --> 00:37:00,070
And one of the big
aspects of, oh, if we

833
00:37:00,070 --> 00:37:02,980
want to increase the block
size, that's a hard fork.

834
00:37:02,980 --> 00:37:06,220
Everyone up to now,
we're enforcing.

835
00:37:06,220 --> 00:37:09,693
The block size must be
one million bytes or less.

836
00:37:09,693 --> 00:37:11,110
There's no way
around that, right?

837
00:37:11,110 --> 00:37:12,377
You can't just increase it.

838
00:37:12,377 --> 00:37:13,210
We've got this rule.

839
00:37:13,210 --> 00:37:15,050
You're breaking that rule.

840
00:37:15,050 --> 00:37:18,850
This is a sneaky way to break
the rule but still not tell

841
00:37:18,850 --> 00:37:21,170
people you're breaking the rule.

842
00:37:21,170 --> 00:37:25,087
Say, OK, I'm enforcing a rule
that there's one million bytes.

843
00:37:25,087 --> 00:37:27,670
As far as I'm concerned, there
are less than one million bytes

844
00:37:27,670 --> 00:37:30,100
in this set of transactions.

845
00:37:30,100 --> 00:37:32,530
The new nodes know, yeah,
there's more than one million.

846
00:37:32,530 --> 00:37:34,270
There's like two
million bytes in here.

847
00:37:34,270 --> 00:37:37,690
We just didn't tell
the old software

848
00:37:37,690 --> 00:37:39,620
about all these extra bytes.

849
00:37:39,620 --> 00:37:43,300
So this is kind of an
interesting thing you can do.

850
00:37:43,300 --> 00:37:46,030
So you can increase
the transaction size

851
00:37:46,030 --> 00:37:47,890
without telling the old nodes.

852
00:37:47,890 --> 00:37:52,350
So yeah, the old nodes don't
see the hundred something bytes

853
00:37:52,350 --> 00:37:53,870
with the pubkey signature.

854
00:37:53,870 --> 00:37:56,940
So they see transactions
that are much smaller.

855
00:37:56,940 --> 00:37:58,380
Around half the size--

856
00:37:58,380 --> 00:38:01,770
depends, but half the size ish.

857
00:38:01,770 --> 00:38:04,260
So those bytes, they
won't count those bites

858
00:38:04,260 --> 00:38:07,890
towards the one million
byte block size limit.

859
00:38:07,890 --> 00:38:11,310
So this ends up being
a soft fork that allows

860
00:38:11,310 --> 00:38:12,960
you to increase the block size.

861
00:38:12,960 --> 00:38:14,310
In a kind of sneaky way, right?

862
00:38:14,310 --> 00:38:17,190
The old nodes don't think
the block size is increased.

863
00:38:17,190 --> 00:38:21,347
They think it's less than a
megabyte, and they also think,

864
00:38:21,347 --> 00:38:21,930
this is weird.

865
00:38:21,930 --> 00:38:24,210
I haven't seen any
signatures for a while.

866
00:38:24,210 --> 00:38:27,420
| seems to be using these
transactions that don't require

867
00:38:27,420 --> 00:38:29,130
signatures, and
somehow everyone's

868
00:38:29,130 --> 00:38:31,530
getting along and not
stealing each other's money

869
00:38:31,530 --> 00:38:34,830
despite the lack of a
need for signatures.

870
00:38:34,830 --> 00:38:38,430
But these are not
intelligent people.

871
00:38:38,430 --> 00:38:41,820
These are software programs,
and it'll just run.

872
00:38:41,820 --> 00:38:43,830
And it'll, OK, yup, yup, yup.

873
00:38:43,830 --> 00:38:46,555
This evaluates to true.

874
00:38:46,555 --> 00:38:47,430
So it's kind of cool.

875
00:38:47,430 --> 00:38:49,750
Block size entry softfork.

876
00:38:49,750 --> 00:38:54,450
However, you Institute
a new rule with segwit.

877
00:38:54,450 --> 00:38:58,470
You don't want to just
say for the new rules,

878
00:38:58,470 --> 00:39:00,870
we don't count signatures
towards the one megabyte limit,

879
00:39:00,870 --> 00:39:01,770
right?

880
00:39:01,770 --> 00:39:05,310
You could do that, but then
people might spam signatures.

881
00:39:05,310 --> 00:39:08,010
Let me make a giant signature
or some kind of like 50

882
00:39:08,010 --> 00:39:12,870
out of a million pubkeys
thing and spam the network,

883
00:39:12,870 --> 00:39:17,187
and then it will still be under
a megabyte of non witness data.

884
00:39:17,187 --> 00:39:19,020
So yes, so now I've got
two classes of data.

885
00:39:19,020 --> 00:39:21,720
You've got all the data
that everyone sees,

886
00:39:21,720 --> 00:39:25,050
and all the witness data
that only the new nodes see.

887
00:39:25,050 --> 00:39:28,650
So what they did is they said,
OK, the witness data still

888
00:39:28,650 --> 00:39:30,460
counts towards that limit.

889
00:39:30,460 --> 00:39:34,800
But each witness byte counts
as a 1/4 of a regular byte.

890
00:39:34,800 --> 00:39:37,290
OK, kind of weird, but yeah.

891
00:39:37,290 --> 00:39:40,650
So in practice in the software,
what they do is they say, OK.

892
00:39:40,650 --> 00:39:45,240
We multiply the non
witness bytes by four.

893
00:39:45,240 --> 00:39:49,020
So every byte in the outputs
and every byte in the txid input

894
00:39:49,020 --> 00:39:51,090
things counts as
like four bytes.

895
00:39:51,090 --> 00:39:53,790
And then, the witnesses just
count as one regular byte.

896
00:39:53,790 --> 00:39:55,830
And then we now say,
OK, the new block size

897
00:39:55,830 --> 00:39:58,000
is four million bytes.

898
00:39:58,000 --> 00:40:02,410
But four million weight units,
because they're sort of, OK,

899
00:40:02,410 --> 00:40:04,780
we've got different
weights for things.

900
00:40:04,780 --> 00:40:09,920
This actually makes sense,
because the utxo set

901
00:40:09,920 --> 00:40:11,980
is what you really
want to minimize,

902
00:40:11,980 --> 00:40:14,560
that database we keep
updating every block.

903
00:40:14,560 --> 00:40:18,100
And the signatures don't
go into the utxo set.

904
00:40:18,100 --> 00:40:19,600
So the signatures
you don't actually

905
00:40:19,600 --> 00:40:23,600
have to store on a fast,
low latency storage.

906
00:40:23,600 --> 00:40:26,200
So in a very real
sense, the signatures

907
00:40:26,200 --> 00:40:28,570
are sort of OK to make bigger.

908
00:40:28,570 --> 00:40:31,690
They don't really cost as
much to the network to store.

909
00:40:31,690 --> 00:40:33,770
So having this
discount where you say,

910
00:40:33,770 --> 00:40:36,752
OK, the signatures, you can
have a bunch of them that

911
00:40:36,752 --> 00:40:37,960
doesn't really count as much.

912
00:40:37,960 --> 00:40:41,160
But the outputs we
really need to minimize.

913
00:40:41,160 --> 00:40:44,440
So this one fourth is
somewhat arbitrary,

914
00:40:44,440 --> 00:40:46,950
but there are some calculations
and a little handwaving.

915
00:40:46,950 --> 00:40:48,950
But it's like yeah, this
is about what it should

916
00:40:48,950 --> 00:40:52,520
be to try to balance things.

917
00:40:52,520 --> 00:40:55,450
So the end result. If
you have this discount,

918
00:40:55,450 --> 00:40:58,510
you can put about 80% more
transactions in a block.

919
00:40:58,510 --> 00:41:01,030
You get about 1.8 megs.

920
00:41:01,030 --> 00:41:01,780
It depends, right?

921
00:41:01,780 --> 00:41:03,405
It depends how big
your signatures are.

922
00:41:05,750 --> 00:41:08,360
So the maximum would be
you have a block that

923
00:41:08,360 --> 00:41:13,490
has one transaction with
just a giant signature that's

924
00:41:13,490 --> 00:41:15,330
like almost four megabytes.

925
00:41:15,330 --> 00:41:17,390
And the old software
would see this block

926
00:41:17,390 --> 00:41:19,593
as being really tiny,
like 100 something bytes.

927
00:41:19,593 --> 00:41:21,260
And the new software
would see, oh yeah,

928
00:41:21,260 --> 00:41:23,990
this block is almost
four megabytes.

929
00:41:23,990 --> 00:41:25,730
But that's sort of
the extreme case.

930
00:41:25,730 --> 00:41:29,930
I remember generating some
like 3.7 meg transaction blocks

931
00:41:29,930 --> 00:41:32,810
and testing that awhile
ago just to test it out.

932
00:41:32,810 --> 00:41:35,710
It works, but in practice
you're seeing about this.

933
00:41:35,710 --> 00:41:39,860
In practice today, as segwit
has been seeing more adoption,

934
00:41:39,860 --> 00:41:42,410
you see like 1.3
megabyte blocks.

935
00:41:42,410 --> 00:41:44,157
Not everyone's using it.

936
00:41:44,157 --> 00:41:45,740
The idea is it's
backwards compatible,

937
00:41:45,740 --> 00:41:47,407
but you can still use
your old software.

938
00:41:47,407 --> 00:41:51,020
But it seems like more and
more software is using this.

939
00:41:51,020 --> 00:41:54,500
You get a discount on your
fees because your transaction

940
00:41:54,500 --> 00:41:55,670
seems to be smaller.

941
00:41:55,670 --> 00:41:57,253
You can fit more
of them in a block.

942
00:41:57,253 --> 00:41:58,670
So that's kind of
cool, and that's

943
00:41:58,670 --> 00:41:59,962
sort of an incentive to use it.

944
00:42:02,410 --> 00:42:04,320
OK, other thing you can do.

945
00:42:04,320 --> 00:42:07,020
You can commit to signatures.

946
00:42:07,020 --> 00:42:09,570
This is a little tricky.

947
00:42:09,570 --> 00:42:12,390
If the signatures aren't
in the transaction ID,

948
00:42:12,390 --> 00:42:15,330
then they aren't in the
merkle route, right?

949
00:42:15,330 --> 00:42:17,850
So there's nothing really
committing the signatures

950
00:42:17,850 --> 00:42:19,410
into the block chain.

951
00:42:19,410 --> 00:42:21,487
And this would actually work.

952
00:42:21,487 --> 00:42:23,070
You could say, no,
I have a signature.

953
00:42:23,070 --> 00:42:26,430
I'll give it to you,
but it could change.

954
00:42:26,430 --> 00:42:29,100
It could be maleated, so
it could be weird, though.

955
00:42:29,100 --> 00:42:31,770
You could agree on a utxo
set, but you could disagree

956
00:42:31,770 --> 00:42:33,630
on how exactly you got there.

957
00:42:33,630 --> 00:42:37,230
So one example
would be multisig,

958
00:42:37,230 --> 00:42:40,020
where there's two of three
multisig, Alice, Bob and Carol.

959
00:42:40,020 --> 00:42:41,610
Two of them need to sign.

960
00:42:41,610 --> 00:42:44,390
And then on my computer, it
says that Alice and Bob signed,

961
00:42:44,390 --> 00:42:47,550
and on your computer, it says
that Alison and Carol signed.

962
00:42:47,550 --> 00:42:49,740
That's weird, right?

963
00:42:49,740 --> 00:42:50,640
For accountability.

964
00:42:50,640 --> 00:42:53,850
If we want to know who
exactly endorsed these things,

965
00:42:53,850 --> 00:42:55,550
we might disagree on it.

966
00:42:55,550 --> 00:42:58,290
There would be no canonical
here's the blockchain,

967
00:42:58,290 --> 00:42:59,288
here's who signed.

968
00:42:59,288 --> 00:43:01,080
The transactions
themselves would all still

969
00:43:01,080 --> 00:43:03,430
be the same but
not the signatures.

970
00:43:03,430 --> 00:43:06,480
So that's kind of weird,
but it also seems like well,

971
00:43:06,480 --> 00:43:10,380
maybe that's part of the price
you pay for fixing malleability

972
00:43:10,380 --> 00:43:11,100
in this way.

973
00:43:11,100 --> 00:43:14,940
If we're not putting the
signatures into the thing that

974
00:43:14,940 --> 00:43:18,370
gets committed to in the
block chain, then yeah,

975
00:43:18,370 --> 00:43:20,170
signatures can change.

976
00:43:20,170 --> 00:43:23,960
So anyway around this?

977
00:43:23,960 --> 00:43:28,060
It sort of seems like
yeah, that's the trade off.

978
00:43:28,060 --> 00:43:29,700
Sneaky way around it?

979
00:43:29,700 --> 00:43:30,306
Sneaky fun?

980
00:43:30,306 --> 00:43:31,220
No?

981
00:43:31,220 --> 00:43:33,420
You know.

982
00:43:33,420 --> 00:43:41,178
OK, so what you do actually,
you commit the signatures

983
00:43:41,178 --> 00:43:41,970
but in a weird way.

984
00:43:41,970 --> 00:43:44,350
OK, so here's the regular
old merkle tree, right?

985
00:43:44,350 --> 00:43:47,570
This is the merkle route
that you put in the header.

986
00:43:47,570 --> 00:43:51,220
Here's all the transaction
IDs, and so you

987
00:43:51,220 --> 00:43:53,112
make these intermediate hashes.

988
00:43:53,112 --> 00:43:55,570
This is the hash of these two
things concatenated together,

989
00:43:55,570 --> 00:44:00,010
this is the hash of these two
things concatenated together.

990
00:44:00,010 --> 00:44:02,650
Now, if the txids
don't have signatures,

991
00:44:02,650 --> 00:44:06,000
there's no commitment to the
signatures in the top hash.

992
00:44:06,000 --> 00:44:07,445
What you do is this.

993
00:44:07,445 --> 00:44:08,920
You say, OK.

994
00:44:08,920 --> 00:44:10,860
I'm going to make
these new witness

995
00:44:10,860 --> 00:44:16,195
txids, hashes of transactions
that do include the signatures.

996
00:44:16,195 --> 00:44:18,820
In practice, you could just make
a hash of just the signatures.

997
00:44:18,820 --> 00:44:19,930
That would also work.

998
00:44:19,930 --> 00:44:22,960
They just take the whole thing.

999
00:44:22,960 --> 00:44:27,100
And now I've got
this other reflected

1000
00:44:27,100 --> 00:44:29,170
merkle tree kind of
thing, where OK, I

1001
00:44:29,170 --> 00:44:33,070
take the hash of these two
witness transaction IDs,

1002
00:44:33,070 --> 00:44:35,770
put it here, and this
one just drops down.

1003
00:44:35,770 --> 00:44:37,720
It's another merkle
tree, and then you

1004
00:44:37,720 --> 00:44:41,500
get a root for all those
things called the witness root.

1005
00:44:41,500 --> 00:44:43,900
And then what you do is
you put the witness root

1006
00:44:43,900 --> 00:44:46,420
in the coinbase transaction.

1007
00:44:46,420 --> 00:44:47,710
Put in an opp return.

1008
00:44:47,710 --> 00:44:50,410
And the idea is the
coinbase transaction

1009
00:44:50,410 --> 00:44:52,390
doesn't have any
signatures anyway, right?

1010
00:44:52,390 --> 00:44:55,720
So you can put it in there.

1011
00:44:55,720 --> 00:44:58,600
You don't need to
include the transaction

1012
00:44:58,600 --> 00:45:01,415
zero in this witness tree.

1013
00:45:01,415 --> 00:45:04,180
Wait, they do though, right?

1014
00:45:04,180 --> 00:45:09,220
But maybe this is slightly
inaccurate in that I think

1015
00:45:09,220 --> 00:45:12,430
they actually do
make a witness txid

1016
00:45:12,430 --> 00:45:14,470
for the coinbase transaction,
but they define it

1017
00:45:14,470 --> 00:45:18,264
as being zero or something.

1018
00:45:18,264 --> 00:45:20,035
I think-- I don't remember.

1019
00:45:20,035 --> 00:45:20,910
So it's weird, right?

1020
00:45:20,910 --> 00:45:24,010
But you could do that.

1021
00:45:24,010 --> 00:45:26,500
They define a zero, or they
let you pick anything you want.

1022
00:45:26,500 --> 00:45:27,940
I would have to
look at the code.

1023
00:45:27,940 --> 00:45:32,100
But anyway, the basic
idea is for these anyway,

1024
00:45:32,100 --> 00:45:34,950
you take the hash of the whole
thing including the signatures,

1025
00:45:34,950 --> 00:45:37,260
put it in the witness
root, put the witness root

1026
00:45:37,260 --> 00:45:40,230
in the coinbase transaction, and
the coinbase this transaction

1027
00:45:40,230 --> 00:45:42,420
gets in to the merkle root.

1028
00:45:42,420 --> 00:45:45,570
So you are committing
to all the signatures

1029
00:45:45,570 --> 00:45:49,380
but on the block level,
not the transaction level.

1030
00:45:49,380 --> 00:45:53,750
So in the case where I
think Alice and Bob signed.

1031
00:45:53,750 --> 00:45:56,010
Oh, I think Alice
and Carol signed.

1032
00:45:56,010 --> 00:45:58,440
You can have those two
transactions floating around

1033
00:45:58,440 --> 00:46:02,385
on the network, and
they have the same txid.

1034
00:46:02,385 --> 00:46:05,100
And so who knows which
one's getting into a block?

1035
00:46:05,100 --> 00:46:07,040
They look almost the same.

1036
00:46:07,040 --> 00:46:09,490
Some of the software won't
be able to pick between them.

1037
00:46:09,490 --> 00:46:12,480
However, once it gets
into a block, one of them

1038
00:46:12,480 --> 00:46:13,700
will be committed to.

1039
00:46:13,700 --> 00:46:17,710
It's like, oh, ended up
being Alice and Carol.

1040
00:46:17,710 --> 00:46:22,340
Those two signatures actually
got into the blockchain.

1041
00:46:22,340 --> 00:46:26,470
However, you could
prove, hey, no I

1042
00:46:26,470 --> 00:46:29,423
had this Alice Bob
signature, but then it

1043
00:46:29,423 --> 00:46:31,090
never got into the
blockchain, and maybe

1044
00:46:31,090 --> 00:46:32,030
you made it after the fact.

1045
00:46:32,030 --> 00:46:33,200
It never gets committed to.

1046
00:46:33,200 --> 00:46:33,540
Yeah.

1047
00:46:33,540 --> 00:46:34,960
AUDIENCE: Also, a
bunch of pool software

1048
00:46:34,960 --> 00:46:36,127
just doesn't always do this.

1049
00:46:36,430 --> 00:46:38,597
PROFESSOR: A bunch of pool
software doesn't do this?

1050
00:46:38,597 --> 00:46:39,240
What you mean?

1051
00:46:39,240 --> 00:46:40,615
AUDIENCE: It's
the responsibility

1052
00:46:40,615 --> 00:46:43,738
of the pool software to
make this construction,

1053
00:46:43,738 --> 00:46:46,673
but [INAUDIBLE]

1054
00:46:46,673 --> 00:46:48,590
PROFESSOR: Have it
implemented as in they just

1055
00:46:48,590 --> 00:46:49,465
don't support segwit?

1056
00:46:49,465 --> 00:46:51,524
AUDIENCE: No, so they
do the first part,

1057
00:46:51,524 --> 00:46:57,510
but [INAUDIBLE] segwit support.

1058
00:46:57,510 --> 00:47:00,150
PROFESSOR: OK, but wouldn't
that just not work?

1059
00:47:00,150 --> 00:47:00,650
How--

1060
00:47:00,650 --> 00:47:01,858
AUDIENCE: It works, because--

1061
00:47:01,858 --> 00:47:02,888
[INAUDIBLE]

1062
00:47:02,888 --> 00:47:05,180
PROFESSOR: But to the new
software, if you don't have--

1063
00:47:17,830 --> 00:47:19,330
so segwit is the
software, right?

1064
00:47:19,330 --> 00:47:22,370
You say, OK, we define
these new transaction types.

1065
00:47:22,370 --> 00:47:25,970
We define this template where
if you have a zero and then

1066
00:47:25,970 --> 00:47:27,900
this pubkey hash.

1067
00:47:27,900 --> 00:47:34,860
It also says, I require
the coinbase transaction

1068
00:47:34,860 --> 00:47:39,720
to have this output that
says, op return aa9c

1069
00:47:39,720 --> 00:47:42,900
whatever this little
four random bytes,

1070
00:47:42,900 --> 00:47:45,837
and then I'd require it to
have the witness root in here.

1071
00:47:45,837 --> 00:47:47,420
AUDIENCE: I'm guessing
they just don't

1072
00:47:47,420 --> 00:47:49,162
include segwit transactions?

1073
00:47:49,162 --> 00:47:50,620
PROFESSOR: So I've
seen that a lot.

1074
00:47:50,620 --> 00:47:51,540
Yeah, so a lot of--

1075
00:47:51,540 --> 00:47:52,415
AUDIENCE: [INAUDIBLE]

1076
00:47:52,415 --> 00:47:54,030
PROFESSOR: Yeah, a
lot of the software

1077
00:47:54,030 --> 00:47:56,807
says, I'm not going to do this.

1078
00:47:56,807 --> 00:47:58,140
So the other thing that's nice--

1079
00:47:58,140 --> 00:48:01,320
segwit transactions to old
software look non-standard.

1080
00:48:01,320 --> 00:48:03,990
So I mentioned before that
there's standardness rules

1081
00:48:03,990 --> 00:48:05,550
where, this looks weird.

1082
00:48:05,550 --> 00:48:06,930
I'm not going to mine it.

1083
00:48:06,930 --> 00:48:09,900
I'm not going to relay it to my
peers, but if I it in a block,

1084
00:48:09,900 --> 00:48:11,850
well, OK, fine.

1085
00:48:11,850 --> 00:48:14,742
So segwit transactions
look very non-standard.

1086
00:48:14,742 --> 00:48:16,200
It looks like
there's no signature.

1087
00:48:16,200 --> 00:48:16,960
That's weird.

1088
00:48:16,960 --> 00:48:19,110
There's this zero.

1089
00:48:19,110 --> 00:48:20,820
What's going on?

1090
00:48:20,820 --> 00:48:23,670
So yeah, you can you
can still run a miner

1091
00:48:23,670 --> 00:48:26,300
and just not even
know about segwit.

1092
00:48:26,300 --> 00:48:28,610
It's a little
dangerous, because you

1093
00:48:28,610 --> 00:48:32,360
might see a block that
is segwit invalid,

1094
00:48:32,360 --> 00:48:33,860
but you wouldn't
know it and so you

1095
00:48:33,860 --> 00:48:35,152
might try to mine on top of it.

1096
00:48:35,152 --> 00:48:36,820
So there are some
risks, but in general

1097
00:48:36,820 --> 00:48:38,990
if most people are
doing the right thing,

1098
00:48:38,990 --> 00:48:41,670
you could still mine without
knowing about this stuff.

1099
00:48:41,670 --> 00:48:47,090
So any questions about
committing to the signatures?

1100
00:48:47,090 --> 00:48:47,962
What else?

1101
00:48:47,962 --> 00:48:49,670
Oh yeah, so you've
got this upgrade path.

1102
00:48:49,670 --> 00:48:52,470
That's kind of cool.

1103
00:48:52,470 --> 00:48:56,780
So it defined zero
pubkey hash as hey,

1104
00:48:56,780 --> 00:49:01,220
this is now pay to
pubkey hash, right?

1105
00:49:01,220 --> 00:49:05,030
Interpret this weird
template as the regular hey,

1106
00:49:05,030 --> 00:49:06,650
verify this signature.

1107
00:49:06,650 --> 00:49:09,590
It also, when segwit
softfork happened,

1108
00:49:09,590 --> 00:49:13,640
redefined a whole bunch of
other templates like this.

1109
00:49:13,640 --> 00:49:17,090
So one and then some data,
or two and then some data.

1110
00:49:17,090 --> 00:49:19,370
Just put a number, and
then put a bunch of data.

1111
00:49:19,370 --> 00:49:23,940
All of these are defined
as future upgrades.

1112
00:49:23,940 --> 00:49:29,400
So if you see a three block of
data, you now say, yeah, OK.

1113
00:49:29,400 --> 00:49:31,080
I know that's segwit
version three.

1114
00:49:31,080 --> 00:49:33,520
My software will maybe pop
up something saying hey,

1115
00:49:33,520 --> 00:49:35,220
people are using
segwit version three.

1116
00:49:35,220 --> 00:49:38,250
You're only aware of
segwit version zero.

1117
00:49:38,250 --> 00:49:40,080
But you'll consider
it non-standard.

1118
00:49:40,080 --> 00:49:41,220
You won't relay it.

1119
00:49:41,220 --> 00:49:43,020
But if it's in a
block, yeah, sure.

1120
00:49:43,020 --> 00:49:46,097
And you don't require
anything about the signature.

1121
00:49:46,097 --> 00:49:48,180
You'll just say, yeah,
whatever weird witness data

1122
00:49:48,180 --> 00:49:50,460
you provide for these
outputs, I don't

1123
00:49:50,460 --> 00:49:51,630
know how to interpret them.

1124
00:49:51,630 --> 00:49:54,270
I'm just going to let
it all go through.

1125
00:49:54,270 --> 00:49:56,040
What that means is--

1126
00:49:56,040 --> 00:49:57,353
there's no witness needed.

1127
00:49:57,353 --> 00:49:58,770
If a witness is
provided, you just

1128
00:49:58,770 --> 00:50:01,758
ignore it and you think
everything's fine.

1129
00:50:01,758 --> 00:50:02,925
This allows easier upgrades.

1130
00:50:05,840 --> 00:50:07,670
You have 16 new
versions to upgrade to.

1131
00:50:10,250 --> 00:50:13,223
Yeah, you don't require any
specific things about this,

1132
00:50:13,223 --> 00:50:15,890
so you can make new scripts, you
can make a completely different

1133
00:50:15,890 --> 00:50:16,720
script interpreter.

1134
00:50:16,720 --> 00:50:18,470
You could say, OK,
we're going to port EVM

1135
00:50:18,470 --> 00:50:22,400
to bitcoin and disable
some of the op codes

1136
00:50:22,400 --> 00:50:24,410
that don't apply, and
have that kind of thing.

1137
00:50:24,410 --> 00:50:25,670
Have new smart contracts.

1138
00:50:25,670 --> 00:50:28,610
So it's kind of a fun,
like yeah, we will--

1139
00:50:28,610 --> 00:50:30,502
and it's a nice,
easy upgrade path.

1140
00:50:30,502 --> 00:50:32,210
You could have multiple
different things,

1141
00:50:32,210 --> 00:50:34,010
things like that.

1142
00:50:34,010 --> 00:50:36,500
The code will be easier.

1143
00:50:36,500 --> 00:50:37,640
Don't do it today.

1144
00:50:37,640 --> 00:50:39,620
You could construct
an output that's

1145
00:50:39,620 --> 00:50:44,060
a two byte and then your
pubkey and send it out there.

1146
00:50:44,060 --> 00:50:48,610
It will be probably stealing by
miners, because everyone else's

1147
00:50:48,610 --> 00:50:51,110
node will say, yeah, I don't
know how to interpret this yet.

1148
00:50:51,110 --> 00:50:54,580
There's no rules about this yet.

1149
00:50:54,580 --> 00:51:01,990
OK, let me show you some
segwit stuff I looked for.

1150
00:51:06,800 --> 00:51:12,657
OK, so there's
actually nested segwit.

1151
00:51:12,657 --> 00:51:13,490
There's an an ugly--

1152
00:51:19,370 --> 00:51:20,750
I didn't like it, but--

1153
00:51:20,750 --> 00:51:25,982
this is like somewhat designed
by committee E. There's also--

1154
00:51:25,982 --> 00:51:28,830
this is 2016, right?

1155
00:51:28,830 --> 00:51:31,330
AUDIENCE: People lose so much
money on segwit two years ago.

1156
00:51:31,330 --> 00:51:34,105
PROFESSOR: So the other
thing I would say with this,

1157
00:51:34,105 --> 00:51:34,730
I was like, OK.

1158
00:51:34,730 --> 00:51:36,550
You've got this witness txid.

1159
00:51:36,550 --> 00:51:39,040
And I remember people
working on segwit

1160
00:51:39,040 --> 00:51:42,460
and I said, hey, why don't
you make the transaction IDs

1161
00:51:42,460 --> 00:51:46,580
a merkle tree of the
inputs and outputs instead

1162
00:51:46,580 --> 00:51:49,040
of just the hash of
everything all together?

1163
00:51:49,040 --> 00:51:51,190
Then, if you had a
really big transaction,

1164
00:51:51,190 --> 00:51:53,690
you could prove that an input
had been spent without sending

1165
00:51:53,690 --> 00:51:55,112
the whole transaction over.

1166
00:51:55,112 --> 00:51:56,570
And I thought that
was a cool idea.

1167
00:51:56,570 --> 00:51:58,737
And then when I talked to
people, they're like yeah,

1168
00:51:58,737 --> 00:52:01,280
Peter Todd already said
that like three weeks ago.

1169
00:52:01,280 --> 00:52:03,620
And whatever, we're
not going to do it.

1170
00:52:03,620 --> 00:52:04,400
It's too late.

1171
00:52:04,400 --> 00:52:05,720
We already coded stuff.

1172
00:52:05,720 --> 00:52:08,420
Oh well.

1173
00:52:08,420 --> 00:52:11,060
And that's the fundamental
aspect of segwit.

1174
00:52:11,060 --> 00:52:13,850
You can't really upgrade that
in the new script versions,

1175
00:52:13,850 --> 00:52:17,490
so whatever.

1176
00:52:17,490 --> 00:52:20,520
There's also still a hard rule
on transactions themselves

1177
00:52:20,520 --> 00:52:22,020
being less than a
megabyte, I think.

1178
00:52:22,020 --> 00:52:24,990
So it's not a huge deal,
but it would have been cool.

1179
00:52:24,990 --> 00:52:29,220
Another thing is
there's actually a way--

1180
00:52:29,220 --> 00:52:32,670
so there's no address
defined for this, right?

1181
00:52:32,670 --> 00:52:36,090
Address is mapped to output
scripts in all the software.

1182
00:52:36,090 --> 00:52:37,590
And so when you
say, OK, I'm sending

1183
00:52:37,590 --> 00:52:40,380
into 1aeecc or
whatever, it knows

1184
00:52:40,380 --> 00:52:43,680
how to interpret that address,
build the 20 byte pubkey hash

1185
00:52:43,680 --> 00:52:45,613
script, and send to it.

1186
00:52:45,613 --> 00:52:46,530
And vise versa, right?

1187
00:52:46,530 --> 00:52:48,697
So from the address, you
can get this output script,

1188
00:52:48,697 --> 00:52:51,330
and from the output script
you can get an address.

1189
00:52:51,330 --> 00:52:53,322
So when an old
software sees this,

1190
00:52:53,322 --> 00:52:54,780
it's just like,
there's no address.

1191
00:52:54,780 --> 00:52:56,280
I don't even know what that is.

1192
00:52:56,280 --> 00:52:58,470
I've never seen that.

1193
00:52:58,470 --> 00:53:01,510
And so people worried that
oh, it's going to be weird.

1194
00:53:01,510 --> 00:53:03,960
People are going to have to
upgrade to even send to people

1195
00:53:03,960 --> 00:53:05,473
using segwit.

1196
00:53:05,473 --> 00:53:07,890
So it's backwards compatible,
but if you want to say, hey,

1197
00:53:07,890 --> 00:53:11,888
send me some money at the segwit
address and then they can't.

1198
00:53:11,888 --> 00:53:12,930
And so you say, OK, fine.

1199
00:53:12,930 --> 00:53:14,638
Send me the money with
a regular address,

1200
00:53:14,638 --> 00:53:17,037
and then we still have
this malleability problem.

1201
00:53:17,037 --> 00:53:18,870
And then I have a wallet
that supports both,

1202
00:53:18,870 --> 00:53:20,580
and I can move money
to my own addresses,

1203
00:53:20,580 --> 00:53:21,510
and it's kind of ugly.

1204
00:53:21,510 --> 00:53:25,560
So they made this nested address
thing, which I don't like,

1205
00:53:25,560 --> 00:53:29,760
because then it
actually has both.

1206
00:53:29,760 --> 00:53:31,610
So you've got a
signature and a witness.

1207
00:53:34,340 --> 00:53:36,090
And the signature is
not a real signature.

1208
00:53:36,090 --> 00:53:37,507
It's just pointing
to the witness.

1209
00:53:37,507 --> 00:53:38,358
It's really ugly.

1210
00:53:38,358 --> 00:53:40,400
There's a bunch of weird
stuff in the segwit code

1211
00:53:40,400 --> 00:53:41,748
that I'm not super into.

1212
00:53:41,748 --> 00:53:43,290
I don't have to use
it though, right?

1213
00:53:43,290 --> 00:53:45,990
That's the beauty of these
permission-less innovation

1214
00:53:45,990 --> 00:53:46,660
kind of systems.

1215
00:53:46,660 --> 00:53:48,210
Like ew, I don't like that code.

1216
00:53:48,210 --> 00:53:49,402
OK, I'm not supporting it.

1217
00:53:53,740 --> 00:54:01,365
OK, so here's one that's nested.

1218
00:54:05,980 --> 00:54:12,280
So I was just randomly
looking through a block.

1219
00:54:12,280 --> 00:54:14,080
Here's one, and you
can see it's like, OK.

1220
00:54:14,080 --> 00:54:18,480
The outputs are probably
also nested segwit,

1221
00:54:18,480 --> 00:54:24,070
and the input has got both a
script sig and a tx witness,

1222
00:54:24,070 --> 00:54:24,615
right?

1223
00:54:24,615 --> 00:54:26,760
A tx input witness.

1224
00:54:26,760 --> 00:54:31,650
A pure one is this one f7.

1225
00:54:37,110 --> 00:54:40,365
OK, so you can see--

1226
00:54:40,365 --> 00:54:42,840
oh wait, am I not running--
what version am I running?

1227
00:54:42,840 --> 00:54:44,670
I think I'm running
to 15-1 still.

1228
00:54:44,670 --> 00:54:46,080
So I'm not seeing the address.

1229
00:54:46,080 --> 00:54:51,550
There's a new address format
called beck 32, bech 32,

1230
00:54:51,550 --> 00:54:53,660
which will turn--

1231
00:54:53,660 --> 00:55:00,370
so it's zero and
then a script hash.

1232
00:55:00,370 --> 00:55:03,930
Zero and then a pubkey hash.

1233
00:55:03,930 --> 00:55:06,010
It says, witness,
version zero, key hash.

1234
00:55:06,010 --> 00:55:08,220
There's also an address
associated with these.

1235
00:55:08,220 --> 00:55:12,850
I think this version of
bitcoin CLI does not show it,

1236
00:55:12,850 --> 00:55:14,330
but the new version does.

1237
00:55:14,330 --> 00:55:18,170
So I think if you guys have
version 0.16.0, it will show,

1238
00:55:18,170 --> 00:55:20,980
here's the address.

1239
00:55:20,980 --> 00:55:23,990
And then you can see
in the single input

1240
00:55:23,990 --> 00:55:27,430
for this transaction,
there is a tx in witness.

1241
00:55:27,430 --> 00:55:28,620
And there's no scripts.

1242
00:55:28,620 --> 00:55:31,490
There's a script sig
field, and it's just empty.

1243
00:55:31,490 --> 00:55:34,460
There's no actual
signature traditionally.

1244
00:55:34,460 --> 00:55:36,260
There's instead this big thing.

1245
00:55:36,260 --> 00:55:39,350
Here's the signature, and here's
the pubkey being revealed.

1246
00:55:39,350 --> 00:55:43,220
And then it also says,
OK, here's the txid

1247
00:55:43,220 --> 00:55:46,160
without the signature, and
then here's the hash or witness

1248
00:55:46,160 --> 00:55:47,053
transaction ID.

1249
00:55:47,053 --> 00:55:49,220
The hash of the whole thing
including the signature,

1250
00:55:49,220 --> 00:55:51,110
and they're different, right?

1251
00:55:51,110 --> 00:55:56,210
Also you've got size so this
is actually 235 bytes, right?

1252
00:55:56,210 --> 00:55:58,410
Because you're
including the witnesses.

1253
00:55:58,410 --> 00:56:03,080
And then, v size,
which is virtual size.

1254
00:56:03,080 --> 00:56:05,690
This is how big it looks
to old software that

1255
00:56:05,690 --> 00:56:08,450
doesn't know about segwit.

1256
00:56:08,450 --> 00:56:10,670
So the new software,
this knows about both.

1257
00:56:10,670 --> 00:56:15,740
The actual size or witness
size is 235, v size is 153.

1258
00:56:15,740 --> 00:56:19,465
So yeah, it's not quite
50%, because this one has

1259
00:56:19,465 --> 00:56:21,590
two outputs, and the outputs
don't get any smaller,

1260
00:56:21,590 --> 00:56:23,990
and the input just gets smaller.

1261
00:56:23,990 --> 00:56:26,860
And then, size, v
size, and then you

1262
00:56:26,860 --> 00:56:28,360
can see what block
it's in when we

1263
00:56:28,360 --> 00:56:30,144
get the coinbase transaction.

1264
00:56:43,300 --> 00:56:46,230
OK, so the first
transaction in the list

1265
00:56:46,230 --> 00:56:48,630
is going to be the
coinbase transaction.

1266
00:56:48,630 --> 00:56:51,390
And I can get that one.

1267
00:56:51,390 --> 00:56:55,980
And yeah, the
coinbase transaction

1268
00:56:55,980 --> 00:56:57,880
has a different txid and hash.

1269
00:56:57,880 --> 00:57:01,020
Its size is 259, its v size 232.

1270
00:57:01,020 --> 00:57:03,840
Coinbase has whatever
random data they want,

1271
00:57:03,840 --> 00:57:08,110
and there's the
actual output, which

1272
00:57:08,110 --> 00:57:12,280
is sending to this address,
and it's sending 12.79 coins.

1273
00:57:12,280 --> 00:57:14,080
And then, there's this
zero value output.

1274
00:57:14,080 --> 00:57:15,580
So you can have an
output that's got

1275
00:57:15,580 --> 00:57:17,760
an amount of coins set to zero.

1276
00:57:17,760 --> 00:57:19,720
It's still OK, and it's
got this op return.

1277
00:57:19,720 --> 00:57:22,840
And the op return
starts with aa21a9ed,

1278
00:57:22,840 --> 00:57:27,910
and those four bytes mean
here's the segwit commitment.

1279
00:57:27,910 --> 00:57:31,420
Here's the witness commitment
to the segwit transaction

1280
00:57:31,420 --> 00:57:35,490
hashes, the root of all those.

1281
00:57:35,490 --> 00:57:38,160
And you have to
have that in order

1282
00:57:38,160 --> 00:57:40,380
to have a valid segwit block.

1283
00:57:40,380 --> 00:57:42,120
And so then we can--

1284
00:57:42,120 --> 00:57:43,710
this is segwit in action.

1285
00:57:43,710 --> 00:57:45,525
I think most blocks
now will have that.

1286
00:57:48,050 --> 00:57:49,770
So there is size
and v size, right?

1287
00:57:49,770 --> 00:57:51,270
And that makes sense.

1288
00:57:51,270 --> 00:57:54,270
But then you have strip--

1289
00:57:54,270 --> 00:57:56,250
no, v size is not size.

1290
00:57:56,250 --> 00:57:57,390
It's really confusing.

1291
00:57:57,390 --> 00:58:02,600
And size, weight,
height, like what?

1292
00:58:02,600 --> 00:58:05,850
So size is--

1293
00:58:05,850 --> 00:58:07,300
I don't actually know.

1294
00:58:07,300 --> 00:58:09,210
I think size is
interpreted the same.

1295
00:58:09,210 --> 00:58:12,270
This is the actual number
of bytes for this block.

1296
00:58:12,270 --> 00:58:18,150
Weight is you multiply all
non witness bytes by four,

1297
00:58:18,150 --> 00:58:20,550
and you leave all witness
bytes as weight one,

1298
00:58:20,550 --> 00:58:22,300
and that has to be
less than four million.

1299
00:58:22,300 --> 00:58:25,110
And you can see here, it's
just under four million.

1300
00:58:25,110 --> 00:58:30,830
And then stripped size is
the size that old nodes see.

1301
00:58:30,830 --> 00:58:31,330
Yeah.

1302
00:58:31,330 --> 00:58:31,880
Pretty sure.

1303
00:58:31,880 --> 00:58:35,217
Anyway, so it's
kind of confusing.

1304
00:58:35,217 --> 00:58:36,800
One of the biggest
problems in bitcoin

1305
00:58:36,800 --> 00:58:38,590
is names, where it's like, wait.

1306
00:58:38,590 --> 00:58:41,520
Script pubkey, and
script sig script?

1307
00:58:41,520 --> 00:58:42,020
Like, what?

1308
00:58:42,020 --> 00:58:44,150
All these terms and names
are really confusing,

1309
00:58:44,150 --> 00:58:46,740
and it's sort of getting worse.

1310
00:58:46,740 --> 00:58:48,190
So yeah.

1311
00:58:48,190 --> 00:58:52,547
Also, there's no v size here.

1312
00:58:52,547 --> 00:58:53,880
I think this is actually v size.

1313
00:58:53,880 --> 00:58:59,010
Anyway, so that's how segwit
works in the actual thing.

1314
00:58:59,010 --> 00:59:01,890
But it's nice, because now you
can reliably spend from things

1315
00:59:01,890 --> 00:59:04,950
before they're confirmed.

1316
00:59:04,950 --> 00:59:07,260
So segwit is cool.

1317
00:59:07,260 --> 00:59:08,580
Fixes malleability.

1318
00:59:08,580 --> 00:59:10,600
Increases the block size.

1319
00:59:10,600 --> 00:59:12,780
Oh, it does a whole bunch
of other stuff, too.

1320
00:59:15,790 --> 00:59:18,990
OK, so one of the
aspects that it fixes.

1321
00:59:18,990 --> 00:59:22,220
When you're signing
a transaction,

1322
00:59:22,220 --> 00:59:24,570
let's say you have five inputs.

1323
00:59:27,360 --> 00:59:29,835
Each time you sign, you need
to hash the whole transaction,

1324
00:59:29,835 --> 00:59:31,460
because it's slightly
different, right?

1325
00:59:31,460 --> 00:59:33,297
You zero out all the
signature fields,

1326
00:59:33,297 --> 00:59:34,880
but in the signature
field for the one

1327
00:59:34,880 --> 00:59:36,838
you're actually signing,
you don't zero it out.

1328
00:59:36,838 --> 00:59:40,480
You put the previous
script there.

1329
00:59:40,480 --> 00:59:41,960
So it's slightly different.

1330
00:59:41,960 --> 00:59:43,645
It's totally redundant.

1331
00:59:43,645 --> 00:59:45,020
There's no reason
to put it there

1332
00:59:45,020 --> 00:59:46,395
because it's
already in the txid,

1333
00:59:46,395 --> 00:59:49,160
but you change things
around a little bit.

1334
00:59:49,160 --> 00:59:52,393
So the idea is, I'm going
to put a signature here,

1335
00:59:52,393 --> 00:59:53,810
I'm going to put
a signature here,

1336
00:59:53,810 --> 00:59:55,640
put a signature--
all five of them.

1337
00:59:55,640 --> 00:59:57,440
Each time I put
a signature here,

1338
00:59:57,440 --> 01:00:00,920
I hash the transaction to get
a slightly different thing

1339
01:00:00,920 --> 01:00:03,530
to sign for each one.

1340
01:00:03,530 --> 01:00:06,800
It might not jump out at
you, but this is actually

1341
01:00:06,800 --> 01:00:11,690
o and squared, which is bad.

1342
01:00:11,690 --> 01:00:15,080
Because the idea is, as I
extend the number of signatures

1343
01:00:15,080 --> 01:00:17,060
required in a transaction,
the number of inputs

1344
01:00:17,060 --> 01:00:21,350
in a transaction, the amount of
data that needs to be processed

1345
01:00:21,350 --> 01:00:24,580
goes up with the square
of the number of inputs.

1346
01:00:24,580 --> 01:00:26,420
Because I had an input.

1347
01:00:26,420 --> 01:00:29,470
Now, the total size of the
transaction gets bigger,

1348
01:00:29,470 --> 01:00:32,980
so each time I sign, I need to
take a bigger amount of data

1349
01:00:32,980 --> 01:00:34,180
through my hash function.

1350
01:00:34,180 --> 01:00:36,000
Also, the number of
signatures gets bigger.

1351
01:00:36,000 --> 01:00:37,000
Or the number of inputs.

1352
01:00:37,000 --> 01:00:38,770
So this is in squared.

1353
01:00:38,770 --> 01:00:39,730
It seems fine, right?

1354
01:00:39,730 --> 01:00:42,710
You never notice,
except when you do.

1355
01:00:42,710 --> 01:00:44,830
So there's pathological block.

1356
01:00:44,830 --> 01:00:47,862
There was one like 2015 early
in the year where some miner was

1357
01:00:47,862 --> 01:00:49,570
like, I'm going to
make this block that's

1358
01:00:49,570 --> 01:00:52,150
one giant transaction
with thousands

1359
01:00:52,150 --> 01:00:53,950
and thousands of inputs.

1360
01:00:53,950 --> 01:00:57,340
And a lot of software choked
on it, and it took gigs of RAM

1361
01:00:57,340 --> 01:01:00,350
to process the transaction,
and things like that.

1362
01:01:00,350 --> 01:01:01,930
So that was bad.

1363
01:01:01,930 --> 01:01:04,720
Just in general, if you have
a lot of little dust outputs,

1364
01:01:04,720 --> 01:01:07,210
if you're trying to
aggregate them into one big--

1365
01:01:07,210 --> 01:01:09,850
I'm going to have 100
inputs and one output,

1366
01:01:09,850 --> 01:01:12,130
it takes forever to sign.

1367
01:01:12,130 --> 01:01:13,630
And it also takes
forever to verify.

1368
01:01:13,630 --> 01:01:15,220
So it's pretty bad.

1369
01:01:15,220 --> 01:01:20,020
I remember sort
of a silly story.

1370
01:01:20,020 --> 01:01:21,220
Tim Draper's coins.

1371
01:01:21,220 --> 01:01:22,390
He had all this dust.

1372
01:01:22,390 --> 01:01:24,820
And it was nerve wracking,
because it was way more money

1373
01:01:24,820 --> 01:01:26,237
than I'm going to
make in my life.

1374
01:01:26,237 --> 01:01:28,810
And moving Tim Draper's
coins to somewhere else.

1375
01:01:28,810 --> 01:01:32,730
And the software by default
just swept all the inputs

1376
01:01:32,730 --> 01:01:34,670
with that wallet controlled.

1377
01:01:34,670 --> 01:01:37,210
And they were looking at me
like, why doesn't this work?

1378
01:01:37,210 --> 01:01:37,810
Is it frozen?

1379
01:01:37,810 --> 01:01:40,810
I'm like, no, I'm not trying
to steal the money, guys.

1380
01:01:40,810 --> 01:01:44,050
Because everyone was sending
all these little outputs to Tim

1381
01:01:44,050 --> 01:01:47,062
Draper's 30,000 coins or
whatever, because he's--

1382
01:01:47,062 --> 01:01:48,520
and then when he
tried to spend it,

1383
01:01:48,520 --> 01:01:50,213
it took five minutes to sign.

1384
01:01:50,213 --> 01:01:52,180
AUDIENCE: When
people use P2 pool,

1385
01:01:52,180 --> 01:01:53,847
the software really
struggles with this.

1386
01:01:53,847 --> 01:01:56,520
PROFESSOR: Yeah, so it's bad.

1387
01:01:56,520 --> 01:01:59,370
Any o event squared,
this is sort of a bug.

1388
01:01:59,370 --> 01:02:00,750
Segwit actually fixed this.

1389
01:02:00,750 --> 01:02:04,560
The way they do it
is they say, OK,

1390
01:02:04,560 --> 01:02:10,830
we sort of pre compute these
three intermediate hashes.

1391
01:02:10,830 --> 01:02:14,240
Take the whole transaction.

1392
01:02:14,240 --> 01:02:16,350
This is sort of the
global transaction data,

1393
01:02:16,350 --> 01:02:18,300
and pre compute
these three things.

1394
01:02:18,300 --> 01:02:21,860
And then for each of the
inputs, add another thing.

1395
01:02:21,860 --> 01:02:23,010
Here's this input specific.

1396
01:02:23,010 --> 01:02:25,340
So this is global.

1397
01:02:25,340 --> 01:02:28,170
It's the hash of all the
tx ends, the hash of all

1398
01:02:28,170 --> 01:02:30,450
the outputs, the hash of this.

1399
01:02:30,450 --> 01:02:32,690
And then here is that
the input specific.

1400
01:02:37,190 --> 01:02:38,270
Input specific.

1401
01:02:38,270 --> 01:02:41,300
And then hash all these
things into one thing

1402
01:02:41,300 --> 01:02:42,530
and then sign that.

1403
01:02:42,530 --> 01:02:45,278
So the idea is it's o of n in
that you compute these three

1404
01:02:45,278 --> 01:02:46,820
and then you sort
of go down and keep

1405
01:02:46,820 --> 01:02:48,530
changing this for each one.

1406
01:02:48,530 --> 01:02:50,630
So that saves a lot of time.

1407
01:02:50,630 --> 01:02:51,470
It's a much nicer--

1408
01:02:51,470 --> 01:02:57,490
oh, you also put in the amount
being spent in your signature

1409
01:02:57,490 --> 01:02:59,870
hash, which is also
redundant, because that's

1410
01:02:59,870 --> 01:03:02,120
committed to in the txid
that you're sending.

1411
01:03:02,120 --> 01:03:04,208
But it's really nice
for hardware wallets,

1412
01:03:04,208 --> 01:03:06,500
because a lot of times hardware
wallets are essentially

1413
01:03:06,500 --> 01:03:09,050
presented with here's a hash.

1414
01:03:09,050 --> 01:03:10,160
Sign it.

1415
01:03:10,160 --> 01:03:12,475
And it's a very small system.

1416
01:03:12,475 --> 01:03:14,600
It's a little chip somewhere,
and it doesn't really

1417
01:03:14,600 --> 01:03:15,870
know too much about bitcoin.

1418
01:03:15,870 --> 01:03:16,912
It's just, here's a hash.

1419
01:03:16,912 --> 01:03:17,540
Sign it.

1420
01:03:17,540 --> 01:03:20,393
OK, and they don't know
how much they're spending,

1421
01:03:20,393 --> 01:03:22,310
so there could be attacks
on hardware wallets,

1422
01:03:22,310 --> 01:03:24,710
where they get a hardware wallet
to sign something where it's

1423
01:03:24,710 --> 01:03:26,120
actually moving too much money.

1424
01:03:26,120 --> 01:03:29,100
So it's nice to be able
to have the actual amount.

1425
01:03:29,100 --> 01:03:30,830
So there's a bunch
of stuff like that.

1426
01:03:30,830 --> 01:03:33,860
It was a giant grab bag of all
these different little fixes,

1427
01:03:33,860 --> 01:03:35,420
things like that.

1428
01:03:35,420 --> 01:03:36,920
Fixes malleability.

1429
01:03:36,920 --> 01:03:38,520
It increases the block size.

1430
01:03:38,520 --> 01:03:40,430
Does all these
other cool things.

1431
01:03:40,430 --> 01:03:42,900
People didn't like it.

1432
01:03:42,900 --> 01:03:46,908
I never really understood why.

1433
01:03:46,908 --> 01:03:49,450
AUDIENCE: For the reasons you've
been telling everyone about?

1434
01:03:49,450 --> 01:03:50,050
PROFESSOR: All these reasons?

1435
01:03:50,050 --> 01:03:51,830
Wait, these seem like
good things, right?

1436
01:03:52,330 --> 01:03:55,777
AUDIENCE: Well,
yeah, but [INAUDIBLE]

1437
01:03:55,777 --> 01:03:56,360
PROFESSOR: Oh.

1438
01:03:56,360 --> 01:03:57,860
No, that wasn't what--

1439
01:03:57,860 --> 01:03:59,640
it wasn't like
people were like, oh,

1440
01:03:59,640 --> 01:04:01,640
here's some little things
I don't like about it.

1441
01:04:01,640 --> 01:04:02,897
Because that was what I said.

1442
01:04:02,897 --> 01:04:05,230
That was like what everyone
working on Bitcoin was like.

1443
01:04:05,230 --> 01:04:06,972
No one thinks it's perfect.

1444
01:04:06,972 --> 01:04:08,930
Everyone was like, oh,
but this thing is weird.

1445
01:04:08,930 --> 01:04:09,763
Why did you do that?

1446
01:04:09,763 --> 01:04:12,560
Or why didn't you put
this in kind of things.

1447
01:04:12,560 --> 01:04:16,210
But no, the people who didn't
like it really didn't like it.

1448
01:04:16,210 --> 01:04:20,310
There's still a bounty on
[INAUDIBLE] head, right?

1449
01:04:20,310 --> 01:04:21,400
There's death threats.

1450
01:04:21,400 --> 01:04:23,483
Someone's like, I'll pay
someone to kill this guy.

1451
01:04:26,780 --> 01:04:28,730
It's all, this is going
to destroy Bitcoin,

1452
01:04:28,730 --> 01:04:31,760
that segwit isn't
bitcoin anymore,

1453
01:04:31,760 --> 01:04:33,362
because there aren't
any signatures.

1454
01:04:33,362 --> 01:04:35,570
It's like no, signatures
are still committed to, just

1455
01:04:35,570 --> 01:04:36,440
in a different way.

1456
01:04:36,440 --> 01:04:37,857
You have to build
this other tree.

1457
01:04:39,350 --> 01:04:40,818
So lots of weird conspiracies.

1458
01:04:40,818 --> 01:04:41,360
I don't know.

1459
01:04:41,360 --> 01:04:44,900
It became this really
sticking point,

1460
01:04:44,900 --> 01:04:48,970
and so that sort of
led to Bitcoin Cash.

1461
01:04:48,970 --> 01:04:51,110
The whole idea is segwit is bad.

1462
01:04:51,110 --> 01:04:52,590
We're making Bitcoin Cash.

1463
01:04:52,590 --> 01:04:54,680
And Bitcoin Cash forked
off before segwit

1464
01:04:54,680 --> 01:04:57,680
activated in the main network.

1465
01:04:57,680 --> 01:05:00,685
Interestingly, Bitcoin
Cash uses this.

1466
01:05:00,685 --> 01:05:02,560
So they took a bunch of
the code from segwit,

1467
01:05:02,560 --> 01:05:05,010
because this is a
really good improvement

1468
01:05:05,010 --> 01:05:06,950
to signing that
Bitcoin Cash used,

1469
01:05:06,950 --> 01:05:09,680
but they didn't like segwit.

1470
01:05:09,680 --> 01:05:12,218
Yeah, I'm still not like--

1471
01:05:12,218 --> 01:05:12,760
I don't know.

1472
01:05:12,760 --> 01:05:15,340
There's problems I have with
it, too, but it's an upgrade,

1473
01:05:15,340 --> 01:05:16,890
and it's cool.

1474
01:05:16,890 --> 01:05:19,526
I think a lot of it was
people wanted a hard fork,

1475
01:05:19,526 --> 01:05:20,865
and this was a softfork.

1476
01:05:20,865 --> 01:05:22,490
And so there's
backwards compatibility,

1477
01:05:22,490 --> 01:05:25,480
and they wanted to
show that people

1478
01:05:25,480 --> 01:05:28,600
have more control over
bitcoin than they maybe do.

1479
01:05:28,600 --> 01:05:31,180
It might never be possible
to have a hard fork

1480
01:05:31,180 --> 01:05:33,190
to get everyone on
board to really switch.

1481
01:05:33,190 --> 01:05:34,540
So who knows.

1482
01:05:34,540 --> 01:05:36,430
So yeah, it was interesting.

1483
01:05:36,430 --> 01:05:40,420
It took forever, and
that was the last change

1484
01:05:40,420 --> 01:05:44,170
to the bitcoin code in
terms of consensus code.

1485
01:05:44,170 --> 01:05:49,240
And it was initially
announced late 2015

1486
01:05:49,240 --> 01:05:53,120
in Hong Kong, and
then all of 2016

1487
01:05:53,120 --> 01:05:56,050
it never-- so it activated
in August of last year.

1488
01:05:56,050 --> 01:05:57,068
And now you can use it.

1489
01:05:57,068 --> 01:05:59,110
AUDIENCE: People had big
interest in stopping it,

1490
01:05:59,110 --> 01:06:00,000
though.

1491
01:06:00,000 --> 01:06:02,950
At one point they were
spending hundreds of thousands

1492
01:06:02,950 --> 01:06:05,740
of dollars a day to
stop it from activating.

1493
01:06:05,740 --> 01:06:08,797
PROFESSOR: Yeah, so on your
vert coin, you're like,

1494
01:06:08,797 --> 01:06:11,380
I'll just take the segwit code
and activate it, and like cool.

1495
01:06:11,380 --> 01:06:13,570
And then people tried to stop
it and spend a lot of money

1496
01:06:13,570 --> 01:06:14,070
to stop it.

1497
01:06:17,050 --> 01:06:19,420
OK, I want to say unclear
why, because I don't know.

1498
01:06:19,420 --> 01:06:20,600
It's sort of weird.

1499
01:06:20,600 --> 01:06:21,970
There's a whole lot of opinions.

1500
01:06:21,970 --> 01:06:28,590
One theory is that
this breaks some mining

1501
01:06:28,590 --> 01:06:31,560
chips optimizations.

1502
01:06:31,560 --> 01:06:33,810
One of the optimizations--

1503
01:06:33,810 --> 01:06:35,960
it doesn't work with
a tree of height two.

1504
01:06:35,960 --> 01:06:40,710
But if you have a really tall
tree, you can swap txids,

1505
01:06:40,710 --> 01:06:43,380
or you can swap intermediate
nodes of the tree

1506
01:06:43,380 --> 01:06:46,140
and you'll get a
different merkle route.

1507
01:06:46,140 --> 01:06:48,720
So you can see--

1508
01:06:48,720 --> 01:06:51,270
so it doesn't work here, because
this has to stay in place.

1509
01:06:51,270 --> 01:06:55,440
But in many cases, the order of
the transactions is arbitrary.

1510
01:06:55,440 --> 01:06:57,450
So I could flip these two.

1511
01:06:57,450 --> 01:07:00,240
It's still valid.

1512
01:07:00,240 --> 01:07:02,430
So what I might do is say, OK.

1513
01:07:02,430 --> 01:07:05,130
I have this merkle
route I'm mining,

1514
01:07:05,130 --> 01:07:08,700
and then I want to flip
these two, calculate

1515
01:07:08,700 --> 01:07:10,290
a different merkle
route, and mine.

1516
01:07:10,290 --> 01:07:13,110
And there were some chips
that maybe did this and had

1517
01:07:13,110 --> 01:07:14,610
these kinds of optimizations.

1518
01:07:14,610 --> 01:07:17,130
There was also a patent on
it and all this weird stuff

1519
01:07:17,130 --> 01:07:19,510
going on.

1520
01:07:19,510 --> 01:07:22,080
It doesn't break,
but it essentially

1521
01:07:22,080 --> 01:07:23,940
loses the optimization
if you have this.

1522
01:07:23,940 --> 01:07:27,780
Because you're saying, OK, I'm
going to have this big tree.

1523
01:07:27,780 --> 01:07:30,570
I'm going to swap
something near the top,

1524
01:07:30,570 --> 01:07:32,610
and it only has to
recompute two hashes

1525
01:07:32,610 --> 01:07:34,770
to get a new merkle route.

1526
01:07:34,770 --> 01:07:40,260
However, if I now have this
mirror image witness merkle

1527
01:07:40,260 --> 01:07:43,770
tree underneath, if I say,
OK, I'm going to swap this,

1528
01:07:43,770 --> 01:07:45,090
I'm also swapping all these.

1529
01:07:45,090 --> 01:07:49,050
And I have to recompute this.

1530
01:07:49,050 --> 01:07:51,780
Maybe I can swap some of it, but
I have to recompute what this.

1531
01:07:51,780 --> 01:07:53,590
This is going to
change just as well.

1532
01:07:53,590 --> 01:07:54,660
And then I have to
put that in here,

1533
01:07:54,660 --> 01:07:56,090
and this is going
to be at the bottom.

1534
01:07:56,090 --> 01:07:58,215
And then, I'm going to have
to recompute everything

1535
01:07:58,215 --> 01:07:59,830
all the way up to
the merkle route.

1536
01:07:59,830 --> 01:08:04,140
So this was called AsicBoost,
and then there was a post--

1537
01:08:04,140 --> 01:08:07,125
Greg Maxwell posted
this sort of like,

1538
01:08:07,125 --> 01:08:12,390
you guys, like accusatory mail
on the mailing list last spring

1539
01:08:12,390 --> 01:08:13,590
saying, look.

1540
01:08:13,590 --> 01:08:17,490
We were trying to figure out
a way to break AsicBoost,

1541
01:08:17,490 --> 01:08:20,790
because we think miners have
this patented algorithm that

1542
01:08:20,790 --> 01:08:23,819
optimizes and it gives
a 20%, 30% speed up.

1543
01:08:23,819 --> 01:08:26,340
And we're worried that the
patents will make one miner,

1544
01:08:26,340 --> 01:08:28,930
have a monopoly, and everyone
else won't be competitive.

1545
01:08:28,930 --> 01:08:30,347
So we're trying
to think, is there

1546
01:08:30,347 --> 01:08:33,140
a way we make software
to prevent this

1547
01:08:33,140 --> 01:08:35,149
from this optimization?

1548
01:08:35,149 --> 01:08:37,220
And then once they
tried to look at it,

1549
01:08:37,220 --> 01:08:38,300
they were like, oh, wait.

1550
01:08:38,300 --> 01:08:39,640
Segwit does that.

1551
01:08:39,640 --> 01:08:43,310
We want to make it costly
to swap things in the tree,

1552
01:08:43,310 --> 01:08:44,450
and segwit does that.

1553
01:08:44,450 --> 01:08:46,220
Oh, so basically, we're good.

1554
01:08:46,220 --> 01:08:47,630
And then he was like, oh, wait.

1555
01:08:47,630 --> 01:08:50,210
Maybe that's why all
these people hate segwit.

1556
01:08:50,210 --> 01:08:54,439
Maybe this is these miners
who have billions of dollars

1557
01:08:54,439 --> 01:08:57,170
worth of equipment with
these optimizations in it,

1558
01:08:57,170 --> 01:09:01,609
which would be rendered unusable
by this new software change,

1559
01:09:01,609 --> 01:09:04,580
maybe they're trying to
prevent it from activating.

1560
01:09:04,580 --> 01:09:07,010
It's a theory, and the
mining companies said,

1561
01:09:07,010 --> 01:09:09,319
oh, no that's a
bunch of nonsense.

1562
01:09:09,319 --> 01:09:11,575
Although, the way they said
it was sort of suspicious.

1563
01:09:11,575 --> 01:09:13,700
They were like, yeah, we
put circuitry in our chips

1564
01:09:13,700 --> 01:09:15,500
to do this, but
we never used it.

1565
01:09:15,500 --> 01:09:17,210
That's strange.

1566
01:09:17,210 --> 01:09:19,520
So who knows.

1567
01:09:19,520 --> 01:09:21,560
But that's one theory.

1568
01:09:21,560 --> 01:09:23,910
I'm not sure how much I
believe that's the real reason,

1569
01:09:23,910 --> 01:09:24,410
but yeah.

1570
01:09:24,410 --> 01:09:26,577
AUDIENCE: but if they want
to calculate Merkle roots

1571
01:09:26,577 --> 01:09:28,240
in bitcoin, don't just--

1572
01:09:28,240 --> 01:09:31,939
order all of the transaction
fees by transaction ID?

1573
01:09:31,939 --> 01:09:35,359
PROFESSOR: You can't,
because the order matters.

1574
01:09:35,359 --> 01:09:38,779
Because when you
validate, this transaction

1575
01:09:38,779 --> 01:09:41,484
might create an output that
this transaction spends.

1576
01:09:41,484 --> 01:09:46,910
And so if you swap them, so
if you didn't have intra block

1577
01:09:46,910 --> 01:09:49,069
dependencies, then it
would all be arbitrary

1578
01:09:49,069 --> 01:09:50,450
and you could put in ordering.

1579
01:09:50,450 --> 01:09:52,729
But there are intra
block dependencies,

1580
01:09:52,729 --> 01:09:54,530
and so the order does matter.

1581
01:09:54,530 --> 01:09:55,705
In many cases, it doesn't.

1582
01:09:55,705 --> 01:09:57,830
In many cases, these are
two separate transactions.

1583
01:09:57,830 --> 01:09:59,060
You can swap them.

1584
01:09:59,060 --> 01:10:02,350
But the software does
use the ordering.

1585
01:10:02,350 --> 01:10:05,100
And there's all sorts of other
things that would be better.

1586
01:10:05,100 --> 01:10:11,150
What I would want is
prepend or append the height

1587
01:10:11,150 --> 01:10:13,430
at each stage of
the merkle tree.

1588
01:10:13,430 --> 01:10:16,345
That would have helped
me out for some things.

1589
01:10:16,345 --> 01:10:17,720
Because then, it's
like you know,

1590
01:10:17,720 --> 01:10:19,178
since you're at
the bottom just put

1591
01:10:19,178 --> 01:10:20,913
a zero at the end of each hash.

1592
01:10:20,913 --> 01:10:22,580
And then when you get
up here, put a one

1593
01:10:22,580 --> 01:10:24,830
at the end of each hash.

1594
01:10:24,830 --> 01:10:26,750
Doesn't really change anything.

1595
01:10:26,750 --> 01:10:31,790
But one problem is
what if I request--

1596
01:10:31,790 --> 01:10:33,330
so what I want to
do in my software.

1597
01:10:33,330 --> 01:10:35,910
I want to request all the
transaction IDs in a block.

1598
01:10:35,910 --> 01:10:37,320
I don't actually care
about the transactions.

1599
01:10:37,320 --> 01:10:38,695
I just want to
see all the txids.

1600
01:10:41,360 --> 01:10:42,230
Like this.

1601
01:10:42,230 --> 01:10:46,830
If I get rid of the head 20,
I get a giant list of txids.

1602
01:10:46,830 --> 01:10:50,422
The thing is, what this let me
do is to look for transactions.

1603
01:10:50,422 --> 01:10:52,380
If I have a txid I know
I'm looking, I can say,

1604
01:10:52,380 --> 01:10:54,600
oh, I can look for it in here.

1605
01:10:54,600 --> 01:10:57,120
The problem is, what if
the person I'm asking

1606
01:10:57,120 --> 01:11:01,080
is giving me this
instead of this?

1607
01:11:01,080 --> 01:11:02,680
I won't know.

1608
01:11:02,680 --> 01:11:05,470
They all look like
random numbers.

1609
01:11:05,470 --> 01:11:09,890
If I do the merkle tree algo,
I'll get to the merkle route.

1610
01:11:09,890 --> 01:11:10,540
That's good.

1611
01:11:10,540 --> 01:11:13,960
But I don't really know
that I'm at the bottom.

1612
01:11:13,960 --> 01:11:15,430
It's OK if I'm
running a full node

1613
01:11:15,430 --> 01:11:17,870
and I actually download all
the transactions and look,

1614
01:11:17,870 --> 01:11:19,210
and OK, it works.

1615
01:11:19,210 --> 01:11:23,032
But to have a way to say, hey,
give me a list of all the txids

1616
01:11:23,032 --> 01:11:24,490
and I can verify
that it's correct,

1617
01:11:24,490 --> 01:11:25,962
I can't do that right now.

1618
01:11:25,962 --> 01:11:26,920
There's ways around it.

1619
01:11:26,920 --> 01:11:28,587
But it would have
been nice if then they

1620
01:11:28,587 --> 01:11:30,172
appended a zero or something.

1621
01:11:30,172 --> 01:11:31,630
Or even, all you
have to do is just

1622
01:11:31,630 --> 01:11:33,970
append something
at the bottom row

1623
01:11:33,970 --> 01:11:35,980
or just append
higher or something.

1624
01:11:35,980 --> 01:11:36,850
Then, it would've
been kind of cool.

1625
01:11:36,850 --> 01:11:38,142
It would've been easier for me.

1626
01:11:38,142 --> 01:11:39,305
But oh well.

1627
01:11:39,305 --> 01:11:41,180
And there's people who've
written about this.

1628
01:11:41,180 --> 01:11:41,820
Yeah.

1629
01:11:41,820 --> 01:11:44,650
AUDIENCE: Did James say that's
pool operators are leaving off

1630
01:11:44,650 --> 01:11:47,140
the [? whipper? ?]
And if so, does it

1631
01:11:47,140 --> 01:11:48,172
weaken the whole system?

1632
01:11:48,172 --> 01:11:49,630
PROFESSOR: I think
what they really

1633
01:11:49,630 --> 01:11:51,400
do is they just
don't support segwit.

1634
01:11:51,400 --> 01:11:52,600
So I've seen, especially--

1635
01:11:52,600 --> 01:11:55,130
AUDIENCE: [INAUDIBLE] it's
expensive but then they--

1636
01:11:55,130 --> 01:11:57,380
PROFESSOR: Yeah, they say
they're going to support it,

1637
01:11:57,380 --> 01:11:58,990
and then they don't.

1638
01:11:58,990 --> 01:12:01,570
So they sort of flag their
transactions, yeah, segwit,

1639
01:12:01,570 --> 01:12:03,410
and then they haven't actually
upgraded their software,

1640
01:12:03,410 --> 01:12:04,330
so they can't use it.

1641
01:12:04,330 --> 01:12:05,250
They can't mine it.

1642
01:12:05,250 --> 01:12:07,210
So you see this a lot
on TestNet as well.

1643
01:12:07,210 --> 01:12:09,635
If you're making TestNet
segwit transactions,

1644
01:12:09,635 --> 01:12:11,260
sometimes they just
don't get confirmed

1645
01:12:11,260 --> 01:12:14,538
for a few hours, because
all the blocks that come out

1646
01:12:14,538 --> 01:12:16,330
don't support it, and
so they won't use it.

1647
01:12:16,330 --> 01:12:18,080
AUDIENCE: The badly
written pool software,

1648
01:12:18,080 --> 01:12:21,012
if they use segwit
supporting full load with it,

1649
01:12:21,012 --> 01:12:24,640
it will give them
segwit transactions,

1650
01:12:24,640 --> 01:12:27,185
and they'll try to include
it but it won't do this, so--

1651
01:12:27,185 --> 01:12:28,310
PROFESSOR: So it's invalid.

1652
01:12:28,310 --> 01:12:29,660
Yes, so it's invalid.

1653
01:12:29,660 --> 01:12:31,327
AUDIENCE: I guess my
question is does it

1654
01:12:31,327 --> 01:12:35,300
weaken the security in the
system if for six months

1655
01:12:35,300 --> 01:12:36,940
they're not supporting this?

1656
01:12:36,940 --> 01:12:37,870
PROFESSOR: No, no.

1657
01:12:37,870 --> 01:12:39,820
It hurts the usability.

1658
01:12:39,820 --> 01:12:41,350
If I want to use a
segwit transact--

1659
01:12:41,350 --> 01:12:44,710
but as me running a
segwit compatible node,

1660
01:12:44,710 --> 01:12:46,810
I require signatures.

1661
01:12:46,810 --> 01:12:49,060
I require all this
whole construction.

1662
01:12:49,060 --> 01:12:51,280
If you make something
that looks like it

1663
01:12:51,280 --> 01:12:54,820
spends the segwit transaction
without this, I just reject it.

1664
01:12:54,820 --> 01:12:56,290
So security wise, it's fine.

1665
01:12:56,290 --> 01:12:56,790
Yes.

1666
01:12:56,790 --> 01:12:58,030
AUDIENCE: I think it
might be important to note

1667
01:12:58,030 --> 01:13:00,790
that the way that these things
are designed, and in particular

1668
01:13:00,790 --> 01:13:04,810
that softforks are designed, is
that anyone who doesn't update

1669
01:13:04,810 --> 01:13:08,740
the new functionality
can't hurt the security

1670
01:13:08,740 --> 01:13:09,970
of the new functionality.

1671
01:13:09,970 --> 01:13:13,510
That's sort of part
of the design process.

1672
01:13:13,510 --> 01:13:16,315
PROFESSOR: Although, their
security might get hurt.

1673
01:13:16,315 --> 01:13:18,320
Not a ton, but yeah.

1674
01:13:18,320 --> 01:13:20,500
If you haven't
upgraded, you might

1675
01:13:20,500 --> 01:13:22,415
see these segwit
transactions, and--

1676
01:13:22,415 --> 01:13:23,290
AUDIENCE: [INAUDIBLE]

1677
01:13:23,290 --> 01:13:24,987
PROFESSOR: Yeah,
they look weird,

1678
01:13:24,987 --> 01:13:26,070
but you're like, OK, fine.

1679
01:13:26,070 --> 01:13:28,810
But you can't actually
verify the whole thing.

1680
01:13:28,810 --> 01:13:32,293
Given an invalid and a
valid segwit transaction,

1681
01:13:32,293 --> 01:13:33,710
the old software
can't distinguish

1682
01:13:33,710 --> 01:13:35,503
but the new software can.

1683
01:13:35,503 --> 01:13:38,170
AUDIENCE: That's even though the
pool operators, whether there's

1684
01:13:38,170 --> 01:13:40,600
six or eight key pool
operators, might not

1685
01:13:40,600 --> 01:13:42,330
be supporting the witrootsub

1686
01:13:42,330 --> 01:13:44,243
PROFESSOR: If they
don't support it,

1687
01:13:44,243 --> 01:13:45,910
you have to wait until
someone that does

1688
01:13:45,910 --> 01:13:48,790
support it mines the block.

1689
01:13:48,790 --> 01:13:52,630
So if they try to support
it and support it wrong,

1690
01:13:52,630 --> 01:13:54,360
you ignore them.

1691
01:13:54,360 --> 01:13:55,840
You don't use their data.

1692
01:13:55,840 --> 01:13:57,030
You don't use their block.

1693
01:13:57,030 --> 01:13:58,278
AUDIENCE: you just want
segwit transactions stay

1694
01:13:58,278 --> 01:13:59,390
in the node pool a bit longer.

1695
01:13:59,390 --> 01:14:00,057
PROFESSOR: Yeah.

1696
01:14:00,057 --> 01:14:03,010
So I think in
bitcoin now, it's OK.

1697
01:14:03,010 --> 01:14:06,980
TestNet is kind of weird,
but there's segwit.party,

1698
01:14:06,980 --> 01:14:10,100
and you can see what people
are doing with segwit.

1699
01:14:12,710 --> 01:14:14,180
So yeah, it's about 30.

1700
01:14:14,180 --> 01:14:17,240
This is by transaction, it's
somewhere around 30 something

1701
01:14:17,240 --> 01:14:19,910
percent of the transactions
are using segwit,

1702
01:14:19,910 --> 01:14:23,410
and then you can see witness
size percentage, block size.

1703
01:14:23,410 --> 01:14:24,800
OK, so sometimes you got--

1704
01:14:24,800 --> 01:14:26,720
oh wow, I had no idea.

1705
01:14:26,720 --> 01:14:29,260
Blocks are way under
a megabyte now.

1706
01:14:29,260 --> 01:14:32,060
Oh, OK, well free
transactions for everyone.

1707
01:14:32,060 --> 01:14:34,040
If you want to use
bitcoin, now's the time.

1708
01:14:34,040 --> 01:14:36,530
You don't have to pay anything.

1709
01:14:36,530 --> 01:14:39,950
That looks very different
a month ago where

1710
01:14:39,950 --> 01:14:41,780
you had a solid red line.

1711
01:14:41,780 --> 01:14:43,220
You had to sort of--

1712
01:14:43,220 --> 01:14:45,710
nothing went below a
million, and then you

1713
01:14:45,710 --> 01:14:47,840
had a little bit of segwit
stuff going on here.

1714
01:14:47,840 --> 01:14:50,680
But now you've got most
things are below a million.

1715
01:14:50,680 --> 01:14:52,020
So interesting.

1716
01:14:52,020 --> 01:14:52,730
OK, so yeah.

1717
01:14:52,730 --> 01:14:56,240
So that's the basic
idea of segwit.

1718
01:14:56,240 --> 01:14:58,790
And if people have
any questions,

1719
01:14:58,790 --> 01:15:01,310
stick around and ask.

1720
01:15:01,310 --> 01:15:03,770
There's office hours tomorrow
at 4:00 to 6:00 over there.

1721
01:15:03,770 --> 01:15:05,450
Look at the homework,
and next time

1722
01:15:05,450 --> 01:15:07,320
I'll talk about lightning
network payment--

1723
01:15:07,320 --> 01:15:08,990
I'll try to get into
payment channels

1724
01:15:08,990 --> 01:15:12,760
and see how far we get into
lightning network stuff.