1 00:00:00,718 --> 00:00:03,260 ANNOUNCER: The following content is provided under a Creative 2 00:00:03,260 --> 00:00:04,650 Commons license. 3 00:00:04,650 --> 00:00:06,860 Your support will help MIT OpenCourseWare 4 00:00:06,860 --> 00:00:10,950 continue to offer high-quality educational resources for free. 5 00:00:10,950 --> 00:00:13,490 To make a donation, or to view additional materials 6 00:00:13,490 --> 00:00:16,010 from hundreds of MIT courses, visit 7 00:00:16,010 --> 00:00:18,830 MITOpenCourseWare at ocw.mit.edu. 8 00:00:22,420 --> 00:00:24,550 TADGE DRYJA: So today I'm going to talk about 9 00:00:24,550 --> 00:00:28,300 MAST, taproot, and graftroot. 10 00:00:28,300 --> 00:00:31,390 And these are pretty cool new ideas in Bitcoin. 11 00:00:31,390 --> 00:00:34,600 They're not really production ready. 12 00:00:34,600 --> 00:00:38,800 They're still sort of ideas, but it's 13 00:00:38,800 --> 00:00:42,490 kind of neat to look at the future directions of how 14 00:00:42,490 --> 00:00:45,970 people are thinking about improving these protocols. 15 00:00:45,970 --> 00:00:49,110 So we're going to talk about new types of scripts-- 16 00:00:49,110 --> 00:00:51,730 MAST, taproot, and graftroot-- 17 00:00:51,730 --> 00:00:53,500 and all those sort of interactions 18 00:00:53,500 --> 00:00:55,450 between these three things. 19 00:00:55,450 --> 00:00:58,420 I will define these, of course. 20 00:00:58,420 --> 00:01:01,120 So so far we've talked about scripts. 21 00:01:01,120 --> 00:01:03,040 And you've got up codes. 22 00:01:03,040 --> 00:01:04,330 You've got a stack. 23 00:01:04,330 --> 00:01:08,050 I think with the homework people sort of got the idea, 24 00:01:08,050 --> 00:01:09,280 OK, I can do OP_RETURN. 25 00:01:09,280 --> 00:01:14,740 I can do OP_CHECKSIG, and the basic idea of how it works. 26 00:01:14,740 --> 00:01:19,070 So right now in Bitcoin, it's mostly pay to pubkey hash. 27 00:01:19,070 --> 00:01:21,070 So most of the scripts that you'll see-- mostly, 28 00:01:21,070 --> 00:01:24,140 output scripts in an output look like this. 29 00:01:24,140 --> 00:01:28,790 OP_DUP, OP_HASH160, thumb pubkey hash OP_EQUALVERIFY, 30 00:01:28,790 --> 00:01:30,160 OP_CHECKSIG. 31 00:01:30,160 --> 00:01:32,740 And then when you want to execute the script, 32 00:01:32,740 --> 00:01:37,990 you put a pubkey and a signature as your input. 33 00:01:37,990 --> 00:01:44,320 It duplicates the pubkey, hashes it, pushes this hash onto it, 34 00:01:44,320 --> 00:01:47,110 checks that those two things are equal. 35 00:01:47,110 --> 00:01:49,180 And this also removes those two things, 36 00:01:49,180 --> 00:01:51,740 leaving only the signature, and then checks the signature. 37 00:01:51,740 --> 00:01:53,390 So if they're not equal-- if you try 38 00:01:53,390 --> 00:01:55,600 to sign with a different pubkey than the one that 39 00:01:55,600 --> 00:01:59,680 is committed to in this pubkey hash, it'll fail at this point. 40 00:01:59,680 --> 00:02:02,050 And if you put the right pubkey but the wrong signature, 41 00:02:02,050 --> 00:02:05,200 it'll fail at this point. 42 00:02:05,200 --> 00:02:08,770 Well, it'll the CHECKSIG will fail, put a 0 on the stack. 43 00:02:08,770 --> 00:02:11,860 And then the stack will have a 0 on it, and that'll fail. 44 00:02:11,860 --> 00:02:16,310 Verify means, immediately fail, if these things are not equal. 45 00:02:16,310 --> 00:02:19,430 And then in segwit, they templated it. 46 00:02:19,430 --> 00:02:23,870 So really, this entire script became OP_0, pubkey hash, 47 00:02:23,870 --> 00:02:25,160 which is confusing. 48 00:02:25,160 --> 00:02:26,760 If you don't know what that means-- 49 00:02:26,760 --> 00:02:31,010 wait, OP_0 means just put a 0 on the stack, 50 00:02:31,010 --> 00:02:32,870 and then put a pubkey hash on the stack, 51 00:02:32,870 --> 00:02:34,880 and anyone can spend this. 52 00:02:34,880 --> 00:02:37,550 But the idea in segwit is, yes, software 53 00:02:37,550 --> 00:02:40,730 that is not aware of segwit will see this as spendable 54 00:02:40,730 --> 00:02:42,830 by anyone without a signature. 55 00:02:42,830 --> 00:02:46,730 Software that is aware of segwit knows that these two things 56 00:02:46,730 --> 00:02:47,450 are the same. 57 00:02:47,450 --> 00:02:51,380 So essentially, if you see this, turn it into this. 58 00:02:51,380 --> 00:02:55,310 Take the pubkey hash and fill in these OP codes. 59 00:02:55,310 --> 00:02:57,080 And that's actually what the code does, 60 00:02:57,080 --> 00:02:58,370 for the script interpreter. 61 00:02:58,370 --> 00:03:00,650 It will say, oh, it matches this template. 62 00:03:00,650 --> 00:03:03,860 It's OP_0 and a 20-byte piece of data. 63 00:03:03,860 --> 00:03:06,710 Turn it into this, and then execute it. 64 00:03:06,710 --> 00:03:09,140 So in this way, segwit saves three bytes. 65 00:03:09,140 --> 00:03:13,790 Because now you have one byte there instead of 1, 2, 3, 4. 66 00:03:13,790 --> 00:03:16,152 You lose a couple more bytes elsewhere in segwit, 67 00:03:16,152 --> 00:03:18,110 so it actually tends to lose a couple of bytes. 68 00:03:18,110 --> 00:03:19,770 But whatever. 69 00:03:19,770 --> 00:03:21,630 So this works. 70 00:03:21,630 --> 00:03:22,450 This makes sense. 71 00:03:22,450 --> 00:03:25,350 Any questions about pay to pubkey hash? 72 00:03:25,350 --> 00:03:27,480 It works OK? 73 00:03:27,480 --> 00:03:30,530 And there's also pay to script hash. 74 00:03:30,530 --> 00:03:33,030 This is the other thing you'll see quite a bit of in Bitcoin 75 00:03:33,030 --> 00:03:35,250 today. 76 00:03:35,250 --> 00:03:36,630 I don't know what the ratios are. 77 00:03:36,630 --> 00:03:40,170 80% pay to pubkey hash, 20% pay to script hash-- 78 00:03:40,170 --> 00:03:41,730 something like that. 79 00:03:41,730 --> 00:03:45,510 So a minority, but significant. 80 00:03:45,510 --> 00:03:49,830 And for pay to script hash, it looks like this-- 81 00:03:49,830 --> 00:03:52,000 also sort of template-y, right? 82 00:03:52,000 --> 00:03:55,260 OP_HASH160, a script hash, OP_EQUAL. 83 00:03:55,260 --> 00:03:57,000 That's it. 84 00:03:57,000 --> 00:03:59,970 This also seems like, wait, all I have to do 85 00:03:59,970 --> 00:04:03,330 is provide a pre-image of this, and then I'll 86 00:04:03,330 --> 00:04:05,070 be able to spend the coins. 87 00:04:05,070 --> 00:04:07,470 But the script interpreter knows-- no, 88 00:04:07,470 --> 00:04:09,050 actually what this means-- 89 00:04:09,050 --> 00:04:12,210 if you see this template, if you see this format-- 90 00:04:12,210 --> 00:04:14,760 verify that this is equal, and then 91 00:04:14,760 --> 00:04:18,779 execute whatever the pre-image was, as a script. 92 00:04:18,779 --> 00:04:20,790 So actually the first time I started programming 93 00:04:20,790 --> 00:04:24,090 Bitcoin stuff, I did not know about pay to script hash, 94 00:04:24,090 --> 00:04:26,400 and I was just trying to make my own transactions. 95 00:04:26,400 --> 00:04:27,240 And I used this. 96 00:04:27,240 --> 00:04:30,210 I just said, well, I want to see that I can get the script 97 00:04:30,210 --> 00:04:31,290 to execute right. 98 00:04:31,290 --> 00:04:34,437 I'll just take a random number, hash it, 99 00:04:34,437 --> 00:04:36,270 put it into this thing, and try to spend it. 100 00:04:36,270 --> 00:04:39,070 And it never worked, and I didn't know why. 101 00:04:39,070 --> 00:04:42,450 And then a few days later, I read about pay to script hash. 102 00:04:42,450 --> 00:04:43,590 Wait, it wasn't days later. 103 00:04:43,590 --> 00:04:45,030 I just put an OP. 104 00:04:45,030 --> 00:04:48,258 I put an OP, no OP, OP_HASH160, script hash, OP_EQUAL. 105 00:04:48,258 --> 00:04:49,050 And then it worked. 106 00:04:49,050 --> 00:04:51,175 And I was like, OK, I don't know how Bitcoin works. 107 00:04:51,175 --> 00:04:52,540 This doesn't make any sense. 108 00:04:52,540 --> 00:04:55,680 I put a no OP, and then it starts working. 109 00:04:55,680 --> 00:04:59,160 And then a few days later I read about pay to script hash, 110 00:04:59,160 --> 00:05:02,070 and it was, oh, this actually has a special meaning. 111 00:05:02,070 --> 00:05:06,240 This is a template where if you HASH160, a bunch of data, 112 00:05:06,240 --> 00:05:10,950 and OP_EQUAL, then it interprets the pre-image as a script. 113 00:05:10,950 --> 00:05:13,130 Does it have to be 20 bytes, probably? 114 00:05:13,130 --> 00:05:15,910 Yeah, I don't know. 115 00:05:15,910 --> 00:05:20,340 There's actually a vulnerability here. 116 00:05:20,340 --> 00:05:22,230 How pay to script hash got introduced 117 00:05:22,230 --> 00:05:23,850 is sort of an interesting debate. 118 00:05:23,850 --> 00:05:26,880 There was OP_EVAL, pay to script hash-- 119 00:05:26,880 --> 00:05:28,590 a bunch of argument about it. 120 00:05:28,590 --> 00:05:32,310 And this was in 2012, I think, or '11. 121 00:05:32,310 --> 00:05:37,140 And it was sort of contentious, and people argue about it. 122 00:05:37,140 --> 00:05:40,770 And in retrospect this is actually insecure 123 00:05:40,770 --> 00:05:44,220 because you're using OP_HASH160 160, 124 00:05:44,220 --> 00:05:46,110 which is 160-byte hash function. 125 00:05:46,110 --> 00:05:52,560 It's basically SHA-256 followed by RIPEMD-160. 126 00:05:52,560 --> 00:05:54,760 This is not big enough. 127 00:05:54,760 --> 00:05:58,320 You're committing to a script hash, which is 20 bytes. 128 00:05:58,320 --> 00:06:03,840 So normally you're like, yeah, whatever, 160 bits is plenty. 129 00:06:03,840 --> 00:06:06,300 You can have collision attacks, where 130 00:06:06,300 --> 00:06:08,550 if you're doing multisig with someone else, 131 00:06:08,550 --> 00:06:12,330 they may be able to calculate different pubkeys, so 132 00:06:12,330 --> 00:06:14,880 that your pubkey-- 133 00:06:14,880 --> 00:06:18,990 they have a collision where two different 20-byte scripts 134 00:06:18,990 --> 00:06:20,250 hash to the same thing. 135 00:06:20,250 --> 00:06:24,347 Sorry, two different scripts, hashed to the same 20 bytes. 136 00:06:24,347 --> 00:06:25,930 This is possible because that's only 2 137 00:06:25,930 --> 00:06:29,722 to the 80 work which is still a lot. 138 00:06:29,722 --> 00:06:31,680 And used to be considered like, no one can do-- 139 00:06:31,680 --> 00:06:35,400 2 to the 80 is beyond any human endeavor. 140 00:06:35,400 --> 00:06:38,970 But Bitcoin does 2 to the 80 work every day, hour. 141 00:06:38,970 --> 00:06:41,310 I don't know, something fairly reasonable. 142 00:06:41,310 --> 00:06:45,060 So it's like, wait, 2 to the 80 is not enough. 143 00:06:45,060 --> 00:06:48,570 For the same security as Bitcoin, which is generally a 2 144 00:06:48,570 --> 00:06:50,670 to the 128 security parameter, we 145 00:06:50,670 --> 00:06:54,780 would need this to be 256 bits instead of 160. 146 00:06:54,780 --> 00:06:59,970 So when they upgraded the segwit pay to witness script hash, 147 00:06:59,970 --> 00:07:03,500 this has to be 32 bytes, to eliminate 148 00:07:03,500 --> 00:07:06,357 any of those collision vulnerabilities. 149 00:07:06,357 --> 00:07:07,940 So yeah, that's what distinguishes it. 150 00:07:07,940 --> 00:07:11,030 So they look the same, Right it's just OP_0, 151 00:07:11,030 --> 00:07:13,725 piece of data, OP_0, piece of data. 152 00:07:13,725 --> 00:07:15,350 But they do completely different things 153 00:07:15,350 --> 00:07:18,280 based on how long this data is. 154 00:07:18,280 --> 00:07:19,790 OK, so that's pay to script hash. 155 00:07:19,790 --> 00:07:23,570 Any questions about the basic construction? 156 00:07:23,570 --> 00:07:27,810 OK, I want to make it so that two of these three keys 157 00:07:27,810 --> 00:07:30,480 must sign, in order to spend the coins. 158 00:07:30,480 --> 00:07:37,380 So I say, OP_2 push three public keys OP_3, OP_CHECKMULTISIG. 159 00:07:37,380 --> 00:07:41,180 So the idea is two of these three must sign. 160 00:07:41,180 --> 00:07:43,470 So you can put OP_1, this OP_3. 161 00:07:43,470 --> 00:07:45,630 You can OP_3-- this OP_3. 162 00:07:45,630 --> 00:07:48,900 If you put OP_4, three keys, and then OP_3, 163 00:07:48,900 --> 00:07:53,820 it probably will never be spendable and just never work. 164 00:07:53,820 --> 00:07:56,010 I'm pretty sure you have to put the signatures 165 00:07:56,010 --> 00:07:57,370 in the correct order. 166 00:07:57,370 --> 00:08:01,682 So when you spend, you say, OP_0, sigA, sigC. 167 00:08:01,682 --> 00:08:05,460 And that's A, C. If you put sigC, sigA, it fails. 168 00:08:08,940 --> 00:08:14,250 This is a fun little part, where you have to put in a 0 byte 169 00:08:14,250 --> 00:08:16,770 before the signatures, when you want to spend. 170 00:08:16,770 --> 00:08:19,960 I'm not 100% sure how that got in. 171 00:08:19,960 --> 00:08:24,912 It was a screw up, and we just live with it forever. 172 00:08:24,912 --> 00:08:28,980 [LAUGHS] If you don't put the OP_0, it doesn't work. 173 00:08:28,980 --> 00:08:30,548 And it's somewhat confusing. 174 00:08:30,548 --> 00:08:32,340 It wastes a byte, which is not a huge deal. 175 00:08:32,340 --> 00:08:34,720 But it's just like, what? 176 00:08:34,720 --> 00:08:37,650 And they didn't fix that in segwit. 177 00:08:37,650 --> 00:08:39,990 It just stays in there. 178 00:08:39,990 --> 00:08:41,730 Who knows if it'll ever get out. 179 00:08:41,730 --> 00:08:43,880 So segwit was an opportunity to fix it. 180 00:08:43,880 --> 00:08:44,610 Yes, go ahead. 181 00:08:44,610 --> 00:08:46,040 AUDIENCE: Why didn't they just update that pretty quickly 182 00:08:46,040 --> 00:08:48,082 when they realized you have to put an OP_0 there? 183 00:08:48,082 --> 00:08:50,670 TADGE DRYJA: Hard fork. 184 00:08:50,670 --> 00:08:52,200 So you put this in. 185 00:08:52,200 --> 00:08:54,550 And you could say, wait, that's stupid. 186 00:08:54,550 --> 00:08:57,130 Wait, you need a 0 in front when you put the signatures? 187 00:08:57,130 --> 00:08:58,130 Let's get rid of that. 188 00:08:58,130 --> 00:09:03,510 So now the old software says, no, I need a 0 here. 189 00:09:03,510 --> 00:09:06,360 And then if you don't put the 0, and you just put the two 190 00:09:06,360 --> 00:09:07,652 signatures, I fail this script. 191 00:09:07,652 --> 00:09:09,068 AUDIENCE: [INAUDIBLE] doesn't have 192 00:09:09,068 --> 00:09:10,910 to be a 0 until the [INAUDIBLE]? 193 00:09:10,910 --> 00:09:11,702 TADGE DRYJA: Right. 194 00:09:11,702 --> 00:09:12,630 It could be anything. 195 00:09:12,630 --> 00:09:17,370 It could just be any data. 196 00:09:17,370 --> 00:09:22,200 And it was like any data the stack would get popped off. 197 00:09:22,200 --> 00:09:24,532 And then the two signatures. 198 00:09:24,532 --> 00:09:26,740 So if you said, let's eliminate that requirement that 199 00:09:26,740 --> 00:09:28,448 would actually be a hard fork, because it 200 00:09:28,448 --> 00:09:32,050 would be allowing scripts that were previously invalid to now 201 00:09:32,050 --> 00:09:33,130 become valid. 202 00:09:33,130 --> 00:09:36,550 And that's a huge undertaking, that has sort of only 203 00:09:36,550 --> 00:09:40,460 happened once in Bitcoin, and that wasn't even planned. 204 00:09:40,460 --> 00:09:42,850 And so it's just like, whatever, leave it. 205 00:09:42,850 --> 00:09:44,430 They did soft fork it then. 206 00:09:44,430 --> 00:09:45,860 Is it soft forked or policy? 207 00:09:45,860 --> 00:09:47,110 AUDIENCE: Soft fork. 208 00:09:47,110 --> 00:09:48,902 TADGE DRYJA: So they did soft fork and say, 209 00:09:48,902 --> 00:09:50,088 it needs to be a 0. 210 00:09:50,088 --> 00:09:51,360 AUDIENCE: [INAUDIBLE] 211 00:09:51,360 --> 00:09:53,695 TADGE DRYJA: Yeah, I'm not sure. 212 00:09:53,695 --> 00:09:56,830 So it could be non-standard, or it could be an actual consensus 213 00:09:56,830 --> 00:09:58,480 rule, that that has to be a 0. 214 00:09:58,480 --> 00:10:02,410 It used to be anything, and now it should be a 0. 215 00:10:02,410 --> 00:10:04,970 Put a 0 and then it'll work. 216 00:10:04,970 --> 00:10:08,650 But that remains in segwit as well, with multisig. 217 00:10:08,650 --> 00:10:09,812 They could have fixed it. 218 00:10:09,812 --> 00:10:11,020 They didn't want to touch it. 219 00:10:11,020 --> 00:10:12,145 It was just like, whatever. 220 00:10:15,660 --> 00:10:18,130 When you see one of these, turn it into one of these, 221 00:10:18,130 --> 00:10:20,560 and just do the exact same thing you used to be doing. 222 00:10:20,560 --> 00:10:22,510 That's a lot simpler and easier. 223 00:10:22,510 --> 00:10:25,870 So kind of weird, but this works. 224 00:10:25,870 --> 00:10:30,270 People use this a lot, especially exchanges. 225 00:10:30,270 --> 00:10:34,750 Exchanges very often use this kind of construction, 226 00:10:34,750 --> 00:10:37,990 because it helps people manage keys. 227 00:10:37,990 --> 00:10:41,920 If one key gets compromised, you don't lose all your money. 228 00:10:41,920 --> 00:10:44,770 Usually, 2 of 3, sometimes 3 of 4. 229 00:10:44,770 --> 00:10:46,570 3 of 3, 2 of 2-- 230 00:10:46,570 --> 00:10:49,210 all sorts of constructions where this is extremely useful. 231 00:10:49,210 --> 00:10:53,770 And actually, I'll be talking about more powerful signature 232 00:10:53,770 --> 00:10:56,530 aggregation and multisig on Wednesday. 233 00:10:56,530 --> 00:10:59,160 But for now, this is what we use. 234 00:10:59,160 --> 00:11:02,130 And, how can we make this better? 235 00:11:02,130 --> 00:11:03,570 So one interesting thing-- 236 00:11:03,570 --> 00:11:07,490 pay to pubkey, which is not really 237 00:11:07,490 --> 00:11:10,070 used anymore, but used to be used more frequently, 238 00:11:10,070 --> 00:11:11,180 like in the early days. 239 00:11:11,180 --> 00:11:14,990 If you look at transactions in 2009, 2010, 240 00:11:14,990 --> 00:11:17,930 this is predominant, I think. 241 00:11:17,930 --> 00:11:21,320 And all the mining outputs from a long time ago looked 242 00:11:21,320 --> 00:11:23,240 like this. 243 00:11:23,240 --> 00:11:26,400 And the output script was just pubkey, 244 00:11:26,400 --> 00:11:28,933 OP_CHECKSIG, which is really simple. 245 00:11:28,933 --> 00:11:30,350 And then the idea is when you want 246 00:11:30,350 --> 00:11:33,350 to spend it, you just push a signature onto the stack. 247 00:11:33,350 --> 00:11:35,960 Then you have signature, pubkey, OP_CHECKSIG. 248 00:11:35,960 --> 00:11:38,210 That's it. 249 00:11:38,210 --> 00:11:42,500 It's really simple, and it actually saves space. 250 00:11:42,500 --> 00:11:49,250 Your pubkey is 33 bytes, whereas your pubkey hash script, 251 00:11:49,250 --> 00:11:50,810 the pubkey hash is 20 bytes. 252 00:11:50,810 --> 00:11:54,770 So yeah, the pubkey hash is 12 bytes smaller 253 00:11:54,770 --> 00:12:00,590 plus the extra OP codes makes it 10 bytes savings for the output 254 00:12:00,590 --> 00:12:02,190 script. 255 00:12:02,190 --> 00:12:05,240 However, when you spend with data pubkey hash, 256 00:12:05,240 --> 00:12:09,290 you need to put the pubkey itself and the signature. 257 00:12:09,290 --> 00:12:12,320 So you're putting the pubkey into the network either way, 258 00:12:12,320 --> 00:12:13,490 eventually. 259 00:12:13,490 --> 00:12:16,550 So this is actually overall more space efficient, 260 00:12:16,550 --> 00:12:20,840 in that you're saving 23 bytes over the lifecycle of it. 261 00:12:20,840 --> 00:12:22,550 The output is a little bit bigger 262 00:12:22,550 --> 00:12:26,450 but the input is significantly smaller, so you end up saving. 263 00:12:26,450 --> 00:12:31,670 Why do we always use pubkey hashes instead of pubkeys? 264 00:12:34,230 --> 00:12:36,590 There's a lot of different opinions on it. 265 00:12:36,590 --> 00:12:39,150 You know, it's Bitcoin, there's no "answer." 266 00:12:39,150 --> 00:12:42,120 People have different ideas of why these are better. 267 00:12:42,120 --> 00:12:43,516 Any ideas? 268 00:12:43,516 --> 00:12:45,900 AUDIENCE: [INAUDIBLE] put their pubkey out in public 269 00:12:45,900 --> 00:12:47,450 before it got spent. 270 00:12:47,450 --> 00:12:50,520 TADGE DRYJA: Yeah, that's probably the predominant one. 271 00:12:50,520 --> 00:12:53,040 And that's going to be a tricky one 272 00:12:53,040 --> 00:12:55,380 to try to convince people is not the case. 273 00:12:57,852 --> 00:12:58,560 I'll get to that. 274 00:12:58,560 --> 00:13:01,740 But people started arguing about pubkey hash. 275 00:13:01,740 --> 00:13:04,450 When someone posted about graftroot, 276 00:13:04,450 --> 00:13:07,170 the discussion devolved into a, wait, 277 00:13:07,170 --> 00:13:09,930 I don't want my pubkey on the network. 278 00:13:09,930 --> 00:13:15,433 And there's some arguments why you'd want a pubkey hash, 279 00:13:15,433 --> 00:13:17,600 and it's more secure, but there's a lot of arguments 280 00:13:17,600 --> 00:13:20,310 that it doesn't actually provide any extra security. 281 00:13:20,310 --> 00:13:22,303 So that's a tricky one. 282 00:13:22,303 --> 00:13:22,970 But that is one. 283 00:13:22,970 --> 00:13:24,710 That is probably a big one people like. 284 00:13:24,710 --> 00:13:27,350 Other ideas why you use pubkey hashes 285 00:13:27,350 --> 00:13:28,964 instead of pubkeys themselves? 286 00:13:31,810 --> 00:13:35,420 Size-- you want the outputs to be small. 287 00:13:35,420 --> 00:13:39,520 Also, I'm pretty sure when Satoshi wrote all this, 288 00:13:39,520 --> 00:13:43,150 he did not know about compressed public keys, 289 00:13:43,150 --> 00:13:45,970 because that stuff was not in there for a while. 290 00:13:48,417 --> 00:13:49,750 I think I mentioned this before. 291 00:13:49,750 --> 00:13:52,725 Did I mention compressed versus uncompressed pubkeys? 292 00:13:52,725 --> 00:13:53,350 Yeah, probably. 293 00:13:53,350 --> 00:13:54,340 OK, so review. 294 00:13:54,340 --> 00:13:56,380 The idea is you've got this whole curve 295 00:13:56,380 --> 00:13:58,780 kind of deal, kind of thing-- 296 00:14:01,380 --> 00:14:04,550 usually like that. 297 00:14:04,550 --> 00:14:07,290 Your public key is a point on the curve. 298 00:14:07,290 --> 00:14:09,660 You need an x and y-coordinate to represent the point. 299 00:14:09,660 --> 00:14:12,450 However, because it's symmetric, you 300 00:14:12,450 --> 00:14:14,940 can just say, well, I'll tell you the x-coordinate. 301 00:14:14,940 --> 00:14:16,388 You know, x equals 7. 302 00:14:16,388 --> 00:14:18,180 I'm not going to tell you the y-coordinate. 303 00:14:18,180 --> 00:14:21,310 I'll just say y equals plus. 304 00:14:21,310 --> 00:14:23,460 So go up, or go down. 305 00:14:23,460 --> 00:14:26,730 That way, I can do 32 bytes for this and 1 bit 306 00:14:26,730 --> 00:14:30,240 for that, at the cost of a little bit 307 00:14:30,240 --> 00:14:33,630 of extra computation. 308 00:14:33,630 --> 00:14:37,270 So I can say, maybe y is actually 5, or something. 309 00:14:37,270 --> 00:14:41,730 So if I say, x equals 7, y equals 5, that's quick 310 00:14:41,730 --> 00:14:42,990 but it takes more space. 311 00:14:42,990 --> 00:14:46,500 If I say x equals 7, y equals plus, 312 00:14:46,500 --> 00:14:49,050 I now have to compute what y is when 313 00:14:49,050 --> 00:14:54,608 I see this-- which is pretty quick, but take some time. 314 00:14:54,608 --> 00:14:55,650 But it's a good tradeoff. 315 00:14:55,650 --> 00:14:59,130 Anyway, I don't think Satoshi knew about this idea-- 316 00:14:59,130 --> 00:15:01,290 or maybe thought of it, never put it in. 317 00:15:01,290 --> 00:15:04,050 So the public keys were actually 65 bytes. 318 00:15:04,050 --> 00:15:06,300 You want to keep the output small, 319 00:15:06,300 --> 00:15:08,680 because they're in the UTF subset. 320 00:15:08,680 --> 00:15:10,050 They're in the database. 321 00:15:10,050 --> 00:15:12,030 And you need to be able to think through this 322 00:15:12,030 --> 00:15:13,260 and read it randomly. 323 00:15:13,260 --> 00:15:14,640 Like, you don't know when it's going to get spent. 324 00:15:14,640 --> 00:15:17,190 You don't know what transaction is going to query this. 325 00:15:17,190 --> 00:15:19,860 So this has to go in an actual database, key value store 326 00:15:19,860 --> 00:15:20,940 kind of thing. 327 00:15:20,940 --> 00:15:23,880 The signatures don't have to be in any database. 328 00:15:23,880 --> 00:15:25,590 They're just in these old blocks, 329 00:15:25,590 --> 00:15:27,460 and you read from them linearly. 330 00:15:27,460 --> 00:15:29,910 You basically read through the whole block at a time. 331 00:15:29,910 --> 00:15:31,710 And high latency is fine. 332 00:15:31,710 --> 00:15:34,890 There's never any timing-critical reads for this. 333 00:15:34,890 --> 00:15:38,340 So basically, you could store the blocks 334 00:15:38,340 --> 00:15:40,840 as just files on your hard drive. 335 00:15:40,840 --> 00:15:43,710 Block 1 dot dat, or whatever-- block 2 dot dat-- 336 00:15:43,710 --> 00:15:47,820 and have 500,000 files, because you basically always read them 337 00:15:47,820 --> 00:15:50,670 a block at a time. 338 00:15:50,670 --> 00:15:52,950 And you only have to read them when 339 00:15:52,950 --> 00:15:54,870 other people are doing IBD-- 340 00:15:54,870 --> 00:15:57,630 initialization block download-- and you're serving it to them. 341 00:15:57,630 --> 00:16:02,630 So you can prune these, if you run Bitcoin core with pruning. 342 00:16:02,630 --> 00:16:06,650 Anyway, so the main idea is, OK, even if it overall 343 00:16:06,650 --> 00:16:09,920 increases the size of transactions, 344 00:16:09,920 --> 00:16:12,180 it does reduce the size of the outputs-- 345 00:16:12,180 --> 00:16:14,390 which is the thing we really want to minimize, 346 00:16:14,390 --> 00:16:17,480 for keeping the speed up. 347 00:16:17,480 --> 00:16:18,360 Questions about that? 348 00:16:18,360 --> 00:16:19,020 Cool? 349 00:16:19,020 --> 00:16:20,430 OK. 350 00:16:20,430 --> 00:16:24,890 So similarly, same thing with pay to pubkey hashes versus pay 351 00:16:24,890 --> 00:16:26,250 to pubkey. 352 00:16:26,250 --> 00:16:29,220 Instead of pay to script hash, you could put the whole script 353 00:16:29,220 --> 00:16:30,750 in an output-- 354 00:16:30,750 --> 00:16:31,620 like a multiset. 355 00:16:31,620 --> 00:16:33,660 You could just have all three of your keys 356 00:16:33,660 --> 00:16:35,850 in your output script. 357 00:16:35,850 --> 00:16:37,980 And that would save space overall. 358 00:16:37,980 --> 00:16:39,360 Your output is 20 bytes, and then 359 00:16:39,360 --> 00:16:42,180 you reveal your whole 100-byte script, 360 00:16:42,180 --> 00:16:43,560 so you save those 20 bytes. 361 00:16:43,560 --> 00:16:47,435 Same amount, but proportionately less, sorry. 362 00:16:47,435 --> 00:16:48,810 It is some space savings overall, 363 00:16:48,810 --> 00:16:52,800 but it's better to keep the output size small. 364 00:16:52,800 --> 00:16:55,675 [INAUDIBLE] If you do this, does it actually work? 365 00:16:55,675 --> 00:16:56,572 AUDIENCE: [INAUDIBLE] 366 00:16:56,572 --> 00:16:58,030 TADGE DRYJA: OK, it's not standard, 367 00:16:58,030 --> 00:16:59,630 so it might not propagate. 368 00:16:59,630 --> 00:17:02,105 AUDIENCE: [INAUDIBLE] 369 00:17:02,105 --> 00:17:03,730 TADGE DRYJA: I wouldn't recommend this. 370 00:17:03,730 --> 00:17:06,099 It probably will not really work. 371 00:17:06,099 --> 00:17:07,810 Maybe eventually it will get confirmed, 372 00:17:07,810 --> 00:17:10,119 if you find people to confirm it for you, 373 00:17:10,119 --> 00:17:14,210 but most nodes will ignore these kinds of things. 374 00:17:14,210 --> 00:17:17,240 OK, so the question for today-- 375 00:17:17,240 --> 00:17:20,290 what if we want really, really big scripts? 376 00:17:20,290 --> 00:17:22,720 So 2 of 3 multisig is cool. 377 00:17:22,720 --> 00:17:24,490 We can just show all three keys. 378 00:17:24,490 --> 00:17:28,630 And there's 33 bytes of data that don't really get used. 379 00:17:28,630 --> 00:17:30,700 If you're signing with 2 of the 3 keys, 380 00:17:30,700 --> 00:17:33,310 well, that means one of the keys never got used. 381 00:17:33,310 --> 00:17:35,990 It was sort of there and pointless. 382 00:17:35,990 --> 00:17:37,750 But whatever, it's 33 bytes. 383 00:17:37,750 --> 00:17:40,750 So what if you want to do, like, 2 of 50 multisig? 384 00:17:40,750 --> 00:17:42,160 So here's 50 different keys. 385 00:17:42,160 --> 00:17:45,127 Any two of these people can sign. 386 00:17:45,127 --> 00:17:46,210 Maybe you're in a company. 387 00:17:46,210 --> 00:17:47,800 There's 50 employees. 388 00:17:47,800 --> 00:17:50,020 And the policy is that, OK, any of these two people 389 00:17:50,020 --> 00:17:54,700 can use the coins for this spending to buy lunch, 390 00:17:54,700 --> 00:17:55,240 or whatever. 391 00:17:58,830 --> 00:18:01,350 So how would you 2 of 250 multisig? 392 00:18:01,350 --> 00:18:03,520 Any ideas? 393 00:18:03,520 --> 00:18:06,340 You commit, and only reveal part of a commitment. 394 00:18:06,340 --> 00:18:09,990 So the cause of and solution to all of blockchain's problems-- 395 00:18:09,990 --> 00:18:10,830 Merkle trees. 396 00:18:10,830 --> 00:18:12,702 That's sort of the solution for all-- 397 00:18:12,702 --> 00:18:14,160 throw a Merkle tree on it, which is 398 00:18:14,160 --> 00:18:17,360 sort of actually what I'm working on now, 399 00:18:17,360 --> 00:18:20,180 for another thing. 400 00:18:20,180 --> 00:18:22,350 So you commit to some kind of root, 401 00:18:22,350 --> 00:18:28,440 and then you reveal only part of what you've committed to. 402 00:18:28,440 --> 00:18:30,840 So the idea, which is from-- 403 00:18:34,240 --> 00:18:36,430 there's debate about who came up with this stuff-- 404 00:18:36,430 --> 00:18:36,970 MAST. 405 00:18:36,970 --> 00:18:38,978 Like Peter [? Wohl ?] was into it, 406 00:18:38,978 --> 00:18:41,270 but then someone else said they wrote a paper about it. 407 00:18:41,270 --> 00:18:41,950 I don't know. 408 00:18:41,950 --> 00:18:44,170 It was like 2013, 2014. 409 00:18:44,170 --> 00:18:50,020 The original idea was make a merkelized abstract syntax 410 00:18:50,020 --> 00:18:51,340 tree. 411 00:18:51,340 --> 00:18:55,270 So if you have done any programming language courses, 412 00:18:55,270 --> 00:18:59,800 you probably recognize the term abstract syntax tree asked, 413 00:18:59,800 --> 00:19:01,510 which is sort of how compilers work. 414 00:19:01,510 --> 00:19:03,040 They make this tree. 415 00:19:03,040 --> 00:19:06,460 So the idea is, OK, we'll make every node in that tree 416 00:19:06,460 --> 00:19:09,910 like a Merkle root, so every single OP code can 417 00:19:09,910 --> 00:19:12,120 be revealed and be swapped out. 418 00:19:12,120 --> 00:19:13,840 And it's super crazy. 419 00:19:13,840 --> 00:19:14,920 That's sort of overkill. 420 00:19:14,920 --> 00:19:18,760 So that was part of the initial idea and paper. 421 00:19:18,760 --> 00:19:21,340 But a much simpler way to reason about it 422 00:19:21,340 --> 00:19:23,830 and program it would just be something like, 423 00:19:23,830 --> 00:19:25,780 pay to script Merkle root. 424 00:19:25,780 --> 00:19:29,830 Where in my output script I have a root, 425 00:19:29,830 --> 00:19:33,250 and then I reveal that there is a script that 426 00:19:33,250 --> 00:19:38,290 goes into that root, and then execute that script. 427 00:19:38,290 --> 00:19:41,550 So for example, I make four different scripts. 428 00:19:41,550 --> 00:19:42,570 So this would be-- 429 00:19:46,810 --> 00:19:49,120 anyway, it's just four different scripts. 430 00:19:49,120 --> 00:19:53,080 There's an O-2 choose n, that results in four. 431 00:19:53,080 --> 00:19:54,580 I don't think so. 432 00:19:54,580 --> 00:19:56,183 But you know, this is Alice and Bob. 433 00:19:56,183 --> 00:19:57,100 This is Bob and Carol. 434 00:19:57,100 --> 00:19:58,058 This is Carol and Dave. 435 00:19:58,058 --> 00:20:01,570 This is Dave and Edna, or something. 436 00:20:01,570 --> 00:20:06,590 And any of these two people, but four different groups, 437 00:20:06,590 --> 00:20:07,090 can sign. 438 00:20:09,820 --> 00:20:11,350 And then this is what you actually 439 00:20:11,350 --> 00:20:12,850 put in your output script. 440 00:20:12,850 --> 00:20:14,350 And then when you want to spend, you 441 00:20:14,350 --> 00:20:16,690 say, OK, I'm going to provide a proof. 442 00:20:16,690 --> 00:20:18,760 So to spend, reveal which I'm spending. 443 00:20:18,760 --> 00:20:22,060 So for example, I'm spending using script 3. 444 00:20:22,060 --> 00:20:24,220 And then I reveal a path to the root, 445 00:20:24,220 --> 00:20:31,120 which would be I reveal 4, and this, and then you compute. 446 00:20:31,120 --> 00:20:35,440 You say, OK, hash these two things together, you get that. 447 00:20:35,440 --> 00:20:38,710 Hash of these two things together, you get that. 448 00:20:38,710 --> 00:20:42,220 And confirm that the result is equal to what 449 00:20:42,220 --> 00:20:43,880 was in the output script. 450 00:20:43,880 --> 00:20:48,430 And if it is, OK, you've provided a valid inclusion 451 00:20:48,430 --> 00:20:53,890 proof that script 3 was inside this root. 452 00:20:53,890 --> 00:20:55,670 What's kind of cool-- in this case, 453 00:20:55,670 --> 00:20:58,690 you do not need the binary tree to be perfect. 454 00:20:58,690 --> 00:21:02,490 You can have different heights, because you're not 455 00:21:02,490 --> 00:21:05,340 committing to the height of the tree when you're sending to it. 456 00:21:05,340 --> 00:21:11,010 So the default case could be here, 457 00:21:11,010 --> 00:21:14,340 and then a really big tree that goes down a lot over here. 458 00:21:14,340 --> 00:21:19,080 So in most cases it's going to be Alice and Bob signing. 459 00:21:19,080 --> 00:21:23,730 And then Carol and Dave, and Edna and whatever, 460 00:21:23,730 --> 00:21:25,380 are unlikely. 461 00:21:25,380 --> 00:21:28,740 So I'm going to put Alice and Bob here, and then 462 00:21:28,740 --> 00:21:30,240 have the tree sort of asymmetrically 463 00:21:30,240 --> 00:21:31,470 get longer over here. 464 00:21:31,470 --> 00:21:35,460 So that when Alice and Bob sign, they can just reveal this. 465 00:21:35,460 --> 00:21:36,960 And then when the other people sign, 466 00:21:36,960 --> 00:21:39,960 they're going to have to reveal this and this. 467 00:21:39,960 --> 00:21:44,352 And then I optimize my space for the most likely case. 468 00:21:44,352 --> 00:21:45,310 So that's kind of cool. 469 00:21:48,010 --> 00:21:50,020 What else? 470 00:21:50,020 --> 00:21:52,530 However, there are a bunch of problems. 471 00:21:52,530 --> 00:21:55,400 One, OK, 2 of 50 is cool. 472 00:21:55,400 --> 00:21:59,230 So in the case of 250, let's just look through it. 473 00:21:59,230 --> 00:22:01,870 50 choose 2-- I couldn't make the little numbers 474 00:22:01,870 --> 00:22:04,000 in parentheses the right-- 475 00:22:04,000 --> 00:22:04,960 whatever. 476 00:22:04,960 --> 00:22:07,960 So that's 1,225 different scripts. 477 00:22:07,960 --> 00:22:14,420 And if you do a regular binary tree-- 478 00:22:14,420 --> 00:22:17,690 balanced-- I forget all the words-- 479 00:22:17,690 --> 00:22:19,340 you get a tree height of 11. 480 00:22:19,340 --> 00:22:22,780 Which is kind of like, oh, it's so close, right? 481 00:22:22,780 --> 00:22:25,220 If it was 1,024, it'd be 10, but a little over. 482 00:22:27,693 --> 00:22:29,860 And actually, since it doesn't have to be symmetric, 483 00:22:29,860 --> 00:22:32,110 you can get like tree height 10 for most leaves, 484 00:22:32,110 --> 00:22:33,562 and then 11 for some of them. 485 00:22:33,562 --> 00:22:35,020 Anyway, so your proof size is going 486 00:22:35,020 --> 00:22:38,740 to be 352 bytes, which is OK. 487 00:22:38,740 --> 00:22:41,620 And if you didn't use MAST, you can say, well, 488 00:22:41,620 --> 00:22:44,120 I'm just going to have a pay to script hash. 489 00:22:44,120 --> 00:22:47,380 And this script is just going to show all 50 keys, 490 00:22:47,380 --> 00:22:50,780 and have OP_2, all 50 keys, OP_3. 491 00:22:50,780 --> 00:22:56,690 And that would be about plus 3, or something, but 1,650 bytes. 492 00:22:56,690 --> 00:22:59,980 So MAST is an improvement. 493 00:22:59,980 --> 00:23:02,220 And it's sort of like, hey, I'm doing log n. 494 00:23:02,220 --> 00:23:04,220 And for all the different scripts, I have log n. 495 00:23:04,220 --> 00:23:07,310 If I actually committed to all the 1,225 scripts 496 00:23:07,310 --> 00:23:09,473 with each of the two keys, it'd be much bigger. 497 00:23:09,473 --> 00:23:11,390 But I don't actually have to, because I've got 498 00:23:11,390 --> 00:23:13,520 this whole 50 choose 2 in here. 499 00:23:13,520 --> 00:23:14,540 So I've got two things. 500 00:23:14,540 --> 00:23:17,710 I've got this combinatorial thing, and then this log thing. 501 00:23:17,710 --> 00:23:20,930 And in balance, it's like, OK, meh-- like, better, 502 00:23:20,930 --> 00:23:23,360 but not actually that awesome. 503 00:23:23,360 --> 00:23:27,050 You're going from 1.6k to 350 bytes. 504 00:23:27,050 --> 00:23:28,130 It gets worse. 505 00:23:28,130 --> 00:23:30,230 Let's say I want to do 25 of 50. 506 00:23:30,230 --> 00:23:32,930 Well, that's 50 choose 25, which is around 100 trillion 507 00:23:32,930 --> 00:23:34,990 different combinations. 508 00:23:34,990 --> 00:23:37,340 The tree height would now be 47. 509 00:23:37,340 --> 00:23:39,960 The proof size is going to be-- 510 00:23:39,960 --> 00:23:43,000 wait, did I do that wrong? 511 00:23:43,000 --> 00:23:43,500 Hold on. 512 00:23:46,400 --> 00:23:49,980 47 by 32 is 1,504. 513 00:23:49,980 --> 00:23:53,160 OK, sorry, for some reason I have 22 there. 514 00:23:53,160 --> 00:23:55,230 Sorry, I'll fix that. 515 00:23:55,230 --> 00:23:57,360 But that is correct. 516 00:23:57,360 --> 00:23:59,070 Yeah, 1,504. 517 00:23:59,070 --> 00:24:03,270 So 1.5k, whereas the raw would still be 1,650. 518 00:24:03,270 --> 00:24:04,560 These are about the same. 519 00:24:04,560 --> 00:24:06,550 This is not a great space savings. 520 00:24:06,550 --> 00:24:09,150 Your proofs are huge. 521 00:24:09,150 --> 00:24:12,420 In fact, I would say it's not only not much better, 522 00:24:12,420 --> 00:24:13,280 it's worse. 523 00:24:13,280 --> 00:24:16,290 You're going to have to compute 200 trillion hashes in order 524 00:24:16,290 --> 00:24:18,780 to compute that root, as the person creating the output 525 00:24:18,780 --> 00:24:19,500 script. 526 00:24:19,500 --> 00:24:22,770 To verify inclusion, you have to compute 527 00:24:22,770 --> 00:24:25,050 47 hashes, which is fine. 528 00:24:25,050 --> 00:24:27,763 200 trillion hashes is doable, but that's 529 00:24:27,763 --> 00:24:28,680 going to take a while. 530 00:24:28,680 --> 00:24:32,140 And that's annoying. 531 00:24:32,140 --> 00:24:33,770 How long? 532 00:24:33,770 --> 00:24:35,478 Hours, days? 533 00:24:35,478 --> 00:24:36,020 I don't know. 534 00:24:36,020 --> 00:24:38,900 Doable, but not fun. 535 00:24:38,900 --> 00:24:42,050 So MAST doesn't really get you necessarily 536 00:24:42,050 --> 00:24:47,020 what you want here, although this is kind of a silly case. 537 00:24:47,020 --> 00:24:48,430 None of the things really get you 538 00:24:48,430 --> 00:24:50,710 what you want here, because of these sort 539 00:24:50,710 --> 00:24:52,810 of combinatorial problems. 540 00:24:52,810 --> 00:24:58,380 Any questions, or oppositions if I have screwed up 541 00:24:58,380 --> 00:25:01,345 some math somewhere? 542 00:25:01,345 --> 00:25:03,680 AUDIENCE: [INAUDIBLE] 543 00:25:11,290 --> 00:25:13,210 TADGE DRYJA: So compare these two. 544 00:25:13,210 --> 00:25:17,600 If I show a tree height of 10 or 11, huh, that's weird. 545 00:25:17,600 --> 00:25:21,910 There's like 1,000 different scripts around in this tree. 546 00:25:21,910 --> 00:25:24,820 If I show a tree height of 47, that's really weird. 547 00:25:24,820 --> 00:25:27,340 Someone either was just joking around 548 00:25:27,340 --> 00:25:30,220 and made this weird sparse tree with all these branches 549 00:25:30,220 --> 00:25:33,250 to just screw around and have a height of 47, 550 00:25:33,250 --> 00:25:38,560 or there's 200 trillion possible spending outcomes. 551 00:25:38,560 --> 00:25:42,070 So it reveals information about the things that were not spent. 552 00:25:42,070 --> 00:25:44,260 Even though it doesn't reveal what the scripts were, 553 00:25:44,260 --> 00:25:46,177 it to some extent reveals how many there were. 554 00:25:52,150 --> 00:25:53,830 But still it is kind of useful, right? 555 00:25:53,830 --> 00:25:57,030 In the 2 of 50 case, yes, this is better. 556 00:25:57,030 --> 00:25:59,510 You have to compute a thousand-something hashes. 557 00:25:59,510 --> 00:26:00,740 No big deal. 558 00:26:00,740 --> 00:26:04,580 You reduce your size from 1.6k to 353 bytes. 559 00:26:04,580 --> 00:26:06,880 That's a good deal. 560 00:26:06,880 --> 00:26:10,340 Here kind of not, but this is also sort of a crazy-- 561 00:26:10,340 --> 00:26:14,100 there's other ways to address this, but it's pretty good. 562 00:26:14,100 --> 00:26:18,650 There's sort of two, or more than two different ways 563 00:26:18,650 --> 00:26:19,982 to implement this. 564 00:26:19,982 --> 00:26:21,440 You could just say, OK, we're going 565 00:26:21,440 --> 00:26:23,330 to have pay to script Merkle root, 566 00:26:23,330 --> 00:26:25,970 where you have a template-- where 567 00:26:25,970 --> 00:26:30,973 it's like OP_2, or OP_3, or something, and then some data. 568 00:26:30,973 --> 00:26:32,390 And the idea is when you spend it, 569 00:26:32,390 --> 00:26:35,540 you have to provide a proof, and then the script itself. 570 00:26:35,540 --> 00:26:37,340 And then, you execute the script. 571 00:26:37,340 --> 00:26:39,830 Another way which is kind of cool-- and people 572 00:26:39,830 --> 00:26:41,810 were talking about it recently-- you 573 00:26:41,810 --> 00:26:44,510 have this tail call recursion-looking thing. 574 00:26:44,510 --> 00:26:48,740 Where the idea is, if you evaluate your script 575 00:26:48,740 --> 00:26:51,740 and then there's two items left on the stack at the end, 576 00:26:51,740 --> 00:26:54,050 what you say is, OK-- 577 00:26:54,050 --> 00:26:55,400 whichever is bottom or top-- 578 00:26:55,400 --> 00:27:01,750 one of these items, the bottom one, is a Merkle root. 579 00:27:01,750 --> 00:27:03,910 And then the other item on the stack 580 00:27:03,910 --> 00:27:06,610 is the proof and arguments-- 581 00:27:06,610 --> 00:27:07,270 another script. 582 00:27:07,270 --> 00:27:10,390 So you can sort of recursively say, OK, well, I 583 00:27:10,390 --> 00:27:12,875 went down into this script with this proof 584 00:27:12,875 --> 00:27:13,750 and then executed it. 585 00:27:13,750 --> 00:27:15,580 And then things were left on the stack, 586 00:27:15,580 --> 00:27:19,600 and it was another proof, for another Merkle root. 587 00:27:19,600 --> 00:27:21,170 So that's kind of cool. 588 00:27:21,170 --> 00:27:25,010 You can make all sorts of crazy things with that. 589 00:27:25,010 --> 00:27:28,220 I don't know how useful recursion is in this case, 590 00:27:28,220 --> 00:27:29,390 but there could be cases. 591 00:27:29,390 --> 00:27:30,780 You're already in a binary tree. 592 00:27:30,780 --> 00:27:34,777 So my personal thing is, why not just keep it simple 593 00:27:34,777 --> 00:27:36,110 and pay to a script Merkle root? 594 00:27:36,110 --> 00:27:38,930 But there's people who think, no, this 595 00:27:38,930 --> 00:27:43,560 should be more expressive, like programming language-y wise. 596 00:27:43,560 --> 00:27:45,670 Anyway, so that's the state of MAST. 597 00:27:45,670 --> 00:27:47,720 MAST has code. 598 00:27:47,720 --> 00:27:49,880 There's a pull request in bip, right? 599 00:27:49,880 --> 00:27:50,380 Yeah. 600 00:27:50,380 --> 00:27:52,850 So there's some people who are really into MAST. 601 00:27:52,850 --> 00:27:55,130 And like, let's get this into Bitcoin. 602 00:27:55,130 --> 00:27:58,080 Let's make a soft fork. 603 00:27:58,080 --> 00:28:02,100 And there's also people who are not as enthusiastic about it. 604 00:28:02,100 --> 00:28:04,500 And so it's like no one's opposed 605 00:28:04,500 --> 00:28:07,380 to it-- like, this is a bad idea, this will break Bitcoin. 606 00:28:07,380 --> 00:28:11,610 But there's varying levels of let's get this 607 00:28:11,610 --> 00:28:14,250 in, you can do all these cool things, versus eh, 608 00:28:14,250 --> 00:28:15,970 is this really a priority? 609 00:28:15,970 --> 00:28:18,380 What are we going to use with it, kind of thing. 610 00:28:18,380 --> 00:28:19,590 OK, any questions about this? 611 00:28:19,590 --> 00:28:23,160 I think we have a quick break, and then I'll 612 00:28:23,160 --> 00:28:28,920 do OP_RETURN, which seems unconnected. 613 00:28:28,920 --> 00:28:31,170 But I will show you how this connects 614 00:28:31,170 --> 00:28:33,730 to these issues we have. 615 00:28:33,730 --> 00:28:36,420 OK, so OP_RETURN, it was in the problem set. 616 00:28:36,420 --> 00:28:39,630 You basically put this OP code in the front of your script, 617 00:28:39,630 --> 00:28:44,350 and that flags it as forever unspendable as an output. 618 00:28:44,350 --> 00:28:46,980 So you shouldn't put much money into these outputs, 619 00:28:46,980 --> 00:28:49,940 because they are basically destroyed. 620 00:28:49,940 --> 00:28:54,510 OP_RETURN means you immediately return from the script 621 00:28:54,510 --> 00:28:56,880 evaluation, and you return a false. 622 00:28:56,880 --> 00:28:58,740 I think it used to be return whatever 623 00:28:58,740 --> 00:29:01,410 is on the top of the stack, which 624 00:29:01,410 --> 00:29:03,690 meant you could just spend anyone's money by using 625 00:29:03,690 --> 00:29:04,800 OP_RETURN. 626 00:29:04,800 --> 00:29:08,430 So they soft forked that to say, no, OP_RETURN always 627 00:29:08,430 --> 00:29:10,273 fails instead of OP_RETURN always 628 00:29:10,273 --> 00:29:12,690 trivially succeeds-- which means you just put an OP_RETURN 629 00:29:12,690 --> 00:29:14,460 and take anyone's money. 630 00:29:14,460 --> 00:29:16,860 So they figured that one out pretty quick. 631 00:29:16,860 --> 00:29:20,940 So people use OP_RETURN to put data into the blockchain. 632 00:29:20,940 --> 00:29:24,480 Why do people do this? 633 00:29:24,480 --> 00:29:25,470 You can't spend it. 634 00:29:25,470 --> 00:29:28,140 You can't do anything with this data. 635 00:29:28,140 --> 00:29:31,600 But why do people do this? 636 00:29:31,600 --> 00:29:33,580 It's kind of cool, right? 637 00:29:33,580 --> 00:29:35,380 To prove it's there. 638 00:29:35,380 --> 00:29:37,528 You want to put some data in. 639 00:29:37,528 --> 00:29:39,820 And you just want to say, hey, I thought of this first, 640 00:29:39,820 --> 00:29:43,770 or I'm making a patent, whatever. 641 00:29:43,770 --> 00:29:44,530 You put data. 642 00:29:44,530 --> 00:29:46,700 People use a lot of OP_RETURN. 643 00:29:46,700 --> 00:29:47,200 What was it? 644 00:29:47,200 --> 00:29:48,564 Like, 10%? 645 00:29:48,564 --> 00:29:52,650 AUDIENCE: [INAUDIBLE] set. 646 00:29:52,650 --> 00:29:58,510 [INAUDIBLE] the current [INAUDIBLE] set, if you remove, 647 00:29:58,510 --> 00:30:01,030 or if you don't for the unspendables, 648 00:30:01,030 --> 00:30:03,718 it would account for about 10% of [INAUDIBLE] data set. 649 00:30:03,718 --> 00:30:05,260 TADGE DRYJA: So that's a lot of data. 650 00:30:05,260 --> 00:30:07,160 People were using it. 651 00:30:07,160 --> 00:30:10,970 There is a better way. 652 00:30:10,970 --> 00:30:14,420 So what if you wanted to do a 0 byte OP_RETURN? 653 00:30:14,420 --> 00:30:15,770 It's not quite the same. 654 00:30:15,770 --> 00:30:18,440 Because an OP_RETURN, everyone can see it. 655 00:30:18,440 --> 00:30:20,180 And in some cases, you might want that. 656 00:30:20,180 --> 00:30:21,680 You might want to put an opportunity 657 00:30:21,680 --> 00:30:24,830 so it's publicly visible. 658 00:30:24,830 --> 00:30:29,910 But in most cases, I don't care about someone's 659 00:30:29,910 --> 00:30:30,747 random OP_RETURN. 660 00:30:30,747 --> 00:30:32,580 Usually, what you're putting into OP_RETURNs 661 00:30:32,580 --> 00:30:33,932 are, like, hashes. 662 00:30:33,932 --> 00:30:35,640 Because you don't have much space anyway. 663 00:30:35,640 --> 00:30:37,410 You have, like, 40 bytes or something. 664 00:30:37,410 --> 00:30:40,530 So usually your space constraint so you 665 00:30:40,530 --> 00:30:42,420 put the hash of some document. 666 00:30:42,420 --> 00:30:44,100 And then someone can prove, no, look, 667 00:30:44,100 --> 00:30:45,690 I put the document on the blockchain, 668 00:30:45,690 --> 00:30:47,280 by putting the hash of it. 669 00:30:47,280 --> 00:30:49,170 That's a commitment to that document itself. 670 00:30:49,170 --> 00:30:53,070 So I show that I had this data at some time 671 00:30:53,070 --> 00:30:54,865 before this block came out. 672 00:30:54,865 --> 00:30:56,490 That's essentially what you're proving. 673 00:30:56,490 --> 00:31:00,990 You're proving you knew it before a certain time, which 674 00:31:00,990 --> 00:31:02,425 is in many cases really useful. 675 00:31:02,425 --> 00:31:04,800 I mean, that's sort of the whole point of the blockchain, 676 00:31:04,800 --> 00:31:07,170 to prove that you knew about this transaction 677 00:31:07,170 --> 00:31:10,960 before a future transaction tries to double spend it. 678 00:31:10,960 --> 00:31:13,410 You want to file a patent, and I had this idea first-- 679 00:31:13,410 --> 00:31:16,260 or prove these things. 680 00:31:16,260 --> 00:31:18,385 But how can we do this with 0 bytes overhead? 681 00:31:21,500 --> 00:31:23,780 OK, it's not obvious. 682 00:31:23,780 --> 00:31:25,450 You put it in the signature. 683 00:31:25,450 --> 00:31:27,800 And this was not obvious, and no one thought of this 684 00:31:27,800 --> 00:31:31,070 until a year or two ago. 685 00:31:31,070 --> 00:31:33,590 I think it was Andrew Poelstra, but I could be wrong. 686 00:31:33,590 --> 00:31:38,170 But I just associate it with him, because he worked on it. 687 00:31:38,170 --> 00:31:39,350 But I'm not 100% sure. 688 00:31:39,350 --> 00:31:42,860 And he called it pay to contract hash, which is confusing. 689 00:31:42,860 --> 00:31:47,030 It's not at all the same as pay to script hash. 690 00:31:47,030 --> 00:31:49,258 It's not at all the same as pay to pubkey hash. 691 00:31:49,258 --> 00:31:51,050 But it's called pay to contract hash, which 692 00:31:51,050 --> 00:31:52,133 makes it really confusing. 693 00:31:52,133 --> 00:32:00,440 Bitcoin has really confusing names, like script pubkey. 694 00:32:00,440 --> 00:32:02,900 Script pubkey does not have to have a pubkey in it. 695 00:32:02,900 --> 00:32:04,340 In most cases, it doesn't. 696 00:32:04,340 --> 00:32:07,760 It has a pubkey hash, or a script hash. 697 00:32:07,760 --> 00:32:09,530 It doesn't have to have anything in it, 698 00:32:09,530 --> 00:32:11,270 but it's called script pubkey. 699 00:32:11,270 --> 00:32:15,830 And then script sig usually has signatures, but again, 700 00:32:15,830 --> 00:32:17,882 not always. 701 00:32:17,882 --> 00:32:19,590 And there's all sorts of confusing names. 702 00:32:19,590 --> 00:32:21,240 Anyway, here's our new contribution 703 00:32:21,240 --> 00:32:22,750 to confusing names-- 704 00:32:22,750 --> 00:32:26,280 pay to contract hash, which is not really paying to anything. 705 00:32:26,280 --> 00:32:28,350 There doesn't have to be a contract. 706 00:32:28,350 --> 00:32:29,640 There is a hash involved. 707 00:32:32,198 --> 00:32:33,990 So it's a weird name, as you can't actually 708 00:32:33,990 --> 00:32:35,865 detect the contract, you're not paying to it. 709 00:32:35,865 --> 00:32:39,690 But to review, I'm going to use Schnoor signatures. 710 00:32:39,690 --> 00:32:41,730 This still works in ECDSA. 711 00:32:41,730 --> 00:32:45,355 But ECDSA is weird and annoying, and it also 712 00:32:45,355 --> 00:32:46,980 makes more sense in Schnoor signatures, 713 00:32:46,980 --> 00:32:49,170 so I'll explain that. 714 00:32:49,170 --> 00:32:52,110 But it totally works in ECDSA. 715 00:32:52,110 --> 00:32:53,610 The idea of the Schnoor signatures-- 716 00:32:53,610 --> 00:32:56,770 OK, this is my private key. 717 00:32:56,770 --> 00:32:58,770 This is the message I want to sign. 718 00:32:58,770 --> 00:33:01,350 This is a random sort of temporary private key 719 00:33:01,350 --> 00:33:02,760 I come up with. 720 00:33:02,760 --> 00:33:06,150 And then this is that temporary private key 721 00:33:06,150 --> 00:33:08,430 turned into a public key. 722 00:33:08,430 --> 00:33:11,040 Multiply by G to get the public key version. 723 00:33:11,040 --> 00:33:16,830 And then to verify the signature, 724 00:33:16,830 --> 00:33:18,990 the verifier multiplies both sides by G. 725 00:33:18,990 --> 00:33:23,190 So you get s times G. k turns in R. Little a turns into big A. 726 00:33:23,190 --> 00:33:29,080 This is just the 32-byte hash, so it stays the same. 727 00:33:29,080 --> 00:33:34,320 So the R and s are the signature, 728 00:33:34,320 --> 00:33:37,390 and the pub key is A, and the message is m. 729 00:33:37,390 --> 00:33:39,930 So that's the signing, or close enough 730 00:33:39,930 --> 00:33:42,680 to the signing that's used in Bitcoin. 731 00:33:42,680 --> 00:33:45,530 So pay to contract hash says, OK, I 732 00:33:45,530 --> 00:33:48,320 want to put arbitrary data into my signature, 733 00:33:48,320 --> 00:33:51,230 in a way that I can prove it was there. 734 00:33:51,230 --> 00:33:53,920 So here's the normal equation. 735 00:33:53,920 --> 00:33:56,350 Now, what if I redefine k. 736 00:33:56,350 --> 00:33:59,050 Normally, k is just a random number. 737 00:33:59,050 --> 00:34:01,090 But now I'm going to redefine k. 738 00:34:01,090 --> 00:34:02,590 k is now j. 739 00:34:02,590 --> 00:34:05,620 So j is my new real random number. 740 00:34:05,620 --> 00:34:10,480 And then I'm going to add the hash... 741 00:34:10,480 --> 00:34:11,800 There's no G there, shoot. 742 00:34:11,800 --> 00:34:14,230 Anyway, G should not be there, but it should be there. 743 00:34:14,230 --> 00:34:14,730 Sorry. 744 00:34:19,310 --> 00:34:24,250 So I redefine k as j, which is an actual random number, 745 00:34:24,250 --> 00:34:27,469 plus the hash of the data I want to commit to-- 746 00:34:27,469 --> 00:34:30,354 and j times G. You get the idea. 747 00:34:30,354 --> 00:34:31,521 That should have been there. 748 00:34:37,409 --> 00:34:39,210 And-- then the signature-- 749 00:34:39,210 --> 00:34:40,590 it's still the same equation. 750 00:34:40,590 --> 00:34:47,760 I'm just saying, OK, it's this new k minus this thing. 751 00:34:47,760 --> 00:34:51,480 And so nobody necessarily knows that I'm doing this. 752 00:34:51,480 --> 00:34:56,889 If I just tell you tell you R and s, 753 00:34:56,889 --> 00:34:58,570 the equation still holds. 754 00:34:58,570 --> 00:35:01,720 It's just that k is a little special. 755 00:35:01,720 --> 00:35:04,660 For anyone else, it looks like a random number. 756 00:35:04,660 --> 00:35:07,870 It's a random number plus this other hash-- 757 00:35:07,870 --> 00:35:10,600 not times G. 758 00:35:10,600 --> 00:35:12,530 So it's a random number plus a hash. 759 00:35:12,530 --> 00:35:14,470 Which hashes look pretty random-- 760 00:35:14,470 --> 00:35:16,780 so it's a random number plus some other random number. 761 00:35:16,780 --> 00:35:19,630 No one's going to tell that anything's weird about this. 762 00:35:19,630 --> 00:35:22,960 However, it is unique, in that I've 763 00:35:22,960 --> 00:35:27,130 got this random number plus the hash of that random number 764 00:35:27,130 --> 00:35:31,420 times G in it, and this extra data I've put in. 765 00:35:31,420 --> 00:35:34,090 So to verify it, if I don't tell you about this, 766 00:35:34,090 --> 00:35:35,950 verification looks the same. 767 00:35:35,950 --> 00:35:38,630 What if I do tell you about it, though? 768 00:35:38,630 --> 00:35:39,690 So normally the sig-- 769 00:35:39,690 --> 00:35:42,380 R, s-- pubkey is A, message is m. 770 00:35:42,380 --> 00:35:47,120 But the signer can prove that R is not kG-- 771 00:35:47,120 --> 00:35:50,330 that there's this other k. 772 00:35:50,330 --> 00:35:52,513 Well, it's k, but there's something else in R. 773 00:35:52,513 --> 00:35:54,680 I can prove that R is special after the fact, right? 774 00:35:54,680 --> 00:35:56,510 Everyone knows what R is. 775 00:35:56,510 --> 00:35:59,090 But I can then prove that something was in R. Also, 776 00:35:59,090 --> 00:36:01,190 never reveal k, even after the fact. 777 00:36:01,190 --> 00:36:04,250 That will let you figure out the person's private key. 778 00:36:04,250 --> 00:36:08,670 So the idea is I can prove that R equals 779 00:36:08,670 --> 00:36:14,967 J plus the hash of the data in J times G. 780 00:36:14,967 --> 00:36:16,800 Here's where it's a little confusing, right? 781 00:36:16,800 --> 00:36:18,932 Because this is already a pubkey, 782 00:36:18,932 --> 00:36:20,640 and you're multiplying by G again, right? 783 00:36:20,640 --> 00:36:24,208 So it's a little weird? 784 00:36:24,208 --> 00:36:25,500 Anyone can compute this, right? 785 00:36:25,500 --> 00:36:27,330 Because I can say, hey, you already know 786 00:36:27,330 --> 00:36:32,790 R. I can give you a J and some data, such that j 787 00:36:32,790 --> 00:36:37,380 plus the hash of this data, and j itself times G, equals R. 788 00:36:37,380 --> 00:36:40,080 And I can't forge this. 789 00:36:40,080 --> 00:36:43,440 If I try to forge this, and I say after the fact-- 790 00:36:43,440 --> 00:36:45,030 I just made R randomly. 791 00:36:45,030 --> 00:36:47,130 I didn't have any actual data. 792 00:36:47,130 --> 00:36:50,700 And then after the fact, I want to come up and lie, and say, 793 00:36:50,700 --> 00:36:52,890 I put this data in to this R. 794 00:36:52,890 --> 00:36:55,290 OK, now we need to solve for J. Because my proof is 795 00:36:55,290 --> 00:36:56,440 going to be J in this data. 796 00:36:56,440 --> 00:37:00,370 So I've got the data I want, and I want to figure out what J is. 797 00:37:00,370 --> 00:37:02,820 So J is the hash of this data. 798 00:37:02,820 --> 00:37:07,148 And J times G minus R-- oh, shoot. 799 00:37:07,148 --> 00:37:08,940 That would be the equation I have to solve, 800 00:37:08,940 --> 00:37:11,723 if I want to falsely prove that this data went into it. 801 00:37:11,723 --> 00:37:13,140 The problem is I've got this thing 802 00:37:13,140 --> 00:37:18,050 where it's like, J is defined in terms of the hash of J. 803 00:37:18,050 --> 00:37:20,840 That's going to be hard, right? 804 00:37:20,840 --> 00:37:22,775 If I'm defining J in terms of the hash of J, 805 00:37:22,775 --> 00:37:27,560 then I'm stuck, because hash functions don't let me do that. 806 00:37:27,560 --> 00:37:29,150 So this is actually kind of cool, 807 00:37:29,150 --> 00:37:32,810 because it's a proof that there was some extra data that 808 00:37:32,810 --> 00:37:37,550 went in to the random R point, before the signing happened. 809 00:37:40,688 --> 00:37:42,230 Yeah, it had to be before the signing 810 00:37:42,230 --> 00:37:44,320 happened, because the signature has R in it, 811 00:37:44,320 --> 00:37:48,522 and S is a function of R. 812 00:37:48,522 --> 00:37:49,230 And this is cool. 813 00:37:49,230 --> 00:37:50,970 Because if you don't know about it, 814 00:37:50,970 --> 00:37:53,640 it just looks like a regular signature with a regular R 815 00:37:53,640 --> 00:37:54,580 value. 816 00:37:54,580 --> 00:37:55,760 But if I tell you about it-- 817 00:37:55,760 --> 00:37:57,510 like, yeah, when I signed that, I actually 818 00:37:57,510 --> 00:37:59,940 put some extra data in here. 819 00:37:59,940 --> 00:38:02,640 So that's kind of better than OP_RETURN. 820 00:38:02,640 --> 00:38:03,990 There's 0 bytes overhead. 821 00:38:03,990 --> 00:38:07,410 You were going to sign anyway. 822 00:38:07,410 --> 00:38:09,840 So you can put data inside a signature's R point. 823 00:38:09,840 --> 00:38:13,260 You can even do it with other people's signatures. 824 00:38:13,260 --> 00:38:15,090 There's no real private information here. 825 00:38:15,090 --> 00:38:19,500 If I just hand you some data, it's totally safe. 826 00:38:19,500 --> 00:38:20,620 Hey, here's some data. 827 00:38:20,620 --> 00:38:24,960 OK, here's the J point, that constructs this, 828 00:38:24,960 --> 00:38:27,120 and the R. It's like, OK, sounds good. 829 00:38:27,120 --> 00:38:29,960 I can put someone else's data into this. 830 00:38:29,960 --> 00:38:31,350 You just hand them the data. 831 00:38:31,350 --> 00:38:34,710 They give you the proof, which in that case is just J. 832 00:38:34,710 --> 00:38:37,810 So it's OP_RETURN with 0 byte overhead. 833 00:38:37,810 --> 00:38:38,670 This is really cool. 834 00:38:38,670 --> 00:38:42,550 I believe this is being used for open timestamps 835 00:38:42,550 --> 00:38:44,520 now, as of a few-- 836 00:38:44,520 --> 00:38:45,605 I think, right? 837 00:38:45,605 --> 00:38:46,980 AUDIENCE: I wasn't aware of that. 838 00:38:46,980 --> 00:38:48,480 TADGE DRYJA: I think they got it in. 839 00:38:48,480 --> 00:38:49,260 I don't know. 840 00:38:49,260 --> 00:38:51,718 But it's also nice-- it's not like a soft fork or anything. 841 00:38:51,718 --> 00:38:54,540 This is just a fun trick you can do with your signatures. 842 00:38:54,540 --> 00:38:57,480 So you could do this today if you wanted, 843 00:38:57,480 --> 00:38:59,430 and then prove to people later, that, hey, I 844 00:38:59,430 --> 00:39:02,765 put my name into my signature. 845 00:39:02,765 --> 00:39:06,520 AUDIENCE: [INAUDIBLE] the hash, wouldn't proving one 846 00:39:06,520 --> 00:39:09,028 essentially refer to all in the batch stuff? 847 00:39:11,173 --> 00:39:13,590 TADGE DRYJA: This is direct replacement for the OP_RETURN. 848 00:39:13,590 --> 00:39:16,780 You commit to the root. 849 00:39:16,780 --> 00:39:21,770 And in their case, this data is a Merkle root. 850 00:39:21,770 --> 00:39:23,480 And then you can improve. 851 00:39:23,480 --> 00:39:26,630 So you can put a Merkle root here. 852 00:39:26,630 --> 00:39:28,460 And then I prove that there's a Merkle root 853 00:39:28,460 --> 00:39:29,400 inside my signature. 854 00:39:29,400 --> 00:39:33,110 And then I also prove a branch, so that the data 855 00:39:33,110 --> 00:39:35,600 is in the Merkle root, which is then in the R point-- which 856 00:39:35,600 --> 00:39:38,330 is in the signature, which is in the block's Merkle tree, which 857 00:39:38,330 --> 00:39:39,530 is in the blockchain. 858 00:39:39,530 --> 00:39:42,920 So you've got, like, four or five different proofs going on, 859 00:39:42,920 --> 00:39:45,240 but they should all be working. 860 00:39:45,240 --> 00:39:49,130 OK, so this is kind of cool. 861 00:39:49,130 --> 00:39:53,000 Any idea why I was explaining all this in terms of MAST 862 00:39:53,000 --> 00:39:54,350 and multisig? 863 00:39:54,350 --> 00:39:58,100 These seem totally unconnected, right? 864 00:39:58,100 --> 00:39:58,640 Any idea? 865 00:40:03,220 --> 00:40:06,340 It took Bitcoin people like well over a year 866 00:40:06,340 --> 00:40:09,760 to see the, in retrospect, really obvious connection, 867 00:40:09,760 --> 00:40:12,950 and thing to do with this. 868 00:40:12,950 --> 00:40:14,780 But it took a year or two. 869 00:40:14,780 --> 00:40:18,380 And then Greg posted on the mailing list in January-- 870 00:40:18,380 --> 00:40:21,680 like, hey wait, you can use this for something else. 871 00:40:21,680 --> 00:40:26,330 And then it was like, oh shoot, how did no one think of that? 872 00:40:26,330 --> 00:40:29,750 So it's called taproot, and I don't 873 00:40:29,750 --> 00:40:31,250 know why Greg called it that. 874 00:40:31,250 --> 00:40:33,560 Greg Maxwell, he's a guy with a big beard, 875 00:40:33,560 --> 00:40:34,460 who works on Bitcoin. 876 00:40:34,460 --> 00:40:37,160 He's super smart and stuff. 877 00:40:37,160 --> 00:40:40,340 And it uses this pay to contract hash construction. 878 00:40:40,340 --> 00:40:42,710 And it's the same equation, but it took us a year 879 00:40:42,710 --> 00:40:45,320 or two to figure out that you could do this. 880 00:40:45,320 --> 00:40:50,990 So the motivation here is pay to pubkey hash and pay 881 00:40:50,990 --> 00:40:53,833 to script hash look different. 882 00:40:53,833 --> 00:40:55,500 You can tell just looking at the output, 883 00:40:55,500 --> 00:40:58,223 these are totally different output scripts. 884 00:40:58,223 --> 00:40:59,640 One of them has got a pubkey hash. 885 00:40:59,640 --> 00:41:01,700 One of them has got a script hash. 886 00:41:01,700 --> 00:41:02,518 Different is bad. 887 00:41:02,518 --> 00:41:04,310 We don't want everything to look different. 888 00:41:04,310 --> 00:41:06,350 Then, you can sort of sort things. 889 00:41:06,350 --> 00:41:09,362 You can try to differentiate, try to track people's coins, 890 00:41:09,362 --> 00:41:10,070 things like that. 891 00:41:10,070 --> 00:41:15,170 You want it to all look uniform, to make it more anonymous. 892 00:41:15,170 --> 00:41:17,140 So one thing you could do is just use pay 893 00:41:17,140 --> 00:41:18,740 to script for everything. 894 00:41:18,740 --> 00:41:20,930 You can put a pubkey single-- 895 00:41:20,930 --> 00:41:27,460 essentially, 1 of 1 multisig, or just pay to pubkey hash script 896 00:41:27,460 --> 00:41:31,040 in pay to script hash. 897 00:41:31,040 --> 00:41:32,320 You wouldn't do that. 898 00:41:32,320 --> 00:41:36,330 You'd have that you'd have the direct pay to pubkey put 899 00:41:36,330 --> 00:41:37,890 into a script hash. 900 00:41:37,890 --> 00:41:39,670 So that like it looks like a script hash, 901 00:41:39,670 --> 00:41:43,090 and then the script is public key OP_CHECKSIG. 902 00:41:43,090 --> 00:41:45,460 It's actually not really any overhead. 903 00:41:45,460 --> 00:41:49,850 I think you actually save a byte or two. 904 00:41:49,850 --> 00:41:51,210 Nobody does that. 905 00:41:51,210 --> 00:41:53,435 You could. 906 00:41:53,435 --> 00:41:57,072 That might solve like 80% of what this is trying to solve. 907 00:41:57,072 --> 00:41:59,280 But it's kind of boring and doesn't use cool math, so 908 00:41:59,280 --> 00:42:01,140 anyway. 909 00:42:01,140 --> 00:42:06,930 OK, the other observation is that in most cases scripts-- 910 00:42:06,930 --> 00:42:08,340 you have these sort of scripts. 911 00:42:08,340 --> 00:42:12,780 And there's a hidden option, which is, or everyone signs. 912 00:42:12,780 --> 00:42:15,480 So in the case of 2 of 50 multisig-- well, 913 00:42:15,480 --> 00:42:18,750 if all 50 people sign, that's OK, right? 914 00:42:18,750 --> 00:42:20,020 That's no worse. 915 00:42:20,020 --> 00:42:23,660 So if it's 25 of 50 multisig, if all 50 people happen to sign, 916 00:42:23,660 --> 00:42:28,110 sure, that's no loss of security there. 917 00:42:28,110 --> 00:42:31,745 The idea is you use this pay to script, 918 00:42:31,745 --> 00:42:33,120 pay to contract hash construction 919 00:42:33,120 --> 00:42:36,480 to merge pay to pubkey hash and pay to script hash, 920 00:42:36,480 --> 00:42:38,565 so that a single output can do both. 921 00:42:38,565 --> 00:42:42,210 The idea is you make a key, J, and J is an actual key. 922 00:42:42,210 --> 00:42:44,160 Like, you have the private key for it. 923 00:42:44,160 --> 00:42:45,810 It's a regular old pubkey. 924 00:42:45,810 --> 00:42:48,470 And you have a script z. 925 00:42:48,470 --> 00:42:51,680 And instead of sending either to the script 926 00:42:51,680 --> 00:42:53,690 z, in a pay to script hash construction, 927 00:42:53,690 --> 00:42:58,050 or to hash this key J inside the pubkey hash, 928 00:42:58,050 --> 00:42:59,780 you say, I'm going to compute key C-- 929 00:42:59,780 --> 00:43:05,190 which is J plus the hash of my script, concatenated with J, 930 00:43:05,190 --> 00:43:06,620 times G. 931 00:43:06,620 --> 00:43:10,190 So this is the same as the thing I just 932 00:43:10,190 --> 00:43:13,160 did with the OP_RETURN and 0 bytes, right? 933 00:43:13,160 --> 00:43:14,380 And then I send money to it. 934 00:43:17,030 --> 00:43:18,960 And then, what do I do? 935 00:43:18,960 --> 00:43:22,120 I've sent money to this C point. 936 00:43:22,120 --> 00:43:25,780 Can I sign with C's private key? 937 00:43:31,270 --> 00:43:34,160 I know I know a little j. 938 00:43:34,160 --> 00:43:35,180 That's a regular key. 939 00:43:35,180 --> 00:43:36,470 Do I know a little c? 940 00:43:41,170 --> 00:43:44,660 Sure, yeah. 941 00:43:44,660 --> 00:43:48,950 I know that little c is just the j private key plus this hash. 942 00:43:53,820 --> 00:43:57,960 So if I want to treat it as a pay to pubkey hash, I just 943 00:43:57,960 --> 00:43:58,880 sign with little c. 944 00:43:58,880 --> 00:44:00,960 I sign my transaction and I'm good. 945 00:44:00,960 --> 00:44:03,420 Nobody has to know that I did this. 946 00:44:03,420 --> 00:44:06,780 However, if I want to make it into pay to script hash, 947 00:44:06,780 --> 00:44:13,800 I reveal the script z and the subkey J. 948 00:44:13,800 --> 00:44:17,890 And then I put some arguments on, and then run the script. 949 00:44:17,890 --> 00:44:21,210 So if I don't want to show that there was a script, 950 00:44:21,210 --> 00:44:23,820 I don't have to. 951 00:44:23,820 --> 00:44:25,540 I just sign with this. 952 00:44:25,540 --> 00:44:26,770 Private key's that. 953 00:44:26,770 --> 00:44:29,320 Nobody knows that there was a script at all. 954 00:44:29,320 --> 00:44:33,010 So if everyone's using this, 80% of the time that's what 955 00:44:33,010 --> 00:44:33,993 happens. 956 00:44:33,993 --> 00:44:35,410 Maybe there was a script in there. 957 00:44:35,410 --> 00:44:36,470 Maybe there wasn't. 958 00:44:36,470 --> 00:44:38,530 Can't tell, right? 959 00:44:38,530 --> 00:44:40,930 However, if I want to reveal, hey, actually this time, 960 00:44:40,930 --> 00:44:42,280 I'm using the script. 961 00:44:42,280 --> 00:44:46,030 So I revealed J and z. 962 00:44:46,030 --> 00:44:50,750 Everyone computes-- OK, well, if I add J 963 00:44:50,750 --> 00:44:54,020 to the hash of z and J times g, does that equal 964 00:44:54,020 --> 00:44:57,410 c-- the key that is in the output script itself? 965 00:44:57,410 --> 00:44:59,990 And if it does, cool, that was a valid proof 966 00:44:59,990 --> 00:45:02,810 that you actually committed to z. 967 00:45:02,810 --> 00:45:06,480 And now I run the script z. 968 00:45:06,480 --> 00:45:07,710 Any questions about this? 969 00:45:07,710 --> 00:45:09,400 Make sense? 970 00:45:09,400 --> 00:45:10,710 So it's actually pretty simple. 971 00:45:10,710 --> 00:45:15,170 It follows directly from the proofs, from the contract hash. 972 00:45:15,170 --> 00:45:19,131 And it's really cool because-- 973 00:45:19,131 --> 00:45:22,180 oh, P. I thought I was doing C. Oops. 974 00:45:22,180 --> 00:45:22,920 Anyway. 975 00:45:22,920 --> 00:45:24,337 So what you can do is you can make 976 00:45:24,337 --> 00:45:26,970 the sum of everyone's keys. 977 00:45:26,970 --> 00:45:29,070 And so in Schnoor signatures we can do this, 978 00:45:29,070 --> 00:45:31,117 and we can sign without revealing 979 00:45:31,117 --> 00:45:32,200 each other's private keys. 980 00:45:32,200 --> 00:45:34,470 So you can say, OK, what I'm going 981 00:45:34,470 --> 00:45:40,560 to do is J is the sum of, like, 50 different pubkeys. 982 00:45:40,560 --> 00:45:47,880 And then z is that Merkle tree of 2 of 50 signatures. 983 00:45:47,880 --> 00:45:51,007 So if I want to use 2 of 50, I have to reveal, 984 00:45:51,007 --> 00:45:52,340 and then I have to do the proof. 985 00:45:52,340 --> 00:45:55,130 But if I can get all 50 of 50 people to sign, 986 00:45:55,130 --> 00:45:58,810 they can produce a signature with private key little C. 987 00:45:58,810 --> 00:46:02,560 So when everyone's cooperating, you 988 00:46:02,560 --> 00:46:06,815 don't even see that there was a script involved. 989 00:46:06,815 --> 00:46:08,440 And you can do this Schnoor signatures. 990 00:46:08,440 --> 00:46:10,180 You cannot do this with ECDSA. 991 00:46:10,180 --> 00:46:16,000 So probably this would be put into Bitcoin 992 00:46:16,000 --> 00:46:20,415 alongside a Schnoor signature kind of construction. 993 00:46:20,415 --> 00:46:21,790 This seems useful because in most 994 00:46:21,790 --> 00:46:24,850 cases, most smart contracts, most multisig 995 00:46:24,850 --> 00:46:27,610 does have sort of an all-participants-sign clause. 996 00:46:27,610 --> 00:46:30,340 Even if we don't code it in right now, 997 00:46:30,340 --> 00:46:31,390 it's generally the case. 998 00:46:31,390 --> 00:46:34,300 Like, 2 of 3 multisig-- well, 3 of 3 is good. 999 00:46:34,300 --> 00:46:36,490 And if you do 3 of 3, hey, you don't even 1000 00:46:36,490 --> 00:46:38,920 see that there was 2 of 3. 1001 00:46:38,920 --> 00:46:40,330 And so that preserves privacy. 1002 00:46:40,330 --> 00:46:41,710 It saves space. 1003 00:46:41,710 --> 00:46:47,110 And most of the time all the participants can be online. 1004 00:46:47,110 --> 00:46:51,340 So that's the same basic idea as in lightning. 1005 00:46:51,340 --> 00:46:53,165 If everyone's co-operative, you don't even 1006 00:46:53,165 --> 00:46:54,790 see that there was a lightning channel. 1007 00:46:54,790 --> 00:46:58,750 You just together broadcast a transaction with just 2 1008 00:46:58,750 --> 00:46:59,970 of 2 multisig. 1009 00:46:59,970 --> 00:47:02,680 But in lightning, you do see that there was 2 of 2 multisig. 1010 00:47:02,680 --> 00:47:04,330 So you can sort of see, oh, it was 1011 00:47:04,330 --> 00:47:06,580 either a channel or a multisig. 1012 00:47:06,580 --> 00:47:08,080 But in this kind of construction, 1013 00:47:08,080 --> 00:47:09,350 you wouldn't even show that. 1014 00:47:09,350 --> 00:47:11,350 You'd say, OK, this is actually 2 of 2 multisig, 1015 00:47:11,350 --> 00:47:13,300 but we can merge them. 1016 00:47:16,520 --> 00:47:19,550 Oh, other weird trick-- 1017 00:47:19,550 --> 00:47:22,130 you can make a public key, and prove that there 1018 00:47:22,130 --> 00:47:24,620 is no known private key. 1019 00:47:24,620 --> 00:47:29,240 So what if I only want this script z, 1020 00:47:29,240 --> 00:47:32,810 and there is no set of everyone signing? 1021 00:47:32,810 --> 00:47:34,430 I don't want that to be a requirement. 1022 00:47:34,430 --> 00:47:37,280 What if I only want the script hash? 1023 00:47:37,280 --> 00:47:38,600 I can do that. 1024 00:47:38,600 --> 00:47:41,930 Interactively, I can use someone else's J. 1025 00:47:41,930 --> 00:47:45,340 If I'm sending you a script that involves someone else, 1026 00:47:45,340 --> 00:47:48,200 I say, hey, can you come up with a key J? 1027 00:47:48,200 --> 00:47:50,180 I'm going to compute a key C, that's 1028 00:47:50,180 --> 00:47:55,210 J plus the hash of the script comma J times G. 1029 00:47:55,210 --> 00:47:57,593 And then I can prove that to you after the fact. 1030 00:47:57,593 --> 00:47:59,510 And you can say, OK, well, I know it's my key. 1031 00:47:59,510 --> 00:48:02,600 So interactive, I can show that it's someone else's key. 1032 00:48:02,600 --> 00:48:04,820 Non-interactive, I can just say, look, 1033 00:48:04,820 --> 00:48:09,550 I know the pre-image of the x-coordinate of J. 1034 00:48:09,550 --> 00:48:12,790 So basically, I can prove to you that there's 1035 00:48:12,790 --> 00:48:15,370 no way I came up with this point on the curve 1036 00:48:15,370 --> 00:48:18,340 in the normal multiply by G way. 1037 00:48:18,340 --> 00:48:24,190 Because that sort of shows that I came up with the x-coordinate 1038 00:48:24,190 --> 00:48:26,920 by just hashing a random number-- 1039 00:48:26,920 --> 00:48:29,500 or a non-random number, if it's the hash of 0, 1040 00:48:29,500 --> 00:48:31,960 or if it's the hash of anything. 1041 00:48:31,960 --> 00:48:35,530 The idea is I randomly picked an x-coordinate 1042 00:48:35,530 --> 00:48:38,523 on this curve, figured out what the y-coordinate was, 1043 00:48:38,523 --> 00:48:39,940 turned that into a point, and then 1044 00:48:39,940 --> 00:48:41,920 used it in this construction. 1045 00:48:41,920 --> 00:48:43,720 If I do that, you can be pretty sure 1046 00:48:43,720 --> 00:48:45,850 that I don't know the private key for J, 1047 00:48:45,850 --> 00:48:50,040 because I didn't compute it the right way. 1048 00:48:50,040 --> 00:48:52,200 Does that make sense? 1049 00:48:52,200 --> 00:48:54,840 So you can do that. 1050 00:48:54,840 --> 00:48:58,310 That's a way to then prove to other people 1051 00:48:58,310 --> 00:49:01,548 like there is no J. It's a point on the curve, 1052 00:49:01,548 --> 00:49:03,090 but it's a random point on the curve. 1053 00:49:03,090 --> 00:49:05,640 So there's no way I can sign with c. 1054 00:49:10,490 --> 00:49:11,810 I sent the pubkey c. 1055 00:49:11,810 --> 00:49:13,640 And I proved to you, look, C is not a key 1056 00:49:13,640 --> 00:49:15,650 that anyone can sign with. 1057 00:49:15,650 --> 00:49:18,800 However, there is a point J, and there's a script z, 1058 00:49:18,800 --> 00:49:21,180 and you can execute the script. 1059 00:49:21,180 --> 00:49:23,460 So that's useful in many cases, where 1060 00:49:23,460 --> 00:49:25,465 you want to prove to people that, look, 1061 00:49:25,465 --> 00:49:26,340 there is no key here. 1062 00:49:26,340 --> 00:49:28,620 It's just a script. 1063 00:49:28,620 --> 00:49:31,727 And then everyone will find out later when you spend it. 1064 00:49:31,727 --> 00:49:33,810 But they don't have to know that there was no key. 1065 00:49:33,810 --> 00:49:35,940 They just know that the script got executed. 1066 00:49:35,940 --> 00:49:41,640 So that's a nice sort of patch, where you can default. 1067 00:49:41,640 --> 00:49:44,760 If there's any use cases where in the current script hash 1068 00:49:44,760 --> 00:49:47,040 you want that exact same functionality 1069 00:49:47,040 --> 00:49:48,990 and you don't want this new functionality, 1070 00:49:48,990 --> 00:49:50,615 you can sort of get rid of it this way. 1071 00:49:55,070 --> 00:49:58,490 AUDIENCE: So the idea of [INAUDIBLE] 1072 00:49:58,490 --> 00:50:03,950 is that you are trying to make your special transaction 1073 00:50:03,950 --> 00:50:05,810 scripts not stand out [INAUDIBLE].. 1074 00:50:05,810 --> 00:50:10,968 The fear is that people will see those and not put them 1075 00:50:10,968 --> 00:50:12,510 into blocks, or not [INAUDIBLE] them, 1076 00:50:12,510 --> 00:50:14,513 or discriminate against them? 1077 00:50:14,513 --> 00:50:15,680 TADGE DRYJA: Maybe a little. 1078 00:50:15,680 --> 00:50:19,310 But it's more that-- 1079 00:50:19,310 --> 00:50:20,870 let's say I have my wallet software, 1080 00:50:20,870 --> 00:50:24,680 and it always uses to P2WSH, P2SH, or something. 1081 00:50:24,680 --> 00:50:27,230 Then I can say, oh, I bet this is the same person. 1082 00:50:27,230 --> 00:50:29,310 I can try to track who is spending them. 1083 00:50:29,310 --> 00:50:30,227 AUDIENCE: [INAUDIBLE]. 1084 00:50:30,227 --> 00:50:32,390 TADGE DRYJA: Yeah, a big part of it is privacy. 1085 00:50:32,390 --> 00:50:36,530 Maybe they're discriminated against them like miners. 1086 00:50:36,530 --> 00:50:38,450 Probably, the miners don't care. 1087 00:50:38,450 --> 00:50:41,360 But it's more like if everyone's using software 1088 00:50:41,360 --> 00:50:43,650 that can create similar transactions, 1089 00:50:43,650 --> 00:50:46,580 then it becomes much harder to tell people apart, 1090 00:50:46,580 --> 00:50:49,100 and it has more privacy for the transactions. 1091 00:50:49,100 --> 00:50:53,670 AUDIENCE: Then this one, you're putting in a script 1092 00:50:53,670 --> 00:50:57,190 that can anybody can potentially execute it, 1093 00:50:57,190 --> 00:50:59,000 but they don't know that they can? 1094 00:51:01,173 --> 00:51:03,090 TADGE DRYJA: They need to know both the script 1095 00:51:03,090 --> 00:51:06,790 and J, which is not obvious from C. C 1096 00:51:06,790 --> 00:51:09,870 is the only thing you see on the blockchain, in the output. 1097 00:51:09,870 --> 00:51:11,790 And so they just said, it's a key-- 1098 00:51:11,790 --> 00:51:14,280 probably, someone knows the private key. 1099 00:51:14,280 --> 00:51:17,230 Maybe there's some weird thing like this going on. 1100 00:51:17,230 --> 00:51:19,740 You don't have to use this, right? 1101 00:51:19,740 --> 00:51:24,051 And then, yeah, so they won't know what J or z are. 1102 00:51:24,051 --> 00:51:26,280 AUDIENCE: Still you're [INAUDIBLE].. 1103 00:51:26,280 --> 00:51:27,030 TADGE DRYJA: Yeah. 1104 00:51:27,030 --> 00:51:32,010 You can publicly publish it, if you want-- 1105 00:51:32,010 --> 00:51:34,230 and tell everyone in the world, hey, this C 1106 00:51:34,230 --> 00:51:36,810 is actually this J plus this script z. 1107 00:51:36,810 --> 00:51:38,640 They still can't spend it. 1108 00:51:38,640 --> 00:51:41,820 That can be public, even beforehand. 1109 00:51:41,820 --> 00:51:44,310 And then they see, oh, there's a script and a key. 1110 00:51:44,310 --> 00:51:47,040 And you can also, say, sign something, and prove 1111 00:51:47,040 --> 00:51:51,070 that you know the private key for J. So you can say, 1112 00:51:51,070 --> 00:51:54,310 I can prove that I'm not doing this-- 1113 00:51:54,310 --> 00:51:57,220 there is no J kind of thing. 1114 00:51:57,220 --> 00:52:00,940 So you can prove all those things, but you don't need to. 1115 00:52:00,940 --> 00:52:04,810 For normal usage, you just send a key C, spend from key C. 1116 00:52:04,810 --> 00:52:06,010 You're done. 1117 00:52:06,010 --> 00:52:09,410 And if you want to spend from the script z, 1118 00:52:09,410 --> 00:52:14,020 you just provide J, the script , and then execute the script. 1119 00:52:14,020 --> 00:52:14,830 So it's nice. 1120 00:52:14,830 --> 00:52:18,985 And you might have had a script, and then you didn't use it, 1121 00:52:18,985 --> 00:52:20,860 so you didn't reveal that there was a script. 1122 00:52:23,400 --> 00:52:25,230 So it helps with privacy. 1123 00:52:25,230 --> 00:52:26,940 It helps with efficiency in many cases, 1124 00:52:26,940 --> 00:52:31,710 because if you don't need to use a script, you don't have to. 1125 00:52:31,710 --> 00:52:36,390 So in a lot of cases you say, all three of the 2 of 3 1126 00:52:36,390 --> 00:52:39,570 multisigs are on board, so let's use C instead of the script z. 1127 00:52:43,090 --> 00:52:44,810 So it's pretty cool. 1128 00:52:44,810 --> 00:52:47,020 OK, so questions about this? 1129 00:52:47,020 --> 00:52:49,460 Go to the next crazy thing. 1130 00:52:52,830 --> 00:52:54,480 Little notes about taproot-- anyone 1131 00:52:54,480 --> 00:52:56,760 can make a key and script and send to it. 1132 00:52:56,760 --> 00:52:58,410 Only the pubkeys are needed. 1133 00:52:58,410 --> 00:53:03,680 So if I want to send to something that's 3 of 3-- 1134 00:53:03,680 --> 00:53:06,530 Alice, Bob, and Carol added all together-- 1135 00:53:06,530 --> 00:53:10,010 or 2 of the 3 of Alice, and Bob, and Carol-- 1136 00:53:10,010 --> 00:53:12,710 I don't have to even ask Alice, Bob, and Carol. 1137 00:53:12,710 --> 00:53:14,810 If I know they're public keys, I can just 1138 00:53:14,810 --> 00:53:19,600 compute all this myself, and send money to them. 1139 00:53:19,600 --> 00:53:21,350 And I can compute any construction I want. 1140 00:53:21,350 --> 00:53:24,830 I can make it 1 of 3. 1141 00:53:24,830 --> 00:53:29,252 I know Alice, Bob, and Carol's public keys. 1142 00:53:29,252 --> 00:53:30,960 And I can say, hey Alice, Bob, and Carol, 1143 00:53:30,960 --> 00:53:33,510 I'm giving you all money, and you can fight over it-- 1144 00:53:33,510 --> 00:53:34,620 or you can cooperate. 1145 00:53:34,620 --> 00:53:36,060 Like, any of you get it. 1146 00:53:36,060 --> 00:53:39,540 And so the idea is 1 of 3 multisig script goes into here, 1147 00:53:39,540 --> 00:53:42,250 and then 3 of 3 is here. 1148 00:53:42,250 --> 00:53:45,590 So if you cooperate, you save a little bit of space, 1149 00:53:45,590 --> 00:53:47,200 and the fees are smaller. 1150 00:53:47,200 --> 00:53:50,208 But if you don't cooperate, any of you can grab it immediately. 1151 00:53:50,208 --> 00:53:52,500 I don't know how useful that is, but you could do this. 1152 00:53:52,500 --> 00:53:55,290 You don't need knowledge of any private keys 1153 00:53:55,290 --> 00:54:00,520 to construct C. Only the pubkeys are needed. 1154 00:54:00,520 --> 00:54:04,560 That's actually really nice, because you're creating. 1155 00:54:04,560 --> 00:54:07,770 So the same is currently the case in Bitcoin. 1156 00:54:07,770 --> 00:54:09,740 If you're creating an output script, like pay 1157 00:54:09,740 --> 00:54:12,150 to pubkey hash, pay to script hash, 1158 00:54:12,150 --> 00:54:15,060 there's no private keys involved in that process. 1159 00:54:15,060 --> 00:54:16,410 You just tell everyone. 1160 00:54:16,410 --> 00:54:19,500 OK, which differs, and is the important distinction 1161 00:54:19,500 --> 00:54:23,220 between the next cool thing, which is graftroot-- 1162 00:54:23,220 --> 00:54:28,313 also Greg Maxwell, like a week or two after taproot. 1163 00:54:28,313 --> 00:54:29,730 They're not actually that similar. 1164 00:54:29,730 --> 00:54:31,170 But it was like, wait-- 1165 00:54:31,170 --> 00:54:33,040 people were sort of talking about it. 1166 00:54:33,040 --> 00:54:35,610 So the idea is allow a lot of scripts 1167 00:54:35,610 --> 00:54:40,790 with a proof that goes up in size with 0 of 1-- aka 1168 00:54:40,790 --> 00:54:42,510 it doesn't go up in size. 1169 00:54:42,510 --> 00:54:44,850 So the Merkle proofs-- the MAST-- 1170 00:54:44,850 --> 00:54:46,140 go in log n. 1171 00:54:46,140 --> 00:54:50,660 So if you've got a million different scripts, 1172 00:54:50,660 --> 00:54:53,600 you're going to take something like 20 hashes 1173 00:54:53,600 --> 00:54:55,730 or whatever to prove that. 1174 00:54:55,730 --> 00:54:59,553 What's a proof that grows in 0 of 1 of the number of things 1175 00:54:59,553 --> 00:55:00,095 being proven? 1176 00:55:03,210 --> 00:55:06,660 It's actually not-- it's kind of obvious. 1177 00:55:06,660 --> 00:55:13,460 Like, I want to prove something, and the proof size 1178 00:55:13,460 --> 00:55:17,400 does not change regardless of how many things I am proving. 1179 00:55:17,400 --> 00:55:19,340 Well, it's just a signature. 1180 00:55:19,340 --> 00:55:21,990 If I make a million signatures, they're all the same size. 1181 00:55:21,990 --> 00:55:24,740 So I could, instead of making a Merkle route, 1182 00:55:24,740 --> 00:55:26,810 I just have all these little leaves. 1183 00:55:26,810 --> 00:55:28,160 And I just sign them all. 1184 00:55:28,160 --> 00:55:33,720 And a leaf with a signature is just as good. 1185 00:55:33,720 --> 00:55:36,750 So the idea is this is called graftroot. 1186 00:55:36,750 --> 00:55:42,240 It's similar to taproot in that it's got sort of two execution 1187 00:55:42,240 --> 00:55:43,320 paths. 1188 00:55:43,320 --> 00:55:47,310 You send to a key C, and there's two ways to spend from it. 1189 00:55:47,310 --> 00:55:49,830 So you can use the regular pay to pubkey hash 1190 00:55:49,830 --> 00:55:51,810 mode, where you're just spending from C. 1191 00:55:51,810 --> 00:55:55,650 You just sign with key C, your transaction-- 1192 00:55:55,650 --> 00:55:59,280 same as in taproot, same as in regular Bitcoin right now. 1193 00:55:59,280 --> 00:56:00,550 That's the easy one. 1194 00:56:00,550 --> 00:56:04,080 The script version is I show a script s, 1195 00:56:04,080 --> 00:56:08,040 and a signature from key C on the message 1196 00:56:08,040 --> 00:56:12,530 s, and then I execute that script. 1197 00:56:12,530 --> 00:56:14,830 So this is kind of cool, right? 1198 00:56:14,830 --> 00:56:18,610 You say, look, I'm sending you a key, and either that key 1199 00:56:18,610 --> 00:56:22,450 itself signs or that key endorses a script 1200 00:56:22,450 --> 00:56:26,370 to be executed. 1201 00:56:26,370 --> 00:56:29,030 And I can make as many of these as I want. 1202 00:56:29,030 --> 00:56:32,900 So if I want 1,000 different scripts, 1203 00:56:32,900 --> 00:56:35,870 it's not like I have to prove inclusion in the three-- 1204 00:56:35,870 --> 00:56:39,260 that's going to be height 22, or height 12, or whatever-- 1205 00:56:39,260 --> 00:56:42,620 I just have a signature, saying, OK, key C 1206 00:56:42,620 --> 00:56:44,900 signed this to a 50 multisig. 1207 00:56:44,900 --> 00:56:49,730 Key C also signed the other two of 50 multisig. 1208 00:56:49,730 --> 00:56:51,770 So the one that I'm actually using, 1209 00:56:51,770 --> 00:56:53,390 I just provide the proof. 1210 00:56:53,390 --> 00:56:56,640 The proof of inclusion is just a signature. 1211 00:56:56,640 --> 00:56:57,700 Questions about this? 1212 00:56:57,700 --> 00:56:58,877 Makes sense? 1213 00:56:58,877 --> 00:56:59,460 Kind of weird? 1214 00:57:02,055 --> 00:57:02,555 It works. 1215 00:57:06,990 --> 00:57:11,880 The real problem is there is this key C, right? 1216 00:57:11,880 --> 00:57:18,700 So there's this sort of root key that controls the whole thing. 1217 00:57:18,700 --> 00:57:22,980 The idea is key C endorses all the different leaves. 1218 00:57:22,980 --> 00:57:25,830 So in the case of MAST you've got, 1219 00:57:25,830 --> 00:57:28,950 let's say, four different scripts that can execute. 1220 00:57:28,950 --> 00:57:33,180 All four of those are committed to by the Merkle root. 1221 00:57:33,180 --> 00:57:34,860 In the case of graftroot, let's say 1222 00:57:34,860 --> 00:57:36,330 you have four different scripts. 1223 00:57:36,330 --> 00:57:40,080 C signs all four of those different scripts. 1224 00:57:40,080 --> 00:57:41,970 The thing is, C can sign 10 scripts. 1225 00:57:41,970 --> 00:57:45,030 C has got total control over this output. 1226 00:57:45,030 --> 00:57:49,860 Whereas before, in the MAST idea, 1227 00:57:49,860 --> 00:57:51,120 it can be different people. 1228 00:57:51,120 --> 00:57:56,310 It could be Alice and Bob, Carol and Dave, Edna and Gertrude-- 1229 00:57:56,310 --> 00:57:57,660 I don't know. 1230 00:57:57,660 --> 00:57:59,460 And they might not be friends. 1231 00:57:59,460 --> 00:58:02,080 No single entity there has full control. 1232 00:58:02,080 --> 00:58:04,920 So the idea of this is, well, you 1233 00:58:04,920 --> 00:58:07,110 can combine a whole bunch of people. 1234 00:58:07,110 --> 00:58:10,050 The key C is essentially everyone, 1235 00:58:10,050 --> 00:58:13,380 and they all have to sign off on all the different scripts that 1236 00:58:13,380 --> 00:58:17,840 could happen, and then distribute 1237 00:58:17,840 --> 00:58:22,070 those signatures on those scripts, which are proofs. 1238 00:58:22,070 --> 00:58:26,870 OK, basic idea make sense? 1239 00:58:26,870 --> 00:58:28,420 This one's a little weirder. 1240 00:58:33,740 --> 00:58:40,280 In this one there is a way to prove that there is no key C. 1241 00:58:40,280 --> 00:58:42,410 So that's to sort of say, look, it's only 1242 00:58:42,410 --> 00:58:45,530 going to be this script, and no one's 1243 00:58:45,530 --> 00:58:48,810 going to sign in the normal just the key signs method. 1244 00:58:48,810 --> 00:58:52,370 There's also a way to do that here. 1245 00:58:52,370 --> 00:58:55,070 It's much less useful, though, because what you essentially do 1246 00:58:55,070 --> 00:58:59,800 is you start with your script, and then you 1247 00:58:59,800 --> 00:59:03,040 compute a signature on it-- 1248 00:59:03,040 --> 00:59:05,860 but you also prove that there was no private key that 1249 00:59:05,860 --> 00:59:08,260 made the signature. 1250 00:59:08,260 --> 00:59:09,340 You have time. 1251 00:59:09,340 --> 00:59:10,630 It's actually really fun. 1252 00:59:10,630 --> 00:59:12,790 What you do is-- 1253 00:59:12,790 --> 00:59:20,090 normally you say, OK, S equals k minus the hash of my message 1254 00:59:20,090 --> 00:59:22,810 and R times point a. 1255 00:59:22,810 --> 00:59:26,545 What if I want to prove to you that there is no a? 1256 00:59:30,010 --> 00:59:36,930 SG equals R minus the hash of message R times pubkey A. 1257 00:59:36,930 --> 00:59:40,267 I want to prove that I do not know that private key, 1258 00:59:40,267 --> 00:59:41,100 and nobody knows it. 1259 00:59:43,065 --> 00:59:46,080 Actually, I have to both. 1260 00:59:46,080 --> 00:59:51,960 I say, OK, I know the pre-image of the x-coordinate. 1261 00:59:51,960 --> 00:59:58,140 Same with R. Wait, can I do this? 1262 00:59:58,140 --> 00:59:59,800 I forget how this is going to work. 1263 00:59:59,800 --> 01:00:05,050 Anyway, basically what I do is I compute A public key randomly. 1264 01:00:05,050 --> 01:00:07,960 Or no, I first get the message I want to sign. 1265 01:00:07,960 --> 01:00:13,150 I make a random R, and I show that it's random-- 1266 01:00:13,150 --> 01:00:15,850 I know the pre-image of its coordinates, or something. 1267 01:00:15,850 --> 01:00:18,220 I can prove that I didn't construct this. 1268 01:00:18,220 --> 01:00:21,010 I don't know the private key. 1269 01:00:21,010 --> 01:00:26,400 And then I solve for A and S, essentially. 1270 01:00:26,400 --> 01:00:28,310 So I can show, look, I've got a signature, 1271 01:00:28,310 --> 01:00:30,020 but I can prove that no one signed. 1272 01:00:33,110 --> 01:00:36,080 I think I make a random s, and then I 1273 01:00:36,080 --> 01:00:45,560 solve for big A. I make a random s, multiply by G, solve for A. 1274 01:00:45,560 --> 01:00:51,410 So A divided by hash of m, R-- 1275 01:00:51,410 --> 01:00:53,340 wait, I can't do that, can I? 1276 01:00:53,340 --> 01:00:54,050 Yeah, I can. 1277 01:00:54,050 --> 01:01:07,160 This is [INAUDIBLE.] Equals R minus SG. 1278 01:01:07,160 --> 01:01:09,980 I come up with a random R, put it in here, 1279 01:01:09,980 --> 01:01:17,070 come up with the message I want to sign, and then solve for A. 1280 01:01:17,070 --> 01:01:19,470 So I can do that, and I can prove 1281 01:01:19,470 --> 01:01:25,450 that there was no real A, because 1282 01:01:25,450 --> 01:01:26,800 of the way I constructed it. 1283 01:01:26,800 --> 01:01:29,830 I know weird things about R and A. 1284 01:01:29,830 --> 01:01:34,137 And so I can show that this is not a real signature. 1285 01:01:34,137 --> 01:01:35,970 However, in this case, it's not that useful. 1286 01:01:35,970 --> 01:01:37,530 In the case of taproot, it's useful, 1287 01:01:37,530 --> 01:01:39,447 because I might want to prove to people, look, 1288 01:01:39,447 --> 01:01:40,560 this is just a script. 1289 01:01:40,560 --> 01:01:43,170 There is no key. 1290 01:01:43,170 --> 01:01:44,985 In this case, I can still do that. 1291 01:01:44,985 --> 01:01:46,360 I can say, there's just a script. 1292 01:01:46,360 --> 01:01:48,580 There is no key. 1293 01:01:48,580 --> 01:01:53,970 But then I can only do it once. 1294 01:01:53,970 --> 01:01:55,620 The whole idea of graftroot is I can 1295 01:01:55,620 --> 01:01:57,660 have a million different scripts, that 1296 01:01:57,660 --> 01:02:00,370 are all going into one key. 1297 01:02:00,370 --> 01:02:03,990 OK, so the problem is the root key must sign every script. 1298 01:02:03,990 --> 01:02:07,910 And now you need to use private keys to create an address. 1299 01:02:07,910 --> 01:02:10,670 That's not great, right? 1300 01:02:10,670 --> 01:02:16,920 It's maybe OK, but you haven't had to do that before. 1301 01:02:16,920 --> 01:02:19,920 So now we have to sign off on every script 1302 01:02:19,920 --> 01:02:23,160 that we're endorsing, in order to compute an address. 1303 01:02:23,160 --> 01:02:24,810 You can do this after the fact, though. 1304 01:02:24,810 --> 01:02:26,935 So that's kind of the interesting thing about this, 1305 01:02:26,935 --> 01:02:29,910 is you can say, OK, I'm sending the key C-- which 1306 01:02:29,910 --> 01:02:33,090 is this root key, that's all 50 participants. 1307 01:02:33,090 --> 01:02:34,590 And then after the fact-- after it's 1308 01:02:34,590 --> 01:02:37,170 gone been confirmed in the blockchain-- those 50 1309 01:02:37,170 --> 01:02:41,852 participants can say, actually, you know what, 2 of 50 is good. 1310 01:02:41,852 --> 01:02:43,560 We're not suspending the money right now. 1311 01:02:43,560 --> 01:02:46,140 But we're all agreeing that, yeah, any two of us 1312 01:02:46,140 --> 01:02:47,770 can spend this money later. 1313 01:02:47,770 --> 01:02:50,940 And so they all get together, and all 50 sign with the root 1314 01:02:50,940 --> 01:02:56,040 key C all the different scripts-- those 1,225 scripts-- 1315 01:02:56,040 --> 01:02:57,510 and then hand those signatures out 1316 01:02:57,510 --> 01:03:01,530 to the respective people who would be 1317 01:03:01,530 --> 01:03:02,790 interested in that signature. 1318 01:03:02,790 --> 01:03:05,160 So, oh, Alice and Bob, if you want to spend the money, 1319 01:03:05,160 --> 01:03:08,170 we all made a signature endorsing your 2 of 2, 1320 01:03:08,170 --> 01:03:09,480 2 of 50-- 1321 01:03:09,480 --> 01:03:10,680 your two keys. 1322 01:03:10,680 --> 01:03:12,930 And Bob and Carol, if you two want to spend the money, 1323 01:03:12,930 --> 01:03:17,160 we've made a script that's endorsed by us saying, 1324 01:03:17,160 --> 01:03:18,642 your two keys can spend it. 1325 01:03:18,642 --> 01:03:19,350 It's really cool. 1326 01:03:19,350 --> 01:03:21,040 The overhead is one signature. 1327 01:03:21,040 --> 01:03:25,320 So you can have that like 100 trillion different-- 1328 01:03:25,320 --> 01:03:27,850 50 choose 25, which is 100 trillion. 1329 01:03:27,850 --> 01:03:30,360 Well, you've got to sign 100 trillion times, 1330 01:03:30,360 --> 01:03:32,700 but when you spend from it, it's small. 1331 01:03:32,700 --> 01:03:37,130 It's an extra 33 bytes of overhead. 1332 01:03:37,130 --> 01:03:38,880 Yeah, the overhead is just a signature. 1333 01:03:38,880 --> 01:03:41,255 So you say, OK, here's key C. Here's a signature from it. 1334 01:03:41,255 --> 01:03:44,020 Here's the script, to endorse the script being executed. 1335 01:03:44,020 --> 01:03:45,240 It's not actually 64 bytes. 1336 01:03:45,240 --> 01:03:48,900 You can get the overhead into 33 bytes, 1337 01:03:48,900 --> 01:03:53,610 because you can aggregate the S values of the signature. 1338 01:03:53,610 --> 01:03:56,528 I'll talk about this on Wednesday. 1339 01:03:56,528 --> 01:03:58,320 I don't think I actually came up with this, 1340 01:03:58,320 --> 01:04:00,060 but Greg cites me on it, and it's 1341 01:04:00,060 --> 01:04:02,940 like, I guess no one thought of this. 1342 01:04:02,940 --> 01:04:05,850 But there's a non-interactive partial aggregation 1343 01:04:05,850 --> 01:04:08,580 of these things, which I was really 1344 01:04:08,580 --> 01:04:10,950 hoping would get into Bitcoin itself, 1345 01:04:10,950 --> 01:04:12,367 but I think it's too slow. 1346 01:04:12,367 --> 01:04:14,950 But in this case it's not that slow, so people are like, yeah, 1347 01:04:14,950 --> 01:04:16,830 we'll use it here. 1348 01:04:16,830 --> 01:04:20,130 So this is kind of cool, because it's simple. 1349 01:04:20,130 --> 01:04:23,220 It's just more scripts can be added any time. 1350 01:04:23,220 --> 01:04:24,363 It's all one scaling. 1351 01:04:24,363 --> 01:04:26,280 So if you have it a million different scripts, 1352 01:04:26,280 --> 01:04:30,540 proving one of them takes 32 bytes, or 33, or something. 1353 01:04:30,540 --> 01:04:33,960 C can be a threshold signature of many different parties. 1354 01:04:33,960 --> 01:04:36,900 The signature can be aggregated within the transaction. 1355 01:04:36,900 --> 01:04:40,770 The downside is this interactive setup, where you can't just 1356 01:04:40,770 --> 01:04:43,530 take Alice, and Bob, and Carol's key, 1357 01:04:43,530 --> 01:04:46,410 and send to a graftroot 2 of 3 multisig. 1358 01:04:46,410 --> 01:04:50,430 Alice, and Bob, and Carol need to sign something. 1359 01:04:50,430 --> 01:04:52,333 In some cases that's no big deal. 1360 01:04:52,333 --> 01:04:54,750 In some cases, you're connected to them over the internet, 1361 01:04:54,750 --> 01:04:57,300 and all the participants are cooperating. 1362 01:04:57,300 --> 01:04:58,110 Sure, we'll sign. 1363 01:04:58,110 --> 01:04:59,370 We'll create addresses. 1364 01:04:59,370 --> 01:05:04,280 Or we'll pre-sign all sorts of different addresses beforehand. 1365 01:05:04,280 --> 01:05:06,780 Doable, but sometimes you don't want this interactive setup. 1366 01:05:06,780 --> 01:05:08,238 Sometimes I want to be able to send 1367 01:05:08,238 --> 01:05:14,500 to participants of my choosing, without their cooperation. 1368 01:05:14,500 --> 01:05:16,847 Really, usually for sending people money, 1369 01:05:16,847 --> 01:05:17,930 they're OK with it, right? 1370 01:05:17,930 --> 01:05:22,870 But sometimes you don't want them to be online. 1371 01:05:22,870 --> 01:05:26,110 So put this all together. 1372 01:05:26,110 --> 01:05:30,130 The goal for this, and I think the way it's going to work 1373 01:05:30,130 --> 01:05:34,120 in Bitcoin-- but this is still research-- 1374 01:05:34,120 --> 01:05:35,540 you have a unified output script. 1375 01:05:35,540 --> 01:05:38,800 So let's say it's a templated with OP_5. 1376 01:05:38,800 --> 01:05:43,510 And you say, OK, OP_5, pubkey. 1377 01:05:43,510 --> 01:05:46,650 Now, when I want to spend to it, I have a bunch of options. 1378 01:05:46,650 --> 01:05:49,680 To spend, I can just put a signature on the stack. 1379 01:05:49,680 --> 01:05:52,440 And then the program says, oh, there's a signature. 1380 01:05:52,440 --> 01:05:57,650 Let me check if the signature matches the public key-- 1381 01:05:57,650 --> 01:05:59,070 you know, this pubkey. 1382 01:05:59,070 --> 01:06:02,300 And if it does, cool, the money moves. 1383 01:06:02,300 --> 01:06:05,460 That's pay to pubkey hash mode, except it's not hashed. 1384 01:06:05,460 --> 01:06:09,270 Another thing I could do is provide a point J-- 1385 01:06:09,270 --> 01:06:13,700 a script-- and a series of arguments for the script. 1386 01:06:13,700 --> 01:06:15,890 And that's taproot. 1387 01:06:15,890 --> 01:06:23,300 I verify that J plus the hash of J in the script times G 1388 01:06:23,300 --> 01:06:27,190 is equal to that pubkey, and then I execute that script. 1389 01:06:27,190 --> 01:06:29,830 Another way to do it is if I've got this-- 1390 01:06:29,830 --> 01:06:32,318 I've got C, which is also just a point 1391 01:06:32,318 --> 01:06:33,610 and a signature on the script-- 1392 01:06:33,610 --> 01:06:36,640 and then a script, and a bunch of arguments, then I say, 1393 01:06:36,640 --> 01:06:38,410 oh, this is graftroot. 1394 01:06:38,410 --> 01:06:43,030 I'll verify this signature on this script, 1395 01:06:43,030 --> 01:06:47,340 and then execute with these arguments. 1396 01:06:47,340 --> 01:06:50,060 So it would be cool if you could do it just based 1397 01:06:50,060 --> 01:06:53,090 on the number of items pushed. 1398 01:06:53,090 --> 01:06:56,000 But you might want to put like a flag or something here, 1399 01:06:56,000 --> 01:06:57,760 to distinguish between these two. 1400 01:06:57,760 --> 01:06:59,900 And with this, if there's just one element, 1401 01:06:59,900 --> 01:07:02,330 you can just quickly say, OK, it's pay to pubkey. 1402 01:07:02,330 --> 01:07:03,830 But to distinguish between these two 1403 01:07:03,830 --> 01:07:05,413 there might be weird edge cases, where 1404 01:07:05,413 --> 01:07:07,160 it's like, well, one of the arguments 1405 01:07:07,160 --> 01:07:09,530 could also look like a script, and annoying things. 1406 01:07:09,530 --> 01:07:13,740 So you might put some, like, flag byte But anyway, it's 1407 01:07:13,740 --> 01:07:17,190 kind of nice, in that when you send to an output, 1408 01:07:17,190 --> 01:07:20,310 you send to an address, all the addresses look the same. 1409 01:07:20,310 --> 01:07:23,160 They just look like public keys, but they 1410 01:07:23,160 --> 01:07:25,260 could be any of these things, and you only 1411 01:07:25,260 --> 01:07:26,490 find out after the fact. 1412 01:07:30,500 --> 01:07:32,030 And not only that-- you could have 1413 01:07:32,030 --> 01:07:37,790 the same key have a taproot and also have a graftroot. 1414 01:07:40,350 --> 01:07:41,630 So there could be an address. 1415 01:07:41,630 --> 01:07:42,883 And I've gotten my wallet. 1416 01:07:42,883 --> 01:07:45,050 Well, there's three different ways I can spend this. 1417 01:07:45,050 --> 01:07:50,270 I can spend this with everyone-- all 50 people-- signing. 1418 01:07:50,270 --> 01:07:53,330 Or I can spend it with a single script 1419 01:07:53,330 --> 01:07:56,810 that's been endorsed this way, that's got priority. 1420 01:07:56,810 --> 01:07:59,210 And then I can also spend it with one 1421 01:07:59,210 --> 01:08:03,200 of the millions of scripts that have been endorsed this way. 1422 01:08:03,200 --> 01:08:04,280 So I can use all three. 1423 01:08:04,280 --> 01:08:05,960 This is a little bit more efficient, 1424 01:08:05,960 --> 01:08:09,080 because you're just revealing the script and a point. 1425 01:08:09,080 --> 01:08:11,620 This one, you have to reveal. 1426 01:08:11,620 --> 01:08:14,170 Oh no, wait, sorry, this is wrong. 1427 01:08:14,170 --> 01:08:16,920 There's no C. You already know C. It's still 1428 01:08:16,920 --> 01:08:18,045 a little more efficient. 1429 01:08:21,868 --> 01:08:22,910 Yeah, there's no C there. 1430 01:08:22,910 --> 01:08:25,649 You already know C. You just put the signature on the script. 1431 01:08:25,649 --> 01:08:30,330 Yeah, OK, so that's [INAUDIBLE] 1432 01:08:30,330 --> 01:08:33,080 OK, so this is graftroot, taproot. 1433 01:08:33,080 --> 01:08:35,569 And then, also, part of the script can be masked. 1434 01:08:35,569 --> 01:08:36,979 You can have a masked OP code. 1435 01:08:36,979 --> 01:08:39,620 You can combine all these things in crazy ways, 1436 01:08:39,620 --> 01:08:42,710 and have like really powerful scripting that way. 1437 01:08:42,710 --> 01:08:47,060 So when this stuff was proposed, the argument was, 1438 01:08:47,060 --> 01:08:50,479 hey, I don't want to spend to a public key. 1439 01:08:50,479 --> 01:08:52,490 I want to spend to a public key hash. 1440 01:08:52,490 --> 01:08:54,649 Because quantum computers are coming. 1441 01:08:54,649 --> 01:08:58,790 And when the quantum computers come, if you know my pubkey, 1442 01:08:58,790 --> 01:09:00,590 you can just calculate my private key, 1443 01:09:00,590 --> 01:09:01,970 and take all my money. 1444 01:09:01,970 --> 01:09:04,850 But if you only know my public key hash, 1445 01:09:04,850 --> 01:09:06,770 quantum computer doesn't help you there. 1446 01:09:06,770 --> 01:09:10,819 You're not going to be able to compute the pre-image of a hash 1447 01:09:10,819 --> 01:09:11,819 with a quantum computer. 1448 01:09:16,750 --> 01:09:19,000 All of those statements are true, 1449 01:09:19,000 --> 01:09:23,319 except in practice it's dumb. 1450 01:09:23,319 --> 01:09:26,140 Because if there's a quantum computer that 1451 01:09:26,140 --> 01:09:30,970 can compute your private key from your public key, 1452 01:09:30,970 --> 01:09:33,310 the only time using pubkey hashes 1453 01:09:33,310 --> 01:09:35,740 will help you is if somehow that quantum computer takes 1454 01:09:35,740 --> 01:09:40,000 a really long time to compute your private key. 1455 01:09:40,000 --> 01:09:43,540 Because if it only takes them a minute to compute it, 1456 01:09:43,540 --> 01:09:47,439 well, you have to reveal your public key to spend your money. 1457 01:09:47,439 --> 01:09:49,960 And then the attacker, who has this nifty quantum computer, 1458 01:09:49,960 --> 01:09:53,729 can just say, oh, that's his public key. 1459 01:09:53,729 --> 01:09:54,930 I just saw it. 1460 01:09:54,930 --> 01:09:55,860 And he signed. 1461 01:09:55,860 --> 01:09:58,320 And using his public key, I just compute his private key, 1462 01:09:58,320 --> 01:10:00,660 sign a different message, and broadcast it. 1463 01:10:00,660 --> 01:10:03,120 And maybe I attach a higher fee. 1464 01:10:03,120 --> 01:10:04,980 Because I don't care, it's not my money. 1465 01:10:04,980 --> 01:10:06,563 And the miners are like, well, there's 1466 01:10:06,563 --> 01:10:07,890 two different transactions-- 1467 01:10:07,890 --> 01:10:09,590 one sending over here, one sending over here. 1468 01:10:09,590 --> 01:10:10,882 This one has a much higher fee. 1469 01:10:10,882 --> 01:10:12,050 I'll use this one. 1470 01:10:12,050 --> 01:10:13,980 And the attacker with the quantum computer 1471 01:10:13,980 --> 01:10:15,720 still takes all your money. 1472 01:10:15,720 --> 01:10:17,280 They can't take it at rest. 1473 01:10:17,280 --> 01:10:19,860 They have to wait for you to try to spend it and take it. 1474 01:10:19,860 --> 01:10:23,310 But you could say, OK, well actually, 1475 01:10:23,310 --> 01:10:25,860 I'm doing OP_5, pubkey hash. 1476 01:10:25,860 --> 01:10:29,130 And then for this, I have to reveal pubkey signature. 1477 01:10:29,130 --> 01:10:33,270 For this, I reveal j component of pubkey script. 1478 01:10:33,270 --> 01:10:36,120 For this, I reveal C and the sig. 1479 01:10:36,120 --> 01:10:38,860 But it's kind of ugly. 1480 01:10:38,860 --> 01:10:42,100 It wastes space, and in most cases 1481 01:10:42,100 --> 01:10:45,940 doesn't provide a lot of protection. 1482 01:10:45,940 --> 01:10:50,140 So there's hopefully better ways to deal with this. 1483 01:10:50,140 --> 01:10:53,290 One thing that I have sort of been joking about, 1484 01:10:53,290 --> 01:10:55,810 but would be kind of fun to put it into [INAUDIBLE].. 1485 01:10:55,810 --> 01:10:58,300 You can actually use taproot to commit 1486 01:10:58,300 --> 01:11:03,640 to a Lamport-like hash-based pubkey. 1487 01:11:03,640 --> 01:11:13,190 So in taproot this is actually quantum secure. 1488 01:11:13,190 --> 01:11:15,550 I hesitate to advertise this. 1489 01:11:15,550 --> 01:11:22,300 But it is a commitment that the quantum computer cannot forge. 1490 01:11:28,250 --> 01:11:36,140 Where was I saying the J equals hash of-- 1491 01:11:36,140 --> 01:11:41,120 yeah, this thing is still a problem for a quantum computer. 1492 01:11:41,120 --> 01:11:43,070 I want to compute a J such that J 1493 01:11:43,070 --> 01:11:48,770 equals this hash times G minus R. And J is in there as well. 1494 01:11:48,770 --> 01:11:51,800 Even with a quantum computer, maybe I can compute 1495 01:11:51,800 --> 01:11:55,160 an arbitrary J and find its discrete lock-- you know, 1496 01:11:55,160 --> 01:11:56,427 find the private key-- 1497 01:11:56,427 --> 01:11:58,510 but it's still not going to satisfy this equation. 1498 01:12:01,310 --> 01:12:07,210 So I can't after the fact find a script and a J 1499 01:12:07,210 --> 01:12:11,290 to compute this C. So that is safe, even if a quantum 1500 01:12:11,290 --> 01:12:13,540 computer exists, because that's based 1501 01:12:13,540 --> 01:12:15,280 on the security the hash function. 1502 01:12:15,280 --> 01:12:17,350 So that's kind of an interesting little tidbit-- 1503 01:12:17,350 --> 01:12:23,860 like, hey, this taproot construction is hash based. 1504 01:12:23,860 --> 01:12:28,390 Quantum computer appears, and we say, look, we no longer allow 1505 01:12:28,390 --> 01:12:31,900 C. We no longer allow the normal spend, where 1506 01:12:31,900 --> 01:12:34,060 you sign with key C, because signatures-- 1507 01:12:34,060 --> 01:12:36,590 all this elliptic curve stuff, it's broken. 1508 01:12:36,590 --> 01:12:39,220 However, we do allow you to prove 1509 01:12:39,220 --> 01:12:44,440 that there was a script z committed to in C. 1510 01:12:44,440 --> 01:12:48,280 And then maybe this script has like a quantum-safe signature 1511 01:12:48,280 --> 01:12:50,710 in it, and then we can use that. 1512 01:12:50,710 --> 01:12:53,560 What's nice about that is you can start using it sooner, 1513 01:12:53,560 --> 01:12:56,020 and without the overhead of all the extra space taken 1514 01:12:56,020 --> 01:12:57,820 by the quantum signature, because it's 1515 01:12:57,820 --> 01:12:59,080 sort of a backup plan. 1516 01:12:59,080 --> 01:13:00,720 It's like, well, normally I'm just 1517 01:13:00,720 --> 01:13:05,350 signing with C, because I know this is just my regular key-- 1518 01:13:05,350 --> 01:13:06,310 and I do this. 1519 01:13:06,310 --> 01:13:08,590 But worst-case scenario, if a quantum computer 1520 01:13:08,590 --> 01:13:13,520 appears in 10 years, I've got my other backup key here. 1521 01:13:13,520 --> 01:13:16,700 So that's kind of a cool thing. 1522 01:13:16,700 --> 01:13:19,830 I don't know how useful it is in practice. 1523 01:13:19,830 --> 01:13:22,530 So yeah, you've got all these three things. 1524 01:13:22,530 --> 01:13:23,967 The other thing about this is-- 1525 01:13:27,310 --> 01:13:29,733 I don't know, big multisig is one use case. 1526 01:13:29,733 --> 01:13:31,400 It seems really powerful, and like, hey, 1527 01:13:31,400 --> 01:13:34,310 I can make these millions of different scripts, 1528 01:13:34,310 --> 01:13:36,320 and Merkle trees of different scripts, 1529 01:13:36,320 --> 01:13:38,440 and taproot and graftroot. 1530 01:13:38,440 --> 01:13:43,400 Not a ton of really good real world use cases, though, 1531 01:13:43,400 --> 01:13:45,380 I think that would motivate it a lot more. 1532 01:13:45,380 --> 01:13:48,770 Because a lot of the hesitation from people working on Bitcoin 1533 01:13:48,770 --> 01:13:50,570 is like, OK, this is really cool, 1534 01:13:50,570 --> 01:13:54,530 but what are we going to do with it? 1535 01:13:54,530 --> 01:13:58,220 As I'll talk about on Wednesday, multisig itself 1536 01:13:58,220 --> 01:14:00,770 is not the best motivation. 1537 01:14:00,770 --> 01:14:03,980 Because once we have Schnoor signatures 1538 01:14:03,980 --> 01:14:08,810 and aggregate signatures there's direct ways to do multisig, 1539 01:14:08,810 --> 01:14:10,970 that are actually more privacy preserving 1540 01:14:10,970 --> 01:14:12,890 and more space preserving. 1541 01:14:12,890 --> 01:14:15,120 So we need to use cases. 1542 01:14:15,120 --> 01:14:16,920 And that's one of the debates-- like, OK, 1543 01:14:16,920 --> 01:14:17,920 what do we do with this? 1544 01:14:17,920 --> 01:14:19,140 This is kind of cool. 1545 01:14:19,140 --> 01:14:21,140 You can make all sorts of weird smart contracts, 1546 01:14:21,140 --> 01:14:22,920 but what are some real-world use cases? 1547 01:14:22,920 --> 01:14:24,212 There's also sort of argument-- 1548 01:14:24,212 --> 01:14:26,870 OK, MAST versus graftroot versus both. 1549 01:14:26,870 --> 01:14:30,260 Well, if you have graftroot, do you really need MAST anymore? 1550 01:14:30,260 --> 01:14:34,240 Instead of this big Merkle tree, you just 1551 01:14:34,240 --> 01:14:36,610 have the signatures endorsing the leaves. 1552 01:14:36,610 --> 01:14:39,730 So it sort of seems better scalability there. 1553 01:14:39,730 --> 01:14:43,340 But graftroot is interactive, so maybe you still want MAST. 1554 01:14:43,340 --> 01:14:45,460 Maybe you have both. 1555 01:14:45,460 --> 01:14:46,990 There's all sorts of debate on this. 1556 01:14:46,990 --> 01:14:51,970 And so in practice that may mean that since people are arguing 1557 01:14:51,970 --> 01:14:56,890 next year, the year after, it's hard to get everyone on board 1558 01:14:56,890 --> 01:14:57,580 to do stuff. 1559 01:14:57,580 --> 01:14:59,710 There is code, though. 1560 01:14:59,710 --> 01:15:02,150 Some things have code. 1561 01:15:02,150 --> 01:15:04,150 A lot of it's sort of obvious enough, that like, 1562 01:15:04,150 --> 01:15:05,410 yeah, graftroot makes sense. 1563 01:15:05,410 --> 01:15:07,370 Just have them sign. 1564 01:15:07,370 --> 01:15:09,250 The taproot construction there's code for. 1565 01:15:09,250 --> 01:15:11,140 But it's not all put together. 1566 01:15:11,140 --> 01:15:12,852 There's no spec for all these things. 1567 01:15:12,852 --> 01:15:15,310 So if people are interested in this stuff, start coding it. 1568 01:15:15,310 --> 01:15:17,260 Start trying it out. 1569 01:15:17,260 --> 01:15:19,660 Come up with cool use cases, and maybe 1570 01:15:19,660 --> 01:15:21,520 push for one thing or another to get in. 1571 01:15:21,520 --> 01:15:24,800 There's a full request open in Bitcoin right now for MAST. 1572 01:15:27,390 --> 01:15:29,340 I know some people are really into it, 1573 01:15:29,340 --> 01:15:33,150 and other people are like, uh, I don't know. 1574 01:15:33,150 --> 01:15:35,320 Also, how to implement MAST exactly. 1575 01:15:35,320 --> 01:15:38,360 So this is still research kind of level, 1576 01:15:38,360 --> 01:15:40,540 but it seems that they're usable, 1577 01:15:40,540 --> 01:15:43,570 and it may improve smart-contract functionality. 1578 01:15:43,570 --> 01:15:46,330 So cool stuff here. 1579 01:15:46,330 --> 01:15:47,726 Any questions about this? 1580 01:15:51,390 --> 01:15:52,950 All right, cool. 1581 01:15:52,950 --> 01:15:56,050 So I'll do office hours tomorrow at 4:00. 1582 01:15:56,050 --> 01:15:57,660 We can talk about projects and stuff. 1583 01:15:57,660 --> 01:16:00,150 And the next class on Wednesday will 1584 01:16:00,150 --> 01:16:02,310 be even more crazy elliptic curve stuff 1585 01:16:02,310 --> 01:16:05,070 about aggregate signatures, Schnoor signatures, 1586 01:16:05,070 --> 01:16:09,070 multi signatures, threshold signatures, things like that. 1587 01:16:09,070 --> 01:16:11,192 And also, privacy-- 1588 01:16:11,192 --> 01:16:12,900 I'm going to focus on the signature part. 1589 01:16:12,900 --> 01:16:16,890 I also put privacy and CoinJoin in there, which is related, 1590 01:16:16,890 --> 01:16:19,830 but might be squished towards the end 1591 01:16:19,830 --> 01:16:22,280 if I don't have a ton of time.