WEBVTT 00:00:00.850 --> 00:00:03.220 The following content is provided under a Creative 00:00:03.220 --> 00:00:04.610 Commons license. 00:00:04.610 --> 00:00:06.820 Your support will help MIT OpenCourseWare 00:00:06.820 --> 00:00:10.910 continue to offer high quality educational resources for free. 00:00:10.910 --> 00:00:13.480 To make a donation or to view additional materials 00:00:13.480 --> 00:00:17.440 from hundreds of MIT courses, visit MIT OpenCourseWare 00:00:17.440 --> 00:00:18.313 at ocw.mit.edu. 00:00:24.012 --> 00:00:24.720 PROFESSOR: Sorry. 00:00:24.720 --> 00:00:28.010 I have a bit of a sore throat, hoarse voice. 00:00:28.010 --> 00:00:30.090 I was talking a lot this weekend. 00:00:30.090 --> 00:00:30.590 OK. 00:00:30.590 --> 00:00:33.140 Also, today we're going to do transaction malleability, 00:00:33.140 --> 00:00:35.390 segregated witness, and I'm endorsing 00:00:35.390 --> 00:00:38.360 an ICO for the first time ever publicly, 00:00:38.360 --> 00:00:40.280 and it's Anne's intermittent cookie offering. 00:00:40.280 --> 00:00:41.447 So if you guys want cookies. 00:00:43.960 --> 00:00:46.810 It's an airdrop and you just get them. 00:00:54.740 --> 00:01:00.780 so it's my first ICO I'm endorsing. 00:01:00.780 --> 00:01:01.280 OK. 00:01:01.280 --> 00:01:04.640 So malleability. 00:01:04.640 --> 00:01:06.950 So malleability is the ability to deform 00:01:06.950 --> 00:01:08.900 under pressure formateer. 00:01:08.900 --> 00:01:11.090 And so bitcoin is modeled off of gold, which 00:01:11.090 --> 00:01:12.350 is the most malleable metal. 00:01:12.350 --> 00:01:14.300 You can make gold leaf and stuff. 00:01:14.300 --> 00:01:19.290 So clearly we need to design bitcoin to be malleable. 00:01:19.290 --> 00:01:20.630 No, I'm joking. 00:01:20.630 --> 00:01:21.130 OK. 00:01:21.130 --> 00:01:26.870 Actually in the context of cryptography, 00:01:26.870 --> 00:01:28.880 it's not super hard definition, but it 00:01:28.880 --> 00:01:31.730 started with Cipher text, where if you can modify a Cipher 00:01:31.730 --> 00:01:36.770 text and that modification will carry over into the plain text 00:01:36.770 --> 00:01:38.000 when it's encrypted. 00:01:38.000 --> 00:01:40.880 It also applies to sort of messages and signatures. 00:01:40.880 --> 00:01:43.710 In our case, signatures can be malleable, 00:01:43.710 --> 00:01:46.220 which means you can change the signature 00:01:46.220 --> 00:01:48.660 and it's still a valid signature. 00:01:48.660 --> 00:01:53.660 So given a signature S1 on message M1, 00:01:53.660 --> 00:01:58.130 you modify the signature to S2 or S prime 00:01:58.130 --> 00:01:59.960 and it still signs the same message. 00:01:59.960 --> 00:02:02.450 It still validates as true. 00:02:02.450 --> 00:02:04.790 So when we were defining signatures 00:02:04.790 --> 00:02:08.509 this wasn't really an attack we'd considered. 00:02:08.509 --> 00:02:12.320 There's still a signature and you can't forge a signature, 00:02:12.320 --> 00:02:14.960 but you can dot an I or something 00:02:14.960 --> 00:02:17.190 and the signature is slightly different. 00:02:17.190 --> 00:02:19.650 You can't create one yourself, but given a valid signature 00:02:19.650 --> 00:02:23.700 you can make a slightly different valid signature. 00:02:23.700 --> 00:02:27.950 And that's how it works in the bitcoin signing algorithm. 00:02:27.950 --> 00:02:30.200 But there's all sorts of different contexts 00:02:30.200 --> 00:02:34.160 where malleability exists in cryptography. 00:02:34.160 --> 00:02:35.900 And then part of it is things still 00:02:35.900 --> 00:02:38.250 have to work for whatever definition. 00:02:38.250 --> 00:02:42.327 So if you malleates a signature and it no longer validates, 00:02:42.327 --> 00:02:43.910 well, that's sort of a trivial, like-- 00:02:43.910 --> 00:02:46.550 yeah, sure, you can do that to any bunch of bytes. 00:02:46.550 --> 00:02:48.645 You can just flip some of them and the whole thing 00:02:48.645 --> 00:02:49.520 doesn't work anymore. 00:02:49.520 --> 00:02:50.690 That's easy. 00:02:50.690 --> 00:02:53.717 But properties where it still works. 00:02:53.717 --> 00:02:55.550 So this leads to some weird stuff in bitcoin 00:02:55.550 --> 00:02:59.060 where you can change a transaction 00:02:59.060 --> 00:03:01.550 and it's still valid. 00:03:01.550 --> 00:03:04.400 And that's generally not what you want. 00:03:04.400 --> 00:03:05.870 If you've got some kind of contract 00:03:05.870 --> 00:03:09.542 or some kind of payment and you write a check, 00:03:09.542 --> 00:03:11.750 you don't want someone to be able to modify the check 00:03:11.750 --> 00:03:13.700 and still be able to cash it. 00:03:13.700 --> 00:03:18.080 And I don't really use checks much, but they draw the line. 00:03:18.080 --> 00:03:20.870 Like $100 and then they draw a line 00:03:20.870 --> 00:03:23.960 so someone doesn't write and $0.99 or something after. 00:03:23.960 --> 00:03:26.870 Not that that's like the greatest attack ever. 00:03:26.870 --> 00:03:30.320 Or $100 and then someone puts like $1,000. 00:03:30.320 --> 00:03:31.730 I don't know. 00:03:31.730 --> 00:03:33.560 But it's sort of like that where someone 00:03:33.560 --> 00:03:35.120 can change the thing you sign, can 00:03:35.120 --> 00:03:38.120 change the thing you are agreeing to after the fact, 00:03:38.120 --> 00:03:42.000 and it's still valid and it does something you don't expect. 00:03:42.000 --> 00:03:43.150 OK. 00:03:43.150 --> 00:03:47.670 So a review of the transaction format, 00:03:47.670 --> 00:03:50.160 which should be probably in people's minds 00:03:50.160 --> 00:03:53.660 if you were looking at the homework, the problem set. 00:03:53.660 --> 00:03:56.310 And one thing to focus on is that the outputs 00:03:56.310 --> 00:03:58.860 don't look like the inputs. 00:03:58.860 --> 00:04:02.190 These are fundamentally different things. 00:04:02.190 --> 00:04:08.640 The outputs specify a transaction ID and the inputs, 00:04:08.640 --> 00:04:12.790 and then the outputs specify a script and an amount. 00:04:12.790 --> 00:04:16.100 There's another 4 byte field here that doesn't matter. 00:04:16.100 --> 00:04:20.220 So basically you're spending from a transaction and a sort 00:04:20.220 --> 00:04:24.510 of row and you're spending too just this arbitrary pub key, 00:04:24.510 --> 00:04:26.790 but you're not spending from a pub key 00:04:26.790 --> 00:04:29.780 and you're not spending to a transaction. 00:04:29.780 --> 00:04:32.500 You don't identify your transaction itself here. 00:04:38.410 --> 00:04:42.500 Almost every website that shows blockchains is it 00:04:42.500 --> 00:04:43.970 gets this wrong. 00:04:43.970 --> 00:04:45.670 So if you look at like, I don't know, 00:04:45.670 --> 00:04:51.390 blockchain.info is probably the most popular 00:04:51.390 --> 00:04:54.190 and you just look at a transaction. 00:04:54.190 --> 00:04:55.410 They don't have it anymore. 00:04:55.410 --> 00:04:55.910 OK. 00:04:55.910 --> 00:04:58.600 So you look at a block and then you look at a transaction 00:04:58.600 --> 00:05:00.460 in the block. 00:05:00.460 --> 00:05:01.200 We're going. 00:05:01.200 --> 00:05:01.700 No. 00:05:01.700 --> 00:05:02.200 No. 00:05:02.200 --> 00:05:03.102 No, not yet. 00:05:03.102 --> 00:05:03.822 There we go OK. 00:05:03.822 --> 00:05:05.030 So you look at a transaction. 00:05:05.030 --> 00:05:06.860 Yeah, it shows. 00:05:06.860 --> 00:05:10.070 This address is sending to these two addresses. 00:05:10.070 --> 00:05:12.810 And blockchain.info is particularly egregious 00:05:12.810 --> 00:05:15.650 and that there may actually be more than one input and two 00:05:15.650 --> 00:05:19.455 outputs in this transaction. 00:05:19.455 --> 00:05:21.860 They hide change transactions. 00:05:21.860 --> 00:05:26.640 So it looks like, hey, this address had some money in it 00:05:26.640 --> 00:05:28.233 and it sent it to these two addresses. 00:05:28.233 --> 00:05:30.150 And if I click, oh, where did this money come? 00:05:30.150 --> 00:05:33.990 It come from 18eecz, and it shows 00:05:33.990 --> 00:05:36.300 here's the bitcoin address, and, oh, it's 00:05:36.300 --> 00:05:42.180 got multiple transactions this addresses has been involved in. 00:05:42.180 --> 00:05:44.580 This is not how bitcoin works. 00:05:44.580 --> 00:05:48.120 They are running their own database and sort 00:05:48.120 --> 00:05:53.730 of making up this view of the network, which is incorrect. 00:05:53.730 --> 00:05:56.790 Transactions don't send from an address, 00:05:56.790 --> 00:06:00.960 they send from another transactions previous output. 00:06:00.960 --> 00:06:03.240 And this is very confusing because in the case, 00:06:03.240 --> 00:06:05.900 let's say in this transaction, there is a-- 00:06:05.900 --> 00:06:06.810 what is it? 00:06:09.440 --> 00:06:11.555 767 something. 00:06:14.880 --> 00:06:19.777 So it says, yeah, it's coming from 18ee whatever, 00:06:19.777 --> 00:06:22.110 and if I click on it I get three different transactions. 00:06:22.110 --> 00:06:25.470 There is a specific transaction that 18ee 00:06:25.470 --> 00:06:28.250 was involved in that is being spent from in this transaction. 00:06:28.250 --> 00:06:31.240 I can look it up because I have an actual full node. 00:06:31.240 --> 00:06:37.730 So if I say get raw transaction and I put it in here 00:06:37.730 --> 00:06:43.410 and I can see, OK, it was spending from c838. 00:06:43.410 --> 00:06:46.870 It was spending from this transaction, not just 00:06:46.870 --> 00:06:47.710 an address. 00:06:47.710 --> 00:06:52.210 So I mean if you're coming at this sort of new it's like, OK, 00:06:52.210 --> 00:06:55.450 fine, why do you keep talking about this? 00:06:55.450 --> 00:06:58.010 But if you've been working on these things, a lot of people, 00:06:58.010 --> 00:07:01.373 myself included, for like six months a year 00:07:01.373 --> 00:07:03.040 I looked at these websites and I'm like, 00:07:03.040 --> 00:07:06.490 oh, this is how it works and then six months in or something 00:07:06.490 --> 00:07:09.100 looking for code, and I'm like, wait, huh? 00:07:09.100 --> 00:07:12.070 This code is wrong, but no, this is the bitcoin code 00:07:12.070 --> 00:07:13.780 that actually is running. 00:07:13.780 --> 00:07:16.060 And so it's a weird thing to sort of get used to. 00:07:16.060 --> 00:07:17.935 Like no, you're not spending from an address. 00:07:17.935 --> 00:07:20.440 You don't show the address at all when you spend from it, 00:07:20.440 --> 00:07:22.170 you spend from a specific output. 00:07:22.170 --> 00:07:22.750 OK. 00:07:22.750 --> 00:07:24.460 So that leads to some weird issues. 00:07:27.810 --> 00:07:30.250 Specifically, what gets signed? 00:07:30.250 --> 00:07:33.160 So to some extent you're signing the whole transaction. 00:07:33.160 --> 00:07:34.820 You sign. 00:07:34.820 --> 00:07:36.070 You want to sign everything. 00:07:36.070 --> 00:07:38.200 When you're saying I'm sending money from here, 00:07:38.200 --> 00:07:40.810 I'm sending it to here, you want to make sure 00:07:40.810 --> 00:07:43.870 that your signature covers the entire transaction so 00:07:43.870 --> 00:07:47.538 that people can't add stuff after or remove stuff. 00:07:47.538 --> 00:07:49.330 So you want to sign the inputs and outputs. 00:07:49.330 --> 00:07:51.460 But the inputs contain signatures 00:07:51.460 --> 00:07:53.850 and you can't sign the signature. 00:07:53.850 --> 00:07:55.630 That doesn't make any sense. 00:07:55.630 --> 00:07:58.003 The signature is the thing you're putting on at the end. 00:07:58.003 --> 00:07:58.920 So it's sort of weird. 00:07:58.920 --> 00:08:00.790 You've got this document and you have a little line 00:08:00.790 --> 00:08:02.200 at the bottom for the signature. 00:08:02.200 --> 00:08:05.560 But should the signatures be maybe a separate page that 00:08:05.560 --> 00:08:07.420 refers to the previous page? 00:08:07.420 --> 00:08:10.450 It's actually kind of a weird confusing problem. 00:08:10.450 --> 00:08:16.390 So in practice, in bitcoin, what Satoshi did in 2009, 00:08:16.390 --> 00:08:18.190 you take the whole transaction, but you 00:08:18.190 --> 00:08:19.740 remove the signature fields. 00:08:19.740 --> 00:08:21.010 You basically zero them out. 00:08:21.010 --> 00:08:22.750 Just put a zero there and then you 00:08:22.750 --> 00:08:27.610 sign that sort of signatureless transaction. 00:08:27.610 --> 00:08:33.000 And then you put that signature in after the fact. 00:08:33.000 --> 00:08:37.070 And so that means if you change any bit of the stuff that gets 00:08:37.070 --> 00:08:42.250 signed other than the signature, the signature will break. 00:08:42.250 --> 00:08:43.250 So does that make sense? 00:08:45.760 --> 00:08:48.080 You have these empty lines kind of, 00:08:48.080 --> 00:08:51.440 and the idea is you empty them out, you make them blank lines, 00:08:51.440 --> 00:08:54.530 and then you take that whole message, hash it, including 00:08:54.530 --> 00:08:58.520 the empty parts, and then paste in those signatures 00:08:58.520 --> 00:08:59.450 after you've signed. 00:09:04.490 --> 00:09:06.680 You don't empty out every line, the line that you're 00:09:06.680 --> 00:09:08.480 specifically putting the signature in, 00:09:08.480 --> 00:09:10.820 you actually put a different few bytes 00:09:10.820 --> 00:09:13.970 in there, which leads to other problems 00:09:13.970 --> 00:09:16.700 that I can maybe mention if I've done. 00:09:16.700 --> 00:09:18.110 So this seems OK. 00:09:18.110 --> 00:09:21.260 It's like well, look, I can't sign the signatures, sure, 00:09:21.260 --> 00:09:24.500 but if you change any bit of the stuff I'm signing, 00:09:24.500 --> 00:09:26.070 the signatures now break. 00:09:26.070 --> 00:09:28.670 So this seems perfectly safe. 00:09:28.670 --> 00:09:30.650 No one can change the amounts I'm sending. 00:09:30.650 --> 00:09:33.400 No one can change where I'm sending it to. 00:09:33.400 --> 00:09:35.780 No one can change where I'm sending from. 00:09:35.780 --> 00:09:39.330 All these things get covered in my signature, so I'm good. 00:09:39.330 --> 00:09:40.560 Problem. 00:09:40.560 --> 00:09:43.800 The transaction ID, the way you refer to transactions 00:09:43.800 --> 00:09:46.020 is the hash of the whole thing. 00:09:46.020 --> 00:09:50.070 The txid does not zero out the signature fields. 00:09:50.070 --> 00:09:53.310 So the identity of the transaction itself, the way 00:09:53.310 --> 00:09:57.180 to point to and indicate where you're spending from, 00:09:57.180 --> 00:10:00.150 that includes the signatures. 00:10:00.150 --> 00:10:02.850 So that also seems like, well, that's OK. 00:10:02.850 --> 00:10:05.280 When I point to something I'm indicating 00:10:05.280 --> 00:10:09.620 the whole transaction, the whole signed transaction. 00:10:09.620 --> 00:10:12.770 But the problem is that can change. 00:10:12.770 --> 00:10:15.590 The signature itself may be malleable, 00:10:15.590 --> 00:10:17.700 and in bitcoin it is. 00:10:17.700 --> 00:10:20.070 There's third party malleability problems. 00:10:20.070 --> 00:10:22.480 So the simplest one was leading zeros 00:10:22.480 --> 00:10:24.830 where all these things are numbers. 00:10:24.830 --> 00:10:26.900 You could say, OK, someone's got a signature. 00:10:26.900 --> 00:10:30.180 It's this big, long string of bytes. 00:10:30.180 --> 00:10:32.180 I'm just going to put zeros in the front. 00:10:32.180 --> 00:10:34.750 I'm going to put a zero byte in the front of it, 00:10:34.750 --> 00:10:36.290 and that doesn't change the meaning. 00:10:36.290 --> 00:10:40.310 If someone says, I'm sending you $1,000 00:10:40.310 --> 00:10:42.255 and I put a 0 front of the one and 1,000. 00:10:42.255 --> 00:10:43.700 Well, it's still 1,000. 00:10:43.700 --> 00:10:47.190 However, for the purpose of a hash function, 00:10:47.190 --> 00:10:48.590 if you have a zero byte in front, 00:10:48.590 --> 00:10:51.380 that changes the whole hash. 00:10:51.380 --> 00:10:54.140 And so they got rid of this pretty early. 00:10:54.140 --> 00:10:56.630 They sort of made it so that you had 00:10:56.630 --> 00:10:58.220 to have the exact right number. 00:10:58.220 --> 00:10:59.660 You can't have any leading zeros. 00:10:59.660 --> 00:11:03.060 But the first one was just, oh, I put a 0 in the front. 00:11:03.060 --> 00:11:06.260 The harder one is called low s, where part 00:11:06.260 --> 00:11:10.080 of the ecdsa signature scheme. 00:11:10.080 --> 00:11:11.930 I showed before that it's this curve that's 00:11:11.930 --> 00:11:15.070 symmetric about the x-axis. 00:11:15.070 --> 00:11:16.690 Whether the thing you're indicating 00:11:16.690 --> 00:11:19.840 is on top of the curve or it's sort of reflection 00:11:19.840 --> 00:11:22.660 on the bottom, it's valid either way. 00:11:22.660 --> 00:11:24.220 So for any given signature, there's 00:11:24.220 --> 00:11:26.080 another signature that will be valid. 00:11:26.080 --> 00:11:29.730 You just sort of flip it, make it negative or positive. 00:11:29.730 --> 00:11:32.440 So now there's a standard, OK, you need to have high s. 00:11:32.440 --> 00:11:34.960 Low s signatures should be invalid. 00:11:34.960 --> 00:11:38.540 Both of these are really tricky because they're 00:11:38.540 --> 00:11:40.010 third party malleability. 00:11:40.010 --> 00:11:43.130 Anyone can just listen on the network, see a transaction, 00:11:43.130 --> 00:11:44.540 change the signature. 00:11:44.540 --> 00:11:46.820 And in doing so they will change the txid, 00:11:46.820 --> 00:11:49.250 which is how all the software refers to transactions. 00:11:49.250 --> 00:11:52.470 So it looks like a new transaction 00:11:52.470 --> 00:11:53.868 to most of the software. 00:11:53.868 --> 00:11:55.410 And the transactions are still valid. 00:11:55.410 --> 00:11:57.350 The signatures are still valid and you're not 00:11:57.350 --> 00:11:59.510 sure which one will get in. 00:11:59.510 --> 00:12:02.390 There's also first party malleability, or in some cases 00:12:02.390 --> 00:12:04.130 second party if you're doing transactions 00:12:04.130 --> 00:12:06.890 with multiple people signing. 00:12:06.890 --> 00:12:10.540 So I'm not going to go back into the elliptic curve signature 00:12:10.540 --> 00:12:12.260 algorithms, but there is a nonce. 00:12:12.260 --> 00:12:13.850 There's randomness that you inject 00:12:13.850 --> 00:12:17.000 into the signing process. 00:12:17.000 --> 00:12:18.080 It's not deterministic. 00:12:18.080 --> 00:12:21.320 It's not that given a message and my private key. 00:12:21.320 --> 00:12:23.000 I always compute the same signature. 00:12:23.000 --> 00:12:24.457 No, that's not how it works. 00:12:24.457 --> 00:12:26.040 There are signature schemes like that, 00:12:26.040 --> 00:12:29.510 but in the case of the elliptic curve stuff that bitcoin uses, 00:12:29.510 --> 00:12:33.310 you have to make up a random number to make each signature, 00:12:33.310 --> 00:12:35.360 and no one knows what that random number is. 00:12:35.360 --> 00:12:38.240 So you could make up different random numbers. 00:12:38.240 --> 00:12:40.110 You can make as many signatures as you want. 00:12:40.110 --> 00:12:44.600 So given a message and your private key, 00:12:44.600 --> 00:12:47.083 you can make arbitrary number of signatures 00:12:47.083 --> 00:12:48.500 that are all different signatures, 00:12:48.500 --> 00:12:52.040 but they're all valid signatures. 00:12:52.040 --> 00:12:56.180 There is a sort of standard for how to make them 00:12:56.180 --> 00:12:58.340 the right way not randomly. 00:12:58.340 --> 00:13:01.580 It's basically take the hash of your private key 00:13:01.580 --> 00:13:04.280 and the message being signed. 00:13:04.280 --> 00:13:07.040 Put them together, hash that, and use that 00:13:07.040 --> 00:13:10.155 as your random number because then the idea is well, 00:13:10.155 --> 00:13:12.260 it's got secret information in it 00:13:12.260 --> 00:13:14.833 as well as the message specific information in it. 00:13:14.833 --> 00:13:17.000 So no one's going to be able to guess what it is so, 00:13:17.000 --> 00:13:18.940 and it's still kind of message dependent 00:13:18.940 --> 00:13:21.410 so it'll change each time. 00:13:21.410 --> 00:13:24.870 So there is that, but that's something you can do. 00:13:24.870 --> 00:13:27.680 It's a really good idea because if you 00:13:27.680 --> 00:13:30.650 use a non-random k, if someone can guess k 00:13:30.650 --> 00:13:32.820 or if your random number generator's broken, 00:13:32.820 --> 00:13:34.070 they can steal all your money. 00:13:34.070 --> 00:13:38.550 They can figure out your private key. 00:13:38.550 --> 00:13:40.780 So you don't want to be dependent on generating 00:13:40.780 --> 00:13:41.530 randomness. 00:13:41.530 --> 00:13:45.270 A nice way to model it is, OK, have some initial event where 00:13:45.270 --> 00:13:47.800 you're putting in random numbers and you're storing them 00:13:47.800 --> 00:13:51.040 and then from then on you want everything to be deterministic, 00:13:51.040 --> 00:13:53.890 then you don't have to rely on random number generators. 00:13:53.890 --> 00:13:55.810 So it's really a good idea to use this. 00:13:55.810 --> 00:13:57.355 And I use it in my software. 00:13:57.355 --> 00:13:59.690 Most things use this kind of standard. 00:13:59.690 --> 00:14:02.410 However, you can't verify that anyone's actually using it. 00:14:02.410 --> 00:14:03.610 It's purely internal. 00:14:03.610 --> 00:14:06.430 It's a internal way for you to make your own signatures, 00:14:06.430 --> 00:14:08.890 but no one can actually-- 00:14:08.890 --> 00:14:09.530 can you prove? 00:14:09.530 --> 00:14:10.042 No. 00:14:10.042 --> 00:14:12.250 I'm not going to say you can't prove you're using it, 00:14:12.250 --> 00:14:16.590 but not in any reasonable fashion. 00:14:16.590 --> 00:14:17.090 Yeah. 00:14:17.090 --> 00:14:19.110 So no one knows if you're doing it. 00:14:19.110 --> 00:14:21.257 So this is an attack where you can say, OK, 00:14:21.257 --> 00:14:23.590 I'm going to make a whole bunch of different signatures. 00:14:23.590 --> 00:14:25.215 They're all going to be valid, but that 00:14:25.215 --> 00:14:28.540 will mean I've got a whole bunch of different transactions 00:14:28.540 --> 00:14:31.900 that are doing the same thing. 00:14:31.900 --> 00:14:34.440 So maybe the question is, what does this really do? 00:14:34.440 --> 00:14:35.640 Does this really hurt? 00:14:35.640 --> 00:14:39.460 If someone dots an eye on your check, it's the same amount. 00:14:39.460 --> 00:14:42.150 It's going to the same place. 00:14:42.150 --> 00:14:44.290 Who cares. 00:14:44.290 --> 00:14:46.160 Outputs are the same. 00:14:46.160 --> 00:14:48.090 Inputs it's pointing to are the same. 00:14:48.090 --> 00:14:50.120 It's just this sort of annoying thing. 00:14:50.120 --> 00:14:52.320 OK, I tweaked it and I changed the txid. 00:14:52.320 --> 00:14:53.620 No big deal. 00:14:53.620 --> 00:14:58.100 Well, in some ways, yeah, it's no big deal, 00:14:58.100 --> 00:15:01.060 but a lot of wallets didn't deal with this well. 00:15:01.060 --> 00:15:04.510 So let's say you're running a wallet, you make a transaction 00:15:04.510 --> 00:15:09.850 and you sign and you broadcast transaction 2d5cac 00:15:09.850 --> 00:15:14.650 and it never gets confirmed, and instead someone out there flips 00:15:14.650 --> 00:15:19.450 a bit, changes your transaction to 9cba3e 00:15:19.450 --> 00:15:21.550 and that gets confirmed, and your wallet just 00:15:21.550 --> 00:15:25.825 says, yeah, this transaction you sent never got confirmed. 00:15:25.825 --> 00:15:27.250 There's wallets that did that. 00:15:27.250 --> 00:15:29.070 Most of them have fixed it by now. 00:15:29.070 --> 00:15:31.120 But if you're thinking of transaction IDs 00:15:31.120 --> 00:15:36.360 as the identity txid, this is the name of the transaction. 00:15:36.360 --> 00:15:40.420 I create it, I'm watching it to see when it gets confirmed, 00:15:40.420 --> 00:15:42.850 and I'm not looking for some malleated version. 00:15:42.850 --> 00:15:45.190 I'm just watching this thing that I created, never 00:15:45.190 --> 00:15:46.720 gets in a block. 00:15:46.720 --> 00:15:48.670 Weird, and it's just stuck in the wallet. 00:15:48.670 --> 00:15:51.100 So there are definitely wallets, and I think 00:15:51.100 --> 00:15:52.550 everyone's fixed it by now. 00:15:52.550 --> 00:15:54.310 But a couple years ago, definitely wallets 00:15:54.310 --> 00:15:57.310 that would have these problems. 00:15:57.310 --> 00:15:58.660 It's a wallet problem. 00:15:58.660 --> 00:16:01.210 Your money got to the right place. 00:16:01.210 --> 00:16:04.630 You just need to sort of either delete stuff in your wallet 00:16:04.630 --> 00:16:07.210 or upgrade the software or tell it to somehow forget 00:16:07.210 --> 00:16:08.680 about this transaction and actually 00:16:08.680 --> 00:16:10.270 look on the blockchain for everything 00:16:10.270 --> 00:16:12.100 similar to your transaction. 00:16:12.100 --> 00:16:16.280 But it did do some damage. 00:16:16.280 --> 00:16:19.540 So, I don't know, 2014 the Mt. 00:16:19.540 --> 00:16:20.800 Gox thing where Mt. 00:16:20.800 --> 00:16:24.190 Gox got hacked supposedly and lost all the money, 00:16:24.190 --> 00:16:26.350 they blamed transaction malleability, 00:16:26.350 --> 00:16:28.340 which was kind of interesting. 00:16:28.340 --> 00:16:33.070 There may have been an attack on Mt Gox that used transaction 00:16:33.070 --> 00:16:35.380 malleability. 00:16:35.380 --> 00:16:41.540 The attack probably was this, which was log into Mt. 00:16:41.540 --> 00:16:47.900 Gox, withdraw some coins, modify the txid to this, 00:16:47.900 --> 00:16:50.600 and then it gets confirmed, you get your coins, 00:16:50.600 --> 00:16:52.077 and then log into Mt. 00:16:52.077 --> 00:16:53.660 Gox and say, hey, this never happened. 00:16:53.660 --> 00:16:55.280 My withdrawal didn't work and then 00:16:55.280 --> 00:16:57.572 their system would automatically issue a new withdrawal 00:16:57.572 --> 00:16:58.820 transaction. 00:16:58.820 --> 00:17:01.520 And so you could just start taking all the money out 00:17:01.520 --> 00:17:03.717 and your balance on the system's like, 00:17:03.717 --> 00:17:05.300 well, we keep trying to send you money 00:17:05.300 --> 00:17:07.200 and it keeps never getting confirmed. 00:17:07.200 --> 00:17:09.260 And so we keep making new ones. 00:17:09.260 --> 00:17:11.869 I don't know to what extent that that actually happened. 00:17:14.555 --> 00:17:16.430 It couldn't have been the whole thing for Mt. 00:17:16.430 --> 00:17:17.182 Gox definitely. 00:17:17.182 --> 00:17:19.099 There's still a lot of uncertainty about that. 00:17:19.099 --> 00:17:21.268 But it's indicative. 00:17:21.268 --> 00:17:23.060 If you write your own software and it's not 00:17:23.060 --> 00:17:26.270 accounting for these things, you may be losing money 00:17:26.270 --> 00:17:29.030 once people say, hey, this didn't work, make a new one, 00:17:29.030 --> 00:17:31.790 and then you keep doing that and losing a ton of money. 00:17:31.790 --> 00:17:36.080 But that's pretty sloppy practice. 00:17:36.080 --> 00:17:37.130 Another issue. 00:17:37.130 --> 00:17:42.440 If you're spending from a unconfirmed change 00:17:42.440 --> 00:17:44.090 output or an unconfirmed output-- 00:17:44.090 --> 00:17:47.690 so you make a transaction, you send the two different outputs, 00:17:47.690 --> 00:17:48.890 you've got a txid. 00:17:48.890 --> 00:17:51.440 And you're sending five coins to this person 00:17:51.440 --> 00:17:53.650 and three coins back to yourself. 00:17:53.650 --> 00:17:55.610 That three coins back to yourself output, 00:17:55.610 --> 00:17:58.070 you might want to use it again pretty quickly. 00:17:58.070 --> 00:18:00.560 Sometimes this happens. 00:18:00.560 --> 00:18:05.390 And so you've got a change output that's 00:18:05.390 --> 00:18:07.610 from transaction 1, 7feec1. 00:18:07.610 --> 00:18:12.380 So you're going to now spend that change output, however 00:18:12.380 --> 00:18:14.870 the txid of transaction one changes. 00:18:14.870 --> 00:18:17.300 So you're saying where you're spending 00:18:17.300 --> 00:18:19.847 from is no longer valid. 00:18:19.847 --> 00:18:21.680 And this is a big problem because now you've 00:18:21.680 --> 00:18:24.380 signed a transaction that you think is going to be valid, 00:18:24.380 --> 00:18:26.900 but the money you thought you were spending sort of 00:18:26.900 --> 00:18:29.270 moves out from under you. 00:18:29.270 --> 00:18:31.460 And so that transaction's no longer valid. 00:18:31.460 --> 00:18:32.780 tx2 is now invalid. 00:18:32.780 --> 00:18:34.610 It refers to something which can never 00:18:34.610 --> 00:18:38.390 be confirmed because there's a different transaction that's 00:18:38.390 --> 00:18:41.300 almost the same, but they're mutually exclusive that 00:18:41.300 --> 00:18:42.840 did get confirmed. 00:18:42.840 --> 00:18:43.340 OK. 00:18:43.340 --> 00:18:45.690 So this is bad. 00:18:48.870 --> 00:18:50.430 It doesn't seem that bad. 00:18:50.430 --> 00:18:53.100 And so for years in bitcoin this was a problem 00:18:53.100 --> 00:18:55.260 that while it dealt with, software and people 00:18:55.260 --> 00:18:58.890 would be like, oh yeah, you have to backup your keys, 00:18:58.890 --> 00:19:01.530 delete your whole database, and rethink the blockchain 00:19:01.530 --> 00:19:04.045 and then it'll find the right transactions. 00:19:04.045 --> 00:19:06.930 Kind of hacky work arounds like that where 00:19:06.930 --> 00:19:09.782 it didn't happen too much. 00:19:09.782 --> 00:19:11.640 It wasn't a great attack. 00:19:11.640 --> 00:19:12.570 You can annoy people. 00:19:12.570 --> 00:19:14.490 You don't get any money. 00:19:14.490 --> 00:19:18.055 So wasn't a huge deal, but it was annoying. 00:19:18.055 --> 00:19:19.680 But the idea is you can always re-sign. 00:19:19.680 --> 00:19:20.888 You've got your private keys. 00:19:20.888 --> 00:19:25.030 If the money you are receiving sort of shifts around 00:19:25.030 --> 00:19:27.030 and changes its location, well it's still yours. 00:19:27.030 --> 00:19:28.860 You just need to re-sign. 00:19:28.860 --> 00:19:31.320 But what if you can't re-sign? 00:19:31.320 --> 00:19:36.910 So the case of multisig where in most cases when you're 00:19:36.910 --> 00:19:40.480 doing transactions if you just have one key, it's just you, 00:19:40.480 --> 00:19:41.560 that's fine. 00:19:41.560 --> 00:19:43.570 In the case of multisig usually you're 00:19:43.570 --> 00:19:46.210 all friends to some extent and you're 00:19:46.210 --> 00:19:51.160 all in the same organization or multiple devices that you own. 00:19:51.160 --> 00:19:54.472 But you can have sort of adversarial multisig 00:19:54.472 --> 00:19:55.930 where you're assigning transactions 00:19:55.930 --> 00:19:58.390 with people who are you're sort of cooperating with them, 00:19:58.390 --> 00:20:00.610 but you may not really trust them, 00:20:00.610 --> 00:20:03.712 or they might be potentially attackers, things like that. 00:20:03.712 --> 00:20:05.920 You can definitely sort of extend your multisig model 00:20:05.920 --> 00:20:07.785 into that. 00:20:07.785 --> 00:20:09.910 And there could be multisig pre-signed transactions 00:20:09.910 --> 00:20:12.610 where, OK, we've got this two of three output 00:20:12.610 --> 00:20:15.820 address, this output that exists, 00:20:15.820 --> 00:20:18.520 and one of the two or three has pre-signed a transaction 00:20:18.520 --> 00:20:20.650 and hands it over to me and then they disappear. 00:20:20.650 --> 00:20:24.400 And they say, oh OK, well I'm going to now sign my side. 00:20:24.400 --> 00:20:28.510 But if malleability occurs and the transaction ID changes, 00:20:28.510 --> 00:20:33.430 that signature is no longer valid, signing something 00:20:33.430 --> 00:20:34.848 that's not there anymore. 00:20:34.848 --> 00:20:37.140 So this is very important in payment channels lightning 00:20:37.140 --> 00:20:41.780 network stuff that I'll get to in a few days. 00:20:41.780 --> 00:20:44.530 And so it wasn't so much that malleability 00:20:44.530 --> 00:20:47.650 was like a showstopper bug and everyone was losing tons 00:20:47.650 --> 00:20:50.140 of money, it was that it was preventing 00:20:50.140 --> 00:20:52.480 kind of new, cool things from happening 00:20:52.480 --> 00:20:55.420 because there were a lot of problems with, 00:20:55.420 --> 00:20:58.570 OK, let's make this construction where we put money 00:20:58.570 --> 00:21:01.420 into a multisig account and then I sign like a refund 00:21:01.420 --> 00:21:05.620 transaction that's got a lock time before I actually fund it 00:21:05.620 --> 00:21:08.090 and things like that where you couldn't reliably do it 00:21:08.090 --> 00:21:10.720 because if either party modified their signature, 00:21:10.720 --> 00:21:13.540 they could break the whole thing and they could have a tax where 00:21:13.540 --> 00:21:15.457 it's like, OK, we're doing something together. 00:21:15.457 --> 00:21:16.780 Oh look, it's got stuck. 00:21:16.780 --> 00:21:19.220 Well both of our coins got stuck in this place. 00:21:19.220 --> 00:21:19.720 Hmm. 00:21:19.720 --> 00:21:22.130 Now it's sort of a hostage situation and you can say, 00:21:22.130 --> 00:21:25.660 well, I think I should get 1 and 1/2 and you should get 1.5. 00:21:25.660 --> 00:21:27.610 It's like wait, we both wanted 1. 00:21:27.610 --> 00:21:29.770 So there is a tax that could happen. 00:21:29.770 --> 00:21:31.572 And so this malleability was a problem 00:21:31.572 --> 00:21:33.280 for people trying to do new, cool things. 00:21:35.890 --> 00:21:37.240 So how do you fix this? 00:21:37.240 --> 00:21:37.740 Any ideas? 00:21:40.270 --> 00:21:41.770 Non-malleable signatures? 00:21:41.770 --> 00:21:45.970 So the one we did for the first homework. 00:21:45.970 --> 00:21:48.970 Does anyone have an idea about why the lamport signatures were 00:21:48.970 --> 00:21:52.930 non-malleable, like from problems at one? 00:21:57.530 --> 00:22:00.330 Yes, it was right. 00:22:00.330 --> 00:22:01.540 But yeah, they weren't. 00:22:04.350 --> 00:22:06.610 There's no randomness for one. 00:22:06.610 --> 00:22:08.957 I'm pretty sure if you flip any of the bits it's not 00:22:08.957 --> 00:22:09.540 going to work. 00:22:09.540 --> 00:22:12.210 So lamport signatures are an example where, yeah, it's 00:22:12.210 --> 00:22:13.540 non-malleable. 00:22:13.540 --> 00:22:18.390 You can't produce multiple different signatures 00:22:18.390 --> 00:22:20.550 on the same message. 00:22:20.550 --> 00:22:22.050 So that's good. 00:22:22.050 --> 00:22:24.540 The thing is many useful signature schemes 00:22:24.540 --> 00:22:25.250 are malleable. 00:22:25.250 --> 00:22:27.750 So to just say no, you have to use a non-malleable signature 00:22:27.750 --> 00:22:30.000 scheme, it's not a great answer to the question. 00:22:33.302 --> 00:22:35.260 I'm pretty sure there's some weird malleability 00:22:35.260 --> 00:22:37.250 stuff in RSA. 00:22:37.250 --> 00:22:40.840 A lot of the systems have randomness in there 00:22:40.840 --> 00:22:43.030 and they're malleable. 00:22:43.030 --> 00:22:46.270 So an idea that I had like 2014 and I 00:22:46.270 --> 00:22:51.640 was sort of going for was just don't sign your inputs at all, 00:22:51.640 --> 00:22:52.967 only sign your outputs. 00:22:52.967 --> 00:22:55.300 So you don't actually specify where you're sending money 00:22:55.300 --> 00:22:56.830 from in your signature. 00:22:56.830 --> 00:22:59.530 You do have to still specify in your transaction 00:22:59.530 --> 00:23:01.540 because people need to know, but you 00:23:01.540 --> 00:23:04.280 say I'm only going to sign off on the outputs. 00:23:04.280 --> 00:23:07.990 The endorsement of my inputs is implicit 00:23:07.990 --> 00:23:10.150 because the keys match. 00:23:10.150 --> 00:23:11.830 So I don't actually sign off on which 00:23:11.830 --> 00:23:16.737 key I'm sending from to something that's redundant. 00:23:16.737 --> 00:23:18.320 You know I'm sending from these inputs 00:23:18.320 --> 00:23:20.195 because the keys match up and the signature's 00:23:20.195 --> 00:23:22.210 valid for this key. 00:23:22.210 --> 00:23:23.970 I really like this idea still. 00:23:23.970 --> 00:23:24.970 I think it's really fun. 00:23:24.970 --> 00:23:26.830 You can do a lot of cool stuff with it. 00:23:26.830 --> 00:23:28.780 It's also dangerous. 00:23:28.780 --> 00:23:31.630 It allows signatures to be replayed, 00:23:31.630 --> 00:23:33.880 which is sort of one of the big points of having 00:23:33.880 --> 00:23:37.720 utxo's because if you send two outputs-- 00:23:41.590 --> 00:23:44.860 I have address one. 00:23:44.860 --> 00:23:46.620 I send two outputs. 00:23:46.620 --> 00:23:52.780 So I've got output one, output two, and this one 00:23:52.780 --> 00:23:55.780 has five coins, this one has three coins, 00:23:55.780 --> 00:23:58.630 and they're both the same address, 00:23:58.630 --> 00:24:01.330 both the same public key, and then I want to spend them. 00:24:01.330 --> 00:24:03.190 And if I use this sort of signature scheme 00:24:03.190 --> 00:24:06.430 where I don't actually sign which input I'm spending from, 00:24:06.430 --> 00:24:07.790 it can be used on either. 00:24:07.790 --> 00:24:11.122 So maybe I'm not aware of this 5-1 yet, 00:24:11.122 --> 00:24:13.330 or it just hasn't happened yet, or I haven't seen it, 00:24:13.330 --> 00:24:15.790 and I say, yeah, I'm going to make a signature sending 00:24:15.790 --> 00:24:18.730 three coins over here and then someone 00:24:18.730 --> 00:24:22.410 can malleate the transaction without touching the signature, 00:24:22.410 --> 00:24:25.050 and pointing over here, and the signature 00:24:25.050 --> 00:24:26.550 wouldn't apply to either. 00:24:26.550 --> 00:24:29.430 And then this is a really good deal for the miners 00:24:29.430 --> 00:24:32.430 because now I'm spending five coins and only outputting three 00:24:32.430 --> 00:24:35.280 and the miners get the two coins difference. 00:24:35.280 --> 00:24:36.990 And so that's pretty dangerous. 00:24:36.990 --> 00:24:40.750 And also, even if they're the same I just say, hey, 00:24:40.750 --> 00:24:43.780 I'm sending three coins to you and then as 00:24:43.780 --> 00:24:46.090 soon as the receiver sees this output, 00:24:46.090 --> 00:24:47.470 oh, it'll also work here. 00:24:47.470 --> 00:24:50.020 I'm going to take another three coins. 00:24:50.020 --> 00:24:54.970 So this is mitigated by not reusing addresses, 00:24:54.970 --> 00:24:58.960 but people reuse addresses. 00:24:58.960 --> 00:25:00.910 So it is dangerous. 00:25:00.910 --> 00:25:03.672 I think in the context of multisig you can reliably 00:25:03.672 --> 00:25:05.380 say like, OK, we're not reusing addresses 00:25:05.380 --> 00:25:07.963 because these addresses are the combination of multiple people 00:25:07.963 --> 00:25:09.148 working together. 00:25:09.148 --> 00:25:10.690 But it would allow really cool things 00:25:10.690 --> 00:25:14.013 where you could sort of work backwards, compute a public key 00:25:14.013 --> 00:25:16.180 that you could prove no one knew the private key to, 00:25:16.180 --> 00:25:17.555 but you could still sign with it. 00:25:17.555 --> 00:25:19.540 Like really weird crazy stuff. 00:25:19.540 --> 00:25:23.930 Anyway, people were still talking about it 00:25:23.930 --> 00:25:24.690 a week or two ago. 00:25:24.690 --> 00:25:26.690 Like, oh, we could do these cool things with it. 00:25:26.690 --> 00:25:29.690 But it's dangerous and so it's like we're not sure 00:25:29.690 --> 00:25:31.520 if it's worth it. 00:25:31.520 --> 00:25:32.020 OK. 00:25:32.020 --> 00:25:34.810 Any questions about this transaction malleability 00:25:34.810 --> 00:25:36.400 so far? 00:25:36.400 --> 00:25:36.900 OK. 00:25:36.900 --> 00:25:39.020 So any ideas of what you actually 00:25:39.020 --> 00:25:42.127 do to fix malleability? 00:25:45.710 --> 00:25:46.760 Nobody? 00:25:46.760 --> 00:25:48.800 OK. 00:25:48.800 --> 00:25:51.590 we'll find out in one minute. 00:25:51.590 --> 00:25:53.660 Segregated Witness. 00:25:53.660 --> 00:25:56.730 I don't think it's a good name. 00:25:56.730 --> 00:26:02.850 Separate signatures would be a much easier to understand name. 00:26:02.850 --> 00:26:04.908 So Peter Wuille who is really good at bitcoin 00:26:04.908 --> 00:26:06.450 and makes all these cool things, he's 00:26:06.450 --> 00:26:08.920 not the best at naming things. 00:26:08.920 --> 00:26:10.960 Makes lots of cool stuff, but just makes 00:26:10.960 --> 00:26:12.210 whatever weird technical name. 00:26:14.910 --> 00:26:16.740 So it's a pretty straightforward idea. 00:26:16.740 --> 00:26:22.460 The idea is when you're signing a transaction you hash 00:26:22.460 --> 00:26:26.330 a bunch of data design, but you don't include the signatures 00:26:26.330 --> 00:26:28.040 in the data you're hashing to sign them 00:26:28.040 --> 00:26:29.210 because that wouldn't make any sense. 00:26:29.210 --> 00:26:29.710 You can't. 00:26:31.788 --> 00:26:34.080 Do the same thing when you're referring to transactions 00:26:34.080 --> 00:26:36.100 themselves as txids. 00:26:36.100 --> 00:26:38.852 So in the exact same way that when you're signing, 00:26:38.852 --> 00:26:40.560 you hash the data without the signatures. 00:26:40.560 --> 00:26:42.420 When you're pointing to a transaction 00:26:42.420 --> 00:26:44.490 to say I'm spending from there, also 00:26:44.490 --> 00:26:46.680 don't include the signature data. 00:26:46.680 --> 00:26:51.292 Just take the hash of the data without the signatures. 00:26:55.530 --> 00:26:56.030 Yeah. 00:26:56.030 --> 00:26:57.980 You just sort of have this pointer. 00:26:57.980 --> 00:27:00.860 You've got a pointer of previous input 00:27:00.860 --> 00:27:03.750 and you've got the outputs, but the signatures aren't in there. 00:27:03.750 --> 00:27:06.750 So the idea is the signature can change and the transaction ID 00:27:06.750 --> 00:27:07.250 doesn't. 00:27:10.900 --> 00:27:12.860 But what about backwards compatibility? 00:27:12.860 --> 00:27:14.600 So this is a great idea. 00:27:14.600 --> 00:27:15.670 Why not go for it? 00:27:15.670 --> 00:27:20.380 But how do you make it backwards compatible so that old software 00:27:20.380 --> 00:27:23.230 can still work with it? 00:27:23.230 --> 00:27:26.880 This seems like a soft fork is I'm 00:27:26.880 --> 00:27:29.910 adding new rules to the system I'm putting 00:27:29.910 --> 00:27:33.070 further restrictions on. 00:27:33.070 --> 00:27:35.260 This seems like just a change. 00:27:35.260 --> 00:27:38.372 It seems like, look, I'm now defining 00:27:38.372 --> 00:27:39.580 something in a different way. 00:27:39.580 --> 00:27:41.980 I'm removing the signatures from the txid. 00:27:41.980 --> 00:27:45.220 How do we make this not appear to be a hard fork? 00:27:45.220 --> 00:27:46.312 Hard fork's easy. 00:27:46.312 --> 00:27:48.520 You just say, look, we're changing the entire system. 00:27:48.520 --> 00:27:52.350 From now on txids don't have signatures. 00:27:52.350 --> 00:27:58.520 So any ideas how you do this in a backwards compatible way 00:27:58.520 --> 00:27:59.930 or just give up hard fork? 00:28:03.834 --> 00:28:09.520 AUDIENCE: Adding restrictions that screw with [INAUDIBLE].. 00:28:09.520 --> 00:28:13.830 PROFESSOR: So you can't change old transactions, 00:28:13.830 --> 00:28:15.900 but having both at the same time is tricky. 00:28:18.453 --> 00:28:20.120 So the idea is it would have been easier 00:28:20.120 --> 00:28:21.470 to start off this way. 00:28:21.470 --> 00:28:24.293 If Satoshi had just started this way, it would have went great. 00:28:24.293 --> 00:28:25.210 He didn't think of it. 00:28:25.210 --> 00:28:27.607 It wasn't a super obvious thing that-- 00:28:27.607 --> 00:28:28.940 so you can do it as a soft fork. 00:28:28.940 --> 00:28:32.150 The way you do it is you make new outputs 00:28:32.150 --> 00:28:34.580 which don't require any signatures at all 00:28:34.580 --> 00:28:37.640 and then you just don't have any signatures. 00:28:37.640 --> 00:28:38.690 This seems kind of silly. 00:28:38.690 --> 00:28:41.630 Signatures are pretty important, otherwise any arbitrary person 00:28:41.630 --> 00:28:43.700 could just take all the money. 00:28:43.700 --> 00:28:46.490 But you redefine things in a way that new people know about 00:28:46.490 --> 00:28:48.380 and old people don't. 00:28:48.380 --> 00:28:51.140 So this is actually what a segwit output looks like. 00:28:51.140 --> 00:28:55.300 The output script is just a zero and then a pubkey hash, 00:28:55.300 --> 00:28:58.300 and then the sig script, the field for a signature 00:28:58.300 --> 00:28:59.500 is just nothing. 00:28:59.500 --> 00:29:03.030 You just don't put a signature there. 00:29:03.030 --> 00:29:05.370 And then when you're running the stack 00:29:05.370 --> 00:29:08.430 you end up with a pubkey hash on the top of the stack, which 00:29:08.430 --> 00:29:12.270 is some number and the interpreter 00:29:12.270 --> 00:29:15.480 looks at a number that's non-zero as true. 00:29:15.480 --> 00:29:17.053 Like in C or things like that. 00:29:17.053 --> 00:29:17.970 And the bitcoins move. 00:29:17.970 --> 00:29:19.080 It's great. 00:29:19.080 --> 00:29:21.990 Someone was joking that you could potentially make this 00:29:21.990 --> 00:29:27.160 into a hard fork, because what if the pubkey hash was zero, 00:29:27.160 --> 00:29:30.868 and you found a pubkey that hashed to zero and then you 00:29:30.868 --> 00:29:33.410 signed signed with it and then segwit would accept it but old 00:29:33.410 --> 00:29:35.440 nodes wouldn't. 00:29:35.440 --> 00:29:38.040 Actually, that doesn't work, but it's sort of-- 00:29:38.040 --> 00:29:42.420 Anyway, if you're running the regular bitcoin software, 00:29:42.420 --> 00:29:45.570 you see this and no signature, and you're like yeah, 00:29:45.570 --> 00:29:47.010 this doesn't need a signature. 00:29:47.010 --> 00:29:48.720 It's just a hash. 00:29:48.720 --> 00:29:50.260 I don't know what this is. 00:29:50.260 --> 00:29:51.690 Fine, the coins move. 00:29:51.690 --> 00:29:54.600 It evaluates to true. 00:29:54.600 --> 00:29:57.600 But the new version of the software 00:29:57.600 --> 00:29:59.777 sort of adds a restriction to this kind of output. 00:29:59.777 --> 00:30:00.360 It says, look. 00:30:00.360 --> 00:30:02.490 If you see this, this is a template. 00:30:02.490 --> 00:30:05.850 This doesn't actually mean put a zero on the stack 00:30:05.850 --> 00:30:07.680 and put a pubkey hash on the stack. 00:30:07.680 --> 00:30:09.690 It means something else. 00:30:09.690 --> 00:30:13.920 Now, it means this is a pubkey hash and look for a signature. 00:30:13.920 --> 00:30:16.583 But look for a signature in a different place. 00:30:16.583 --> 00:30:18.000 Don't actually put it in the place 00:30:18.000 --> 00:30:19.500 you're supposed to put signatures, 00:30:19.500 --> 00:30:20.640 put it in a new place. 00:30:20.640 --> 00:30:24.940 And don't tell the old software about this place. 00:30:24.940 --> 00:30:30.000 We add a new field to the transaction inputs. 00:30:30.000 --> 00:30:33.610 It's sort of in the inputs, but they put it at the end. 00:30:33.610 --> 00:30:35.110 It's kind of weird. 00:30:35.110 --> 00:30:37.240 Logically, it's in the input. 00:30:37.240 --> 00:30:42.120 It's the same, but physically it's not, which is silly. 00:30:42.120 --> 00:30:44.262 I don't like that aspect of it. 00:30:44.262 --> 00:30:46.720 But the idea is there's this new field in the inputs called 00:30:46.720 --> 00:30:49.270 the witness field, and in cryptography, 00:30:49.270 --> 00:30:53.320 witness sort of means signature in this case anyway. 00:30:53.320 --> 00:30:56.300 It's a little bit more general. 00:30:56.300 --> 00:30:57.920 But the old software never sees it. 00:30:57.920 --> 00:31:00.410 So the idea for here's the old transaction format. 00:31:00.410 --> 00:31:04.790 You've got your tx id and index, 36 bytes sort of pointer 00:31:04.790 --> 00:31:06.470 to what you're spending, and then 00:31:06.470 --> 00:31:11.060 a signature which is 100 bytes, and then this stays the same. 00:31:11.060 --> 00:31:12.350 And the new tx format. 00:31:12.350 --> 00:31:14.100 The idea is, yeah, the signatures field 00:31:14.100 --> 00:31:14.930 is still there. 00:31:14.930 --> 00:31:16.370 You just leave it empty. 00:31:16.370 --> 00:31:17.880 So you're not putting any signature. 00:31:17.880 --> 00:31:19.880 It doesn't look like you need to put a signature 00:31:19.880 --> 00:31:21.680 to the old software. 00:31:21.680 --> 00:31:23.510 And then you have this third thing, 00:31:23.510 --> 00:31:28.130 which is witness, which is the same as signature basically. 00:31:28.130 --> 00:31:29.480 Slightly different format. 00:31:29.480 --> 00:31:31.760 And technically, they put them all together 00:31:31.760 --> 00:31:33.802 and put it at the end, which is kind of annoying. 00:31:33.802 --> 00:31:36.140 But anyway, logically this is how they do it. 00:31:36.140 --> 00:31:39.350 They make a new version of the transaction format. 00:31:39.350 --> 00:31:43.160 So the old version looks like empty signatures. 00:31:43.160 --> 00:31:45.050 The new version looks like here's 00:31:45.050 --> 00:31:46.702 this useless empty signature field, 00:31:46.702 --> 00:31:48.410 and here's where the real signatures are. 00:31:51.310 --> 00:31:53.820 And you omit this to the old nodes. 00:31:53.820 --> 00:31:58.710 So when people ask for witness transactions, 00:31:58.710 --> 00:32:01.507 when people know about this new system, 00:32:01.507 --> 00:32:02.590 yeah, you give it to them. 00:32:02.590 --> 00:32:06.450 So they say hey, yeah, I'm hip to this new segwit thing. 00:32:06.450 --> 00:32:08.070 Give me a segwit transaction. 00:32:08.070 --> 00:32:10.680 And you're like, OK, here's the witnesses at the end. 00:32:10.680 --> 00:32:12.833 But when they don't seem to know about this 00:32:12.833 --> 00:32:14.250 and they're running older software 00:32:14.250 --> 00:32:16.250 and they say, hey, just give me the transaction, 00:32:16.250 --> 00:32:18.400 you give it to them without the witness at all. 00:32:18.400 --> 00:32:20.340 It still looks valid to-- 00:32:20.340 --> 00:32:22.170 either one looks valid. 00:32:22.170 --> 00:32:28.380 However, the new people, they know that if you see this, 00:32:28.380 --> 00:32:31.120 it does not mean push a zero, push up pubkey has. 00:32:31.120 --> 00:32:33.120 There is a new rule that no, this is a template. 00:32:33.120 --> 00:32:34.110 This is segwit. 00:32:34.110 --> 00:32:38.890 I need a signature, and I need it to be in the witness field. 00:32:38.890 --> 00:32:44.250 So if a new node gets a transaction without a witness 00:32:44.250 --> 00:32:47.580 that they know needs a witness, they will declare it invalid. 00:32:47.580 --> 00:32:49.710 But the old nodes won't be able to distinguish. 00:32:49.710 --> 00:32:52.260 They'll say, well, it looks like no signature is needed here. 00:32:52.260 --> 00:32:53.250 OK. 00:32:53.250 --> 00:32:56.447 So you're sort of tricking the old software 00:32:56.447 --> 00:32:58.530 into accepting things that they shouldn't actually 00:32:58.530 --> 00:33:00.060 accept in some cases. 00:33:00.060 --> 00:33:02.250 There may not be a valid signature that 00:33:02.250 --> 00:33:03.990 goes into the segwit transaction, 00:33:03.990 --> 00:33:07.490 but old software will still think it's OK. 00:33:07.490 --> 00:33:10.440 So this is how you make it into a softfork. 00:33:10.440 --> 00:33:11.190 It's kind of ugly. 00:33:11.190 --> 00:33:11.962 But, yeah. 00:33:11.962 --> 00:33:12.920 Do you have a question? 00:33:12.920 --> 00:33:13.526 AUDIENCE: Yeah. 00:33:13.526 --> 00:33:14.568 Is this still implicitly? 00:33:14.568 --> 00:33:17.702 So when the signature is zero, [INAUDIBLE].. 00:33:20.650 --> 00:33:28.150 PROFESSOR: No, because it's based on the output script. 00:33:28.150 --> 00:33:31.870 You could make you a different output script that 00:33:31.870 --> 00:33:34.570 would have a signature that no signature requirement, 00:33:34.570 --> 00:33:37.630 and it would still work even with this new system. 00:33:37.630 --> 00:33:39.240 So it's just based on-- 00:33:39.240 --> 00:33:42.750 we changed the definition of an output script. 00:33:42.750 --> 00:33:44.980 So have this sort of template. 00:33:44.980 --> 00:33:46.060 You can still do weird-- 00:33:46.060 --> 00:33:49.750 like you could put without a zero in front. 00:33:49.750 --> 00:33:51.900 You could put just a pubkey hash, 00:33:51.900 --> 00:33:53.380 and that's not defined in segwit. 00:33:53.380 --> 00:33:54.580 That's not defined anywhere. 00:33:54.580 --> 00:33:57.250 It would just be, OK, yeah, it evaluates 00:33:57.250 --> 00:33:58.480 to true without a signature. 00:33:58.480 --> 00:34:00.090 Anyone can spend it. 00:34:00.090 --> 00:34:03.460 And you could do that-- 00:34:03.460 --> 00:34:06.532 that would have to be a non-segwit transaction. 00:34:06.532 --> 00:34:08.199 The only way to use a segwit transaction 00:34:08.199 --> 00:34:12.500 is to have the special format for the output script. 00:34:12.500 --> 00:34:14.620 Any other questions about network stuff? 00:34:14.620 --> 00:34:20.480 Yeah, and this solves malleability 00:34:20.480 --> 00:34:22.010 in a pretty good way. 00:34:22.010 --> 00:34:24.157 For the old software, the old nodes, 00:34:24.157 --> 00:34:25.699 well, they can't change the signature 00:34:25.699 --> 00:34:26.699 because there isn't one. 00:34:26.699 --> 00:34:29.120 There's nothing to malleate. 00:34:29.120 --> 00:34:31.070 And from the new node's perspective, 00:34:31.070 --> 00:34:33.949 yes, the signature can change, but that doesn't 00:34:33.949 --> 00:34:35.449 affect the transaction ID. 00:34:35.449 --> 00:34:38.090 Both old and new nodes still agree 00:34:38.090 --> 00:34:40.489 on the exact same transaction ID. 00:34:40.489 --> 00:34:46.320 The transaction ID does not include the witness field. 00:34:46.320 --> 00:34:48.520 So when you're calculating a transaction, 00:34:48.520 --> 00:34:50.260 you include all this for backwards. 00:34:50.260 --> 00:34:52.052 And if there's this actual signature there, 00:34:52.052 --> 00:34:54.060 that gets into that the txid. 00:34:54.060 --> 00:34:55.860 But if you're using empty signature 00:34:55.860 --> 00:34:58.820 and only using witness, then it doesn't get into the txid 00:34:58.820 --> 00:35:00.470 at all. 00:35:00.470 --> 00:35:03.110 So both old and new software agree, 00:35:03.110 --> 00:35:06.530 and that's important, because if they didn't the merkle routes 00:35:06.530 --> 00:35:07.320 would look wrong. 00:35:07.320 --> 00:35:09.528 You take all the txids, put them into a merkle route, 00:35:09.528 --> 00:35:10.800 put that in the header. 00:35:10.800 --> 00:35:13.790 And that's really important that everyone agrees on that. 00:35:13.790 --> 00:35:16.010 So they do work together, So that's cool. 00:35:19.620 --> 00:35:21.360 So this is kind of interesting. 00:35:21.360 --> 00:35:24.750 You've got two different old version, 00:35:24.750 --> 00:35:28.050 new version operating at the same time on the network. 00:35:28.050 --> 00:35:30.180 And they agree on a lot of stuff, 00:35:30.180 --> 00:35:32.475 but they also sort of disagree on some things. 00:35:32.475 --> 00:35:35.970 So they agree on outputs of the transactions, 00:35:35.970 --> 00:35:38.485 and they agree on which inputs there are. 00:35:38.485 --> 00:35:40.110 But they have a slightly different view 00:35:40.110 --> 00:35:41.152 of what these inputs are. 00:35:41.152 --> 00:35:42.940 Some of them think, no signatures here. 00:35:42.940 --> 00:35:45.065 Some of them think, yeah, there's a signature here. 00:35:45.065 --> 00:35:46.170 That's weird. 00:35:46.170 --> 00:35:48.150 They don't agree on how things got spent. 00:35:48.150 --> 00:35:51.090 What are some other things that these two different classes 00:35:51.090 --> 00:35:52.724 of nodes would not agree on? 00:35:55.470 --> 00:35:56.740 Any ideas? 00:35:56.740 --> 00:36:00.310 So you understand how they see different transactions. 00:36:00.310 --> 00:36:02.660 What are some other aspects that may 00:36:02.660 --> 00:36:05.470 be sort of interesting for this consensus system 00:36:05.470 --> 00:36:08.160 that we have different views on? 00:36:08.160 --> 00:36:09.170 I forget what I put. 00:36:09.170 --> 00:36:11.660 I put two things. 00:36:11.660 --> 00:36:13.604 Any? 00:36:13.604 --> 00:36:15.560 Hint. 00:36:15.560 --> 00:36:20.360 Biggest argument since 2010 in bitcoin. 00:36:20.360 --> 00:36:23.320 What do these two different classes of nodes not agree on? 00:36:26.603 --> 00:36:28.010 Yeah. 00:36:28.010 --> 00:36:29.420 AUDIENCE: Size? 00:36:29.420 --> 00:36:31.050 PROFESSOR: Well, the transaction size. 00:36:31.050 --> 00:36:31.550 Yeah. 00:36:31.550 --> 00:36:34.640 So they both see two different transactions. 00:36:34.640 --> 00:36:36.890 One of them sees it with these signatures, one of them 00:36:36.890 --> 00:36:38.030 sees it without. 00:36:38.030 --> 00:36:40.160 They don't agree on how big the transaction is. 00:36:40.160 --> 00:36:41.920 They agree on the txid. 00:36:41.920 --> 00:36:44.583 They agree on where the money is going, where it's coming from, 00:36:44.583 --> 00:36:46.250 but they have completely different views 00:36:46.250 --> 00:36:50.190 of how big this transaction is in terms of number of bytes. 00:36:50.190 --> 00:36:55.780 So this is really interesting, For many, many years 00:36:55.780 --> 00:36:58.300 since 2010, everyone's been arguing. 00:36:58.300 --> 00:37:00.070 And one of the big aspects of, oh, if we 00:37:00.070 --> 00:37:02.980 want to increase the block size, that's a hard fork. 00:37:02.980 --> 00:37:06.220 Everyone up to now, we're enforcing. 00:37:06.220 --> 00:37:09.693 The block size must be one million bytes or less. 00:37:09.693 --> 00:37:11.110 There's no way around that, right? 00:37:11.110 --> 00:37:12.377 You can't just increase it. 00:37:12.377 --> 00:37:13.210 We've got this rule. 00:37:13.210 --> 00:37:15.050 You're breaking that rule. 00:37:15.050 --> 00:37:18.850 This is a sneaky way to break the rule but still not tell 00:37:18.850 --> 00:37:21.170 people you're breaking the rule. 00:37:21.170 --> 00:37:25.087 Say, OK, I'm enforcing a rule that there's one million bytes. 00:37:25.087 --> 00:37:27.670 As far as I'm concerned, there are less than one million bytes 00:37:27.670 --> 00:37:30.100 in this set of transactions. 00:37:30.100 --> 00:37:32.530 The new nodes know, yeah, there's more than one million. 00:37:32.530 --> 00:37:34.270 There's like two million bytes in here. 00:37:34.270 --> 00:37:37.690 We just didn't tell the old software 00:37:37.690 --> 00:37:39.620 about all these extra bytes. 00:37:39.620 --> 00:37:43.300 So this is kind of an interesting thing you can do. 00:37:43.300 --> 00:37:46.030 So you can increase the transaction size 00:37:46.030 --> 00:37:47.890 without telling the old nodes. 00:37:47.890 --> 00:37:52.350 So yeah, the old nodes don't see the hundred something bytes 00:37:52.350 --> 00:37:53.870 with the pubkey signature. 00:37:53.870 --> 00:37:56.940 So they see transactions that are much smaller. 00:37:56.940 --> 00:37:58.380 Around half the size-- 00:37:58.380 --> 00:38:01.770 depends, but half the size ish. 00:38:01.770 --> 00:38:04.260 So those bytes, they won't count those bites 00:38:04.260 --> 00:38:07.890 towards the one million byte block size limit. 00:38:07.890 --> 00:38:11.310 So this ends up being a soft fork that allows 00:38:11.310 --> 00:38:12.960 you to increase the block size. 00:38:12.960 --> 00:38:14.310 In a kind of sneaky way, right? 00:38:14.310 --> 00:38:17.190 The old nodes don't think the block size is increased. 00:38:17.190 --> 00:38:21.347 They think it's less than a megabyte, and they also think, 00:38:21.347 --> 00:38:21.930 this is weird. 00:38:21.930 --> 00:38:24.210 I haven't seen any signatures for a while. 00:38:24.210 --> 00:38:27.420 | seems to be using these transactions that don't require 00:38:27.420 --> 00:38:29.130 signatures, and somehow everyone's 00:38:29.130 --> 00:38:31.530 getting along and not stealing each other's money 00:38:31.530 --> 00:38:34.830 despite the lack of a need for signatures. 00:38:34.830 --> 00:38:38.430 But these are not intelligent people. 00:38:38.430 --> 00:38:41.820 These are software programs, and it'll just run. 00:38:41.820 --> 00:38:43.830 And it'll, OK, yup, yup, yup. 00:38:43.830 --> 00:38:46.555 This evaluates to true. 00:38:46.555 --> 00:38:47.430 So it's kind of cool. 00:38:47.430 --> 00:38:49.750 Block size entry softfork. 00:38:49.750 --> 00:38:54.450 However, you Institute a new rule with segwit. 00:38:54.450 --> 00:38:58.470 You don't want to just say for the new rules, 00:38:58.470 --> 00:39:00.870 we don't count signatures towards the one megabyte limit, 00:39:00.870 --> 00:39:01.770 right? 00:39:01.770 --> 00:39:05.310 You could do that, but then people might spam signatures. 00:39:05.310 --> 00:39:08.010 Let me make a giant signature or some kind of like 50 00:39:08.010 --> 00:39:12.870 out of a million pubkeys thing and spam the network, 00:39:12.870 --> 00:39:17.187 and then it will still be under a megabyte of non witness data. 00:39:17.187 --> 00:39:19.020 So yes, so now I've got two classes of data. 00:39:19.020 --> 00:39:21.720 You've got all the data that everyone sees, 00:39:21.720 --> 00:39:25.050 and all the witness data that only the new nodes see. 00:39:25.050 --> 00:39:28.650 So what they did is they said, OK, the witness data still 00:39:28.650 --> 00:39:30.460 counts towards that limit. 00:39:30.460 --> 00:39:34.800 But each witness byte counts as a 1/4 of a regular byte. 00:39:34.800 --> 00:39:37.290 OK, kind of weird, but yeah. 00:39:37.290 --> 00:39:40.650 So in practice in the software, what they do is they say, OK. 00:39:40.650 --> 00:39:45.240 We multiply the non witness bytes by four. 00:39:45.240 --> 00:39:49.020 So every byte in the outputs and every byte in the txid input 00:39:49.020 --> 00:39:51.090 things counts as like four bytes. 00:39:51.090 --> 00:39:53.790 And then, the witnesses just count as one regular byte. 00:39:53.790 --> 00:39:55.830 And then we now say, OK, the new block size 00:39:55.830 --> 00:39:58.000 is four million bytes. 00:39:58.000 --> 00:40:02.410 But four million weight units, because they're sort of, OK, 00:40:02.410 --> 00:40:04.780 we've got different weights for things. 00:40:04.780 --> 00:40:09.920 This actually makes sense, because the utxo set 00:40:09.920 --> 00:40:11.980 is what you really want to minimize, 00:40:11.980 --> 00:40:14.560 that database we keep updating every block. 00:40:14.560 --> 00:40:18.100 And the signatures don't go into the utxo set. 00:40:18.100 --> 00:40:19.600 So the signatures you don't actually 00:40:19.600 --> 00:40:23.600 have to store on a fast, low latency storage. 00:40:23.600 --> 00:40:26.200 So in a very real sense, the signatures 00:40:26.200 --> 00:40:28.570 are sort of OK to make bigger. 00:40:28.570 --> 00:40:31.690 They don't really cost as much to the network to store. 00:40:31.690 --> 00:40:33.770 So having this discount where you say, 00:40:33.770 --> 00:40:36.752 OK, the signatures, you can have a bunch of them that 00:40:36.752 --> 00:40:37.960 doesn't really count as much. 00:40:37.960 --> 00:40:41.160 But the outputs we really need to minimize. 00:40:41.160 --> 00:40:44.440 So this one fourth is somewhat arbitrary, 00:40:44.440 --> 00:40:46.950 but there are some calculations and a little handwaving. 00:40:46.950 --> 00:40:48.950 But it's like yeah, this is about what it should 00:40:48.950 --> 00:40:52.520 be to try to balance things. 00:40:52.520 --> 00:40:55.450 So the end result. If you have this discount, 00:40:55.450 --> 00:40:58.510 you can put about 80% more transactions in a block. 00:40:58.510 --> 00:41:01.030 You get about 1.8 megs. 00:41:01.030 --> 00:41:01.780 It depends, right? 00:41:01.780 --> 00:41:03.405 It depends how big your signatures are. 00:41:05.750 --> 00:41:08.360 So the maximum would be you have a block that 00:41:08.360 --> 00:41:13.490 has one transaction with just a giant signature that's 00:41:13.490 --> 00:41:15.330 like almost four megabytes. 00:41:15.330 --> 00:41:17.390 And the old software would see this block 00:41:17.390 --> 00:41:19.593 as being really tiny, like 100 something bytes. 00:41:19.593 --> 00:41:21.260 And the new software would see, oh yeah, 00:41:21.260 --> 00:41:23.990 this block is almost four megabytes. 00:41:23.990 --> 00:41:25.730 But that's sort of the extreme case. 00:41:25.730 --> 00:41:29.930 I remember generating some like 3.7 meg transaction blocks 00:41:29.930 --> 00:41:32.810 and testing that awhile ago just to test it out. 00:41:32.810 --> 00:41:35.710 It works, but in practice you're seeing about this. 00:41:35.710 --> 00:41:39.860 In practice today, as segwit has been seeing more adoption, 00:41:39.860 --> 00:41:42.410 you see like 1.3 megabyte blocks. 00:41:42.410 --> 00:41:44.157 Not everyone's using it. 00:41:44.157 --> 00:41:45.740 The idea is it's backwards compatible, 00:41:45.740 --> 00:41:47.407 but you can still use your old software. 00:41:47.407 --> 00:41:51.020 But it seems like more and more software is using this. 00:41:51.020 --> 00:41:54.500 You get a discount on your fees because your transaction 00:41:54.500 --> 00:41:55.670 seems to be smaller. 00:41:55.670 --> 00:41:57.253 You can fit more of them in a block. 00:41:57.253 --> 00:41:58.670 So that's kind of cool, and that's 00:41:58.670 --> 00:41:59.962 sort of an incentive to use it. 00:42:02.410 --> 00:42:04.320 OK, other thing you can do. 00:42:04.320 --> 00:42:07.020 You can commit to signatures. 00:42:07.020 --> 00:42:09.570 This is a little tricky. 00:42:09.570 --> 00:42:12.390 If the signatures aren't in the transaction ID, 00:42:12.390 --> 00:42:15.330 then they aren't in the merkle route, right? 00:42:15.330 --> 00:42:17.850 So there's nothing really committing the signatures 00:42:17.850 --> 00:42:19.410 into the block chain. 00:42:19.410 --> 00:42:21.487 And this would actually work. 00:42:21.487 --> 00:42:23.070 You could say, no, I have a signature. 00:42:23.070 --> 00:42:26.430 I'll give it to you, but it could change. 00:42:26.430 --> 00:42:29.100 It could be maleated, so it could be weird, though. 00:42:29.100 --> 00:42:31.770 You could agree on a utxo set, but you could disagree 00:42:31.770 --> 00:42:33.630 on how exactly you got there. 00:42:33.630 --> 00:42:37.230 So one example would be multisig, 00:42:37.230 --> 00:42:40.020 where there's two of three multisig, Alice, Bob and Carol. 00:42:40.020 --> 00:42:41.610 Two of them need to sign. 00:42:41.610 --> 00:42:44.390 And then on my computer, it says that Alice and Bob signed, 00:42:44.390 --> 00:42:47.550 and on your computer, it says that Alison and Carol signed. 00:42:47.550 --> 00:42:49.740 That's weird, right? 00:42:49.740 --> 00:42:50.640 For accountability. 00:42:50.640 --> 00:42:53.850 If we want to know who exactly endorsed these things, 00:42:53.850 --> 00:42:55.550 we might disagree on it. 00:42:55.550 --> 00:42:58.290 There would be no canonical here's the blockchain, 00:42:58.290 --> 00:42:59.288 here's who signed. 00:42:59.288 --> 00:43:01.080 The transactions themselves would all still 00:43:01.080 --> 00:43:03.430 be the same but not the signatures. 00:43:03.430 --> 00:43:06.480 So that's kind of weird, but it also seems like well, 00:43:06.480 --> 00:43:10.380 maybe that's part of the price you pay for fixing malleability 00:43:10.380 --> 00:43:11.100 in this way. 00:43:11.100 --> 00:43:14.940 If we're not putting the signatures into the thing that 00:43:14.940 --> 00:43:18.370 gets committed to in the block chain, then yeah, 00:43:18.370 --> 00:43:20.170 signatures can change. 00:43:20.170 --> 00:43:23.960 So anyway around this? 00:43:23.960 --> 00:43:28.060 It sort of seems like yeah, that's the trade off. 00:43:28.060 --> 00:43:29.700 Sneaky way around it? 00:43:29.700 --> 00:43:30.306 Sneaky fun? 00:43:30.306 --> 00:43:31.220 No? 00:43:31.220 --> 00:43:33.420 You know. 00:43:33.420 --> 00:43:41.178 OK, so what you do actually, you commit the signatures 00:43:41.178 --> 00:43:41.970 but in a weird way. 00:43:41.970 --> 00:43:44.350 OK, so here's the regular old merkle tree, right? 00:43:44.350 --> 00:43:47.570 This is the merkle route that you put in the header. 00:43:47.570 --> 00:43:51.220 Here's all the transaction IDs, and so you 00:43:51.220 --> 00:43:53.112 make these intermediate hashes. 00:43:53.112 --> 00:43:55.570 This is the hash of these two things concatenated together, 00:43:55.570 --> 00:44:00.010 this is the hash of these two things concatenated together. 00:44:00.010 --> 00:44:02.650 Now, if the txids don't have signatures, 00:44:02.650 --> 00:44:06.000 there's no commitment to the signatures in the top hash. 00:44:06.000 --> 00:44:07.445 What you do is this. 00:44:07.445 --> 00:44:08.920 You say, OK. 00:44:08.920 --> 00:44:10.860 I'm going to make these new witness 00:44:10.860 --> 00:44:16.195 txids, hashes of transactions that do include the signatures. 00:44:16.195 --> 00:44:18.820 In practice, you could just make a hash of just the signatures. 00:44:18.820 --> 00:44:19.930 That would also work. 00:44:19.930 --> 00:44:22.960 They just take the whole thing. 00:44:22.960 --> 00:44:27.100 And now I've got this other reflected 00:44:27.100 --> 00:44:29.170 merkle tree kind of thing, where OK, I 00:44:29.170 --> 00:44:33.070 take the hash of these two witness transaction IDs, 00:44:33.070 --> 00:44:35.770 put it here, and this one just drops down. 00:44:35.770 --> 00:44:37.720 It's another merkle tree, and then you 00:44:37.720 --> 00:44:41.500 get a root for all those things called the witness root. 00:44:41.500 --> 00:44:43.900 And then what you do is you put the witness root 00:44:43.900 --> 00:44:46.420 in the coinbase transaction. 00:44:46.420 --> 00:44:47.710 Put in an opp return. 00:44:47.710 --> 00:44:50.410 And the idea is the coinbase transaction 00:44:50.410 --> 00:44:52.390 doesn't have any signatures anyway, right? 00:44:52.390 --> 00:44:55.720 So you can put it in there. 00:44:55.720 --> 00:44:58.600 You don't need to include the transaction 00:44:58.600 --> 00:45:01.415 zero in this witness tree. 00:45:01.415 --> 00:45:04.180 Wait, they do though, right? 00:45:04.180 --> 00:45:09.220 But maybe this is slightly inaccurate in that I think 00:45:09.220 --> 00:45:12.430 they actually do make a witness txid 00:45:12.430 --> 00:45:14.470 for the coinbase transaction, but they define it 00:45:14.470 --> 00:45:18.264 as being zero or something. 00:45:18.264 --> 00:45:20.035 I think-- I don't remember. 00:45:20.035 --> 00:45:20.910 So it's weird, right? 00:45:20.910 --> 00:45:24.010 But you could do that. 00:45:24.010 --> 00:45:26.500 They define a zero, or they let you pick anything you want. 00:45:26.500 --> 00:45:27.940 I would have to look at the code. 00:45:27.940 --> 00:45:32.100 But anyway, the basic idea is for these anyway, 00:45:32.100 --> 00:45:34.950 you take the hash of the whole thing including the signatures, 00:45:34.950 --> 00:45:37.260 put it in the witness root, put the witness root 00:45:37.260 --> 00:45:40.230 in the coinbase transaction, and the coinbase this transaction 00:45:40.230 --> 00:45:42.420 gets in to the merkle root. 00:45:42.420 --> 00:45:45.570 So you are committing to all the signatures 00:45:45.570 --> 00:45:49.380 but on the block level, not the transaction level. 00:45:49.380 --> 00:45:53.750 So in the case where I think Alice and Bob signed. 00:45:53.750 --> 00:45:56.010 Oh, I think Alice and Carol signed. 00:45:56.010 --> 00:45:58.440 You can have those two transactions floating around 00:45:58.440 --> 00:46:02.385 on the network, and they have the same txid. 00:46:02.385 --> 00:46:05.100 And so who knows which one's getting into a block? 00:46:05.100 --> 00:46:07.040 They look almost the same. 00:46:07.040 --> 00:46:09.490 Some of the software won't be able to pick between them. 00:46:09.490 --> 00:46:12.480 However, once it gets into a block, one of them 00:46:12.480 --> 00:46:13.700 will be committed to. 00:46:13.700 --> 00:46:17.710 It's like, oh, ended up being Alice and Carol. 00:46:17.710 --> 00:46:22.340 Those two signatures actually got into the blockchain. 00:46:22.340 --> 00:46:26.470 However, you could prove, hey, no I 00:46:26.470 --> 00:46:29.423 had this Alice Bob signature, but then it 00:46:29.423 --> 00:46:31.090 never got into the blockchain, and maybe 00:46:31.090 --> 00:46:32.030 you made it after the fact. 00:46:32.030 --> 00:46:33.200 It never gets committed to. 00:46:33.200 --> 00:46:33.540 Yeah. 00:46:33.540 --> 00:46:34.960 AUDIENCE: Also, a bunch of pool software 00:46:34.960 --> 00:46:36.127 just doesn't always do this. 00:46:36.430 --> 00:46:38.597 PROFESSOR: A bunch of pool software doesn't do this? 00:46:38.597 --> 00:46:39.240 What you mean? 00:46:39.240 --> 00:46:40.615 AUDIENCE: It's the responsibility 00:46:40.615 --> 00:46:43.738 of the pool software to make this construction, 00:46:43.738 --> 00:46:46.673 but [INAUDIBLE] 00:46:46.673 --> 00:46:48.590 PROFESSOR: Have it implemented as in they just 00:46:48.590 --> 00:46:49.465 don't support segwit? 00:46:49.465 --> 00:46:51.524 AUDIENCE: No, so they do the first part, 00:46:51.524 --> 00:46:57.510 but [INAUDIBLE] segwit support. 00:46:57.510 --> 00:47:00.150 PROFESSOR: OK, but wouldn't that just not work? 00:47:00.150 --> 00:47:00.650 How-- 00:47:00.650 --> 00:47:01.858 AUDIENCE: It works, because-- 00:47:01.858 --> 00:47:02.888 [INAUDIBLE] 00:47:02.888 --> 00:47:05.180 PROFESSOR: But to the new software, if you don't have-- 00:47:17.830 --> 00:47:19.330 so segwit is the software, right? 00:47:19.330 --> 00:47:22.370 You say, OK, we define these new transaction types. 00:47:22.370 --> 00:47:25.970 We define this template where if you have a zero and then 00:47:25.970 --> 00:47:27.900 this pubkey hash. 00:47:27.900 --> 00:47:34.860 It also says, I require the coinbase transaction 00:47:34.860 --> 00:47:39.720 to have this output that says, op return aa9c 00:47:39.720 --> 00:47:42.900 whatever this little four random bytes, 00:47:42.900 --> 00:47:45.837 and then I'd require it to have the witness root in here. 00:47:45.837 --> 00:47:47.420 AUDIENCE: I'm guessing they just don't 00:47:47.420 --> 00:47:49.162 include segwit transactions? 00:47:49.162 --> 00:47:50.620 PROFESSOR: So I've seen that a lot. 00:47:50.620 --> 00:47:51.540 Yeah, so a lot of-- 00:47:51.540 --> 00:47:52.415 AUDIENCE: [INAUDIBLE] 00:47:52.415 --> 00:47:54.030 PROFESSOR: Yeah, a lot of the software 00:47:54.030 --> 00:47:56.807 says, I'm not going to do this. 00:47:56.807 --> 00:47:58.140 So the other thing that's nice-- 00:47:58.140 --> 00:48:01.320 segwit transactions to old software look non-standard. 00:48:01.320 --> 00:48:03.990 So I mentioned before that there's standardness rules 00:48:03.990 --> 00:48:05.550 where, this looks weird. 00:48:05.550 --> 00:48:06.930 I'm not going to mine it. 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, 00:48:09.900 --> 00:48:11.850 well, OK, fine. 00:48:11.850 --> 00:48:14.742 So segwit transactions look very non-standard. 00:48:14.742 --> 00:48:16.200 It looks like there's no signature. 00:48:16.200 --> 00:48:16.960 That's weird. 00:48:16.960 --> 00:48:19.110 There's this zero. 00:48:19.110 --> 00:48:20.820 What's going on? 00:48:20.820 --> 00:48:23.670 So yeah, you can you can still run a miner 00:48:23.670 --> 00:48:26.300 and just not even know about segwit. 00:48:26.300 --> 00:48:28.610 It's a little dangerous, because you 00:48:28.610 --> 00:48:32.360 might see a block that is segwit invalid, 00:48:32.360 --> 00:48:33.860 but you wouldn't know it and so you 00:48:33.860 --> 00:48:35.152 might try to mine on top of it. 00:48:35.152 --> 00:48:36.820 So there are some risks, but in general 00:48:36.820 --> 00:48:38.990 if most people are doing the right thing, 00:48:38.990 --> 00:48:41.670 you could still mine without knowing about this stuff. 00:48:41.670 --> 00:48:47.090 So any questions about committing to the signatures? 00:48:47.090 --> 00:48:47.962 What else? 00:48:47.962 --> 00:48:49.670 Oh yeah, so you've got this upgrade path. 00:48:49.670 --> 00:48:52.470 That's kind of cool. 00:48:52.470 --> 00:48:56.780 So it defined zero pubkey hash as hey, 00:48:56.780 --> 00:49:01.220 this is now pay to pubkey hash, right? 00:49:01.220 --> 00:49:05.030 Interpret this weird template as the regular hey, 00:49:05.030 --> 00:49:06.650 verify this signature. 00:49:06.650 --> 00:49:09.590 It also, when segwit softfork happened, 00:49:09.590 --> 00:49:13.640 redefined a whole bunch of other templates like this. 00:49:13.640 --> 00:49:17.090 So one and then some data, or two and then some data. 00:49:17.090 --> 00:49:19.370 Just put a number, and then put a bunch of data. 00:49:19.370 --> 00:49:23.940 All of these are defined as future upgrades. 00:49:23.940 --> 00:49:29.400 So if you see a three block of data, you now say, yeah, OK. 00:49:29.400 --> 00:49:31.080 I know that's segwit version three. 00:49:31.080 --> 00:49:33.520 My software will maybe pop up something saying hey, 00:49:33.520 --> 00:49:35.220 people are using segwit version three. 00:49:35.220 --> 00:49:38.250 You're only aware of segwit version zero. 00:49:38.250 --> 00:49:40.080 But you'll consider it non-standard. 00:49:40.080 --> 00:49:41.220 You won't relay it. 00:49:41.220 --> 00:49:43.020 But if it's in a block, yeah, sure. 00:49:43.020 --> 00:49:46.097 And you don't require anything about the signature. 00:49:46.097 --> 00:49:48.180 You'll just say, yeah, whatever weird witness data 00:49:48.180 --> 00:49:50.460 you provide for these outputs, I don't 00:49:50.460 --> 00:49:51.630 know how to interpret them. 00:49:51.630 --> 00:49:54.270 I'm just going to let it all go through. 00:49:54.270 --> 00:49:56.040 What that means is-- 00:49:56.040 --> 00:49:57.353 there's no witness needed. 00:49:57.353 --> 00:49:58.770 If a witness is provided, you just 00:49:58.770 --> 00:50:01.758 ignore it and you think everything's fine. 00:50:01.758 --> 00:50:02.925 This allows easier upgrades. 00:50:05.840 --> 00:50:07.670 You have 16 new versions to upgrade to. 00:50:10.250 --> 00:50:13.223 Yeah, you don't require any specific things about this, 00:50:13.223 --> 00:50:15.890 so you can make new scripts, you can make a completely different 00:50:15.890 --> 00:50:16.720 script interpreter. 00:50:16.720 --> 00:50:18.470 You could say, OK, we're going to port EVM 00:50:18.470 --> 00:50:22.400 to bitcoin and disable some of the op codes 00:50:22.400 --> 00:50:24.410 that don't apply, and have that kind of thing. 00:50:24.410 --> 00:50:25.670 Have new smart contracts. 00:50:25.670 --> 00:50:28.610 So it's kind of a fun, like yeah, we will-- 00:50:28.610 --> 00:50:30.502 and it's a nice, easy upgrade path. 00:50:30.502 --> 00:50:32.210 You could have multiple different things, 00:50:32.210 --> 00:50:34.010 things like that. 00:50:34.010 --> 00:50:36.500 The code will be easier. 00:50:36.500 --> 00:50:37.640 Don't do it today. 00:50:37.640 --> 00:50:39.620 You could construct an output that's 00:50:39.620 --> 00:50:44.060 a two byte and then your pubkey and send it out there. 00:50:44.060 --> 00:50:48.610 It will be probably stealing by miners, because everyone else's 00:50:48.610 --> 00:50:51.110 node will say, yeah, I don't know how to interpret this yet. 00:50:51.110 --> 00:50:54.580 There's no rules about this yet. 00:50:54.580 --> 00:51:01.990 OK, let me show you some segwit stuff I looked for. 00:51:06.800 --> 00:51:12.657 OK, so there's actually nested segwit. 00:51:12.657 --> 00:51:13.490 There's an an ugly-- 00:51:19.370 --> 00:51:20.750 I didn't like it, but-- 00:51:20.750 --> 00:51:25.982 this is like somewhat designed by committee E. There's also-- 00:51:25.982 --> 00:51:28.830 this is 2016, right? 00:51:28.830 --> 00:51:31.330 AUDIENCE: People lose so much money on segwit two years ago. 00:51:31.330 --> 00:51:34.105 PROFESSOR: So the other thing I would say with this, 00:51:34.105 --> 00:51:34.730 I was like, OK. 00:51:34.730 --> 00:51:36.550 You've got this witness txid. 00:51:36.550 --> 00:51:39.040 And I remember people working on segwit 00:51:39.040 --> 00:51:42.460 and I said, hey, why don't you make the transaction IDs 00:51:42.460 --> 00:51:46.580 a merkle tree of the inputs and outputs instead 00:51:46.580 --> 00:51:49.040 of just the hash of everything all together? 00:51:49.040 --> 00:51:51.190 Then, if you had a really big transaction, 00:51:51.190 --> 00:51:53.690 you could prove that an input had been spent without sending 00:51:53.690 --> 00:51:55.112 the whole transaction over. 00:51:55.112 --> 00:51:56.570 And I thought that was a cool idea. 00:51:56.570 --> 00:51:58.737 And then when I talked to people, they're like yeah, 00:51:58.737 --> 00:52:01.280 Peter Todd already said that like three weeks ago. 00:52:01.280 --> 00:52:03.620 And whatever, we're not going to do it. 00:52:03.620 --> 00:52:04.400 It's too late. 00:52:04.400 --> 00:52:05.720 We already coded stuff. 00:52:05.720 --> 00:52:08.420 Oh well. 00:52:08.420 --> 00:52:11.060 And that's the fundamental aspect of segwit. 00:52:11.060 --> 00:52:13.850 You can't really upgrade that in the new script versions, 00:52:13.850 --> 00:52:17.490 so whatever. 00:52:17.490 --> 00:52:20.520 There's also still a hard rule on transactions themselves 00:52:20.520 --> 00:52:22.020 being less than a megabyte, I think. 00:52:22.020 --> 00:52:24.990 So it's not a huge deal, but it would have been cool. 00:52:24.990 --> 00:52:29.220 Another thing is there's actually a way-- 00:52:29.220 --> 00:52:32.670 so there's no address defined for this, right? 00:52:32.670 --> 00:52:36.090 Address is mapped to output scripts in all the software. 00:52:36.090 --> 00:52:37.590 And so when you say, OK, I'm sending 00:52:37.590 --> 00:52:40.380 into 1aeecc or whatever, it knows 00:52:40.380 --> 00:52:43.680 how to interpret that address, build the 20 byte pubkey hash 00:52:43.680 --> 00:52:45.613 script, and send to it. 00:52:45.613 --> 00:52:46.530 And vise versa, right? 00:52:46.530 --> 00:52:48.697 So from the address, you can get this output script, 00:52:48.697 --> 00:52:51.330 and from the output script you can get an address. 00:52:51.330 --> 00:52:53.322 So when an old software sees this, 00:52:53.322 --> 00:52:54.780 it's just like, there's no address. 00:52:54.780 --> 00:52:56.280 I don't even know what that is. 00:52:56.280 --> 00:52:58.470 I've never seen that. 00:52:58.470 --> 00:53:01.510 And so people worried that oh, it's going to be weird. 00:53:01.510 --> 00:53:03.960 People are going to have to upgrade to even send to people 00:53:03.960 --> 00:53:05.473 using segwit. 00:53:05.473 --> 00:53:07.890 So it's backwards compatible, but if you want to say, hey, 00:53:07.890 --> 00:53:11.888 send me some money at the segwit address and then they can't. 00:53:11.888 --> 00:53:12.930 And so you say, OK, fine. 00:53:12.930 --> 00:53:14.638 Send me the money with a regular address, 00:53:14.638 --> 00:53:17.037 and then we still have this malleability problem. 00:53:17.037 --> 00:53:18.870 And then I have a wallet that supports both, 00:53:18.870 --> 00:53:20.580 and I can move money to my own addresses, 00:53:20.580 --> 00:53:21.510 and it's kind of ugly. 00:53:21.510 --> 00:53:25.560 So they made this nested address thing, which I don't like, 00:53:25.560 --> 00:53:29.760 because then it actually has both. 00:53:29.760 --> 00:53:31.610 So you've got a signature and a witness. 00:53:34.340 --> 00:53:36.090 And the signature is not a real signature. 00:53:36.090 --> 00:53:37.507 It's just pointing to the witness. 00:53:37.507 --> 00:53:38.358 It's really ugly. 00:53:38.358 --> 00:53:40.400 There's a bunch of weird stuff in the segwit code 00:53:40.400 --> 00:53:41.748 that I'm not super into. 00:53:41.748 --> 00:53:43.290 I don't have to use it though, right? 00:53:43.290 --> 00:53:45.990 That's the beauty of these permission-less innovation 00:53:45.990 --> 00:53:46.660 kind of systems. 00:53:46.660 --> 00:53:48.210 Like ew, I don't like that code. 00:53:48.210 --> 00:53:49.402 OK, I'm not supporting it. 00:53:53.740 --> 00:54:01.365 OK, so here's one that's nested. 00:54:05.980 --> 00:54:12.280 So I was just randomly looking through a block. 00:54:12.280 --> 00:54:14.080 Here's one, and you can see it's like, OK. 00:54:14.080 --> 00:54:18.480 The outputs are probably also nested segwit, 00:54:18.480 --> 00:54:24.070 and the input has got both a script sig and a tx witness, 00:54:24.070 --> 00:54:24.615 right? 00:54:24.615 --> 00:54:26.760 A tx input witness. 00:54:26.760 --> 00:54:31.650 A pure one is this one f7. 00:54:37.110 --> 00:54:40.365 OK, so you can see-- 00:54:40.365 --> 00:54:42.840 oh wait, am I not running-- what version am I running? 00:54:42.840 --> 00:54:44.670 I think I'm running to 15-1 still. 00:54:44.670 --> 00:54:46.080 So I'm not seeing the address. 00:54:46.080 --> 00:54:51.550 There's a new address format called beck 32, bech 32, 00:54:51.550 --> 00:54:53.660 which will turn-- 00:54:53.660 --> 00:55:00.370 so it's zero and then a script hash. 00:55:00.370 --> 00:55:03.930 Zero and then a pubkey hash. 00:55:03.930 --> 00:55:06.010 It says, witness, version zero, key hash. 00:55:06.010 --> 00:55:08.220 There's also an address associated with these. 00:55:08.220 --> 00:55:12.850 I think this version of bitcoin CLI does not show it, 00:55:12.850 --> 00:55:14.330 but the new version does. 00:55:14.330 --> 00:55:18.170 So I think if you guys have version 0.16.0, it will show, 00:55:18.170 --> 00:55:20.980 here's the address. 00:55:20.980 --> 00:55:23.990 And then you can see in the single input 00:55:23.990 --> 00:55:27.430 for this transaction, there is a tx in witness. 00:55:27.430 --> 00:55:28.620 And there's no scripts. 00:55:28.620 --> 00:55:31.490 There's a script sig field, and it's just empty. 00:55:31.490 --> 00:55:34.460 There's no actual signature traditionally. 00:55:34.460 --> 00:55:36.260 There's instead this big thing. 00:55:36.260 --> 00:55:39.350 Here's the signature, and here's the pubkey being revealed. 00:55:39.350 --> 00:55:43.220 And then it also says, OK, here's the txid 00:55:43.220 --> 00:55:46.160 without the signature, and then here's the hash or witness 00:55:46.160 --> 00:55:47.053 transaction ID. 00:55:47.053 --> 00:55:49.220 The hash of the whole thing including the signature, 00:55:49.220 --> 00:55:51.110 and they're different, right? 00:55:51.110 --> 00:55:56.210 Also you've got size so this is actually 235 bytes, right? 00:55:56.210 --> 00:55:58.410 Because you're including the witnesses. 00:55:58.410 --> 00:56:03.080 And then, v size, which is virtual size. 00:56:03.080 --> 00:56:05.690 This is how big it looks to old software that 00:56:05.690 --> 00:56:08.450 doesn't know about segwit. 00:56:08.450 --> 00:56:10.670 So the new software, this knows about both. 00:56:10.670 --> 00:56:15.740 The actual size or witness size is 235, v size is 153. 00:56:15.740 --> 00:56:19.465 So yeah, it's not quite 50%, because this one has 00:56:19.465 --> 00:56:21.590 two outputs, and the outputs don't get any smaller, 00:56:21.590 --> 00:56:23.990 and the input just gets smaller. 00:56:23.990 --> 00:56:26.860 And then, size, v size, and then you 00:56:26.860 --> 00:56:28.360 can see what block it's in when we 00:56:28.360 --> 00:56:30.144 get the coinbase transaction. 00:56:43.300 --> 00:56:46.230 OK, so the first transaction in the list 00:56:46.230 --> 00:56:48.630 is going to be the coinbase transaction. 00:56:48.630 --> 00:56:51.390 And I can get that one. 00:56:51.390 --> 00:56:55.980 And yeah, the coinbase transaction 00:56:55.980 --> 00:56:57.880 has a different txid and hash. 00:56:57.880 --> 00:57:01.020 Its size is 259, its v size 232. 00:57:01.020 --> 00:57:03.840 Coinbase has whatever random data they want, 00:57:03.840 --> 00:57:08.110 and there's the actual output, which 00:57:08.110 --> 00:57:12.280 is sending to this address, and it's sending 12.79 coins. 00:57:12.280 --> 00:57:14.080 And then, there's this zero value output. 00:57:14.080 --> 00:57:15.580 So you can have an output that's got 00:57:15.580 --> 00:57:17.760 an amount of coins set to zero. 00:57:17.760 --> 00:57:19.720 It's still OK, and it's got this op return. 00:57:19.720 --> 00:57:22.840 And the op return starts with aa21a9ed, 00:57:22.840 --> 00:57:27.910 and those four bytes mean here's the segwit commitment. 00:57:27.910 --> 00:57:31.420 Here's the witness commitment to the segwit transaction 00:57:31.420 --> 00:57:35.490 hashes, the root of all those. 00:57:35.490 --> 00:57:38.160 And you have to have that in order 00:57:38.160 --> 00:57:40.380 to have a valid segwit block. 00:57:40.380 --> 00:57:42.120 And so then we can-- 00:57:42.120 --> 00:57:43.710 this is segwit in action. 00:57:43.710 --> 00:57:45.525 I think most blocks now will have that. 00:57:48.050 --> 00:57:49.770 So there is size and v size, right? 00:57:49.770 --> 00:57:51.270 And that makes sense. 00:57:51.270 --> 00:57:54.270 But then you have strip-- 00:57:54.270 --> 00:57:56.250 no, v size is not size. 00:57:56.250 --> 00:57:57.390 It's really confusing. 00:57:57.390 --> 00:58:02.600 And size, weight, height, like what? 00:58:02.600 --> 00:58:05.850 So size is-- 00:58:05.850 --> 00:58:07.300 I don't actually know. 00:58:07.300 --> 00:58:09.210 I think size is interpreted the same. 00:58:09.210 --> 00:58:12.270 This is the actual number of bytes for this block. 00:58:12.270 --> 00:58:18.150 Weight is you multiply all non witness bytes by four, 00:58:18.150 --> 00:58:20.550 and you leave all witness bytes as weight one, 00:58:20.550 --> 00:58:22.300 and that has to be less than four million. 00:58:22.300 --> 00:58:25.110 And you can see here, it's just under four million. 00:58:25.110 --> 00:58:30.830 And then stripped size is the size that old nodes see. 00:58:30.830 --> 00:58:31.330 Yeah. 00:58:31.330 --> 00:58:31.880 Pretty sure. 00:58:31.880 --> 00:58:35.217 Anyway, so it's kind of confusing. 00:58:35.217 --> 00:58:36.800 One of the biggest problems in bitcoin 00:58:36.800 --> 00:58:38.590 is names, where it's like, wait. 00:58:38.590 --> 00:58:41.520 Script pubkey, and script sig script? 00:58:41.520 --> 00:58:42.020 Like, what? 00:58:42.020 --> 00:58:44.150 All these terms and names are really confusing, 00:58:44.150 --> 00:58:46.740 and it's sort of getting worse. 00:58:46.740 --> 00:58:48.190 So yeah. 00:58:48.190 --> 00:58:52.547 Also, there's no v size here. 00:58:52.547 --> 00:58:53.880 I think this is actually v size. 00:58:53.880 --> 00:58:59.010 Anyway, so that's how segwit works in the actual thing. 00:58:59.010 --> 00:59:01.890 But it's nice, because now you can reliably spend from things 00:59:01.890 --> 00:59:04.950 before they're confirmed. 00:59:04.950 --> 00:59:07.260 So segwit is cool. 00:59:07.260 --> 00:59:08.580 Fixes malleability. 00:59:08.580 --> 00:59:10.600 Increases the block size. 00:59:10.600 --> 00:59:12.780 Oh, it does a whole bunch of other stuff, too. 00:59:15.790 --> 00:59:18.990 OK, so one of the aspects that it fixes. 00:59:18.990 --> 00:59:22.220 When you're signing a transaction, 00:59:22.220 --> 00:59:24.570 let's say you have five inputs. 00:59:27.360 --> 00:59:29.835 Each time you sign, you need to hash the whole transaction, 00:59:29.835 --> 00:59:31.460 because it's slightly different, right? 00:59:31.460 --> 00:59:33.297 You zero out all the signature fields, 00:59:33.297 --> 00:59:34.880 but in the signature field for the one 00:59:34.880 --> 00:59:36.838 you're actually signing, you don't zero it out. 00:59:36.838 --> 00:59:40.480 You put the previous script there. 00:59:40.480 --> 00:59:41.960 So it's slightly different. 00:59:41.960 --> 00:59:43.645 It's totally redundant. 00:59:43.645 --> 00:59:45.020 There's no reason to put it there 00:59:45.020 --> 00:59:46.395 because it's already in the txid, 00:59:46.395 --> 00:59:49.160 but you change things around a little bit. 00:59:49.160 --> 00:59:52.393 So the idea is, I'm going to put a signature here, 00:59:52.393 --> 00:59:53.810 I'm going to put a signature here, 00:59:53.810 --> 00:59:55.640 put a signature-- all five of them. 00:59:55.640 --> 00:59:57.440 Each time I put a signature here, 00:59:57.440 --> 01:00:00.920 I hash the transaction to get a slightly different thing 01:00:00.920 --> 01:00:03.530 to sign for each one. 01:00:03.530 --> 01:00:06.800 It might not jump out at you, but this is actually 01:00:06.800 --> 01:00:11.690 o and squared, which is bad. 01:00:11.690 --> 01:00:15.080 Because the idea is, as I extend the number of signatures 01:00:15.080 --> 01:00:17.060 required in a transaction, the number of inputs 01:00:17.060 --> 01:00:21.350 in a transaction, the amount of data that needs to be processed 01:00:21.350 --> 01:00:24.580 goes up with the square of the number of inputs. 01:00:24.580 --> 01:00:26.420 Because I had an input. 01:00:26.420 --> 01:00:29.470 Now, the total size of the transaction gets bigger, 01:00:29.470 --> 01:00:32.980 so each time I sign, I need to take a bigger amount of data 01:00:32.980 --> 01:00:34.180 through my hash function. 01:00:34.180 --> 01:00:36.000 Also, the number of signatures gets bigger. 01:00:36.000 --> 01:00:37.000 Or the number of inputs. 01:00:37.000 --> 01:00:38.770 So this is in squared. 01:00:38.770 --> 01:00:39.730 It seems fine, right? 01:00:39.730 --> 01:00:42.710 You never notice, except when you do. 01:00:42.710 --> 01:00:44.830 So there's pathological block. 01:00:44.830 --> 01:00:47.862 There was one like 2015 early in the year where some miner was 01:00:47.862 --> 01:00:49.570 like, I'm going to make this block that's 01:00:49.570 --> 01:00:52.150 one giant transaction with thousands 01:00:52.150 --> 01:00:53.950 and thousands of inputs. 01:00:53.950 --> 01:00:57.340 And a lot of software choked on it, and it took gigs of RAM 01:00:57.340 --> 01:01:00.350 to process the transaction, and things like that. 01:01:00.350 --> 01:01:01.930 So that was bad. 01:01:01.930 --> 01:01:04.720 Just in general, if you have a lot of little dust outputs, 01:01:04.720 --> 01:01:07.210 if you're trying to aggregate them into one big-- 01:01:07.210 --> 01:01:09.850 I'm going to have 100 inputs and one output, 01:01:09.850 --> 01:01:12.130 it takes forever to sign. 01:01:12.130 --> 01:01:13.630 And it also takes forever to verify. 01:01:13.630 --> 01:01:15.220 So it's pretty bad. 01:01:15.220 --> 01:01:20.020 I remember sort of a silly story. 01:01:20.020 --> 01:01:21.220 Tim Draper's coins. 01:01:21.220 --> 01:01:22.390 He had all this dust. 01:01:22.390 --> 01:01:24.820 And it was nerve wracking, because it was way more money 01:01:24.820 --> 01:01:26.237 than I'm going to make in my life. 01:01:26.237 --> 01:01:28.810 And moving Tim Draper's coins to somewhere else. 01:01:28.810 --> 01:01:32.730 And the software by default just swept all the inputs 01:01:32.730 --> 01:01:34.670 with that wallet controlled. 01:01:34.670 --> 01:01:37.210 And they were looking at me like, why doesn't this work? 01:01:37.210 --> 01:01:37.810 Is it frozen? 01:01:37.810 --> 01:01:40.810 I'm like, no, I'm not trying to steal the money, guys. 01:01:40.810 --> 01:01:44.050 Because everyone was sending all these little outputs to Tim 01:01:44.050 --> 01:01:47.062 Draper's 30,000 coins or whatever, because he's-- 01:01:47.062 --> 01:01:48.520 and then when he tried to spend it, 01:01:48.520 --> 01:01:50.213 it took five minutes to sign. 01:01:50.213 --> 01:01:52.180 AUDIENCE: When people use P2 pool, 01:01:52.180 --> 01:01:53.847 the software really struggles with this. 01:01:53.847 --> 01:01:56.520 PROFESSOR: Yeah, so it's bad. 01:01:56.520 --> 01:01:59.370 Any o event squared, this is sort of a bug. 01:01:59.370 --> 01:02:00.750 Segwit actually fixed this. 01:02:00.750 --> 01:02:04.560 The way they do it is they say, OK, 01:02:04.560 --> 01:02:10.830 we sort of pre compute these three intermediate hashes. 01:02:10.830 --> 01:02:14.240 Take the whole transaction. 01:02:14.240 --> 01:02:16.350 This is sort of the global transaction data, 01:02:16.350 --> 01:02:18.300 and pre compute these three things. 01:02:18.300 --> 01:02:21.860 And then for each of the inputs, add another thing. 01:02:21.860 --> 01:02:23.010 Here's this input specific. 01:02:23.010 --> 01:02:25.340 So this is global. 01:02:25.340 --> 01:02:28.170 It's the hash of all the tx ends, the hash of all 01:02:28.170 --> 01:02:30.450 the outputs, the hash of this. 01:02:30.450 --> 01:02:32.690 And then here is that the input specific. 01:02:37.190 --> 01:02:38.270 Input specific. 01:02:38.270 --> 01:02:41.300 And then hash all these things into one thing 01:02:41.300 --> 01:02:42.530 and then sign that. 01:02:42.530 --> 01:02:45.278 So the idea is it's o of n in that you compute these three 01:02:45.278 --> 01:02:46.820 and then you sort of go down and keep 01:02:46.820 --> 01:02:48.530 changing this for each one. 01:02:48.530 --> 01:02:50.630 So that saves a lot of time. 01:02:50.630 --> 01:02:51.470 It's a much nicer-- 01:02:51.470 --> 01:02:57.490 oh, you also put in the amount being spent in your signature 01:02:57.490 --> 01:02:59.870 hash, which is also redundant, because that's 01:02:59.870 --> 01:03:02.120 committed to in the txid that you're sending. 01:03:02.120 --> 01:03:04.208 But it's really nice for hardware wallets, 01:03:04.208 --> 01:03:06.500 because a lot of times hardware wallets are essentially 01:03:06.500 --> 01:03:09.050 presented with here's a hash. 01:03:09.050 --> 01:03:10.160 Sign it. 01:03:10.160 --> 01:03:12.475 And it's a very small system. 01:03:12.475 --> 01:03:14.600 It's a little chip somewhere, and it doesn't really 01:03:14.600 --> 01:03:15.870 know too much about bitcoin. 01:03:15.870 --> 01:03:16.912 It's just, here's a hash. 01:03:16.912 --> 01:03:17.540 Sign it. 01:03:17.540 --> 01:03:20.393 OK, and they don't know how much they're spending, 01:03:20.393 --> 01:03:22.310 so there could be attacks on hardware wallets, 01:03:22.310 --> 01:03:24.710 where they get a hardware wallet to sign something where it's 01:03:24.710 --> 01:03:26.120 actually moving too much money. 01:03:26.120 --> 01:03:29.100 So it's nice to be able to have the actual amount. 01:03:29.100 --> 01:03:30.830 So there's a bunch of stuff like that. 01:03:30.830 --> 01:03:33.860 It was a giant grab bag of all these different little fixes, 01:03:33.860 --> 01:03:35.420 things like that. 01:03:35.420 --> 01:03:36.920 Fixes malleability. 01:03:36.920 --> 01:03:38.520 It increases the block size. 01:03:38.520 --> 01:03:40.430 Does all these other cool things. 01:03:40.430 --> 01:03:42.900 People didn't like it. 01:03:42.900 --> 01:03:46.908 I never really understood why. 01:03:46.908 --> 01:03:49.450 AUDIENCE: For the reasons you've been telling everyone about? 01:03:49.450 --> 01:03:50.050 PROFESSOR: All these reasons? 01:03:50.050 --> 01:03:51.830 Wait, these seem like good things, right? 01:03:52.330 --> 01:03:55.777 AUDIENCE: Well, yeah, but [INAUDIBLE] 01:03:55.777 --> 01:03:56.360 PROFESSOR: Oh. 01:03:56.360 --> 01:03:57.860 No, that wasn't what-- 01:03:57.860 --> 01:03:59.640 it wasn't like people were like, oh, 01:03:59.640 --> 01:04:01.640 here's some little things I don't like about it. 01:04:01.640 --> 01:04:02.897 Because that was what I said. 01:04:02.897 --> 01:04:05.230 That was like what everyone working on Bitcoin was like. 01:04:05.230 --> 01:04:06.972 No one thinks it's perfect. 01:04:06.972 --> 01:04:08.930 Everyone was like, oh, but this thing is weird. 01:04:08.930 --> 01:04:09.763 Why did you do that? 01:04:09.763 --> 01:04:12.560 Or why didn't you put this in kind of things. 01:04:12.560 --> 01:04:16.210 But no, the people who didn't like it really didn't like it. 01:04:16.210 --> 01:04:20.310 There's still a bounty on [INAUDIBLE] head, right? 01:04:20.310 --> 01:04:21.400 There's death threats. 01:04:21.400 --> 01:04:23.483 Someone's like, I'll pay someone to kill this guy. 01:04:26.780 --> 01:04:28.730 It's all, this is going to destroy Bitcoin, 01:04:28.730 --> 01:04:31.760 that segwit isn't bitcoin anymore, 01:04:31.760 --> 01:04:33.362 because there aren't any signatures. 01:04:33.362 --> 01:04:35.570 It's like no, signatures are still committed to, just 01:04:35.570 --> 01:04:36.440 in a different way. 01:04:36.440 --> 01:04:37.857 You have to build this other tree. 01:04:39.350 --> 01:04:40.818 So lots of weird conspiracies. 01:04:40.818 --> 01:04:41.360 I don't know. 01:04:41.360 --> 01:04:44.900 It became this really sticking point, 01:04:44.900 --> 01:04:48.970 and so that sort of led to Bitcoin Cash. 01:04:48.970 --> 01:04:51.110 The whole idea is segwit is bad. 01:04:51.110 --> 01:04:52.590 We're making Bitcoin Cash. 01:04:52.590 --> 01:04:54.680 And Bitcoin Cash forked off before segwit 01:04:54.680 --> 01:04:57.680 activated in the main network. 01:04:57.680 --> 01:05:00.685 Interestingly, Bitcoin Cash uses this. 01:05:00.685 --> 01:05:02.560 So they took a bunch of the code from segwit, 01:05:02.560 --> 01:05:05.010 because this is a really good improvement 01:05:05.010 --> 01:05:06.950 to signing that Bitcoin Cash used, 01:05:06.950 --> 01:05:09.680 but they didn't like segwit. 01:05:09.680 --> 01:05:12.218 Yeah, I'm still not like-- 01:05:12.218 --> 01:05:12.760 I don't know. 01:05:12.760 --> 01:05:15.340 There's problems I have with it, too, but it's an upgrade, 01:05:15.340 --> 01:05:16.890 and it's cool. 01:05:16.890 --> 01:05:19.526 I think a lot of it was people wanted a hard fork, 01:05:19.526 --> 01:05:20.865 and this was a softfork. 01:05:20.865 --> 01:05:22.490 And so there's backwards compatibility, 01:05:22.490 --> 01:05:25.480 and they wanted to show that people 01:05:25.480 --> 01:05:28.600 have more control over bitcoin than they maybe do. 01:05:28.600 --> 01:05:31.180 It might never be possible to have a hard fork 01:05:31.180 --> 01:05:33.190 to get everyone on board to really switch. 01:05:33.190 --> 01:05:34.540 So who knows. 01:05:34.540 --> 01:05:36.430 So yeah, it was interesting. 01:05:36.430 --> 01:05:40.420 It took forever, and that was the last change 01:05:40.420 --> 01:05:44.170 to the bitcoin code in terms of consensus code. 01:05:44.170 --> 01:05:49.240 And it was initially announced late 2015 01:05:49.240 --> 01:05:53.120 in Hong Kong, and then all of 2016 01:05:53.120 --> 01:05:56.050 it never-- so it activated in August of last year. 01:05:56.050 --> 01:05:57.068 And now you can use it. 01:05:57.068 --> 01:05:59.110 AUDIENCE: People had big interest in stopping it, 01:05:59.110 --> 01:06:00.000 though. 01:06:00.000 --> 01:06:02.950 At one point they were spending hundreds of thousands 01:06:02.950 --> 01:06:05.740 of dollars a day to stop it from activating. 01:06:05.740 --> 01:06:08.797 PROFESSOR: Yeah, so on your vert coin, you're like, 01:06:08.797 --> 01:06:11.380 I'll just take the segwit code and activate it, and like cool. 01:06:11.380 --> 01:06:13.570 And then people tried to stop it and spend a lot of money 01:06:13.570 --> 01:06:14.070 to stop it. 01:06:17.050 --> 01:06:19.420 OK, I want to say unclear why, because I don't know. 01:06:19.420 --> 01:06:20.600 It's sort of weird. 01:06:20.600 --> 01:06:21.970 There's a whole lot of opinions. 01:06:21.970 --> 01:06:28.590 One theory is that this breaks some mining 01:06:28.590 --> 01:06:31.560 chips optimizations. 01:06:31.560 --> 01:06:33.810 One of the optimizations-- 01:06:33.810 --> 01:06:35.960 it doesn't work with a tree of height two. 01:06:35.960 --> 01:06:40.710 But if you have a really tall tree, you can swap txids, 01:06:40.710 --> 01:06:43.380 or you can swap intermediate nodes of the tree 01:06:43.380 --> 01:06:46.140 and you'll get a different merkle route. 01:06:46.140 --> 01:06:48.720 So you can see-- 01:06:48.720 --> 01:06:51.270 so it doesn't work here, because this has to stay in place. 01:06:51.270 --> 01:06:55.440 But in many cases, the order of the transactions is arbitrary. 01:06:55.440 --> 01:06:57.450 So I could flip these two. 01:06:57.450 --> 01:07:00.240 It's still valid. 01:07:00.240 --> 01:07:02.430 So what I might do is say, OK. 01:07:02.430 --> 01:07:05.130 I have this merkle route I'm mining, 01:07:05.130 --> 01:07:08.700 and then I want to flip these two, calculate 01:07:08.700 --> 01:07:10.290 a different merkle route, and mine. 01:07:10.290 --> 01:07:13.110 And there were some chips that maybe did this and had 01:07:13.110 --> 01:07:14.610 these kinds of optimizations. 01:07:14.610 --> 01:07:17.130 There was also a patent on it and all this weird stuff 01:07:17.130 --> 01:07:19.510 going on. 01:07:19.510 --> 01:07:22.080 It doesn't break, but it essentially 01:07:22.080 --> 01:07:23.940 loses the optimization if you have this. 01:07:23.940 --> 01:07:27.780 Because you're saying, OK, I'm going to have this big tree. 01:07:27.780 --> 01:07:30.570 I'm going to swap something near the top, 01:07:30.570 --> 01:07:32.610 and it only has to recompute two hashes 01:07:32.610 --> 01:07:34.770 to get a new merkle route. 01:07:34.770 --> 01:07:40.260 However, if I now have this mirror image witness merkle 01:07:40.260 --> 01:07:43.770 tree underneath, if I say, OK, I'm going to swap this, 01:07:43.770 --> 01:07:45.090 I'm also swapping all these. 01:07:45.090 --> 01:07:49.050 And I have to recompute this. 01:07:49.050 --> 01:07:51.780 Maybe I can swap some of it, but I have to recompute what this. 01:07:51.780 --> 01:07:53.590 This is going to change just as well. 01:07:53.590 --> 01:07:54.660 And then I have to put that in here, 01:07:54.660 --> 01:07:56.090 and this is going to be at the bottom. 01:07:56.090 --> 01:07:58.215 And then, I'm going to have to recompute everything 01:07:58.215 --> 01:07:59.830 all the way up to the merkle route. 01:07:59.830 --> 01:08:04.140 So this was called AsicBoost, and then there was a post-- 01:08:04.140 --> 01:08:07.125 Greg Maxwell posted this sort of like, 01:08:07.125 --> 01:08:12.390 you guys, like accusatory mail on the mailing list last spring 01:08:12.390 --> 01:08:13.590 saying, look. 01:08:13.590 --> 01:08:17.490 We were trying to figure out a way to break AsicBoost, 01:08:17.490 --> 01:08:20.790 because we think miners have this patented algorithm that 01:08:20.790 --> 01:08:23.819 optimizes and it gives a 20%, 30% speed up. 01:08:23.819 --> 01:08:26.340 And we're worried that the patents will make one miner, 01:08:26.340 --> 01:08:28.930 have a monopoly, and everyone else won't be competitive. 01:08:28.930 --> 01:08:30.347 So we're trying to think, is there 01:08:30.347 --> 01:08:33.140 a way we make software to prevent this 01:08:33.140 --> 01:08:35.149 from this optimization? 01:08:35.149 --> 01:08:37.220 And then once they tried to look at it, 01:08:37.220 --> 01:08:38.300 they were like, oh, wait. 01:08:38.300 --> 01:08:39.640 Segwit does that. 01:08:39.640 --> 01:08:43.310 We want to make it costly to swap things in the tree, 01:08:43.310 --> 01:08:44.450 and segwit does that. 01:08:44.450 --> 01:08:46.220 Oh, so basically, we're good. 01:08:46.220 --> 01:08:47.630 And then he was like, oh, wait. 01:08:47.630 --> 01:08:50.210 Maybe that's why all these people hate segwit. 01:08:50.210 --> 01:08:54.439 Maybe this is these miners who have billions of dollars 01:08:54.439 --> 01:08:57.170 worth of equipment with these optimizations in it, 01:08:57.170 --> 01:09:01.609 which would be rendered unusable by this new software change, 01:09:01.609 --> 01:09:04.580 maybe they're trying to prevent it from activating. 01:09:04.580 --> 01:09:07.010 It's a theory, and the mining companies said, 01:09:07.010 --> 01:09:09.319 oh, no that's a bunch of nonsense. 01:09:09.319 --> 01:09:11.575 Although, the way they said it was sort of suspicious. 01:09:11.575 --> 01:09:13.700 They were like, yeah, we put circuitry in our chips 01:09:13.700 --> 01:09:15.500 to do this, but we never used it. 01:09:15.500 --> 01:09:17.210 That's strange. 01:09:17.210 --> 01:09:19.520 So who knows. 01:09:19.520 --> 01:09:21.560 But that's one theory. 01:09:21.560 --> 01:09:23.910 I'm not sure how much I believe that's the real reason, 01:09:23.910 --> 01:09:24.410 but yeah. 01:09:24.410 --> 01:09:26.577 AUDIENCE: but if they want to calculate Merkle roots 01:09:26.577 --> 01:09:28.240 in bitcoin, don't just-- 01:09:28.240 --> 01:09:31.939 order all of the transaction fees by transaction ID? 01:09:31.939 --> 01:09:35.359 PROFESSOR: You can't, because the order matters. 01:09:35.359 --> 01:09:38.779 Because when you validate, this transaction 01:09:38.779 --> 01:09:41.484 might create an output that this transaction spends. 01:09:41.484 --> 01:09:46.910 And so if you swap them, so if you didn't have intra block 01:09:46.910 --> 01:09:49.069 dependencies, then it would all be arbitrary 01:09:49.069 --> 01:09:50.450 and you could put in ordering. 01:09:50.450 --> 01:09:52.729 But there are intra block dependencies, 01:09:52.729 --> 01:09:54.530 and so the order does matter. 01:09:54.530 --> 01:09:55.705 In many cases, it doesn't. 01:09:55.705 --> 01:09:57.830 In many cases, these are two separate transactions. 01:09:57.830 --> 01:09:59.060 You can swap them. 01:09:59.060 --> 01:10:02.350 But the software does use the ordering. 01:10:02.350 --> 01:10:05.100 And there's all sorts of other things that would be better. 01:10:05.100 --> 01:10:11.150 What I would want is prepend or append the height 01:10:11.150 --> 01:10:13.430 at each stage of the merkle tree. 01:10:13.430 --> 01:10:16.345 That would have helped me out for some things. 01:10:16.345 --> 01:10:17.720 Because then, it's like you know, 01:10:17.720 --> 01:10:19.178 since you're at the bottom just put 01:10:19.178 --> 01:10:20.913 a zero at the end of each hash. 01:10:20.913 --> 01:10:22.580 And then when you get up here, put a one 01:10:22.580 --> 01:10:24.830 at the end of each hash. 01:10:24.830 --> 01:10:26.750 Doesn't really change anything. 01:10:26.750 --> 01:10:31.790 But one problem is what if I request-- 01:10:31.790 --> 01:10:33.330 so what I want to do in my software. 01:10:33.330 --> 01:10:35.910 I want to request all the transaction IDs in a block. 01:10:35.910 --> 01:10:37.320 I don't actually care about the transactions. 01:10:37.320 --> 01:10:38.695 I just want to see all the txids. 01:10:41.360 --> 01:10:42.230 Like this. 01:10:42.230 --> 01:10:46.830 If I get rid of the head 20, I get a giant list of txids. 01:10:46.830 --> 01:10:50.422 The thing is, what this let me do is to look for transactions. 01:10:50.422 --> 01:10:52.380 If I have a txid I know I'm looking, I can say, 01:10:52.380 --> 01:10:54.600 oh, I can look for it in here. 01:10:54.600 --> 01:10:57.120 The problem is, what if the person I'm asking 01:10:57.120 --> 01:11:01.080 is giving me this instead of this? 01:11:01.080 --> 01:11:02.680 I won't know. 01:11:02.680 --> 01:11:05.470 They all look like random numbers. 01:11:05.470 --> 01:11:09.890 If I do the merkle tree algo, I'll get to the merkle route. 01:11:09.890 --> 01:11:10.540 That's good. 01:11:10.540 --> 01:11:13.960 But I don't really know that I'm at the bottom. 01:11:13.960 --> 01:11:15.430 It's OK if I'm running a full node 01:11:15.430 --> 01:11:17.870 and I actually download all the transactions and look, 01:11:17.870 --> 01:11:19.210 and OK, it works. 01:11:19.210 --> 01:11:23.032 But to have a way to say, hey, give me a list of all the txids 01:11:23.032 --> 01:11:24.490 and I can verify that it's correct, 01:11:24.490 --> 01:11:25.962 I can't do that right now. 01:11:25.962 --> 01:11:26.920 There's ways around it. 01:11:26.920 --> 01:11:28.587 But it would have been nice if then they 01:11:28.587 --> 01:11:30.172 appended a zero or something. 01:11:30.172 --> 01:11:31.630 Or even, all you have to do is just 01:11:31.630 --> 01:11:33.970 append something at the bottom row 01:11:33.970 --> 01:11:35.980 or just append higher or something. 01:11:35.980 --> 01:11:36.850 Then, it would've been kind of cool. 01:11:36.850 --> 01:11:38.142 It would've been easier for me. 01:11:38.142 --> 01:11:39.305 But oh well. 01:11:39.305 --> 01:11:41.180 And there's people who've written about this. 01:11:41.180 --> 01:11:41.820 Yeah. 01:11:41.820 --> 01:11:44.650 AUDIENCE: Did James say that's pool operators are leaving off 01:11:44.650 --> 01:11:47.140 the [? whipper? ?] And if so, does it 01:11:47.140 --> 01:11:48.172 weaken the whole system? 01:11:48.172 --> 01:11:49.630 PROFESSOR: I think what they really 01:11:49.630 --> 01:11:51.400 do is they just don't support segwit. 01:11:51.400 --> 01:11:52.600 So I've seen, especially-- 01:11:52.600 --> 01:11:55.130 AUDIENCE: [INAUDIBLE] it's expensive but then they-- 01:11:55.130 --> 01:11:57.380 PROFESSOR: Yeah, they say they're going to support it, 01:11:57.380 --> 01:11:58.990 and then they don't. 01:11:58.990 --> 01:12:01.570 So they sort of flag their transactions, yeah, segwit, 01:12:01.570 --> 01:12:03.410 and then they haven't actually upgraded their software, 01:12:03.410 --> 01:12:04.330 so they can't use it. 01:12:04.330 --> 01:12:05.250 They can't mine it. 01:12:05.250 --> 01:12:07.210 So you see this a lot on TestNet as well. 01:12:07.210 --> 01:12:09.635 If you're making TestNet segwit transactions, 01:12:09.635 --> 01:12:11.260 sometimes they just don't get confirmed 01:12:11.260 --> 01:12:14.538 for a few hours, because all the blocks that come out 01:12:14.538 --> 01:12:16.330 don't support it, and so they won't use it. 01:12:16.330 --> 01:12:18.080 AUDIENCE: The badly written pool software, 01:12:18.080 --> 01:12:21.012 if they use segwit supporting full load with it, 01:12:21.012 --> 01:12:24.640 it will give them segwit transactions, 01:12:24.640 --> 01:12:27.185 and they'll try to include it but it won't do this, so-- 01:12:27.185 --> 01:12:28.310 PROFESSOR: So it's invalid. 01:12:28.310 --> 01:12:29.660 Yes, so it's invalid. 01:12:29.660 --> 01:12:31.327 AUDIENCE: I guess my question is does it 01:12:31.327 --> 01:12:35.300 weaken the security in the system if for six months 01:12:35.300 --> 01:12:36.940 they're not supporting this? 01:12:36.940 --> 01:12:37.870 PROFESSOR: No, no. 01:12:37.870 --> 01:12:39.820 It hurts the usability. 01:12:39.820 --> 01:12:41.350 If I want to use a segwit transact-- 01:12:41.350 --> 01:12:44.710 but as me running a segwit compatible node, 01:12:44.710 --> 01:12:46.810 I require signatures. 01:12:46.810 --> 01:12:49.060 I require all this whole construction. 01:12:49.060 --> 01:12:51.280 If you make something that looks like it 01:12:51.280 --> 01:12:54.820 spends the segwit transaction without this, I just reject it. 01:12:54.820 --> 01:12:56.290 So security wise, it's fine. 01:12:56.290 --> 01:12:56.790 Yes. 01:12:56.790 --> 01:12:58.030 AUDIENCE: I think it might be important to note 01:12:58.030 --> 01:13:00.790 that the way that these things are designed, and in particular 01:13:00.790 --> 01:13:04.810 that softforks are designed, is that anyone who doesn't update 01:13:04.810 --> 01:13:08.740 the new functionality can't hurt the security 01:13:08.740 --> 01:13:09.970 of the new functionality. 01:13:09.970 --> 01:13:13.510 That's sort of part of the design process. 01:13:13.510 --> 01:13:16.315 PROFESSOR: Although, their security might get hurt. 01:13:16.315 --> 01:13:18.320 Not a ton, but yeah. 01:13:18.320 --> 01:13:20.500 If you haven't upgraded, you might 01:13:20.500 --> 01:13:22.415 see these segwit transactions, and-- 01:13:22.415 --> 01:13:23.290 AUDIENCE: [INAUDIBLE] 01:13:23.290 --> 01:13:24.987 PROFESSOR: Yeah, they look weird, 01:13:24.987 --> 01:13:26.070 but you're like, OK, fine. 01:13:26.070 --> 01:13:28.810 But you can't actually verify the whole thing. 01:13:28.810 --> 01:13:32.293 Given an invalid and a valid segwit transaction, 01:13:32.293 --> 01:13:33.710 the old software can't distinguish 01:13:33.710 --> 01:13:35.503 but the new software can. 01:13:35.503 --> 01:13:38.170 AUDIENCE: That's even though the pool operators, whether there's 01:13:38.170 --> 01:13:40.600 six or eight key pool operators, might not 01:13:40.600 --> 01:13:42.330 be supporting the witrootsub 01:13:42.330 --> 01:13:44.243 PROFESSOR: If they don't support it, 01:13:44.243 --> 01:13:45.910 you have to wait until someone that does 01:13:45.910 --> 01:13:48.790 support it mines the block. 01:13:48.790 --> 01:13:52.630 So if they try to support it and support it wrong, 01:13:52.630 --> 01:13:54.360 you ignore them. 01:13:54.360 --> 01:13:55.840 You don't use their data. 01:13:55.840 --> 01:13:57.030 You don't use their block. 01:13:57.030 --> 01:13:58.278 AUDIENCE: you just want segwit transactions stay 01:13:58.278 --> 01:13:59.390 in the node pool a bit longer. 01:13:59.390 --> 01:14:00.057 PROFESSOR: Yeah. 01:14:00.057 --> 01:14:03.010 So I think in bitcoin now, it's OK. 01:14:03.010 --> 01:14:06.980 TestNet is kind of weird, but there's segwit.party, 01:14:06.980 --> 01:14:10.100 and you can see what people are doing with segwit. 01:14:12.710 --> 01:14:14.180 So yeah, it's about 30. 01:14:14.180 --> 01:14:17.240 This is by transaction, it's somewhere around 30 something 01:14:17.240 --> 01:14:19.910 percent of the transactions are using segwit, 01:14:19.910 --> 01:14:23.410 and then you can see witness size percentage, block size. 01:14:23.410 --> 01:14:24.800 OK, so sometimes you got-- 01:14:24.800 --> 01:14:26.720 oh wow, I had no idea. 01:14:26.720 --> 01:14:29.260 Blocks are way under a megabyte now. 01:14:29.260 --> 01:14:32.060 Oh, OK, well free transactions for everyone. 01:14:32.060 --> 01:14:34.040 If you want to use bitcoin, now's the time. 01:14:34.040 --> 01:14:36.530 You don't have to pay anything. 01:14:36.530 --> 01:14:39.950 That looks very different a month ago where 01:14:39.950 --> 01:14:41.780 you had a solid red line. 01:14:41.780 --> 01:14:43.220 You had to sort of-- 01:14:43.220 --> 01:14:45.710 nothing went below a million, and then you 01:14:45.710 --> 01:14:47.840 had a little bit of segwit stuff going on here. 01:14:47.840 --> 01:14:50.680 But now you've got most things are below a million. 01:14:50.680 --> 01:14:52.020 So interesting. 01:14:52.020 --> 01:14:52.730 OK, so yeah. 01:14:52.730 --> 01:14:56.240 So that's the basic idea of segwit. 01:14:56.240 --> 01:14:58.790 And if people have any questions, 01:14:58.790 --> 01:15:01.310 stick around and ask. 01:15:01.310 --> 01:15:03.770 There's office hours tomorrow at 4:00 to 6:00 over there. 01:15:03.770 --> 01:15:05.450 Look at the homework, and next time 01:15:05.450 --> 01:15:07.320 I'll talk about lightning network payment-- 01:15:07.320 --> 01:15:08.990 I'll try to get into payment channels 01:15:08.990 --> 01:15:12.760 and see how far we get into lightning network stuff.