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.