1 00:00:00,940 --> 00:00:03,280 The following content is provided under a Creative 2 00:00:03,280 --> 00:00:04,670 Commons license. 3 00:00:04,670 --> 00:00:06,880 Your support will help MIT OpenCourseWare 4 00:00:06,880 --> 00:00:10,970 continue to offer high quality educational resources for free. 5 00:00:10,970 --> 00:00:13,540 To make a donation or to view additional materials 6 00:00:13,540 --> 00:00:17,500 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:17,500 --> 00:00:18,380 at ocw.mit.edu. 8 00:00:22,293 --> 00:00:22,960 TADGE DRYJA: OK. 9 00:00:22,960 --> 00:00:25,660 So today, I'll talk about payment channels 10 00:00:25,660 --> 00:00:28,000 and the lightning network. 11 00:00:28,000 --> 00:00:30,550 And I am sorry if I gloss over things. 12 00:00:30,550 --> 00:00:33,580 I've explained this, like, a lot in the last two years 13 00:00:33,580 --> 00:00:36,040 because that's, sort of, what I work on. 14 00:00:36,040 --> 00:00:38,473 So I might skip over something, and you're like, 15 00:00:38,473 --> 00:00:39,640 wait, how did you get there? 16 00:00:39,640 --> 00:00:40,660 So let me know. 17 00:00:40,660 --> 00:00:43,330 So I'll have uni-directional payment channels, and then 18 00:00:43,330 --> 00:00:44,380 lightning channels. 19 00:00:44,380 --> 00:00:46,750 And then, multi-hop. 20 00:00:46,750 --> 00:00:49,190 OK, so the idea of payment channels. 21 00:00:49,190 --> 00:00:51,500 Why do we need to do all this complicated, weird stuff 22 00:00:51,500 --> 00:00:52,880 with payment channels? 23 00:00:52,880 --> 00:00:55,790 Well, the problem is these networks 24 00:00:55,790 --> 00:00:57,320 are really poor in scalability. 25 00:00:57,320 --> 00:00:57,820 Right? 26 00:00:57,820 --> 00:01:01,100 Every transaction on the blockchain, you know, 27 00:01:01,100 --> 00:01:02,840 that whole idea doesn't scale. 28 00:01:02,840 --> 00:01:06,530 People say it's O of n squared. 29 00:01:06,530 --> 00:01:09,680 Depends on what you define as n and then things like that. 30 00:01:09,680 --> 00:01:15,612 So if you double the number of nodes, it actually doesn't. 31 00:01:15,612 --> 00:01:17,820 You can say, well, if you double the number of nodes, 32 00:01:17,820 --> 00:01:20,460 each node is going to be making some transactions. 33 00:01:20,460 --> 00:01:21,090 Right? 34 00:01:21,090 --> 00:01:22,632 And then, you're like, OK, yeah, it's 35 00:01:22,632 --> 00:01:25,170 n squared if you count the total number of computations 36 00:01:25,170 --> 00:01:26,510 throughout the entire system. 37 00:01:26,510 --> 00:01:27,750 But at the same time, it's like, well, you've 38 00:01:27,750 --> 00:01:29,350 doubled the number of nodes. 39 00:01:29,350 --> 00:01:31,380 So really, it's O of n, right? 40 00:01:31,380 --> 00:01:34,410 For any one computer, your amount of computation 41 00:01:34,410 --> 00:01:37,800 you have to do scales with how many other computers there are. 42 00:01:37,800 --> 00:01:41,238 So it's a little questionable. 43 00:01:41,238 --> 00:01:42,780 But basically, it doesn't scale well. 44 00:01:42,780 --> 00:01:43,280 Right? 45 00:01:43,280 --> 00:01:45,610 It doesn't scale to what you want. 46 00:01:45,610 --> 00:01:48,840 And so I put a little history at the first response of anyone 47 00:01:48,840 --> 00:01:50,580 ever referring to Bitcoin. 48 00:01:50,580 --> 00:01:53,240 So there was a 2008-- 49 00:01:53,240 --> 00:01:57,010 like October, Halloween 2008, or maybe after midnight, so 50 00:01:57,010 --> 00:01:58,170 November 1st-- 51 00:01:58,170 --> 00:02:00,090 and Satoshi wrote, I've been working 52 00:02:00,090 --> 00:02:02,700 on a new electronic cash system that's fully peer-to-peer, 53 00:02:02,700 --> 00:02:04,040 with no trusted third party. 54 00:02:04,040 --> 00:02:05,460 Then, he has a little blurb. 55 00:02:05,460 --> 00:02:08,729 The first reply on this mailing list was some guy-- 56 00:02:08,729 --> 00:02:10,892 James A. Donald-- saying, we very, 57 00:02:10,892 --> 00:02:12,600 very much need such a system, but the way 58 00:02:12,600 --> 00:02:14,225 I understand your proposal, it does not 59 00:02:14,225 --> 00:02:15,930 seem to scale to the required size. 60 00:02:15,930 --> 00:02:17,430 So that was the first thing anyone's 61 00:02:17,430 --> 00:02:20,130 ever said about Bitcoin. 62 00:02:20,130 --> 00:02:23,812 And we're still talking about it almost 10 years later. 63 00:02:23,812 --> 00:02:25,020 I wonder who James Donald is. 64 00:02:25,020 --> 00:02:28,650 Maybe he's got a ton of Bitcoin now and he mined it. 65 00:02:28,650 --> 00:02:31,620 So it was written about in late 2008. 66 00:02:31,620 --> 00:02:36,267 The actual software was released in 2009. 67 00:02:36,267 --> 00:02:37,350 There was a couple emails. 68 00:02:37,350 --> 00:02:40,350 No one really looked into it much, at the time. 69 00:02:40,350 --> 00:02:44,800 OK, so you can start with a one way payment channel. 70 00:02:47,540 --> 00:02:51,320 I think Satoshi, sort of, mentioned these ideas. 71 00:02:51,320 --> 00:02:52,970 Never really implemented anything. 72 00:02:52,970 --> 00:02:56,360 And the way he talked about it didn't actually work. 73 00:02:56,360 --> 00:03:00,230 Some people in 2012 I remember looking at this. 74 00:03:00,230 --> 00:03:02,540 I think [INAUDIBLE] and Mike Hearn 75 00:03:02,540 --> 00:03:05,910 gave a talk about how you could make payment channels. 76 00:03:05,910 --> 00:03:10,568 That didn't quite work either, but the idea made sense. 77 00:03:10,568 --> 00:03:12,360 So the idea is you have some kind of shared 78 00:03:12,360 --> 00:03:14,790 balance between two parties. 79 00:03:14,790 --> 00:03:17,400 And you can move coins in one direction 80 00:03:17,400 --> 00:03:20,540 without making new transactions on the blockchain. 81 00:03:32,360 --> 00:03:35,880 So if you look at a transaction-- 82 00:03:35,880 --> 00:03:39,680 you probably have seen this kind of thing through homework-- 83 00:03:39,680 --> 00:03:41,588 it's got a lock time. 84 00:03:41,588 --> 00:03:43,130 And in this case, the lock time is 0. 85 00:03:43,130 --> 00:03:45,760 That means this transaction is valid at any point. 86 00:03:45,760 --> 00:03:49,610 Above height 0, it's valid. 87 00:03:49,610 --> 00:03:51,200 And every block is above height 0. 88 00:03:51,200 --> 00:04:03,810 You can also find transactions, let's see, 89 00:04:03,810 --> 00:04:05,970 which has a block time of this. 90 00:04:05,970 --> 00:04:11,320 So this looks like a Unix time where you set a time. 91 00:04:11,320 --> 00:04:12,480 This is like a Unix time. 92 00:04:12,480 --> 00:04:16,500 So Unix time, if you don't know, it's 93 00:04:16,500 --> 00:04:19,260 seconds since January 1, 1970. 94 00:04:19,260 --> 00:04:21,899 That's, sort of, like the first second. 95 00:04:21,899 --> 00:04:22,920 And I don't know. 96 00:04:22,920 --> 00:04:25,890 That's probably a week ago or something. 97 00:04:25,890 --> 00:04:28,620 So you can have that field in a transaction. 98 00:04:28,620 --> 00:04:31,130 The idea is the transaction is only valid after that time 99 00:04:31,130 --> 00:04:32,220 or height. 100 00:04:32,220 --> 00:04:33,720 It's a little weird. 101 00:04:33,720 --> 00:04:34,810 Below-- what is it-- 102 00:04:34,810 --> 00:04:38,400 500 million, it counts as a height. 103 00:04:38,400 --> 00:04:41,280 Above 500 million, it counts as a Unix time, 104 00:04:41,280 --> 00:04:44,580 which ends up working because the Unix times below 500 105 00:04:44,580 --> 00:04:45,960 million are in the 80s. 106 00:04:45,960 --> 00:04:49,500 So you know, Bitcoin didn't exist then. 107 00:04:49,500 --> 00:04:52,026 There's no real need to have time locks them. 108 00:04:52,026 --> 00:04:52,526 Sorry? 109 00:04:52,526 --> 00:04:55,195 AUDIENCE: What about when you get that far in block height? 110 00:04:55,195 --> 00:04:55,680 TADGE DRYJA: About what? 111 00:04:55,680 --> 00:04:56,400 Sorry. 112 00:04:56,400 --> 00:04:57,180 AUDIENCE: Don't you eventually get 113 00:04:57,180 --> 00:04:58,500 that far in block height, though? 114 00:04:58,500 --> 00:04:59,542 TADGE DRYJA: 500 million? 115 00:04:59,542 --> 00:05:01,620 Yeah, couple thousand years. 116 00:05:01,620 --> 00:05:02,130 So yeah. 117 00:05:02,130 --> 00:05:04,910 No, there's way more problems with Bitcoin before that. 118 00:05:04,910 --> 00:05:09,060 The time field in the header is four bytes. 119 00:05:09,060 --> 00:05:11,928 So if it was signed, it'd be 2038 120 00:05:11,928 --> 00:05:13,470 that it flips over and goes negative. 121 00:05:13,470 --> 00:05:18,170 But it's unsigned, so you got until 2106. 122 00:05:18,170 --> 00:05:20,050 There's actually a hard fork to fix that. 123 00:05:20,050 --> 00:05:22,313 So you know, there's all sorts of weird, 124 00:05:22,313 --> 00:05:24,980 like, wait, what do we do in the hundreds of thousands of years? 125 00:05:24,980 --> 00:05:27,500 We have to make these little tweaks, which, hopefully, 126 00:05:27,500 --> 00:05:29,450 wouldn't be super controversial because it's like, well, it'll 127 00:05:29,450 --> 00:05:31,450 stop working unless we change this little thing. 128 00:05:33,680 --> 00:05:34,180 OK. 129 00:05:34,180 --> 00:05:36,550 So yeah, you can have these lock times. 130 00:05:36,550 --> 00:05:38,450 And you can use those. 131 00:05:38,450 --> 00:05:40,900 So what you can do is make a channel. 132 00:05:40,900 --> 00:05:44,200 And a channel is really just a multisig output. 133 00:05:44,200 --> 00:05:47,460 Multisig, a lot of times, is used for-- 134 00:05:47,460 --> 00:05:49,420 I don't want to say two factor authentication-- 135 00:05:49,420 --> 00:05:51,840 but you could have two of two multisig 136 00:05:51,840 --> 00:05:54,737 where your phone needs to sign, and your desktop needs to sign. 137 00:05:54,737 --> 00:05:56,320 And then, if someone steals your phone 138 00:05:56,320 --> 00:05:58,403 or you know hacks your phone and gets the key out, 139 00:05:58,403 --> 00:06:02,380 well, they have to also get your computer. 140 00:06:02,380 --> 00:06:03,720 So this is useful. 141 00:06:03,720 --> 00:06:08,890 But in these cases, it's, sort of, adversarial multisig 142 00:06:08,890 --> 00:06:11,260 where it's not just you and you. 143 00:06:11,260 --> 00:06:13,300 It's not like your phone and your computer. 144 00:06:13,300 --> 00:06:14,530 OK, it's Alice and Bob. 145 00:06:14,530 --> 00:06:16,060 They're completely separate people. 146 00:06:16,060 --> 00:06:17,930 They're not necessarily friends. 147 00:06:17,930 --> 00:06:21,490 You know, it could be a customer merchant kind of thing. 148 00:06:21,490 --> 00:06:23,290 And they create a transaction together. 149 00:06:23,290 --> 00:06:24,490 So they fund it. 150 00:06:24,490 --> 00:06:26,530 And Alice is funding this channel. 151 00:06:26,530 --> 00:06:30,130 And so she takes her own coins, her own txid:index, 152 00:06:30,130 --> 00:06:34,120 her own output, signs it, and sends to an Alice and Bob 153 00:06:34,120 --> 00:06:37,340 multisig and sends 10 coins. 154 00:06:37,340 --> 00:06:43,140 So in order to spend this, they both have to cooperate. 155 00:06:43,140 --> 00:06:48,880 But before doing this, Bob gives her a refund transaction. 156 00:06:48,880 --> 00:06:53,110 So the idea is, if Alice just broadcasts this and says, 157 00:06:53,110 --> 00:06:55,090 OK, I'm taking my coins and I'm sending it 158 00:06:55,090 --> 00:06:58,180 to Alice and Bob multisig, Bob can just disappear. 159 00:06:58,180 --> 00:06:59,500 And then, Alice is stuck. 160 00:06:59,500 --> 00:07:00,958 And the money's stuck there forever 161 00:07:00,958 --> 00:07:02,680 because Bob can never sign. 162 00:07:02,680 --> 00:07:06,970 Or Bob can say, oh, Alice, looks like you sent 10 coins. 163 00:07:06,970 --> 00:07:08,065 How about this. 164 00:07:08,065 --> 00:07:09,190 I'll give you nine of them. 165 00:07:09,190 --> 00:07:10,825 You just give me one of them. 166 00:07:10,825 --> 00:07:11,950 You're not buying anything. 167 00:07:11,950 --> 00:07:15,040 This is just I'm holding your coins hostage. 168 00:07:15,040 --> 00:07:19,950 Bob could even make a even better threat and say, 169 00:07:19,950 --> 00:07:22,770 I will sign a bunch of time lock transactions. 170 00:07:22,770 --> 00:07:25,398 If you want your money today, you only get one coin. 171 00:07:25,398 --> 00:07:27,690 If you want your money in a week, you'll get two coins. 172 00:07:27,690 --> 00:07:30,690 And you know, sign these things with lock times. 173 00:07:30,690 --> 00:07:33,060 Hand all the transactions over to Alice and say, 174 00:07:33,060 --> 00:07:34,590 well, you can pick. 175 00:07:34,590 --> 00:07:37,250 How long do you want to wait to get your money back? 176 00:07:37,250 --> 00:07:40,200 And then, Alice's only response is, oh shoot, well, 177 00:07:40,200 --> 00:07:42,540 if I wait years, maybe I'll get most of my coins back. 178 00:07:42,540 --> 00:07:44,123 But if I want my money now-- you know, 179 00:07:44,123 --> 00:07:47,310 there's all sorts of horrible hostage situations, 180 00:07:47,310 --> 00:07:50,460 even if they both have money at stake. 181 00:07:50,460 --> 00:07:53,470 One person could have less time value of money. 182 00:07:53,470 --> 00:07:55,800 So they're like, look, I don't need this anytime soon. 183 00:07:55,800 --> 00:07:58,050 So I'm willing to wait. 184 00:07:58,050 --> 00:07:59,220 So this is dangerous. 185 00:07:59,220 --> 00:08:01,170 So what they do beforehand is Alice says, 186 00:08:01,170 --> 00:08:04,290 hey Bob, give me a refund transaction. 187 00:08:04,290 --> 00:08:06,450 So Bob signs a refund transaction 188 00:08:06,450 --> 00:08:09,510 with a lock time of one week from now, March 28. 189 00:08:09,510 --> 00:08:13,380 And the input is the fund transaction ID. 190 00:08:13,380 --> 00:08:17,430 Even though the fund transaction comes later, thanks to segwit, 191 00:08:17,430 --> 00:08:20,310 you can say I know what the Tx ID's gonna be. 192 00:08:20,310 --> 00:08:22,740 I'm gonna reference a spin for that. 193 00:08:22,740 --> 00:08:25,320 And Bob's signature is going to be on there. 194 00:08:25,320 --> 00:08:26,160 Bob signs it. 195 00:08:26,160 --> 00:08:28,470 Hands it over to Alice. 196 00:08:28,470 --> 00:08:30,240 Alice's signature is not there yet. 197 00:08:30,240 --> 00:08:33,340 So Alice can sign it and store it on her drive, 198 00:08:33,340 --> 00:08:35,049 or she can sign later. 199 00:08:35,049 --> 00:08:39,789 But until March 28th, this transaction is not happening. 200 00:08:39,789 --> 00:08:43,460 If you try to broadcast it, everyone will reject it. 201 00:08:43,460 --> 00:08:45,470 In the output from this refund transaction, 202 00:08:45,470 --> 00:08:47,990 it just sends to Alice's address, all 10 coins. 203 00:08:47,990 --> 00:08:48,490 Yes? 204 00:08:48,490 --> 00:08:50,434 AUDIENCE: How do they know the transaction 205 00:08:50,434 --> 00:08:54,808 in the future, the transaction ID in the future? 206 00:08:54,808 --> 00:08:58,060 TADGE DRYJA: Oh, how do they know the funds Tx ID? 207 00:08:58,060 --> 00:09:00,190 Alice can calculate it and tell Bob. 208 00:09:00,190 --> 00:09:03,070 Alice can say I'm building a fund transaction. 209 00:09:03,070 --> 00:09:04,823 Alice knows her inputs. 210 00:09:04,823 --> 00:09:06,490 She doesn't actually have to sign it all 211 00:09:06,490 --> 00:09:10,300 because the Tx ID won't contain the signature 212 00:09:10,300 --> 00:09:12,550 and what their key is. 213 00:09:12,550 --> 00:09:18,197 So Alice can compute the Tx ID and tell Bob, hey, sign this. 214 00:09:18,197 --> 00:09:19,780 You know, this is what the transaction 215 00:09:19,780 --> 00:09:20,740 is going to look like. 216 00:09:20,740 --> 00:09:21,460 Sign it. 217 00:09:21,460 --> 00:09:25,180 And Bob, at this point, has no risk. 218 00:09:25,180 --> 00:09:28,300 Bob, I guess, needs to make sure that he's not inadvertently 219 00:09:28,300 --> 00:09:30,580 signing his own money. 220 00:09:30,580 --> 00:09:32,560 So if Alice says, hey, here's the Tx ID, 221 00:09:32,560 --> 00:09:34,780 Bob should make sure, OK, this is not my Tx ID. 222 00:09:34,780 --> 00:09:36,700 Right? 223 00:09:36,700 --> 00:09:43,410 But it actually doesn't matter since he, sort of, commits 224 00:09:43,410 --> 00:09:44,910 to Alice's pub key here. 225 00:09:44,910 --> 00:09:49,760 So even if you've swapped the Tx ID, when you sign, 226 00:09:49,760 --> 00:09:51,682 you say this is two of two multisig. 227 00:09:51,682 --> 00:09:53,640 So if this was Bob's single key, it wouldn't it 228 00:09:53,640 --> 00:09:56,720 wouldn't even work. 229 00:09:56,720 --> 00:09:59,210 Yeah, so Alice has to give some information to Bob. 230 00:09:59,210 --> 00:10:01,490 Bob signs, hands the refund over to Alice, 231 00:10:01,490 --> 00:10:04,490 then Alice is able to create this fund transaction. 232 00:10:04,490 --> 00:10:06,800 And now Alice's risk is minimized because she says, 233 00:10:06,800 --> 00:10:11,973 OK, I'll send this to this channel and, worst case, 234 00:10:11,973 --> 00:10:12,890 I have to wait a week. 235 00:10:12,890 --> 00:10:13,390 Right? 236 00:10:13,390 --> 00:10:16,160 If Bob disappears as soon as I broadcast this, 237 00:10:16,160 --> 00:10:17,450 well, then Bob's gone. 238 00:10:17,450 --> 00:10:19,100 I can't do anything. 239 00:10:19,100 --> 00:10:20,270 We can't sign. 240 00:10:20,270 --> 00:10:23,330 But then, next week, I'll be able to use this transaction 241 00:10:23,330 --> 00:10:25,030 and get all my money back. 242 00:10:25,030 --> 00:10:25,530 Yes? 243 00:10:25,530 --> 00:10:27,185 AUDIENCE: You said that if this refund 244 00:10:27,185 --> 00:10:32,260 transaction is broadcasted, all the notes will be discarded. 245 00:10:32,260 --> 00:10:33,310 TADGE DRYJA: Yes. 246 00:10:33,310 --> 00:10:36,302 AUDIENCE: But then-- 247 00:10:36,302 --> 00:10:37,260 TADGE DRYJA: This week. 248 00:10:37,260 --> 00:10:39,010 AUDIENCE: --it has to be sent before Alice 249 00:10:39,010 --> 00:10:41,470 sends out the other transaction, right? 250 00:10:41,470 --> 00:10:44,510 Because what makes sure that Alice 251 00:10:44,510 --> 00:10:48,170 will have this transaction up there in the systems 252 00:10:48,170 --> 00:10:50,745 before the other transaction, before they're bought? 253 00:10:50,745 --> 00:10:52,140 TADGE DRYJA: Which transaction? 254 00:10:52,140 --> 00:10:54,070 So there's the fund and the refund. 255 00:10:54,070 --> 00:10:54,570 Right? 256 00:10:54,570 --> 00:10:55,237 AUDIENCE: Right. 257 00:10:55,237 --> 00:10:57,445 So the refund must be sent before the fund. 258 00:10:57,445 --> 00:11:00,750 TADGE DRYJA: No, it needs to be created before the fund. 259 00:11:00,750 --> 00:11:01,250 Right? 260 00:11:01,250 --> 00:11:03,170 So it's not going to be on the network. 261 00:11:03,170 --> 00:11:06,590 But Bob creates this first, signs it, 262 00:11:06,590 --> 00:11:08,030 and gives it to Alice. 263 00:11:08,030 --> 00:11:09,890 That way Alice knows, well, I have this 264 00:11:09,890 --> 00:11:11,850 that will be valid in a week. 265 00:11:11,850 --> 00:11:15,110 And so that means it's safe to sign and broadcast this. 266 00:11:15,110 --> 00:11:15,867 Yeah. 267 00:11:15,867 --> 00:11:17,450 AUDIENCE: And the refund just requires 268 00:11:17,450 --> 00:11:18,566 Alice's initial signature. 269 00:11:18,566 --> 00:11:19,316 TADGE DRYJA: Yeah. 270 00:11:19,316 --> 00:11:19,890 AUDIENCE: They're [INAUDIBLE]. 271 00:11:19,890 --> 00:11:20,680 OK. 272 00:11:20,680 --> 00:11:21,430 TADGE DRYJA: Yeah. 273 00:11:21,430 --> 00:11:23,860 So the refund transaction, it's got Bob's signature. 274 00:11:23,860 --> 00:11:25,460 And that's what hand you hand over. 275 00:11:25,460 --> 00:11:27,860 And then, Alice can sign later. 276 00:11:27,860 --> 00:11:30,410 She can sign it immediately on reception and then store it. 277 00:11:30,410 --> 00:11:34,545 Or she can sign it on March 28th. 278 00:11:34,545 --> 00:11:36,920 But the idea is she's got Bob's signature endorsing this. 279 00:11:36,920 --> 00:11:39,770 And it's not valid yet, but she knows minimize risk. 280 00:11:39,770 --> 00:11:40,370 Right? 281 00:11:40,370 --> 00:11:42,170 Worst case, wait a week. 282 00:11:42,170 --> 00:11:45,740 OK, so then what can you do with this? 283 00:11:45,740 --> 00:11:49,850 You can make, sort of, similar to refund transactions, 284 00:11:49,850 --> 00:11:52,390 but they give Bob more money. 285 00:11:52,390 --> 00:11:53,390 So you make two outputs. 286 00:11:53,390 --> 00:11:57,080 You say, OK, I'm spending the fund transaction ID. 287 00:11:57,080 --> 00:11:58,940 I put Alice's signature. 288 00:11:58,940 --> 00:12:00,860 And I say Alice gets nine coins. 289 00:12:00,860 --> 00:12:02,160 Bob gets one coin. 290 00:12:02,160 --> 00:12:04,438 And Alice hands that over to Bob. 291 00:12:04,438 --> 00:12:06,230 So you make a transaction like that, right. 292 00:12:06,230 --> 00:12:08,250 It spends the fund transaction output. 293 00:12:08,250 --> 00:12:10,910 Alice and Bob's key are both needed. 294 00:12:10,910 --> 00:12:13,220 And Alice signs this and says, OK, I get nine. 295 00:12:13,220 --> 00:12:14,090 You get one. 296 00:12:14,090 --> 00:12:16,320 Hands it over to Bob. 297 00:12:16,320 --> 00:12:20,960 And Bob says, basically, I just got the money. 298 00:12:20,960 --> 00:12:22,430 I can broadcast this if I want. 299 00:12:22,430 --> 00:12:22,930 Right? 300 00:12:22,930 --> 00:12:24,170 Bob's got Alice's signature. 301 00:12:24,170 --> 00:12:25,790 Bob can add his signature. 302 00:12:25,790 --> 00:12:29,450 Broadcast this transaction, and receive one Bitcoin. 303 00:12:29,450 --> 00:12:32,270 OK, but see, Bob doesn't sign his side in broadcast. 304 00:12:32,270 --> 00:12:33,470 Bob just waits. 305 00:12:33,470 --> 00:12:35,960 Bob's like, cool, I've got this coin. 306 00:12:35,960 --> 00:12:38,420 I'm not even going to sign and broadcast this. 307 00:12:38,420 --> 00:12:40,640 I know it's as good as having received 308 00:12:40,640 --> 00:12:44,210 the actual coin because there's nothing else Alice 309 00:12:44,210 --> 00:12:45,390 can do on her own. 310 00:12:45,390 --> 00:12:47,030 She can't take these 10 coins. 311 00:12:47,030 --> 00:12:49,200 She can, eventually, get the refund in a week. 312 00:12:49,200 --> 00:12:51,980 But for now, Bob's safe. 313 00:12:51,980 --> 00:12:54,930 And then, maybe a day later Alice says, 314 00:12:54,930 --> 00:12:57,800 OK, I'm giving you another coin. 315 00:12:57,800 --> 00:13:00,170 What I'm doing is I'm signing a new transaction. 316 00:13:00,170 --> 00:13:02,840 It spends the same output. 317 00:13:02,840 --> 00:13:03,930 This is still there. 318 00:13:03,930 --> 00:13:06,080 These have not been broadcast. 319 00:13:06,080 --> 00:13:08,240 But in this one, Alice gets eight coins. 320 00:13:08,240 --> 00:13:09,320 Bob gets two coins. 321 00:13:09,320 --> 00:13:10,430 Alice signs it. 322 00:13:10,430 --> 00:13:11,750 Hands that over to Bob. 323 00:13:11,750 --> 00:13:14,390 Bob's like, great, I got another coin. 324 00:13:14,390 --> 00:13:16,820 I will also just wait. 325 00:13:16,820 --> 00:13:21,040 Bob can actually delete this because, well, this is better. 326 00:13:21,040 --> 00:13:21,540 Right? 327 00:13:21,540 --> 00:13:26,060 From Bob's perspective, I'd rather have two than one. 328 00:13:26,060 --> 00:13:29,195 And any of them are valid. 329 00:13:29,195 --> 00:13:31,070 According to the network, the network itself, 330 00:13:31,070 --> 00:13:32,373 no one's seen these things. 331 00:13:32,373 --> 00:13:33,290 They're not broadcast. 332 00:13:33,290 --> 00:13:36,690 Only this exists as an output. 333 00:13:36,690 --> 00:13:38,630 And you can keep doing this. 334 00:13:38,630 --> 00:13:40,760 You can keep doing this as many times as you want. 335 00:13:40,760 --> 00:13:42,320 Well, within limits, right? 336 00:13:42,320 --> 00:13:44,247 What's the obvious limit here? 337 00:13:44,247 --> 00:13:45,830 AUDIENCE: 10 BTC when Alice bought it. 338 00:13:45,830 --> 00:13:46,650 TADGE DRYJA: Yeah. 339 00:13:46,650 --> 00:13:47,150 Sure. 340 00:13:47,150 --> 00:13:51,830 Once Bob gets all 10, there's no reason to keep it open anymore. 341 00:13:51,830 --> 00:13:54,240 Also, you can't reverse. 342 00:13:54,240 --> 00:13:54,740 Right? 343 00:13:57,350 --> 00:13:59,217 So Alice is always sending money. 344 00:13:59,217 --> 00:14:01,550 If Bob says, hey, I'm going to give you some money back, 345 00:14:01,550 --> 00:14:04,310 and Bob signs something and say, hey, now I have two coins 346 00:14:04,310 --> 00:14:05,570 and you have eight coins. 347 00:14:05,570 --> 00:14:08,760 Alice is like, yeah, but you have this. 348 00:14:08,760 --> 00:14:09,260 Right? 349 00:14:09,260 --> 00:14:12,790 You have this Alice 7 Bob 3 transaction. 350 00:14:12,790 --> 00:14:14,790 I know you can broadcast that whenever you want. 351 00:14:14,790 --> 00:14:17,030 So there's no credible way for Bob 352 00:14:17,030 --> 00:14:20,090 to say like, oh, I'm giving you the money back in this channel. 353 00:14:20,090 --> 00:14:21,170 Right? 354 00:14:21,170 --> 00:14:21,735 Yes? 355 00:14:21,735 --> 00:14:26,850 AUDIENCE: But what if the next transaction Alice signs-- 356 00:14:26,850 --> 00:14:30,170 so she gave 1, 2, and 3. 357 00:14:30,170 --> 00:14:34,775 And the next one, she gives Bob 2.5 and keeps 7.5. 358 00:14:34,775 --> 00:14:35,520 Is that right? 359 00:14:35,520 --> 00:14:39,230 TADGE DRYJA: Yeah, Bob would just ignore it. 360 00:14:39,230 --> 00:14:42,440 Bob would be like, yeah, but I already have three. 361 00:14:42,440 --> 00:14:43,610 Why would I want 2 1/2? 362 00:14:46,340 --> 00:14:48,315 And it's more like, in that case, 363 00:14:48,315 --> 00:14:49,940 if Alice says, oh, I have two, Alice is 364 00:14:49,940 --> 00:14:51,232 trying to take some money back. 365 00:14:51,232 --> 00:14:53,450 Essentially, Bob is paying Alice, in that case. 366 00:14:53,450 --> 00:14:54,650 But it's not credible. 367 00:14:54,650 --> 00:14:57,650 Alice is like, yeah, I can sign this again. 368 00:14:57,650 --> 00:14:59,750 Or I have all 10 again. 369 00:14:59,750 --> 00:15:01,730 But you know, Bob's idea is like, I'm just 370 00:15:01,730 --> 00:15:05,500 going to sign the one where I get the most money. 371 00:15:05,500 --> 00:15:07,510 So you know, that's a limitation. 372 00:15:07,510 --> 00:15:09,260 It's one direction. 373 00:15:09,260 --> 00:15:10,800 Alice can keep paying Bob. 374 00:15:10,800 --> 00:15:11,810 Bob can't pay back. 375 00:15:11,810 --> 00:15:14,610 But that's still pretty useful, in some cases. 376 00:15:14,610 --> 00:15:17,600 If you have some kind of recurrent payment, 377 00:15:17,600 --> 00:15:19,710 you're streaming videos or something. 378 00:15:19,710 --> 00:15:22,340 You open a channel, you can keep paying. 379 00:15:22,340 --> 00:15:24,440 One thing that's nice is these can be really fast. 380 00:15:24,440 --> 00:15:26,480 So this, you have to actually wait 381 00:15:26,480 --> 00:15:27,770 till it's in the blockchain. 382 00:15:27,770 --> 00:15:30,170 But these transactions, there's no blockchain involved. 383 00:15:30,170 --> 00:15:32,420 You just sign it, and hand it over to the other party. 384 00:15:32,420 --> 00:15:35,040 And as soon as they've received it, they're like, yep, 385 00:15:35,040 --> 00:15:36,080 I got the money. 386 00:15:36,080 --> 00:15:38,030 So this can be very low latency. 387 00:15:38,030 --> 00:15:39,900 So this is pretty cool. 388 00:15:39,900 --> 00:15:42,030 There are limitations. 389 00:15:42,030 --> 00:15:42,530 So, yeah. 390 00:15:42,530 --> 00:15:44,870 Bob keeps getting these half signed transactions 391 00:15:44,870 --> 00:15:47,120 with more and more money going to him. 392 00:15:47,120 --> 00:15:48,440 The old ones are useless. 393 00:15:48,440 --> 00:15:50,210 Why would I keep this old transaction 394 00:15:50,210 --> 00:15:51,160 where I got one coin? 395 00:15:51,160 --> 00:15:52,340 Just delete it. 396 00:15:52,340 --> 00:15:55,443 So Bob only actually has to store one thing. 397 00:15:55,443 --> 00:15:57,110 Bob also has to be very careful, though. 398 00:15:57,110 --> 00:16:01,250 He's got to sign and broadcast one of these before next week. 399 00:16:01,250 --> 00:16:03,620 If he doesn't, Alice could just broadcast the refund 400 00:16:03,620 --> 00:16:04,780 transaction. 401 00:16:04,780 --> 00:16:07,125 And you know, he thinks he's getting three coins, 402 00:16:07,125 --> 00:16:09,250 but Alice is like, no, I'm just taking all 10 back. 403 00:16:09,250 --> 00:16:12,920 And Bob was like, shoot, I just got ripped off. 404 00:16:12,920 --> 00:16:16,880 So from the Bitcoin network's point of view, 405 00:16:16,880 --> 00:16:18,500 no one's seen any of this. 406 00:16:18,500 --> 00:16:20,870 All they see is the fund transaction. 407 00:16:20,870 --> 00:16:23,060 Nothing happens for days. 408 00:16:23,060 --> 00:16:24,920 And then, they see one of these payment 409 00:16:24,920 --> 00:16:27,383 channel closing transactions. 410 00:16:27,383 --> 00:16:28,550 And they might see multiple. 411 00:16:28,550 --> 00:16:29,050 Right? 412 00:16:29,050 --> 00:16:30,645 Bob could broadcast all three. 413 00:16:30,645 --> 00:16:31,610 It would be dumb. 414 00:16:31,610 --> 00:16:32,780 Bob only wants this one. 415 00:16:32,780 --> 00:16:36,080 But you're, basically, using double spends 416 00:16:36,080 --> 00:16:38,060 to create these channels. 417 00:16:40,800 --> 00:16:41,300 yes? 418 00:16:41,300 --> 00:16:42,920 AUDIENCE: So the refund transaction 419 00:16:42,920 --> 00:16:46,030 is pretty much insurance, right, for Alice? 420 00:16:46,030 --> 00:16:46,780 TADGE DRYJA: Yeah. 421 00:16:46,780 --> 00:16:53,750 If it happens, that means either Bob went down or Bob never-- 422 00:16:53,750 --> 00:16:56,800 you should never use it in real life. 423 00:16:56,800 --> 00:16:59,290 It's insurance so that you're not 424 00:16:59,290 --> 00:17:01,330 worried that Bob's just going to run off and get 425 00:17:01,330 --> 00:17:02,070 your funds stuck. 426 00:17:02,070 --> 00:17:04,310 AUDIENCE: So in the case that, both, Allison and Bob 427 00:17:04,310 --> 00:17:09,630 are honest actors, I guess, in this situation, 428 00:17:09,630 --> 00:17:14,300 if a week does go by, there's no reason for Alice to actually 429 00:17:14,300 --> 00:17:18,050 use that refund transaction, right? 430 00:17:18,050 --> 00:17:20,908 There's no guarantee that she's going to use it in a week. 431 00:17:20,908 --> 00:17:21,700 TADGE DRYJA: Right. 432 00:17:21,700 --> 00:17:23,290 But you can't keep using the cha-- 433 00:17:23,290 --> 00:17:27,143 like, at that point, there's so much trust involved. 434 00:17:27,143 --> 00:17:29,560 If you keep trying to use the channel after the weeks gone 435 00:17:29,560 --> 00:17:31,410 by, Bob now-- 436 00:17:31,410 --> 00:17:34,190 like, it's the same reason you can't make it bidirectional. 437 00:17:34,190 --> 00:17:34,690 Right? 438 00:17:34,690 --> 00:17:36,523 If Bob says, hey, here's a transaction where 439 00:17:36,523 --> 00:17:38,590 you get more of the money, Alice is like, yeah, 440 00:17:38,590 --> 00:17:40,930 but that's not credible because I 441 00:17:40,930 --> 00:17:43,342 know you can broadcast and take more. 442 00:17:43,342 --> 00:17:44,800 And similarly, if Alice says, let's 443 00:17:44,800 --> 00:17:46,690 just keep the channel open, Bob's like, 444 00:17:46,690 --> 00:17:48,760 no, that's not credible. 445 00:17:48,760 --> 00:17:50,980 I know you can just take all the money at any time. 446 00:17:50,980 --> 00:17:52,930 So you handing me these new signatures, 447 00:17:52,930 --> 00:17:55,692 like, it's, sort of, meaningless. 448 00:17:55,692 --> 00:17:57,400 There's so much trust involved that like, 449 00:17:57,400 --> 00:18:00,790 why bother with this whole payment channel thing, right? 450 00:18:00,790 --> 00:18:03,850 So this is nice in that you don't have 451 00:18:03,850 --> 00:18:05,710 to trust the counter parties. 452 00:18:05,710 --> 00:18:09,355 The worst they can do is disappear. 453 00:18:09,355 --> 00:18:10,980 I mean, yeah, they can hurt themselves. 454 00:18:10,980 --> 00:18:11,480 Right? 455 00:18:11,480 --> 00:18:14,458 Bob can broadcast this after this exists. 456 00:18:14,458 --> 00:18:16,000 And Alice is like, OK, that was dumb. 457 00:18:16,000 --> 00:18:18,460 Thanks for the two coins back. 458 00:18:18,460 --> 00:18:19,690 Or Bob can just disappear. 459 00:18:19,690 --> 00:18:23,303 And Alice is like, hey, I'm going to do the refund. 460 00:18:23,303 --> 00:18:25,720 You're supposed to get these three coins, but you're gone. 461 00:18:25,720 --> 00:18:31,343 And the refund is my only option, so I'm broadcasting it. 462 00:18:31,343 --> 00:18:33,760 So you don't have to worry about who is your counterparty. 463 00:18:33,760 --> 00:18:35,500 And you don't have any debt. 464 00:18:35,500 --> 00:18:37,760 There's no custody or anything like that. 465 00:18:37,760 --> 00:18:40,360 So that's really nice. 466 00:18:40,360 --> 00:18:42,483 You can add trust, but we already 467 00:18:42,483 --> 00:18:44,400 have that with Coinbase and Gemini-- you know, 468 00:18:44,400 --> 00:18:45,842 the exchanges. 469 00:18:45,842 --> 00:18:47,050 OK, so this is pretty useful. 470 00:18:50,130 --> 00:18:51,630 Time limits. 471 00:18:51,630 --> 00:18:54,060 Limits on back and forth. 472 00:18:54,060 --> 00:18:57,510 Refund transactions have to be built before the fund 473 00:18:57,510 --> 00:19:00,390 transaction, and so malleability hurts that. 474 00:19:00,390 --> 00:19:03,610 Before segwit, this was very risky, 475 00:19:03,610 --> 00:19:06,030 slash you couldn't really do it. 476 00:19:06,030 --> 00:19:09,540 The refund transaction has to spend the fund transaction. 477 00:19:09,540 --> 00:19:12,055 And without segwit, you don't know 478 00:19:12,055 --> 00:19:13,430 what that transaction ID is going 479 00:19:13,430 --> 00:19:17,320 to be before it gets confirmed. 480 00:19:17,320 --> 00:19:20,130 And so you can try to anticipate, oh, well 481 00:19:20,130 --> 00:19:22,590 it might get malleated to these five different things. 482 00:19:22,590 --> 00:19:23,250 Let's do it. 483 00:19:26,430 --> 00:19:27,620 But it's risky. 484 00:19:27,620 --> 00:19:28,900 So with segit, it's nice. 485 00:19:28,900 --> 00:19:30,360 You don't have to worry about it. 486 00:19:30,360 --> 00:19:33,780 OK, so any questions about the simple, one direction payments? 487 00:19:36,570 --> 00:19:37,680 Makes sense? 488 00:19:37,680 --> 00:19:38,180 OK. 489 00:19:38,180 --> 00:19:41,160 So how can you make it even better? 490 00:19:41,160 --> 00:19:44,210 What if you want to make it bidirectional and last forever? 491 00:19:44,210 --> 00:19:45,650 That would be much more useful. 492 00:19:45,650 --> 00:19:46,310 Right? 493 00:19:46,310 --> 00:19:48,500 But it's a tricky problem. 494 00:19:48,500 --> 00:19:51,710 The refund transaction is there, and the clock's ticking. 495 00:19:51,710 --> 00:19:55,250 Also, how do you delete or revoke these old transaction? 496 00:19:55,250 --> 00:19:57,800 if you've signed over, OK, you've got eight coins. 497 00:19:57,800 --> 00:20:00,520 I've got two coins. 498 00:20:00,520 --> 00:20:01,900 That's there forever. 499 00:20:01,900 --> 00:20:05,080 And the blockchain doesn't know that it's not valid anymore. 500 00:20:05,080 --> 00:20:05,930 Right? 501 00:20:05,930 --> 00:20:07,305 The whole point of the blockchain 502 00:20:07,305 --> 00:20:09,450 is to say, OK, this is gone. 503 00:20:09,450 --> 00:20:13,740 Actually, between the unidirectional and lightening, 504 00:20:13,740 --> 00:20:15,640 I think-- 505 00:20:15,640 --> 00:20:16,520 how did the order go? 506 00:20:16,520 --> 00:20:18,020 Like, Christian Decker wrote a thing 507 00:20:18,020 --> 00:20:20,600 about decrementing time locks. 508 00:20:20,600 --> 00:20:22,370 And I don't think he published. 509 00:20:22,370 --> 00:20:24,830 I think he published after we wrote lightning. 510 00:20:24,830 --> 00:20:27,830 But the idea was these would have lock times. 511 00:20:27,830 --> 00:20:34,420 It's like, you could broadcast this on the 27th. 512 00:20:34,420 --> 00:20:36,640 All three of these could be broadcast on the 27th. 513 00:20:36,640 --> 00:20:39,210 And then, the idea is Bob wants to send money back. 514 00:20:39,210 --> 00:20:42,020 And you put a lock time on the 26th. 515 00:20:42,020 --> 00:20:46,300 And the idea is like, oh, now these all are 27th. 516 00:20:46,300 --> 00:20:49,650 But now there's a Bob 2 Alice 8 over here that's 517 00:20:49,650 --> 00:20:51,550 the broadcastable on the 26th. 518 00:20:51,550 --> 00:20:55,330 And so the idea is, well, Alice can get the money back. 519 00:20:55,330 --> 00:20:58,090 Bob can go back to paying Alice because it's sooner, 520 00:20:58,090 --> 00:20:59,320 and Alice can raise. 521 00:20:59,320 --> 00:21:02,140 So that helps a little in that you can switch back and forth 522 00:21:02,140 --> 00:21:02,860 a few times. 523 00:21:02,860 --> 00:21:07,850 But each time you do it, the time window gets sooner. 524 00:21:07,850 --> 00:21:09,400 So that's, kind of, a cool idea. 525 00:21:09,400 --> 00:21:12,760 But I think the lightening one is nicer because it makes it-- 526 00:21:12,760 --> 00:21:16,355 OK, the goal is back and forth between these two parties. 527 00:21:16,355 --> 00:21:17,230 And it lasts forever. 528 00:21:17,230 --> 00:21:19,780 And you can do as many transactions as you want. 529 00:21:19,780 --> 00:21:20,280 OK. 530 00:21:20,280 --> 00:21:21,270 So how do you do that? 531 00:21:21,270 --> 00:21:24,090 So there's two timing up quotes that 532 00:21:24,090 --> 00:21:26,060 have been added to Bitcoin. 533 00:21:26,060 --> 00:21:29,160 And CHECKSEQUENCEVERIFY is pretty much for lightning, 534 00:21:29,160 --> 00:21:30,848 in my opinion. 535 00:21:30,848 --> 00:21:31,890 That's the real use case. 536 00:21:31,890 --> 00:21:34,960 There's also CHECKLOCKTIMEVERIFY. 537 00:21:34,960 --> 00:21:39,580 So the idea of SEQUENCEVERIFY is it's a relative lock time. 538 00:21:39,580 --> 00:21:41,710 So it doesn't specify, OK, this transaction 539 00:21:41,710 --> 00:21:43,720 is valid on March 28th. 540 00:21:43,720 --> 00:21:46,420 It says, this transaction is valid 541 00:21:46,420 --> 00:21:49,390 when the input it's spending is a week old. 542 00:21:49,390 --> 00:21:53,620 And by a week old, it's in a week's worth of blocks. 543 00:21:53,620 --> 00:21:55,900 In the actual software, we don't usually use time. 544 00:21:55,900 --> 00:21:58,620 We always use block height. 545 00:21:58,620 --> 00:22:01,150 It's simpler to think about, in a lot of ways. 546 00:22:01,150 --> 00:22:06,670 But you can say, OK, well I send to an output script. 547 00:22:06,670 --> 00:22:08,740 And the output script specifies that you can only 548 00:22:08,740 --> 00:22:13,060 spend these coins after the transaction creating 549 00:22:13,060 --> 00:22:17,920 them has been 100 blocks deep. 550 00:22:17,920 --> 00:22:21,520 So that's, kind of, an interesting, useful thing. 551 00:22:21,520 --> 00:22:22,720 Yeah, and confirmations. 552 00:22:22,720 --> 00:22:24,980 If not, you can't spend it. 553 00:22:24,980 --> 00:22:26,760 OP_CHECKLOCKTIMEVERIFY. 554 00:22:26,760 --> 00:22:28,830 It's a lot absolute lock time opcode. 555 00:22:28,830 --> 00:22:32,130 So you require that the transaction be 556 00:22:32,130 --> 00:22:37,320 confirmed at high end or above. 557 00:22:37,320 --> 00:22:42,270 So what we said in the refund transaction, the refund 558 00:22:42,270 --> 00:22:45,790 transaction, the transaction field has a lock time. 559 00:22:50,630 --> 00:22:51,130 Where is it? 560 00:22:51,130 --> 00:22:52,710 Oh, well, in this case, yeah. 561 00:22:52,710 --> 00:22:55,980 But the transaction itself has a locktime. 562 00:22:55,980 --> 00:22:58,100 But that's difference from the opcode. 563 00:22:58,100 --> 00:23:00,500 What the opcode does, it says, OK, this output 564 00:23:00,500 --> 00:23:02,510 has a locktime because the output 565 00:23:02,510 --> 00:23:06,380 script ensures that the transaction itself 566 00:23:06,380 --> 00:23:07,730 has a locktime. 567 00:23:07,730 --> 00:23:13,910 So basically, you say OP_CHECKLOCKTIMEVERIFY 500,000. 568 00:23:13,910 --> 00:23:18,860 And then, it checks that the transactions locktime field 569 00:23:18,860 --> 00:23:23,570 is exactly equal to 500,000. 570 00:23:23,570 --> 00:23:26,570 So it's a way to enforce a transaction wide field 571 00:23:26,570 --> 00:23:28,200 inside of an output. 572 00:23:28,200 --> 00:23:29,900 It's a little weird. 573 00:23:29,900 --> 00:23:33,040 But both of these become opcodes that you can use in scripts. 574 00:23:33,040 --> 00:23:36,680 And now, you can specify, like, make an address that has 575 00:23:36,680 --> 00:23:38,740 these weird timing properties. 576 00:23:38,740 --> 00:23:39,240 OK. 577 00:23:39,240 --> 00:23:40,710 Any questions about these two? 578 00:23:40,710 --> 00:23:41,556 AUDIENCE: Can you use both of them? 579 00:23:41,556 --> 00:23:42,360 TADGE DRYJA: Yep. 580 00:23:42,360 --> 00:23:43,693 You can mix them and match them. 581 00:23:45,970 --> 00:23:49,220 CHECKSEQUENCEVERIFY is specific to an input. 582 00:23:49,220 --> 00:23:53,470 So there's a sequence field in each input that was completely 583 00:23:53,470 --> 00:23:54,825 useless until like-- 584 00:23:54,825 --> 00:23:55,690 AUDIENCE: This or-- 585 00:23:55,690 --> 00:23:56,440 TADGE DRYJA: What? 586 00:23:56,440 --> 00:23:57,745 AUDIENCE: Like, this or that. 587 00:23:57,745 --> 00:24:02,440 TADGE DRYJA: Well, OK, so if you look, there's a sequence. 588 00:24:02,440 --> 00:24:04,740 And it was always just FFFFF. 589 00:24:04,740 --> 00:24:07,800 You know, that's like 2 to the 32 or whatever. 590 00:24:07,800 --> 00:24:09,520 2 to 32 minus 1, I think. 591 00:24:09,520 --> 00:24:11,770 And it didn't do anything. 592 00:24:11,770 --> 00:24:14,650 Satoshi put it in because he thought, OK, this 593 00:24:14,650 --> 00:24:18,497 will let you indicate finality where you can increment 594 00:24:18,497 --> 00:24:19,330 the sequence number. 595 00:24:19,330 --> 00:24:21,280 So you say, OK, this is sequence 1. 596 00:24:21,280 --> 00:24:23,200 And then, I can replace it with sequence 2. 597 00:24:23,200 --> 00:24:25,360 And it didn't work because you can't 598 00:24:25,360 --> 00:24:27,110 have consensus on those things. 599 00:24:27,110 --> 00:24:30,970 So this was a field that was, sort of, unused in the inputs. 600 00:24:30,970 --> 00:24:33,820 And what they did is they said, OK, we'll 601 00:24:33,820 --> 00:24:37,355 make that a sequence number where if you now make this, 602 00:24:37,355 --> 00:24:37,855 say-- 603 00:24:41,062 --> 00:24:43,500 how did it work-- 604 00:24:43,500 --> 00:24:46,710 you make the sequence number 100, for example. 605 00:24:46,710 --> 00:24:50,400 And then, in your transaction, it will say, OK, 606 00:24:50,400 --> 00:24:55,590 this transaction output that you're spending, 607 00:24:55,590 --> 00:24:57,600 is it 100 blocks old? 608 00:24:57,600 --> 00:24:59,380 And if so, we're good. 609 00:24:59,380 --> 00:25:01,560 If not, this input spending fails. 610 00:25:01,560 --> 00:25:04,950 So it's another check in addition to the signature. 611 00:25:04,950 --> 00:25:09,840 And then, you can also ensure that, with CHECKSEQUENCEVERIFY, 612 00:25:09,840 --> 00:25:11,160 you can put in the opcodes. 613 00:25:11,160 --> 00:25:12,330 You can put in the script. 614 00:25:12,330 --> 00:25:16,200 OK, this must have a sequence of 100. 615 00:25:16,200 --> 00:25:21,030 And then, check that sequence is equal or greater to the depth 616 00:25:21,030 --> 00:25:22,442 of the transaction. 617 00:25:22,442 --> 00:25:26,750 And yeah, you can mix them and match them in the same script. 618 00:25:26,750 --> 00:25:28,430 It's a little ugly to use because it 619 00:25:28,430 --> 00:25:30,530 was introduced as a soft work. 620 00:25:30,530 --> 00:25:35,710 And they rename and op and op. 621 00:25:35,710 --> 00:25:38,840 A no op opcode got renamed to this. 622 00:25:38,840 --> 00:25:40,225 This is, like, no op 3. 623 00:25:40,225 --> 00:25:43,780 6 And so you have to push the number 624 00:25:43,780 --> 00:25:46,420 you're checking on the stack, OP_CHECKSEQUENCEVERIFY. 625 00:25:46,420 --> 00:25:49,060 And then, you have to drop the number off the stack 626 00:25:49,060 --> 00:25:51,518 because this opcode doesn't actually consume anything 627 00:25:51,518 --> 00:25:53,810 off the top of the stack so that it looks the same as a 628 00:25:53,810 --> 00:25:56,780 no up to nodes that don't know about it. 629 00:25:56,780 --> 00:25:57,280 Anyway. 630 00:25:57,280 --> 00:26:02,010 So you've got these two ways to specify output timing. 631 00:26:02,010 --> 00:26:02,723 OK. 632 00:26:02,723 --> 00:26:03,390 Questions there? 633 00:26:03,390 --> 00:26:04,290 Good. 634 00:26:04,290 --> 00:26:08,050 So then, what you can do is you can revoke based on timing. 635 00:26:08,050 --> 00:26:10,050 So the idea of the script-- 636 00:26:10,050 --> 00:26:12,030 and this is, sort of, in C like notation, 637 00:26:12,030 --> 00:26:14,160 not the actual opcodes for Bitcoin 638 00:26:14,160 --> 00:26:17,500 because the actual opcodes are, kind of, confusing-- 639 00:26:17,500 --> 00:26:21,480 the idea is, OK, you can spend with 2 of 2 multisig, 640 00:26:21,480 --> 00:26:22,335 essentially, right? 641 00:26:22,335 --> 00:26:29,250 keyA and keyB, or keyC, and wait 100 blocks. 642 00:26:29,250 --> 00:26:32,170 And by wait 100 blocks, it means that whatever you're spending 643 00:26:32,170 --> 00:26:35,700 has to be confirmed 100 blocks ago or more. 644 00:26:35,700 --> 00:26:39,790 So A and B together, they can spend any time they want. 645 00:26:39,790 --> 00:26:40,290 Together? 646 00:26:40,290 --> 00:26:42,210 Oops. 647 00:26:42,210 --> 00:26:45,640 C can spend, but must wait. 648 00:26:45,640 --> 00:26:47,530 And A and B can grab their coins first. 649 00:26:50,130 --> 00:26:52,770 So this is a revokable transaction. 650 00:26:52,770 --> 00:26:54,577 So the idea is you've got some-- 651 00:26:54,577 --> 00:26:56,910 and we call it a commitment transaction in the lightning 652 00:26:56,910 --> 00:26:57,780 paper. 653 00:26:57,780 --> 00:26:58,770 You've got some input. 654 00:26:58,770 --> 00:27:00,540 The funding transaction output. 655 00:27:00,540 --> 00:27:02,220 You're spending that. 656 00:27:02,220 --> 00:27:03,410 You need 2 of 2 multisig. 657 00:27:03,410 --> 00:27:07,357 So like, Bob's signs and sends it over to Alice. 658 00:27:07,357 --> 00:27:08,940 And then, you've got that script where 659 00:27:08,940 --> 00:27:11,610 it's, OK, it's Alice's key, and you wait 100 blocks. 660 00:27:11,610 --> 00:27:14,020 Or Alice's key and you make a new key for Bob. 661 00:27:14,020 --> 00:27:17,490 Like, the Bob revoke key. 662 00:27:17,490 --> 00:27:18,960 And this has 2 coins. 663 00:27:18,960 --> 00:27:19,790 This has 8 coins. 664 00:27:23,560 --> 00:27:24,140 Oh. 665 00:27:24,140 --> 00:27:25,280 Oops. 666 00:27:25,280 --> 00:27:26,160 This should be our-- 667 00:27:26,160 --> 00:27:26,660 hold on. 668 00:27:26,660 --> 00:27:27,590 I should change that. 669 00:27:27,590 --> 00:27:29,526 That's, kind of, going to be really confusing. 670 00:27:29,526 --> 00:27:30,400 Wait. 671 00:27:30,400 --> 00:27:32,750 I put the r in the wrong place. 672 00:27:32,750 --> 00:27:36,210 Let me redo this. 673 00:27:36,210 --> 00:27:39,558 That's a typo, but it's super confusing. 674 00:27:42,630 --> 00:27:46,218 Yeah, that is opposite. 675 00:27:46,218 --> 00:27:47,150 Wait. 676 00:27:47,150 --> 00:27:48,480 AliceR and Bob. 677 00:27:51,880 --> 00:27:53,847 Alice and Bob are-- wait. 678 00:27:53,847 --> 00:27:55,180 So I put the same thing on both. 679 00:27:55,180 --> 00:27:55,821 Right? 680 00:27:55,821 --> 00:27:59,050 Alice and Bob are-- 681 00:27:59,050 --> 00:28:03,080 this one is AliceR and Bob. 682 00:28:03,080 --> 00:28:08,290 Yeah, and when you're actually coding this stuff, 683 00:28:08,290 --> 00:28:09,865 it's pretty easy to screw up. 684 00:28:09,865 --> 00:28:12,240 There's a lot of like, wait, who is Alice and who is Bob? 685 00:28:12,240 --> 00:28:14,282 So in any of the code, I don't use Alice and Bob. 686 00:28:14,282 --> 00:28:17,300 I use mine and theirs. 687 00:28:17,300 --> 00:28:19,500 But a lot of times, it's not clear 688 00:28:19,500 --> 00:28:22,170 because it's held by Alice. 689 00:28:22,170 --> 00:28:26,000 So this is the transaction that Bob creates, Bob's signs, 690 00:28:26,000 --> 00:28:29,560 transfers to Alice, and then it sits on Alice's hard drive. 691 00:28:29,560 --> 00:28:30,060 Yes? 692 00:28:30,060 --> 00:28:30,900 AUDIENCE: AliceR? 693 00:28:30,900 --> 00:28:35,070 TADGE DRYJA: OK, so you make these separate keys. 694 00:28:35,070 --> 00:28:36,700 Right? 695 00:28:36,700 --> 00:28:38,490 It's a key that Alice creates. 696 00:28:38,490 --> 00:28:41,160 Alice creates another pub key pair, 697 00:28:41,160 --> 00:28:44,700 and tells the pub key to Bob. 698 00:28:44,700 --> 00:28:47,088 And this is her revocable key. 699 00:28:47,088 --> 00:28:48,130 AUDIENCE: The revocation. 700 00:28:48,130 --> 00:28:49,420 TADGE DRYJA: Yeah, where Alice can then-- 701 00:28:49,420 --> 00:28:50,878 basically, what Alice does is Alice 702 00:28:50,878 --> 00:28:54,560 gives the private key to Bob in order 703 00:28:54,560 --> 00:28:56,270 to revoke this transaction. 704 00:28:56,270 --> 00:29:00,470 So they're, sort of, mirror images. 705 00:29:00,470 --> 00:29:03,050 In both cases, both parties agree, look, 706 00:29:03,050 --> 00:29:04,400 Alice has got 2 coins. 707 00:29:04,400 --> 00:29:05,710 Bob's got 8 coins. 708 00:29:05,710 --> 00:29:06,770 Right? 709 00:29:06,770 --> 00:29:11,420 But the transaction that Bob creates and signs-- 710 00:29:14,550 --> 00:29:16,860 yes, the transaction that Bob creates and signs 711 00:29:16,860 --> 00:29:19,560 sends Bob 8 coins in the clear. 712 00:29:19,560 --> 00:29:21,870 This is just a regular old pay to pub key hash 713 00:29:21,870 --> 00:29:23,520 where Bob gets 8 coins. 714 00:29:23,520 --> 00:29:27,030 The coins that are Alice's though, Alice 715 00:29:27,030 --> 00:29:28,470 has to wait 100 blocks. 716 00:29:28,470 --> 00:29:31,410 If she broadcasts this commitment transaction, 717 00:29:31,410 --> 00:29:34,200 she can't spend her money for a day. 718 00:29:34,200 --> 00:29:38,970 Like, whatever 100 block is. 719 00:29:38,970 --> 00:29:43,120 Bob can get the money, but only if he knows Alice's R key, 720 00:29:43,120 --> 00:29:45,960 Alice's revocable key. 721 00:29:45,960 --> 00:29:53,210 So Alice has this Bob doesn't and in the Bob case 722 00:29:53,210 --> 00:29:55,520 it's similar you know the outputs are the same 723 00:29:55,520 --> 00:29:58,940 but the ideas Alice creates this. 724 00:29:58,940 --> 00:30:00,740 Alice signs it. 725 00:30:00,740 --> 00:30:02,270 Hands it over to Bob. 726 00:30:02,270 --> 00:30:03,800 And in this case, the transaction 727 00:30:03,800 --> 00:30:06,660 is, well, Alice gets 2 coins in the clear. 728 00:30:06,660 --> 00:30:07,940 This is immediately spendable. 729 00:30:07,940 --> 00:30:09,980 No fancy scripts or anything. 730 00:30:09,980 --> 00:30:14,180 Bob gets the money, but he has to wait a day. 731 00:30:14,180 --> 00:30:16,280 Or Alice can spend the money if she 732 00:30:16,280 --> 00:30:21,210 knows Bob's revokable key is BobR key. 733 00:30:21,210 --> 00:30:23,430 So either party, at any time, can 734 00:30:23,430 --> 00:30:25,260 broadcast these transactions. 735 00:30:25,260 --> 00:30:27,780 The thing is, the money they're supposed to get-- 736 00:30:27,780 --> 00:30:31,840 so in Bob's case, Bob can have Bob's signature broadcast, 737 00:30:31,840 --> 00:30:33,330 but now he has to wait. 738 00:30:33,330 --> 00:30:33,990 No big deal. 739 00:30:33,990 --> 00:30:35,130 Wait 100 blocks. 740 00:30:35,130 --> 00:30:35,860 OK. 741 00:30:35,860 --> 00:30:40,320 In Alice's case, OK, she can close it and put her signature 742 00:30:40,320 --> 00:30:45,060 on here, broadcast, wait a day, spend the money. 743 00:30:45,060 --> 00:30:47,410 But what's nice is you can revoke it. 744 00:30:47,410 --> 00:30:47,910 Right? 745 00:30:47,910 --> 00:30:54,750 So Alice can tell Bob I'm not going to do this. 746 00:30:54,750 --> 00:30:58,230 I'm not going to use this transaction. 747 00:30:58,230 --> 00:30:59,310 You know, I deleted it. 748 00:30:59,310 --> 00:31:01,680 And Bob's like, yeah, sure you deleted it. 749 00:31:01,680 --> 00:31:03,900 The way I'll prove to you that I deleted this is I 750 00:31:03,900 --> 00:31:06,240 will tell you the private key. 751 00:31:06,240 --> 00:31:08,010 I'll tell you AliceR. 752 00:31:08,010 --> 00:31:11,890 So now Bob knows because Bob created this transaction. 753 00:31:11,890 --> 00:31:12,390 Right? 754 00:31:12,390 --> 00:31:13,140 Bob signed it. 755 00:31:13,140 --> 00:31:14,700 Bob knows what it looks like. 756 00:31:14,700 --> 00:31:17,100 And Bob knows, well, yeah, this is the script. 757 00:31:17,100 --> 00:31:21,300 Since Bob knows AliceR and Bob knows his own key, Bob knows, 758 00:31:21,300 --> 00:31:23,580 look, this money is mine. 759 00:31:23,580 --> 00:31:27,700 This money's mine too because I can do this immediately. 760 00:31:27,700 --> 00:31:29,550 So if you broadcast this transaction, 761 00:31:29,550 --> 00:31:32,190 I don't have to even touch this because this was my money. 762 00:31:32,190 --> 00:31:35,420 And this output, I can spend immediately 763 00:31:35,420 --> 00:31:38,160 while you have to wait 100 blocks. 764 00:31:38,160 --> 00:31:40,660 And you know, my software is going to automatically do that. 765 00:31:40,660 --> 00:31:42,780 So I know AliceR's private key. 766 00:31:42,780 --> 00:31:44,490 I know Bob's private key. 767 00:31:44,490 --> 00:31:45,780 I just take these 2 coins. 768 00:31:45,780 --> 00:31:47,580 As soon as I see this transaction, 769 00:31:47,580 --> 00:31:50,460 I take these 2 coins, I spend them back to Bob's address 770 00:31:50,460 --> 00:31:52,750 and get all 10. 771 00:31:52,750 --> 00:31:54,700 So that's a pretty convincing way for Alice 772 00:31:54,700 --> 00:31:56,690 to say, look, I'm not going to use this. 773 00:31:56,690 --> 00:32:00,040 I'm deleting to show, even if I do use it, here. 774 00:32:00,040 --> 00:32:01,950 Here's the key. 775 00:32:01,950 --> 00:32:03,360 Any questions about this? 776 00:32:03,360 --> 00:32:06,840 AUDIENCE: Does Alice have to voluntarily give her key up? 777 00:32:06,840 --> 00:32:07,760 TADGE DRYJA: Yep. 778 00:32:07,760 --> 00:32:09,520 Yeah, so Alice has to hand it over. 779 00:32:09,520 --> 00:32:10,140 Right? 780 00:32:10,140 --> 00:32:15,570 This is just a regular 32 byte private key that Alice created 781 00:32:15,570 --> 00:32:18,150 and same idea for Bob. 782 00:32:18,150 --> 00:32:21,480 They both create, essentially, the same transaction 783 00:32:21,480 --> 00:32:24,450 but with everything swapped. 784 00:32:24,450 --> 00:32:25,710 Bob can broadcast this. 785 00:32:25,710 --> 00:32:29,280 If he does, he has to wait a day. 786 00:32:29,280 --> 00:32:32,460 But if he reveals BobR private key to Alice, 787 00:32:32,460 --> 00:32:35,370 Alice knows, OK, I get two coins in the clear. 788 00:32:35,370 --> 00:32:37,800 And then, these 8 coins, I can sign this. 789 00:32:37,800 --> 00:32:39,030 I can sign this. 790 00:32:39,030 --> 00:32:40,710 I can get these 8 coins immediately. 791 00:32:40,710 --> 00:32:42,980 Bob's got to wait a day. 792 00:32:42,980 --> 00:32:45,950 So that's a way to say, look, I'm not going to use these. 793 00:32:45,950 --> 00:32:47,700 Any other questions? 794 00:32:47,700 --> 00:32:48,200 OK. 795 00:32:48,200 --> 00:32:52,340 So what you do with that is, yeah, either party 796 00:32:52,340 --> 00:32:52,930 can broadcast. 797 00:32:52,930 --> 00:32:54,300 They have to wait. 798 00:32:54,300 --> 00:32:59,440 They exchange these revocation private keys. 799 00:32:59,440 --> 00:33:02,550 And now, if they broadcast, the counterparty 800 00:33:02,550 --> 00:33:04,420 can take all the faults. 801 00:33:04,420 --> 00:33:06,195 So it's pretty good. 802 00:33:06,195 --> 00:33:09,930 So the idea is this is a lightning channel. 803 00:33:09,930 --> 00:33:12,582 You've got this output. 804 00:33:12,582 --> 00:33:13,540 You create these dates. 805 00:33:13,540 --> 00:33:15,610 OK, the first date is Alice gets 1 coin. 806 00:33:15,610 --> 00:33:17,270 Bob gets 9 coins. 807 00:33:17,270 --> 00:33:20,890 Then, Bob wants to pay Alice. 808 00:33:20,890 --> 00:33:23,000 So Bob says, hey, Alice, I'm paying you 4 coins. 809 00:33:23,000 --> 00:33:23,500 Here. 810 00:33:23,500 --> 00:33:27,500 I'll sign and create this new output, this new transaction. 811 00:33:27,500 --> 00:33:29,080 Hand it to Alice. 812 00:33:29,080 --> 00:33:32,740 And Alice says, OK, but now we have to revoke this one. 813 00:33:35,350 --> 00:33:36,250 Alice has this. 814 00:33:36,250 --> 00:33:36,760 It's signed. 815 00:33:36,760 --> 00:33:39,040 Alice can broadcast it, but Alice also 816 00:33:39,040 --> 00:33:41,860 wants to be sure that Bob can't broadcast this anymore. 817 00:33:41,860 --> 00:33:44,320 So they, sort of, trash it. 818 00:33:44,320 --> 00:33:48,650 They reveal their R private keys to each other. 819 00:33:48,650 --> 00:33:51,760 So in practice, it could be, well, only Bob 820 00:33:51,760 --> 00:33:53,830 has to reveal the private key, in this case 821 00:33:53,830 --> 00:33:59,680 because Alice is going to broadcast this, not this. 822 00:33:59,680 --> 00:34:04,480 It's just so much simpler if they both reveal their R keys 823 00:34:04,480 --> 00:34:06,760 because then you don't have to worry about something. 824 00:34:06,760 --> 00:34:09,370 You know, what happens in the future when Alice has 0.5 825 00:34:09,370 --> 00:34:11,389 and Alice still has this thing? 826 00:34:11,389 --> 00:34:12,760 So it's really simple. 827 00:34:12,760 --> 00:34:15,610 They both reveal. 828 00:34:15,610 --> 00:34:17,770 Now this transaction-- this state 1-- 829 00:34:17,770 --> 00:34:19,150 it's, basically, unbroadcast. 830 00:34:19,150 --> 00:34:21,092 You know, you're not going to use it. 831 00:34:21,092 --> 00:34:22,300 And they can keep doing that. 832 00:34:22,300 --> 00:34:23,230 And they can go back and forth. 833 00:34:23,230 --> 00:34:23,730 Right? 834 00:34:23,730 --> 00:34:26,570 So now Alice pays Bob and says, hey. 835 00:34:26,570 --> 00:34:27,230 Whoops. 836 00:34:27,230 --> 00:34:28,469 I wanted to make it go back and forth. 837 00:34:28,469 --> 00:34:28,969 Oh well. 838 00:34:28,969 --> 00:34:29,650 Oops. 839 00:34:29,650 --> 00:34:32,590 Anyway, you can make this like Alice back to 2 and Bob 840 00:34:32,590 --> 00:34:34,870 back to 8 or whatever. 841 00:34:34,870 --> 00:34:37,179 Basically, arbitrary numbers. 842 00:34:37,179 --> 00:34:39,070 You can keep going in both directions 843 00:34:39,070 --> 00:34:42,489 and deleting the old one. 844 00:34:42,489 --> 00:34:44,120 So that's pretty useful. 845 00:34:44,120 --> 00:34:48,940 There's no lock time for the channel itself. 846 00:34:48,940 --> 00:34:52,179 The channel can just keep going on forever. 847 00:34:52,179 --> 00:34:55,750 And Alice and Bob can keep sending these things. 848 00:34:55,750 --> 00:34:58,240 It's a little more complicated. 849 00:34:58,240 --> 00:35:01,660 Yeah, I didn't put the messages. 850 00:35:01,660 --> 00:35:06,412 But they have to send four messages. 851 00:35:06,412 --> 00:35:07,620 You can optimize it to three. 852 00:35:10,240 --> 00:35:10,740 Right. 853 00:35:10,740 --> 00:35:17,320 So if you have Alice and Bob, the first thing they do 854 00:35:17,320 --> 00:35:22,221 is Alice sends a signature. 855 00:35:22,221 --> 00:35:25,630 So let's say they're at state 5. 856 00:35:25,630 --> 00:35:28,850 OK, so she says, here's a signature for state six. 857 00:35:28,850 --> 00:35:34,550 And Bob says, OK, I'll give you a signature for state 6. 858 00:35:34,550 --> 00:35:36,260 So now, they both build the state 6. 859 00:35:36,260 --> 00:35:37,250 All right? 860 00:35:37,250 --> 00:35:39,470 Let's say, go from 5 to 6. 861 00:35:39,470 --> 00:35:40,970 And then, Alice can say, OK, I'll 862 00:35:40,970 --> 00:35:47,630 give you your revocation key for state 5. 863 00:35:47,630 --> 00:35:49,310 And then, Bob can say, OK, I'll give you 864 00:35:49,310 --> 00:35:52,400 a revocation key for state 5. 865 00:35:52,400 --> 00:35:53,840 And then, they're done. 866 00:35:53,840 --> 00:35:57,530 They've created the new state and revoked the old state. 867 00:36:02,070 --> 00:36:07,240 Alice can not put rev 5 here in the same message. 868 00:36:07,240 --> 00:36:08,390 Do you know why it went on? 869 00:36:08,390 --> 00:36:10,040 AUDIENCE: You need rev key. 870 00:36:10,040 --> 00:36:11,040 TADGE DRYJA: Well, yeah. 871 00:36:11,040 --> 00:36:15,800 Rev key just abbreviate to rev. So why would this 872 00:36:15,800 --> 00:36:18,320 be bad if Alice says, look, here's state six, 873 00:36:18,320 --> 00:36:21,270 and I'm revoking my claim on state 5? 874 00:36:21,270 --> 00:36:23,650 What goes wrong if you do that? 875 00:36:23,650 --> 00:36:26,576 AUDIENCE: Bob just takes them all. 876 00:36:26,576 --> 00:36:28,590 TADGE DRYJA: Not quite. 877 00:36:28,590 --> 00:36:32,265 Bob broadcasting state 6 is OK, in that case. 878 00:36:35,050 --> 00:36:40,300 AUDIENCE: Bob can sign the rev key for 5. 879 00:36:40,300 --> 00:36:46,100 TADGE DRYJA: No because state 5 is not broadcast. 880 00:36:46,100 --> 00:36:46,600 Right? 881 00:36:46,600 --> 00:36:49,340 Only Alice can sign and broadcast state 5. 882 00:36:49,340 --> 00:36:54,220 So the problem with this is, if you do this, Bob's fine. 883 00:36:54,220 --> 00:36:57,550 Alice is stuck because Alice does not 884 00:36:57,550 --> 00:37:01,590 have state 6 on her drive. 885 00:37:01,590 --> 00:37:03,520 All Alice has on her drive is state 5, 886 00:37:03,520 --> 00:37:06,830 and she's just revealed the key for state 5 to revoke it. 887 00:37:06,830 --> 00:37:09,340 So basically, Alice has nothing, at this point. 888 00:37:09,340 --> 00:37:12,730 And Bob can just wait, and Alice is stuck. 889 00:37:12,730 --> 00:37:14,712 And that's a really good position for Bob 890 00:37:14,712 --> 00:37:17,170 to be in because Bob is like, hey, I can close the channel. 891 00:37:17,170 --> 00:37:21,190 I can close the channel at state 5 or state 6. 892 00:37:21,190 --> 00:37:22,720 Probably, he wants state 6. 893 00:37:22,720 --> 00:37:25,360 Usually, you're sending money. 894 00:37:25,360 --> 00:37:28,560 But I can close this channel, and you can't. 895 00:37:28,560 --> 00:37:31,920 So give me some money, and I'll close the channel. 896 00:37:31,920 --> 00:37:32,670 That's the attack. 897 00:37:32,670 --> 00:37:34,548 AUDIENCE: So conceptually, a new state 898 00:37:34,548 --> 00:37:36,340 has to be created before you can revoke it. 899 00:37:36,340 --> 00:37:37,170 TADGE DRYJA: Right. 900 00:37:37,170 --> 00:37:39,540 And you want it on your side. 901 00:37:39,540 --> 00:37:43,410 So this is creating a new state for Bob, 902 00:37:43,410 --> 00:37:47,200 but it's revoking the old state for Alice if and when 903 00:37:47,200 --> 00:37:48,510 you do this. 904 00:37:48,510 --> 00:37:49,860 So that's dangerous. 905 00:37:49,860 --> 00:37:52,150 Alice doesn't want to do that. 906 00:37:52,150 --> 00:37:54,690 So the simplest way is, OK, create the new state 907 00:37:54,690 --> 00:38:01,372 by signing 6, revoking 5, revoking 5. 908 00:38:01,372 --> 00:38:02,580 You can optimize this though. 909 00:38:05,470 --> 00:38:07,566 Can you guys see the-- 910 00:38:07,566 --> 00:38:09,215 it reduces the three messages? 911 00:38:09,215 --> 00:38:10,610 AUDIENCE: He can send rev 5 back? 912 00:38:10,610 --> 00:38:11,360 TADGE DRYJA: Yeah. 913 00:38:11,360 --> 00:38:17,120 He can send 6, 6 rev 5 at the same time. 914 00:38:17,120 --> 00:38:20,210 So you can do it down into three messages. 915 00:38:20,210 --> 00:38:21,200 So that's cool. 916 00:38:21,200 --> 00:38:23,780 It's basically, here's state 6. 917 00:38:23,780 --> 00:38:26,770 OK, here is state 6, and I revoke my claim on state 5. 918 00:38:26,770 --> 00:38:28,520 OK, revoke my claim on state 5. 919 00:38:28,520 --> 00:38:31,490 Then, they both update their-- 920 00:38:31,490 --> 00:38:33,375 once this happens, the UI is finished. 921 00:38:33,375 --> 00:38:35,667 AUDIENCE: And you're generating keys on the fly, right? 922 00:38:35,667 --> 00:38:37,575 You don't need to pre-generate them? 923 00:38:41,130 --> 00:38:43,800 TADGE DRYJA: It ends up being faster if you pre-generate, 924 00:38:43,800 --> 00:38:46,990 like, one key ahead where you say like, hey, 925 00:38:46,990 --> 00:38:51,060 here's the next public key I'm going to use so that I can-- 926 00:38:54,790 --> 00:38:57,820 because Alice, when she's building state 6, 927 00:38:57,820 --> 00:39:02,050 she needs to know Bob's revocation key in the state 6. 928 00:39:02,050 --> 00:39:04,180 So you pre-share one or two steps 929 00:39:04,180 --> 00:39:06,392 ahead so that you don't have to say, hey, 930 00:39:06,392 --> 00:39:07,600 can you give me the next key? 931 00:39:07,600 --> 00:39:08,510 OK. 932 00:39:08,510 --> 00:39:10,385 Otherwise, you'd have this message where it's 933 00:39:10,385 --> 00:39:12,610 like request state six key. 934 00:39:12,610 --> 00:39:13,450 Send it. 935 00:39:13,450 --> 00:39:15,010 Send the signature back. 936 00:39:15,010 --> 00:39:18,318 So there's more data in these messages without optimizing. 937 00:39:18,318 --> 00:39:20,526 AUDIENCE: So I assume with public keys, in that case, 938 00:39:20,526 --> 00:39:21,010 it's similar. 939 00:39:21,010 --> 00:39:21,760 TADGE DRYJA: Yeah. 940 00:39:21,760 --> 00:39:24,850 Yeah, so you also put some public keys in here. 941 00:39:24,850 --> 00:39:26,930 And this is the private key. 942 00:39:26,930 --> 00:39:27,430 Yes? 943 00:39:27,430 --> 00:39:31,644 AUDIENCE: Where does state 6 [INAUDIBLE]?? 944 00:39:31,644 --> 00:39:32,785 TADGE DRYJA: In here. 945 00:39:32,785 --> 00:39:34,910 You're sending the signature, but you can also send 946 00:39:34,910 --> 00:39:36,950 here's how much I'm giving you. 947 00:39:36,950 --> 00:39:39,860 Here's what the times and stuff are. 948 00:39:39,860 --> 00:39:44,570 Most of it can be computed because the transactions don't 949 00:39:44,570 --> 00:39:45,628 change that much. 950 00:39:45,628 --> 00:39:46,670 The scripts are the same. 951 00:39:46,670 --> 00:39:48,010 Everyone knows what this is going to look like, 952 00:39:48,010 --> 00:39:50,340 so you don't have to actually send too much data. 953 00:39:50,340 --> 00:39:54,350 Another optimization I didn't put in is you're going to, 954 00:39:54,350 --> 00:39:58,710 potentially, have to retain all of these R private keys. 955 00:39:58,710 --> 00:40:02,930 So if you make a million states and 900 and whatever 956 00:40:02,930 --> 00:40:06,560 are revoked, Bob has to keep track of all 957 00:40:06,560 --> 00:40:09,320 those million old Alice private keys. 958 00:40:09,320 --> 00:40:12,680 And Alice has to keep track of all those old Bob private keys. 959 00:40:12,680 --> 00:40:14,660 That's, kind of, annoying. 960 00:40:14,660 --> 00:40:17,720 Not the end of the world, but it's like 32 bytes each. 961 00:40:17,720 --> 00:40:19,370 Can be a couple hundred megabytes 962 00:40:19,370 --> 00:40:22,970 if you use this channel a lot. 963 00:40:22,970 --> 00:40:24,520 So I thought I came up with it. 964 00:40:24,520 --> 00:40:26,550 But at the same time, when I was coming up with it, I was like, 965 00:40:26,550 --> 00:40:28,850 no, I'm pretty sure this is in some paper somewhere, 966 00:40:28,850 --> 00:40:29,785 and I can't find it. 967 00:40:29,785 --> 00:40:31,160 And then, talking to people here, 968 00:40:31,160 --> 00:40:33,850 apparently, it's Goldwasser. 969 00:40:33,850 --> 00:40:37,910 Like, a professor here came up with it in, like, the '80s. 970 00:40:37,910 --> 00:40:44,040 I called it elkrem because spelled backwards it's 971 00:40:44,040 --> 00:40:46,950 merkle, right? 972 00:40:46,950 --> 00:40:49,230 So you have a binary tree. 973 00:40:49,230 --> 00:40:56,170 And you say, OK, 0, 1, 2, 3, 4, 5. 974 00:40:56,170 --> 00:40:58,670 6 Is the root, for example. 975 00:40:58,670 --> 00:41:03,790 And when you want to descend to the left, 976 00:41:03,790 --> 00:41:10,210 you take the value here, append an l, or maybe 0 is left 977 00:41:10,210 --> 00:41:14,380 and 1 is right or something or l or r, and you hash it. 978 00:41:14,380 --> 00:41:16,390 So you say, OK, I'm taking this value, 979 00:41:16,390 --> 00:41:19,460 sticking something on hashing to get down here. 980 00:41:19,460 --> 00:41:22,563 And similarly to here, you make a big tree. 981 00:41:22,563 --> 00:41:24,730 The idea there is you can reveal things sequentially 982 00:41:24,730 --> 00:41:26,270 and say, OK, I reveal 0. 983 00:41:26,270 --> 00:41:26,770 Fine. 984 00:41:26,770 --> 00:41:27,550 I'll store it. 985 00:41:27,550 --> 00:41:28,510 I'll reveal 1. 986 00:41:28,510 --> 00:41:29,290 Store it. 987 00:41:29,290 --> 00:41:30,280 I reveal 2. 988 00:41:30,280 --> 00:41:33,370 Now, you can delete 0 and 1 because you know the parent, 989 00:41:33,370 --> 00:41:36,500 and you can compute 0 and 1 from knowing 2. 990 00:41:36,500 --> 00:41:37,000 Right? 991 00:41:37,000 --> 00:41:37,810 So I give you 0. 992 00:41:37,810 --> 00:41:38,350 Give you 1. 993 00:41:38,350 --> 00:41:38,860 Give me 2. 994 00:41:38,860 --> 00:41:40,110 You delete 0 and 1. 995 00:41:40,110 --> 00:41:43,210 Going to give me 3, 4, 5. 996 00:41:43,210 --> 00:41:44,480 You delete 3 and 4. 997 00:41:44,480 --> 00:41:47,950 When I give you 6, you delete 2 and 5. 998 00:41:47,950 --> 00:41:52,150 So that way, you only have to store login secrets. 999 00:41:54,810 --> 00:41:57,290 Given 0 and 1, you can't compute 2. 1000 00:41:57,290 --> 00:42:01,180 And given 2, 3, and 4, you can't compute 5 or 6. 1001 00:42:01,180 --> 00:42:05,480 But once you've got them, you can compute all the old ones. 1002 00:42:05,480 --> 00:42:11,220 So if we do that for the secret keys, 1003 00:42:11,220 --> 00:42:13,390 that reduces storage a lot. 1004 00:42:13,390 --> 00:42:15,470 So that's kind of a nice optimization. 1005 00:42:15,470 --> 00:42:17,870 It was pretty quick. 1006 00:42:17,870 --> 00:42:21,040 And so then, your total data you're 1007 00:42:21,040 --> 00:42:23,570 storing for these channels never gets more than a kilobyte 1008 00:42:23,570 --> 00:42:25,210 or two. 1009 00:42:25,210 --> 00:42:26,710 So that's pretty useful. 1010 00:42:26,710 --> 00:42:27,370 OK. 1011 00:42:27,370 --> 00:42:31,300 Other questions on this? 1012 00:42:31,300 --> 00:42:34,390 This alone, actually, is really complicated. 1013 00:42:34,390 --> 00:42:38,390 AUDIENCE: You only want one active state, right? 1014 00:42:38,390 --> 00:42:42,310 TADGE DRYJA: So there is a, sort of, superposition time here 1015 00:42:42,310 --> 00:42:42,810 where-- 1016 00:42:46,630 --> 00:42:48,550 so let's say this is time 0. 1017 00:42:48,550 --> 00:42:49,330 This is time 1. 1018 00:42:49,330 --> 00:42:49,970 This is time 2. 1019 00:42:49,970 --> 00:42:51,040 This is time 3. 1020 00:42:51,040 --> 00:42:57,140 So at time 1, Bob's got 2 states he can broadcast. 1021 00:42:57,140 --> 00:42:57,640 Right? 1022 00:42:57,640 --> 00:42:59,560 Bob's like, I can do 6 or 5. 1023 00:42:59,560 --> 00:43:02,140 Alice can only broadcast 5. 1024 00:43:02,140 --> 00:43:05,800 But Alice knows that Bob can broadcast 6. 1025 00:43:05,800 --> 00:43:10,150 So Alice is also like, well, I'm not sure which it is. 1026 00:43:10,150 --> 00:43:13,000 From Alice's perspective, if I close, I'm at state 5. 1027 00:43:13,000 --> 00:43:16,240 If Bob closes, he's at state 6. 1028 00:43:16,240 --> 00:43:21,340 And then, at state 2, Alice can only broadcast state 6 1029 00:43:21,340 --> 00:43:23,610 but Bob can broadcast-- 1030 00:43:23,610 --> 00:43:27,230 sorry, Alice can broadcast either, 1031 00:43:27,230 --> 00:43:28,760 but Bob can only broadcast one. 1032 00:43:28,760 --> 00:43:31,850 So yeah, during this process, it's 1033 00:43:31,850 --> 00:43:33,590 not clear which state it is. 1034 00:43:33,590 --> 00:43:40,740 And you know, if something happens, like Alice sends sig-- 1035 00:43:40,740 --> 00:43:41,960 signature for 6-- 1036 00:43:41,960 --> 00:43:43,520 and Bob goes offline. 1037 00:43:43,520 --> 00:43:46,880 Then, it's like, OK, I never got a response. 1038 00:43:46,880 --> 00:43:49,237 I'll just try to close at state 5, I guess. 1039 00:43:49,237 --> 00:43:51,320 And then, I guess that payment never went through. 1040 00:43:51,320 --> 00:43:53,612 But then, Bob could say, no, I got it and broadcast it. 1041 00:43:53,612 --> 00:43:55,790 So things can get weird where you're not 1042 00:43:55,790 --> 00:43:57,660 really sure what happens here. 1043 00:43:57,660 --> 00:44:01,220 So it's more a UI issue where, in the UI, 1044 00:44:01,220 --> 00:44:05,030 you only show things after you get to the end. 1045 00:44:05,030 --> 00:44:07,670 Hopefully, in most cases, this whole process 1046 00:44:07,670 --> 00:44:11,120 takes a fraction of a second because you're just sending 1047 00:44:11,120 --> 00:44:12,730 some messages to each other. 1048 00:44:12,730 --> 00:44:13,730 So that's the nice part. 1049 00:44:13,730 --> 00:44:16,580 That's, sort of, the lightning-y thing. 1050 00:44:16,580 --> 00:44:17,730 It's fast right. 1051 00:44:17,730 --> 00:44:18,230 Yes? 1052 00:44:18,230 --> 00:44:19,550 AUDIENCE: Does this require both actors 1053 00:44:19,550 --> 00:44:20,870 to be online at the same time? 1054 00:44:20,870 --> 00:44:21,620 TADGE DRYJA: Yeah. 1055 00:44:21,620 --> 00:44:22,310 Yeah, right. 1056 00:44:22,310 --> 00:44:26,540 So they're sending messages to each other. 1057 00:44:26,540 --> 00:44:28,342 They can't really pre-compute these things 1058 00:44:28,342 --> 00:44:30,050 because they don't know how much money is 1059 00:44:30,050 --> 00:44:32,160 getting sent back and forth. 1060 00:44:32,160 --> 00:44:34,280 So when you're signing state 6, you're 1061 00:44:34,280 --> 00:44:37,190 also signing the output values. 1062 00:44:37,190 --> 00:44:40,310 And when Bob receives state 6 and signs his version of state 1063 00:44:40,310 --> 00:44:43,518 6, he also is like, you know, I don't know 1064 00:44:43,518 --> 00:44:44,810 how much money I'm getting yet. 1065 00:44:44,810 --> 00:44:46,190 So I need to sign off on that. 1066 00:44:46,190 --> 00:44:50,177 So yeah, both parties need to be online to receive, 1067 00:44:50,177 --> 00:44:52,010 which is different than normally in Bitcoin. 1068 00:44:55,073 --> 00:44:56,990 That's the same as the uni-directional payment 1069 00:44:56,990 --> 00:44:58,040 channels. 1070 00:44:58,040 --> 00:45:00,520 In the unidirectional one, where Bob's the receiver, 1071 00:45:00,520 --> 00:45:01,790 he doesn't have to sign. 1072 00:45:01,790 --> 00:45:05,900 But he still has to be online because the transaction just 1073 00:45:05,900 --> 00:45:06,890 goes directly to him. 1074 00:45:06,890 --> 00:45:08,360 It doesn't go onto the block chain. 1075 00:45:08,360 --> 00:45:11,480 None of these are publicly known. 1076 00:45:11,480 --> 00:45:11,980 OK. 1077 00:45:11,980 --> 00:45:12,938 AUDIENCE: One question. 1078 00:45:12,938 --> 00:45:13,680 TADGE DRYJA: Yes? 1079 00:45:13,680 --> 00:45:15,430 AUDIENCE: Why do we care about old states? 1080 00:45:15,430 --> 00:45:16,250 Say you had a million states. 1081 00:45:16,250 --> 00:45:17,667 Why do we care about the old ones? 1082 00:45:17,667 --> 00:45:23,170 TADGE DRYJA: Well, this was state 1 where Alice had 1 1083 00:45:23,170 --> 00:45:24,280 and Bob had 9. 1084 00:45:24,280 --> 00:45:28,210 And then, you keep going, and the general trend 1085 00:45:28,210 --> 00:45:29,560 is Bob's losing money. 1086 00:45:29,560 --> 00:45:30,880 Right? 1087 00:45:30,880 --> 00:45:34,420 You go back and forth but, at the end, Bob has 1. 1088 00:45:34,420 --> 00:45:38,350 Bob needs to worry that Alice holds onto state 1. 1089 00:45:38,350 --> 00:45:40,540 And then, months later, broadcasts it 1090 00:45:40,540 --> 00:45:43,910 while Bob's not watching. 1091 00:45:43,910 --> 00:45:45,160 Sorry, wait. 1092 00:45:45,160 --> 00:45:46,210 No. 1093 00:45:46,210 --> 00:45:46,960 Opposite. 1094 00:45:46,960 --> 00:45:49,810 Alice has to worry about Bob broadcasting 1095 00:45:49,810 --> 00:45:51,190 state 1 in the future. 1096 00:45:51,190 --> 00:45:53,523 AUDIENCE: Well, everything's going to be revoked, right? 1097 00:45:53,523 --> 00:45:54,370 TADGE DRYJA: Right. 1098 00:45:54,370 --> 00:45:56,245 So you still need to keep the secret, though. 1099 00:45:56,245 --> 00:45:59,560 It's revoked, but the whole process of revocation 1100 00:45:59,560 --> 00:46:02,860 is Bob gives a key to Alice. 1101 00:46:02,860 --> 00:46:05,680 So if Bob forgets that key-- 1102 00:46:05,680 --> 00:46:06,180 sorry. 1103 00:46:06,180 --> 00:46:08,920 If Alice forgets this key, Bob can broadcast it. 1104 00:46:08,920 --> 00:46:10,170 And then, Alice can't grab it. 1105 00:46:10,170 --> 00:46:13,220 AUDIENCE: It doesn't stop them from broadcasting. 1106 00:46:13,220 --> 00:46:16,050 TADGE DRYJA: Yeah, they can broadcast. 1107 00:46:16,050 --> 00:46:17,790 So from the network's perspective, 1108 00:46:17,790 --> 00:46:19,680 these are all equally valid. 1109 00:46:19,680 --> 00:46:22,860 The network has no idea which came when 1110 00:46:22,860 --> 00:46:24,070 or anything like that. 1111 00:46:24,070 --> 00:46:28,680 The only way you enforce it is, if Bob broadcasts this, 1112 00:46:28,680 --> 00:46:30,890 Alice is like, uh uh, I'm taking this one 1113 00:46:30,890 --> 00:46:31,980 because I have the key. 1114 00:46:31,980 --> 00:46:37,570 So that's also a pretty significant, different security 1115 00:46:37,570 --> 00:46:38,070 model. 1116 00:46:38,070 --> 00:46:39,780 It's a security reduction. 1117 00:46:39,780 --> 00:46:40,320 Right? 1118 00:46:40,320 --> 00:46:43,950 Now, you have to actively defend your channel 1119 00:46:43,950 --> 00:46:45,990 because if you go offline-- 1120 00:46:45,990 --> 00:46:47,160 I'm Alice. 1121 00:46:47,160 --> 00:46:48,690 I'm supposed to have 9 coins. 1122 00:46:48,690 --> 00:46:49,860 I go on vacation. 1123 00:46:49,860 --> 00:46:52,770 I turn off my computer, and Bob knows 1124 00:46:52,770 --> 00:46:54,600 I've turned off my computer. 1125 00:46:54,600 --> 00:46:57,795 Then, Bob can say, oh, Alice is out like. 1126 00:46:57,795 --> 00:47:00,000 It's this 100 block delay. 1127 00:47:00,000 --> 00:47:01,230 She's not going to be online. 1128 00:47:01,230 --> 00:47:03,840 I'm just going to broadcast this, get the 9 coins, 1129 00:47:03,840 --> 00:47:07,440 wait 100 blocks, and then sweep them as soon as I can. 1130 00:47:07,440 --> 00:47:09,840 And then, Alice comes back, plugs in, and it's like, oh, 1131 00:47:09,840 --> 00:47:11,010 you were-- wait. 1132 00:47:11,010 --> 00:47:12,570 Oh, it says I lost 8 coins. 1133 00:47:12,570 --> 00:47:15,030 What? 1134 00:47:15,030 --> 00:47:20,130 Because Bob defrauded, so you have to be online. 1135 00:47:20,130 --> 00:47:23,010 I think I'm going to get into it next time. 1136 00:47:23,010 --> 00:47:25,307 There is a way to outsource that so that you 1137 00:47:25,307 --> 00:47:26,390 don't have to be watching. 1138 00:47:26,390 --> 00:47:28,730 You can have someone else watch for you. 1139 00:47:28,730 --> 00:47:32,680 And I'll, probably, talk about that next time. 1140 00:47:32,680 --> 00:47:35,240 But then, the last 20ish minutes-- 1141 00:47:39,670 --> 00:47:41,010 yeah, so this is cool. 1142 00:47:41,010 --> 00:47:42,480 This is lightning channels. 1143 00:47:42,480 --> 00:47:43,020 Two parties. 1144 00:47:43,020 --> 00:47:43,860 Indefinite. 1145 00:47:43,860 --> 00:47:46,020 You still need to create a channel to pay people. 1146 00:47:46,020 --> 00:47:48,805 So you're going to do 1 on chain transaction 1147 00:47:48,805 --> 00:47:49,920 to open the channel. 1148 00:47:49,920 --> 00:47:51,480 1 to close the channel. 1149 00:47:51,480 --> 00:47:52,980 Potentially, 2 to close the channel, 1150 00:47:52,980 --> 00:47:54,150 but that's pretty rare. 1151 00:47:54,150 --> 00:47:57,180 If you need to immediately grab it, then you're time sensitive, 1152 00:47:57,180 --> 00:47:59,670 and you're going to have two closing transactions. 1153 00:47:59,670 --> 00:48:01,606 If you close normally-- 1154 00:48:01,606 --> 00:48:04,140 like, you close the current state-- 1155 00:48:04,140 --> 00:48:07,460 you need to wait 100 blocks for your money to be active. 1156 00:48:07,460 --> 00:48:09,710 But you don't have to spend it immediately after that. 1157 00:48:09,710 --> 00:48:13,270 You can just leave it because you know. 1158 00:48:13,270 --> 00:48:17,120 So in this case, let's say, this is Bob's held transaction. 1159 00:48:17,120 --> 00:48:20,020 Bob broadcasts it. 1160 00:48:20,020 --> 00:48:22,600 Bob knows, OK, Alice gets her 2 coins. 1161 00:48:22,600 --> 00:48:23,590 I get my 8 coins. 1162 00:48:23,590 --> 00:48:25,773 I have to wait 100 blocks, but I don't actually 1163 00:48:25,773 --> 00:48:27,190 have to spend it after 100 blocks. 1164 00:48:27,190 --> 00:48:31,180 I can just leave it in my wallet because Bob knows 1165 00:48:31,180 --> 00:48:33,460 he never gave Alice this key. 1166 00:48:33,460 --> 00:48:36,785 So this clause-- this or Alice and BobR key-- this 1167 00:48:36,785 --> 00:48:38,750 is not going to happen. 1168 00:48:38,750 --> 00:48:41,710 So Bob's safe and just leaves it. 1169 00:48:41,710 --> 00:48:44,000 So he can just use that, as well. 1170 00:48:44,000 --> 00:48:46,900 However, if it's the no you don't kind of thing, 1171 00:48:46,900 --> 00:48:49,360 then you have to do two transactions. 1172 00:48:49,360 --> 00:48:50,260 That's rare though. 1173 00:48:50,260 --> 00:48:53,693 So this is pretty good, but you still 1174 00:48:53,693 --> 00:48:54,860 have to do two transactions. 1175 00:48:54,860 --> 00:48:57,610 So if you use this, you open a channel, you use it once, 1176 00:48:57,610 --> 00:48:58,930 and then you close it. 1177 00:48:58,930 --> 00:48:59,920 Well, that was dumb. 1178 00:48:59,920 --> 00:49:04,330 You just paid twice as much in fees that you needed to. 1179 00:49:04,330 --> 00:49:07,300 So it's useful for some things, not for others. 1180 00:49:07,300 --> 00:49:09,580 Could we do something like multiple party channels? 1181 00:49:09,580 --> 00:49:12,010 So there's research about this. 1182 00:49:12,010 --> 00:49:13,540 It gets real ugly real fast. 1183 00:49:13,540 --> 00:49:15,730 Like, I want a single channel with three 1184 00:49:15,730 --> 00:49:18,400 or four users or, like, a tree of channels 1185 00:49:18,400 --> 00:49:23,320 where the first top output has 4 of 4 multisig and then branches 1186 00:49:23,320 --> 00:49:25,040 into these 2 of 2 multisigs. 1187 00:49:25,040 --> 00:49:26,870 There's a lot of interesting ideas, 1188 00:49:26,870 --> 00:49:29,650 but it gets a little ugly. 1189 00:49:29,650 --> 00:49:32,830 But the off chain scalability gets bad. 1190 00:49:32,830 --> 00:49:35,950 There's a lot of n squared kind of stuff. 1191 00:49:35,950 --> 00:49:37,930 So what about a forwarding network of point 1192 00:49:37,930 --> 00:49:38,860 to point channels? 1193 00:49:38,860 --> 00:49:41,260 So OK, we have these two party channels, 1194 00:49:41,260 --> 00:49:43,120 and people are connected with them. 1195 00:49:43,120 --> 00:49:46,000 So Alice and Bob have a channel, and Bob and Carol 1196 00:49:46,000 --> 00:49:47,770 have a channel. 1197 00:49:47,770 --> 00:49:49,180 So this would be cool. 1198 00:49:49,180 --> 00:49:53,350 Alice can just say hey, Bob, I will pay you if you pay Carol. 1199 00:49:53,350 --> 00:49:54,555 And you can do that. 1200 00:49:54,555 --> 00:49:56,430 Alice says, look, I'm just making a new state 1201 00:49:56,430 --> 00:49:57,910 where you have an extra coin. 1202 00:49:57,910 --> 00:50:01,180 Now, please, give this extra coin Carol. 1203 00:50:01,180 --> 00:50:03,160 And Bob says, yeah, OK and does. 1204 00:50:03,160 --> 00:50:08,330 So the word there that should have immediately 1205 00:50:08,330 --> 00:50:11,300 raised a, uh oh, that's not how this stuff works, is the word 1206 00:50:11,300 --> 00:50:12,690 please. 1207 00:50:12,690 --> 00:50:15,950 You don't say please in Bitcoin. 1208 00:50:15,950 --> 00:50:21,620 So yeah, the other option is Bob just keeps it. 1209 00:50:21,620 --> 00:50:23,360 So Alice says, OK, here. 1210 00:50:23,360 --> 00:50:27,650 I'll add a coin to your output in this channel. 1211 00:50:27,650 --> 00:50:30,240 And please add a coin to Carol's output 1212 00:50:30,240 --> 00:50:31,580 in your channel with her. 1213 00:50:31,580 --> 00:50:32,390 And Bob says, yeah. 1214 00:50:32,390 --> 00:50:33,890 No, I'm just going to keep the coin. 1215 00:50:33,890 --> 00:50:36,560 Thanks. 1216 00:50:36,560 --> 00:50:41,170 So this might not be super crazy in that, well, you 1217 00:50:41,170 --> 00:50:42,170 got a channel with them. 1218 00:50:42,170 --> 00:50:43,503 Maybe they're [INAUDIBLE] chain. 1219 00:50:43,503 --> 00:50:46,490 Also, you can you reduce the number of coins 1220 00:50:46,490 --> 00:50:47,750 you send per update. 1221 00:50:47,750 --> 00:50:51,130 You can say, look, I'm going to send one Satoshi at a time. 1222 00:50:51,130 --> 00:50:55,180 And so worst case, you keep one Satoshi 1223 00:50:55,180 --> 00:50:56,360 that you shouldn't have. 1224 00:50:56,360 --> 00:50:57,080 Right? 1225 00:50:57,080 --> 00:50:57,790 You could. 1226 00:50:57,790 --> 00:50:59,080 Right? 1227 00:50:59,080 --> 00:51:01,842 It's not as scalable, though, because let's say 1228 00:51:01,842 --> 00:51:03,550 you want to send a lot of money to Carol. 1229 00:51:03,550 --> 00:51:05,090 You're going to have to keep doing these little things. 1230 00:51:05,090 --> 00:51:06,470 It's, kind of, annoying. 1231 00:51:06,470 --> 00:51:08,930 Also, what if you want multiple hops 1232 00:51:08,930 --> 00:51:13,380 where you're not even sure who's in the middle of your chain? 1233 00:51:13,380 --> 00:51:14,620 It doesn't work for that. 1234 00:51:14,620 --> 00:51:15,120 OK. 1235 00:51:15,120 --> 00:51:18,650 So you can have what's called HTLCs. 1236 00:51:18,650 --> 00:51:21,390 And these are even more complicated. 1237 00:51:21,390 --> 00:51:25,200 OK, so the idea is it's Hash/Time Locked Contract. 1238 00:51:25,200 --> 00:51:26,430 Or Hash/Time Lock Contract. 1239 00:51:26,430 --> 00:51:27,600 Whatever. 1240 00:51:27,600 --> 00:51:29,780 The script is, essentially, this. 1241 00:51:29,780 --> 00:51:32,580 KeyA and preimageR. 1242 00:51:32,580 --> 00:51:35,130 You need to present the preimage of a hash. 1243 00:51:35,130 --> 00:51:39,540 Or KeyB and some absolute lock time. 1244 00:51:39,540 --> 00:51:42,192 Op check lock time verify. 1245 00:51:42,192 --> 00:51:44,400 And it's important that this is an absolute time, not 1246 00:51:44,400 --> 00:51:46,440 a relative time because these should 1247 00:51:46,440 --> 00:51:49,650 be able to expire, regardless of when they get broadcast 1248 00:51:49,650 --> 00:51:51,540 onto the blockchain. 1249 00:51:51,540 --> 00:51:54,950 So the idea is, in this case-- 1250 00:51:54,950 --> 00:51:56,810 so let's say A is Alice, B is Bob-- 1251 00:51:56,810 --> 00:52:03,870 Alice gets the money if she knows this preimageR. 1252 00:52:03,870 --> 00:52:05,030 This 32 bite. 1253 00:52:05,030 --> 00:52:07,760 So what actually goes here is the hash of R. 1254 00:52:07,760 --> 00:52:13,105 It's like a Pay-to-PubKey Hash, where you say op dup, 1255 00:52:13,105 --> 00:52:17,020 op hash 160, the thing, op equal verify. 1256 00:52:17,020 --> 00:52:20,090 So you need to know some preimage, and you need to sign. 1257 00:52:20,090 --> 00:52:24,680 Or you can be Bob, and then you can sign after a certain date. 1258 00:52:27,987 --> 00:52:29,070 So this is, kind of, nice. 1259 00:52:29,070 --> 00:52:33,420 It's like, well, if R is known, then it's Alice's money. 1260 00:52:33,420 --> 00:52:35,850 If R is unknown, then it's Bob's money 1261 00:52:35,850 --> 00:52:38,440 after a certain period of time. 1262 00:52:38,440 --> 00:52:43,440 OK, so this was the revokable transaction where Alice 1263 00:52:43,440 --> 00:52:46,260 got 2 coins, Bob's got 8 coins, and then you 1264 00:52:46,260 --> 00:52:49,980 add a third output, this HTLC output where now Alice 1265 00:52:49,980 --> 00:52:55,170 has 2 coins, Bob has 7 coins, and Alice might be getting 1266 00:52:55,170 --> 00:52:57,900 an extra coin if she learns R. 1267 00:52:57,900 --> 00:53:02,580 Bob gets the coin back after height 500,000. 1268 00:53:02,580 --> 00:53:08,010 So similarly, with this it's like, OK, this is Bob's money. 1269 00:53:08,010 --> 00:53:11,910 But if he does something bad, Alice can grab it. 1270 00:53:11,910 --> 00:53:15,660 This is Alice's money if she knows R. If she doesn't, Bob 1271 00:53:15,660 --> 00:53:16,860 gets it back. 1272 00:53:16,860 --> 00:53:20,470 So there's no-- like, really, this is Bob's money. 1273 00:53:20,470 --> 00:53:20,970 Right? 1274 00:53:20,970 --> 00:53:24,360 This only happens if someone's trying to rip someone off. 1275 00:53:24,360 --> 00:53:27,510 This, on the other hand, is well it depends. 1276 00:53:27,510 --> 00:53:30,070 Is Alice going to learn R or not? 1277 00:53:30,070 --> 00:53:31,080 And what is R? 1278 00:53:31,080 --> 00:53:31,580 OK. 1279 00:53:31,580 --> 00:53:35,200 So the multi-party adversarial payment model. 1280 00:53:35,200 --> 00:53:38,640 So the lightning forwarding is Alice wants to pay Carol. 1281 00:53:38,640 --> 00:53:39,140 Right? 1282 00:53:39,140 --> 00:53:41,780 She doesn't want to just ask Bob to keep forwarding the funds 1283 00:53:41,780 --> 00:53:44,490 because she doesn't trust Bob. 1284 00:53:44,490 --> 00:53:46,290 So she connects to Carol-- 1285 00:53:46,290 --> 00:53:49,050 and by connect I mean, like, regular TCP connection-- 1286 00:53:49,050 --> 00:53:53,970 and says, hey, Carol, make a random number R, 1287 00:53:53,970 --> 00:53:55,040 and send me the hash. 1288 00:53:55,040 --> 00:53:57,360 carol OK, here you go. 1289 00:53:57,360 --> 00:54:01,410 Carol knows H, which is the hash and R, which is the pre-image. 1290 00:54:01,410 --> 00:54:04,450 She sends over H to Alice. 1291 00:54:04,450 --> 00:54:07,180 Alice then says to Bob, hey, I'm going 1292 00:54:07,180 --> 00:54:09,700 to add an HTLC to our channel. 1293 00:54:09,700 --> 00:54:13,660 So basically, Bob, if you know the pre-image of H-- 1294 00:54:13,660 --> 00:54:15,700 if you know R-- 1295 00:54:15,700 --> 00:54:17,230 you can get this coin. 1296 00:54:17,230 --> 00:54:22,540 If not, I get the coin back after 5:00. 1297 00:54:22,540 --> 00:54:24,430 And then, Bob says, OK, cool. 1298 00:54:24,430 --> 00:54:30,600 I know H now, but I don't know R. So I can't grab this money. 1299 00:54:30,600 --> 00:54:32,340 I don't know this, so there's no way 1300 00:54:32,340 --> 00:54:34,080 this is going to be my money. 1301 00:54:34,080 --> 00:54:37,740 It's just going to go back to you after 5:00. 1302 00:54:37,740 --> 00:54:42,730 And Alice says, yeah, but Carol knows R, so ask Carol. 1303 00:54:42,730 --> 00:54:44,440 Bob says, OK, I get it. 1304 00:54:44,440 --> 00:54:47,400 I will forward this on to Carol. 1305 00:54:47,400 --> 00:54:49,380 And then, I create a similar output. 1306 00:54:49,380 --> 00:54:52,290 I make sure that these are the same R or the same H. 1307 00:54:52,290 --> 00:54:53,460 I don't know R yet. 1308 00:54:53,460 --> 00:54:55,410 But I say, hey, Carol, if you know R-- 1309 00:54:55,410 --> 00:54:57,990 if you know the pre-image of H-- 1310 00:54:57,990 --> 00:54:59,160 you can get this coin. 1311 00:54:59,160 --> 00:55:03,480 If not, after 4:00 o'clock, I get the money back. 1312 00:55:03,480 --> 00:55:05,033 And then, Carol says, oh, cool. 1313 00:55:05,033 --> 00:55:05,700 Well guess what? 1314 00:55:05,700 --> 00:55:10,512 I know R because I made R up. 1315 00:55:10,512 --> 00:55:11,970 So from Carol's perspective, Carrol 1316 00:55:11,970 --> 00:55:15,330 could broadcast this onto the blockchain immediately. 1317 00:55:15,330 --> 00:55:18,480 And she will be able to grab the money because she knows 1318 00:55:18,480 --> 00:55:21,632 R. She has to grab it soon because, by 4:00 o'clock, 1319 00:55:21,632 --> 00:55:22,590 Bob can grab the money. 1320 00:55:26,280 --> 00:55:28,190 And if Carol does this-- 1321 00:55:28,190 --> 00:55:30,410 she closes the channel, she uses R 1322 00:55:30,410 --> 00:55:34,250 because she knows it to take this coin from this output. 1323 00:55:34,250 --> 00:55:37,100 Carol doing that will reveal R to everyone in the world 1324 00:55:37,100 --> 00:55:38,790 because it's on the blockchain now. 1325 00:55:38,790 --> 00:55:43,048 And so then Bob can say, ah, I know R now. 1326 00:55:43,048 --> 00:55:44,090 I need to get this money. 1327 00:55:44,090 --> 00:55:45,680 So Bob can close the channel. 1328 00:55:45,680 --> 00:55:46,460 Grab the money. 1329 00:55:46,460 --> 00:55:47,195 Yes? 1330 00:55:47,195 --> 00:55:49,712 AUDIENCE: Those times are actually block heights, right? 1331 00:55:49,712 --> 00:55:53,450 TADGE DRYJA: In the software, yeah, we use heights. 1332 00:55:53,450 --> 00:55:56,010 You could do it with time. 1333 00:55:56,010 --> 00:55:59,720 The main reason for heights is, what 1334 00:55:59,720 --> 00:56:04,272 if a block's full because height's, sort of, variable. 1335 00:56:04,272 --> 00:56:06,230 Like, maybe a bunch of blocks come out quickly, 1336 00:56:06,230 --> 00:56:08,570 and maybe they come out slowly. 1337 00:56:08,570 --> 00:56:10,790 So time is a little dangerous in that you 1338 00:56:10,790 --> 00:56:12,980 could say, OK, 4:00 o'clock. 1339 00:56:12,980 --> 00:56:14,690 But maybe in the next five hours, 1340 00:56:14,690 --> 00:56:17,510 only a couple blocks come out, just by chance. 1341 00:56:17,510 --> 00:56:20,200 And they're full, and you're not able to broadcast. 1342 00:56:20,200 --> 00:56:23,250 You're not able to get this in, and it's risky. 1343 00:56:23,250 --> 00:56:26,090 So the height takes into account the variable nature of it 1344 00:56:26,090 --> 00:56:27,860 a little bit better. 1345 00:56:27,860 --> 00:56:31,090 AUDIENCE: What if there's some situation where blocks are 1346 00:56:31,090 --> 00:56:32,730 [INAUDIBLE]? 1347 00:56:32,730 --> 00:56:33,480 TADGE DRYJA: Yeah. 1348 00:56:33,480 --> 00:56:36,090 Well, child pays for parent-- 1349 00:56:36,090 --> 00:56:37,040 yeah. 1350 00:56:37,040 --> 00:56:42,150 So the question is, what if the fees get really high? 1351 00:56:42,150 --> 00:56:45,620 The thing is, this whole process should take a few seconds. 1352 00:56:45,620 --> 00:56:51,710 So it's not like these outputs have weird fees that are old. 1353 00:56:51,710 --> 00:56:54,020 One issue is what if you're building these states 1354 00:56:54,020 --> 00:56:54,920 back and forth. 1355 00:56:54,920 --> 00:56:56,840 And then, you sit on one for a few weeks. 1356 00:56:56,840 --> 00:56:58,695 And then, the fee rate goes way up. 1357 00:56:58,695 --> 00:57:00,070 And you're like shoot, if I tried 1358 00:57:00,070 --> 00:57:02,760 to broadcast these transactions, the fee's too low 1359 00:57:02,760 --> 00:57:06,260 and it might not get confirmed. 1360 00:57:06,260 --> 00:57:09,050 It's not a huge risk because if you're not 1361 00:57:09,050 --> 00:57:11,870 trying to rip people off, you don't actually 1362 00:57:11,870 --> 00:57:15,320 have any time risk. 1363 00:57:15,320 --> 00:57:18,740 In this case, this gets built. This gets built. 1364 00:57:18,740 --> 00:57:20,270 These are, sort of, in real time. 1365 00:57:20,270 --> 00:57:21,770 And so you know what the fee rate is in the network, 1366 00:57:21,770 --> 00:57:22,990 so you can adapt to it. 1367 00:57:22,990 --> 00:57:24,490 But yeah, that's an interesting one. 1368 00:57:24,490 --> 00:57:25,430 Yeah? 1369 00:57:25,430 --> 00:57:28,528 AUDIENCE: Are there any problems in this system being slow? 1370 00:57:28,528 --> 00:57:31,113 Because I think, as we were reading literature 1371 00:57:31,113 --> 00:57:34,400 prior to blockchain, like 1980, that I 1372 00:57:34,400 --> 00:57:36,670 read some stuff about distributed computing 1373 00:57:36,670 --> 00:57:39,350 that if you n number of nodes, you 1374 00:57:39,350 --> 00:57:41,370 need a minimal number of 3 [INAUDIBLE] 1375 00:57:41,370 --> 00:57:43,530 or something in order to get consensus. 1376 00:57:43,530 --> 00:57:46,192 But does blockchain sort of make something 1377 00:57:46,192 --> 00:57:47,150 underneath all of the-- 1378 00:57:47,150 --> 00:57:50,210 TADGE DRYJA: You don't need global consensus in that-- 1379 00:57:53,270 --> 00:57:56,325 I did only 3, so you can't show. 1380 00:57:56,325 --> 00:57:57,700 If you have four, you can sort of 1381 00:57:57,700 --> 00:58:00,040 say-- let's say you have Alice, Bob, Carol, Dave. 1382 00:58:02,910 --> 00:58:04,910 You don't actually have to know the whole thing. 1383 00:58:04,910 --> 00:58:06,400 You just have to know the person before you and the person 1384 00:58:06,400 --> 00:58:07,000 after you. 1385 00:58:07,000 --> 00:58:10,990 And you don't care what the actual endpoints are. 1386 00:58:10,990 --> 00:58:13,840 So to some extent, Bob doesn't need to know. 1387 00:58:13,840 --> 00:58:16,840 Maybe Alice got this HTLC forwarded from someone 1388 00:58:16,840 --> 00:58:18,130 else before. 1389 00:58:18,130 --> 00:58:21,910 And Bob's like, all I know is I could get money from Alice if I 1390 00:58:21,910 --> 00:58:24,580 know R, and Carol gets it from me 1391 00:58:24,580 --> 00:58:28,150 if she knows R. And maybe that keeps going or something. 1392 00:58:28,150 --> 00:58:30,160 You don't need global consensus. 1393 00:58:30,160 --> 00:58:32,785 AUDIENCE: And that's because of how it's chained? 1394 00:58:32,785 --> 00:58:33,540 TADGE DRYJA: Yeah. 1395 00:58:33,540 --> 00:58:35,080 AUDIENCE: Like the message? 1396 00:58:35,080 --> 00:58:35,830 TADGE DRYJA: Yeah. 1397 00:58:38,225 --> 00:58:39,850 You're only concerned with the channels 1398 00:58:39,850 --> 00:58:41,200 you're participating in. 1399 00:58:41,200 --> 00:58:45,420 If there's something else happening before it, 1400 00:58:45,420 --> 00:58:49,930 you might want to watch in case ours shows up. 1401 00:58:49,930 --> 00:58:52,750 But you don't have to worry about it. 1402 00:58:52,750 --> 00:58:54,500 And then, these will all get broadcast. 1403 00:58:54,500 --> 00:58:58,320 The failure mode is broadcast everything onto the blockchain, 1404 00:58:58,320 --> 00:59:00,330 and let the blockchain sort it out. 1405 00:59:00,330 --> 00:59:04,650 And that's very high latency because it's, like, 10 minutes. 1406 00:59:04,650 --> 00:59:06,750 But the idea is the blockchain already 1407 00:59:06,750 --> 00:59:08,400 has that global consensus because it's 1408 00:59:08,400 --> 00:59:11,310 really high latency and everyone can agree on it. 1409 00:59:11,310 --> 00:59:13,940 So I think that's the basic idea. 1410 00:59:13,940 --> 00:59:17,350 Yeah, so what you could do here is you could just close it. 1411 00:59:17,350 --> 00:59:17,850 Right? 1412 00:59:17,850 --> 00:59:20,040 You could broadcast this whole transaction on the blockchain 1413 00:59:20,040 --> 00:59:21,240 and get the payment through. 1414 00:59:21,240 --> 00:59:22,470 That's really inefficient. 1415 00:59:22,470 --> 00:59:27,170 You want to keep your channels open so what instead happens-- 1416 00:59:27,170 --> 00:59:29,333 when everything's working. 1417 00:59:29,333 --> 00:59:30,000 It could happen. 1418 00:59:30,000 --> 00:59:30,230 right? 1419 00:59:30,230 --> 00:59:31,310 Carol could just broadcast it. 1420 00:59:31,310 --> 00:59:32,030 OK, that's annoying. 1421 00:59:32,030 --> 00:59:32,540 Whatever. 1422 00:59:32,540 --> 00:59:33,860 But no one loses money. 1423 00:59:33,860 --> 00:59:35,725 Or Carol can go offline, at this point. 1424 00:59:35,725 --> 00:59:37,100 And then, these things get stuck. 1425 00:59:37,100 --> 00:59:38,930 And there's all sorts of weird things that can go wrong, 1426 00:59:38,930 --> 00:59:40,178 but you don't lose money. 1427 00:59:40,178 --> 00:59:41,720 But what happens when things go right 1428 00:59:41,720 --> 00:59:47,450 is Carol says, hey, Bob, I know R. And so really, 1429 00:59:47,450 --> 00:59:51,110 this whole crazy HTLC thing, it's just my money. 1430 00:59:51,110 --> 00:59:53,900 I know what R is. 1431 00:59:53,900 --> 00:59:56,210 You're not getting this money at 4:00 o'clock 1432 00:59:56,210 --> 00:59:57,350 because I know R. So here. 1433 00:59:57,350 --> 00:59:58,040 Look. 1434 00:59:58,040 --> 01:00:02,450 I'll tell you R. And when Carol tells Bob R, 1435 01:00:02,450 --> 01:00:03,440 she's doing two things. 1436 01:00:03,440 --> 01:00:06,990 She's proving that this HTLC is her money. 1437 01:00:06,990 --> 01:00:11,690 She's also giving Bob R so that he can then grab Alice's money. 1438 01:00:14,300 --> 01:00:16,850 And so as soon as she reveals R to Bob, Bob says, 1439 01:00:16,850 --> 01:00:18,260 yeah, I agree. 1440 01:00:18,260 --> 01:00:20,870 This HTLC is superfluous, at this point. 1441 01:00:20,870 --> 01:00:23,480 I know you know R, so this is just your money. 1442 01:00:23,480 --> 01:00:26,980 And if it gets close to 4:00 o'clock, 1443 01:00:26,980 --> 01:00:29,480 I know you're going to broadcast this channel onto the chain 1444 01:00:29,480 --> 01:00:30,920 if I don't let you clear it out. 1445 01:00:30,920 --> 01:00:35,390 So let's just make a new state through these state updates 1446 01:00:35,390 --> 01:00:38,000 where you just have the extra money. 1447 01:00:38,000 --> 01:00:39,440 Let's clear out that HTLC. 1448 01:00:39,440 --> 01:00:41,495 So that 1 coin goes to you. 1449 01:00:41,495 --> 01:00:42,620 And Carol's like, OK, cool. 1450 01:00:42,620 --> 01:00:43,100 I agree. 1451 01:00:43,100 --> 01:00:44,642 We'll sign this, and they'll all just 1452 01:00:44,642 --> 01:00:45,980 get rid of the HTLC output. 1453 01:00:45,980 --> 01:00:48,940 Then, Bob goes to Alice and says, hey, Alice, guess what? 1454 01:00:48,940 --> 01:00:53,720 I know R. So this part, I'm going to do it. 1455 01:00:53,720 --> 01:00:55,590 I know R and Bob. 1456 01:00:55,590 --> 01:00:58,230 Alice, after 5:00 o'clock, it's not happening. 1457 01:00:58,230 --> 01:01:02,070 If you stop answering me and it gets to 4:30, 1458 01:01:02,070 --> 01:01:07,020 I'm just going to broadcast the channel on chain 1459 01:01:07,020 --> 01:01:09,010 and grab it that way. 1460 01:01:09,010 --> 01:01:12,275 And then, Bob reveals R to Alice. 1461 01:01:12,275 --> 01:01:15,120 Alice says, oh yeah, you do know R. OK, we'll clear the HTLC up, 1462 01:01:15,120 --> 01:01:17,350 and you get the money. 1463 01:01:17,350 --> 01:01:19,340 And then, Alice gets R. And that's, sort of, 1464 01:01:19,340 --> 01:01:20,800 a receipt for the payment. 1465 01:01:20,800 --> 01:01:23,620 And Alice knows, well, Carol was the one who 1466 01:01:23,620 --> 01:01:26,880 told me H. Carol must have gotten the money. 1467 01:01:26,880 --> 01:01:27,640 Right? 1468 01:01:27,640 --> 01:01:30,605 So that's my confirmation of that. 1469 01:01:30,605 --> 01:01:35,420 AUDIENCE: How does creating a new channel state of the HTLC-- 1470 01:01:35,420 --> 01:01:38,607 how does that provoke the HTLC itself? 1471 01:01:38,607 --> 01:01:40,690 TADGE DRYJA: Oh, so I didn't put it in the script. 1472 01:01:40,690 --> 01:01:44,440 But it's revocable the same way the regular outputs 1473 01:01:44,440 --> 01:01:45,620 are revocable. 1474 01:01:45,620 --> 01:01:49,240 There's also this, which you don't even 1475 01:01:49,240 --> 01:01:52,810 have to do because the idea is that the HTLCs are very 1476 01:01:52,810 --> 01:01:56,860 small in comparison with the other outputs in the state 1477 01:01:56,860 --> 01:01:58,810 that, if you try to broadcast an old one, 1478 01:01:58,810 --> 01:02:01,540 you'll lose way more than the HTLCs worth. 1479 01:02:01,540 --> 01:02:07,580 But you can also tack on a or other clause to the HTLC script 1480 01:02:07,580 --> 01:02:09,650 with a relative lock time. 1481 01:02:09,650 --> 01:02:12,290 So there's actually a couple different ways to do it. 1482 01:02:12,290 --> 01:02:15,210 The simplest is you just say, look, 1483 01:02:15,210 --> 01:02:20,420 I've got 2 coins, 7 coins, and then a 1 coin HTLC. 1484 01:02:20,420 --> 01:02:24,230 I'm not going to risk my 7 coins to go back and try 1485 01:02:24,230 --> 01:02:27,590 to get this 1 coin in HTLC. 1486 01:02:27,590 --> 01:02:29,750 But that's not how most of the software does it. 1487 01:02:29,750 --> 01:02:31,130 You just add a new clause. 1488 01:02:31,130 --> 01:02:36,950 OK, so this is a multiple party adversarial. 1489 01:02:36,950 --> 01:02:39,188 Whoops. 1490 01:02:39,188 --> 01:02:40,730 So yeah, that would be really useful. 1491 01:02:40,730 --> 01:02:41,230 Right? 1492 01:02:41,230 --> 01:02:44,090 You build lots of nodes with channels connecting. 1493 01:02:44,090 --> 01:02:46,310 And they form a big graph. 1494 01:02:46,310 --> 01:02:47,750 And then, you can request payment 1495 01:02:47,750 --> 01:02:50,930 routing via these HTLC outputs. 1496 01:02:50,930 --> 01:02:52,730 And if you open a few channels, then you 1497 01:02:52,730 --> 01:02:55,190 can pay lots of different users on the network. 1498 01:02:55,190 --> 01:02:55,825 Yes? 1499 01:02:55,825 --> 01:02:57,200 AUDIENCE: I may have missed this, 1500 01:02:57,200 --> 01:03:01,093 but what is Bob's incentive in relaying transactions? 1501 01:03:01,093 --> 01:03:01,760 TADGE DRYJA: OK. 1502 01:03:01,760 --> 01:03:05,900 So yeah, Bob could charge a fee, or he could just be a nice guy. 1503 01:03:05,900 --> 01:03:07,820 That's, basically, the-- 1504 01:03:07,820 --> 01:03:11,760 AUDIENCE: But you said you never ask for [INAUDIBLE],, 1505 01:03:11,760 --> 01:03:13,890 because you know Bob's not a nice guy. 1506 01:03:13,890 --> 01:03:16,190 TADGE DRYJA: Yeah, so you can pay him. 1507 01:03:16,190 --> 01:03:17,930 It's going to be hard to pay him much 1508 01:03:17,930 --> 01:03:20,840 because Alice is going to say, look, we've got a channel. 1509 01:03:20,840 --> 01:03:22,040 We're using it. 1510 01:03:22,040 --> 01:03:24,532 If you charge me a ton to forward payments to Carol, 1511 01:03:24,532 --> 01:03:25,990 I'm just going to close the channel 1512 01:03:25,990 --> 01:03:28,280 and open with someone who does it cheaper. 1513 01:03:28,280 --> 01:03:31,910 So yeah, you can make the amounts slightly less. 1514 01:03:31,910 --> 01:03:34,910 So Alice says, I'm sending you 1 coin. 1515 01:03:34,910 --> 01:03:39,140 And Bob says, OK, I'm sending 0.9999 coins to Carol, 1516 01:03:39,140 --> 01:03:42,920 and I'm keeping the difference. 1517 01:03:42,920 --> 01:03:43,915 You can have that. 1518 01:03:43,915 --> 01:03:45,290 And then, it's really up to Carol 1519 01:03:45,290 --> 01:03:48,980 to decide if the fee-- because all Alice knows is, hey, 1520 01:03:48,980 --> 01:03:51,380 I'm sending one coin. 1521 01:03:51,380 --> 01:03:53,730 What if Bob puts a crazy fee, like 1/2 a coin? 1522 01:03:53,730 --> 01:03:55,820 Carol sees 0.5. 1523 01:03:55,820 --> 01:03:58,590 And Carol's like, no, that's way too low. 1524 01:03:58,590 --> 01:04:00,230 I don't know what happened, if Alice 1525 01:04:00,230 --> 01:04:03,170 sent 0.5 and Bob forwarded it to me 1526 01:04:03,170 --> 01:04:06,060 or if Alice sent 1 and Bob forwarded me 0.5. 1527 01:04:06,060 --> 01:04:07,200 But I'm not accepting this. 1528 01:04:07,200 --> 01:04:07,700 Right? 1529 01:04:07,700 --> 01:04:10,130 I'm not going to reveal R to you. 1530 01:04:10,130 --> 01:04:11,800 I'm just going to say no. 1531 01:04:11,800 --> 01:04:12,980 So you can do that. 1532 01:04:12,980 --> 01:04:15,095 At this point, Carol has not yet revealed 1533 01:04:15,095 --> 01:04:18,230 R. Carol can refuse and say, look, Bob, 1534 01:04:18,230 --> 01:04:19,760 I'm not going to accept this HTLC. 1535 01:04:19,760 --> 01:04:22,490 We can just clear it out right away without revealing R 1536 01:04:22,490 --> 01:04:24,970 and just, basically, undo what we just did. 1537 01:04:24,970 --> 01:04:25,470 Yeah. 1538 01:04:25,470 --> 01:04:27,840 AUDIENCE: So two follow-ups to that. 1539 01:04:27,840 --> 01:04:31,730 The first is, can there be a situation where 1540 01:04:31,730 --> 01:04:35,360 it's an efficient market place for these relaying 1541 01:04:35,360 --> 01:04:39,170 points in the network where Alice asks for a bid, 1542 01:04:39,170 --> 01:04:41,000 and the lowest transaction fee wins 1543 01:04:41,000 --> 01:04:42,305 and she routes it from that? 1544 01:04:42,305 --> 01:04:43,280 TADGE DRYJA: You can. 1545 01:04:43,280 --> 01:04:48,590 So let's say Alice is connected to three Bob's in the middle, 1546 01:04:48,590 --> 01:04:50,450 and then asks all of them, hey, what 1547 01:04:50,450 --> 01:04:53,190 are you going to charge me to forward a coin to Carol? 1548 01:04:53,190 --> 01:04:55,940 Then, they can all answer. 1549 01:04:55,940 --> 01:04:58,610 It's a little weird because they can lie, at that point 1550 01:04:58,610 --> 01:05:00,990 because they haven't actually signed anything. 1551 01:05:00,990 --> 01:05:03,400 And this, Bob can say, oh, I'll do it for free. 1552 01:05:03,400 --> 01:05:05,480 And this Bob says, oh, I'll do it for 1/2 a coin. 1553 01:05:05,480 --> 01:05:07,520 And this Bob says, I'll do it a tenth of a coin. 1554 01:05:07,520 --> 01:05:09,710 And then, you try to go for the free one, 1555 01:05:09,710 --> 01:05:14,180 and Carol gets some really low amount and says, 1556 01:05:14,180 --> 01:05:18,320 I'm not telling you R. Let's cancel this. 1557 01:05:18,320 --> 01:05:22,310 And then, if Alice trusts Carol, Carol could be like, 1558 01:05:22,310 --> 01:05:25,430 Alice, Bob just tried to charge a ridiculous fee. 1559 01:05:25,430 --> 01:05:26,370 Don't use this. 1560 01:05:26,370 --> 01:05:27,757 You know, this Bob is bad. 1561 01:05:27,757 --> 01:05:29,840 And then, you try the other Bob, and the other Bob 1562 01:05:29,840 --> 01:05:30,830 does the right thing. 1563 01:05:30,830 --> 01:05:31,330 Yeah. 1564 01:05:31,330 --> 01:05:35,603 AUDIENCE: Can't Alice just send directly to Carol? 1565 01:05:35,603 --> 01:05:36,770 TADGE DRYJA: Open a channel? 1566 01:05:36,770 --> 01:05:37,870 So yeah, you could. 1567 01:05:37,870 --> 01:05:39,203 You just have to open a channel. 1568 01:05:39,203 --> 01:05:41,540 AUDIENCE: Is that expensive or something? 1569 01:05:41,540 --> 01:05:42,460 TADGE DRYJA: Yeah. 1570 01:05:42,460 --> 01:05:43,460 You have to go on chain. 1571 01:05:47,960 --> 01:05:50,300 We, sort of, saw a preview of it in November, December, 1572 01:05:50,300 --> 01:05:52,730 and January where it was actually, kind of, 1573 01:05:52,730 --> 01:05:54,530 expensive to use Bitcoin. 1574 01:05:54,530 --> 01:05:55,460 Now it's cheap again. 1575 01:05:55,460 --> 01:05:57,020 Costs a few cents. 1576 01:05:57,020 --> 01:05:59,990 But for a month or two, it was like, oh shoot. 1577 01:05:59,990 --> 01:06:05,760 Like, this costs $5 to make a on chain transaction. 1578 01:06:05,760 --> 01:06:08,930 And so creating a direct channel from Alice to Carol, 1579 01:06:08,930 --> 01:06:10,490 it might cost $5. 1580 01:06:10,490 --> 01:06:11,720 Or it might cost $20. 1581 01:06:11,720 --> 01:06:14,840 Or long term, if everyone's trying to use the blockchain 1582 01:06:14,840 --> 01:06:18,470 and the fees go really high, it could be, kind of, expensive. 1583 01:06:18,470 --> 01:06:20,990 And so the idea is, well, if I've got a channel already, 1584 01:06:20,990 --> 01:06:23,780 I'd rather use that and move my money around that way 1585 01:06:23,780 --> 01:06:26,188 without having to touch the blockchain. 1586 01:06:26,188 --> 01:06:27,550 Yeah. 1587 01:06:27,550 --> 01:06:31,353 AUDIENCE: Wouldn't it be a graph problem 1588 01:06:31,353 --> 01:06:33,770 trying to figure out what the cheapest way to get to Carol 1589 01:06:33,770 --> 01:06:34,270 is? 1590 01:06:34,270 --> 01:06:37,530 Would that be [INAUDIBLE],, and would that be scalable? 1591 01:06:37,530 --> 01:06:40,373 TADGE DRYJA: So you can sort of-- 1592 01:06:40,373 --> 01:06:42,290 so it's [INAUDIBLE] or it's like [INAUDIBLE],, 1593 01:06:42,290 --> 01:06:44,810 kind of, if you know the whole graph. 1594 01:06:44,810 --> 01:06:47,420 AUDIENCE: Yeah, but then you have to ask. 1595 01:06:47,420 --> 01:06:48,582 TADGE DRYJA: Yeah. 1596 01:06:48,582 --> 01:06:50,540 So the one part is if you know the whole graph. 1597 01:06:50,540 --> 01:06:53,420 And you can know the whole graph because the graph never 1598 01:06:53,420 --> 01:06:55,910 gets bigger than the UTXO set. 1599 01:06:55,910 --> 01:06:58,448 Every channel is a transaction output. 1600 01:06:58,448 --> 01:06:59,990 And so, if you're running a full node 1601 01:06:59,990 --> 01:07:03,140 and you have the whole UTXO set, the entire graph 1602 01:07:03,140 --> 01:07:06,150 is on the order of that size. 1603 01:07:06,150 --> 01:07:07,700 So maybe it's twice as big in that 1604 01:07:07,700 --> 01:07:10,400 you have to have some extra metadata about what 1605 01:07:10,400 --> 01:07:12,630 these outputs are. 1606 01:07:12,630 --> 01:07:14,510 And Bob and Carol can make proof. 1607 01:07:14,510 --> 01:07:16,190 So like, oh, here is our channel, 1608 01:07:16,190 --> 01:07:17,420 and it's in the UTXO set. 1609 01:07:17,420 --> 01:07:20,810 And we can reveal our pub keys, the big O in here. 1610 01:07:20,810 --> 01:07:22,700 So if you have the whole graph, you 1611 01:07:22,700 --> 01:07:27,443 could do some routing that's in login kind of speed. 1612 01:07:27,443 --> 01:07:28,610 But then, it might not work. 1613 01:07:32,450 --> 01:07:36,810 So there's actually tons of ways things can go wrong in this. 1614 01:07:36,810 --> 01:07:41,210 That's the, sort of, fun part of dealing with it. 1615 01:07:41,210 --> 01:07:43,700 One of the ways it can not work is you're like, yeah, 1616 01:07:43,700 --> 01:07:45,560 I found a path. 1617 01:07:45,560 --> 01:07:49,570 The simplest is, I found a path, and I query Bob, 1618 01:07:49,570 --> 01:07:50,930 and Bob is just offline. 1619 01:07:50,930 --> 01:07:51,770 I'm like, oh, OK. 1620 01:07:51,770 --> 01:07:54,200 Well, that's not an active path. 1621 01:07:54,200 --> 01:07:56,450 OK, what's the second shortest path? 1622 01:07:56,450 --> 01:07:59,400 OK, this other Bob, and he says, yes. 1623 01:07:59,400 --> 01:08:00,650 But the fee seems really high. 1624 01:08:00,650 --> 01:08:01,790 So OK, I found the-- 1625 01:08:01,790 --> 01:08:03,650 So most of the algorithms, though, 1626 01:08:03,650 --> 01:08:06,860 will get you the second and third and fourth and fifth 1627 01:08:06,860 --> 01:08:10,220 shortest in much less time than recomputing 1628 01:08:10,220 --> 01:08:11,970 the whole thing from scratch. 1629 01:08:11,970 --> 01:08:15,800 So you can get a bunch of pretty good ones and try them all. 1630 01:08:15,800 --> 01:08:18,624 Like query and the-- 1631 01:08:18,624 --> 01:08:20,249 AUDIENCE: By the time you try them all, 1632 01:08:20,249 --> 01:08:23,120 what if the first Bob is online and you try the first Bob? 1633 01:08:23,120 --> 01:08:23,870 TADGE DRYJA: Yeah. 1634 01:08:23,870 --> 01:08:28,850 The thing is, in practice, it's all real fast. 1635 01:08:28,850 --> 01:08:31,430 Well right now, for a small network, it's nothing. 1636 01:08:31,430 --> 01:08:33,740 But even total number of UTXOs is on the order 1637 01:08:33,740 --> 01:08:34,580 of, like, millions. 1638 01:08:34,580 --> 01:08:35,210 Right? 1639 01:08:35,210 --> 01:08:40,700 So if you've got a graph with millions of edges, 1640 01:08:40,700 --> 01:08:41,850 that's easy for a computer. 1641 01:08:41,850 --> 01:08:42,350 Right? 1642 01:08:42,350 --> 01:08:45,380 They'll do it in less than a second. 1643 01:08:45,380 --> 01:08:48,830 And then, your main thing here is network latency 1644 01:08:48,830 --> 01:08:50,350 for all of these things. 1645 01:08:50,350 --> 01:08:55,303 For building new states, it's the time taken for the data 1646 01:08:55,303 --> 01:08:56,720 to get from one side to the other. 1647 01:08:56,720 --> 01:08:59,240 It's much larger than computing the signatures, 1648 01:08:59,240 --> 01:09:02,660 verifying the signatures, building the hash tree thing. 1649 01:09:02,660 --> 01:09:06,130 All that stuff is real fast compared to a network. 1650 01:09:06,130 --> 01:09:07,310 So the same with routing. 1651 01:09:07,310 --> 01:09:10,040 Looking at the graph and dissecting it 1652 01:09:10,040 --> 01:09:14,510 is going to be faster than contacting all the things. 1653 01:09:14,510 --> 01:09:16,760 There's a bunch of other things that can go wrong. 1654 01:09:16,760 --> 01:09:24,149 So for example, this gets built, get to here, 1655 01:09:24,149 --> 01:09:27,939 and Carol just stops responding. 1656 01:09:27,939 --> 01:09:30,849 So now you've got these two HTLCs. 1657 01:09:30,849 --> 01:09:34,649 They're a third output in your channel transaction, 1658 01:09:34,649 --> 01:09:36,798 and Carol's just not saying anything. 1659 01:09:36,798 --> 01:09:37,965 And then, Alice goes to Bob. 1660 01:09:37,965 --> 01:09:39,120 He's like, Bob, what's up? 1661 01:09:39,120 --> 01:09:40,800 Like, we're going to clear this HTLC. 1662 01:09:40,800 --> 01:09:42,479 Usually, these only take a second. 1663 01:09:42,479 --> 01:09:44,819 And Bob's like, uh, yeah, hold on. 1664 01:09:44,819 --> 01:09:48,920 And so it's, kind of, awkward because now we've got this HTLC 1665 01:09:48,920 --> 01:09:52,229 and you don't know whose money it ends up being. 1666 01:09:52,229 --> 01:09:54,710 The way to mitigate that, Rusty-- 1667 01:09:54,710 --> 01:09:56,910 yeah, I think it works; Rusty's the other guy 1668 01:09:56,910 --> 01:09:58,800 who works on this stuff-- 1669 01:09:58,800 --> 01:10:02,100 was that he has a timeout period-- 1670 01:10:02,100 --> 01:10:04,710 I think 30 seconds, a minute, whatever-- 1671 01:10:04,710 --> 01:10:08,760 where Alice says, OK, Bob, I made this HTLC a minute ago. 1672 01:10:08,760 --> 01:10:09,810 Minute's up. 1673 01:10:09,810 --> 01:10:12,600 You need to either shut down this channel 1674 01:10:12,600 --> 01:10:14,970 right now because you're doing something bad, 1675 01:10:14,970 --> 01:10:20,400 or you need to prove to me that a channel has been shut down 1676 01:10:20,400 --> 01:10:23,710 with this HTLC, this H value in it. 1677 01:10:23,710 --> 01:10:26,190 And then, I know where to ascribe blame. 1678 01:10:26,190 --> 01:10:28,340 So if Bob's like, yeah, I can't contact Carol. 1679 01:10:28,340 --> 01:10:29,073 Carol's offline. 1680 01:10:29,073 --> 01:10:30,240 Then, Alice says, all right. 1681 01:10:30,240 --> 01:10:31,490 Well, then, shut down the channel. 1682 01:10:31,490 --> 01:10:33,032 AUDIENCE: Isn't that pretty expensive 1683 01:10:33,032 --> 01:10:37,060 considering Carol isn't necessarily malicious? 1684 01:10:37,060 --> 01:10:38,780 TADGE DRYJA: Yeah, so that's a downside. 1685 01:10:38,780 --> 01:10:39,280 Right? 1686 01:10:39,280 --> 01:10:41,460 AUDIENCE: Yeah, it seems a little harsh on Carol. 1687 01:10:41,460 --> 01:10:43,860 TADGE DRYJA: Well, the thing is, if you don't do that-- 1688 01:10:43,860 --> 01:10:45,610 AUDIENCE: It just seems to me like running 1689 01:10:45,610 --> 01:10:48,430 a lightning node is not anywhere near as voluntary as running 1690 01:10:48,430 --> 01:10:51,230 a Bitcoin node in this world where it's, like, 1691 01:10:51,230 --> 01:10:52,577 being live really matters. 1692 01:10:52,577 --> 01:10:54,910 Responding even faster than the timeouts really matters. 1693 01:10:54,910 --> 01:10:56,200 TADGE DRYJA: OK. 1694 01:10:56,200 --> 01:10:57,930 OK, one thing to mitigate that. 1695 01:11:01,560 --> 01:11:06,270 Carol responded by signing off on the HTLC, 1696 01:11:06,270 --> 01:11:08,253 and then immediately goes offline. 1697 01:11:08,253 --> 01:11:09,420 It's not like you accident-- 1698 01:11:09,420 --> 01:11:10,712 AUDIENCE: This is all protocol. 1699 01:11:10,712 --> 01:11:12,620 She didn't truly break the rule by doing so. 1700 01:11:12,620 --> 01:11:14,245 TADGE DRYJA: Well, part of the protocol 1701 01:11:14,245 --> 01:11:17,610 is, if you have an HTLC and you don't remove it 1702 01:11:17,610 --> 01:11:20,850 within 30 to 60 seconds, it's like, you know, 1703 01:11:20,850 --> 01:11:22,920 that's a violation of the rules, and we're 1704 01:11:22,920 --> 01:11:26,370 going to close their channels because if you're 1705 01:11:26,370 --> 01:11:29,183 just straight up offline, and then it's like, well, OK, 1706 01:11:29,183 --> 01:11:30,600 I'm not going to use that channel. 1707 01:11:30,600 --> 01:11:32,640 But it's like, oh, I accepted this, 1708 01:11:32,640 --> 01:11:35,970 and immediately said, OK, I'm not talking to you anymore. 1709 01:11:35,970 --> 01:11:38,970 And they're like, well, now it's stuck because the attack 1710 01:11:38,970 --> 01:11:42,120 vector is build a ton of HTLCs. 1711 01:11:42,120 --> 01:11:45,210 You could add multiple per channel and build them all, 1712 01:11:45,210 --> 01:11:46,260 and they all get stuck. 1713 01:11:46,260 --> 01:11:49,260 And one party is just not responding with their R values. 1714 01:11:49,260 --> 01:11:52,800 And then, everyone's like, OK, if we try to close, 1715 01:11:52,800 --> 01:11:54,900 our transactions now have, like, 100 outputs. 1716 01:11:54,900 --> 01:11:57,120 And they're huge and have all these fees. 1717 01:11:57,120 --> 01:12:00,360 Also, all these HTLCs, yeah, they might be really little, 1718 01:12:00,360 --> 01:12:01,650 and we have to wait. 1719 01:12:01,650 --> 01:12:04,440 And then, it charges a lot of fees to recover them and stuff. 1720 01:12:04,440 --> 01:12:07,470 So you don't want people to be able to, 1721 01:12:07,470 --> 01:12:09,910 sort of, blow up the number of HTLCs in your channels. 1722 01:12:09,910 --> 01:12:12,570 So the way to do it is, if one of them is stuck, 1723 01:12:12,570 --> 01:12:14,130 you need to find someone to blame. 1724 01:12:14,130 --> 01:12:16,980 And yeah, it's possible. 1725 01:12:16,980 --> 01:12:17,480 Right? 1726 01:12:17,480 --> 01:12:20,340 But the thing is, you accurately find the person to blame. 1727 01:12:20,340 --> 01:12:23,840 If Carol accepts the HTLC, and then, a split second later, 1728 01:12:23,840 --> 01:12:26,920 unplugs their computer, Bob's like, what? 1729 01:12:26,920 --> 01:12:27,420 OK, fine. 1730 01:12:27,420 --> 01:12:28,170 I'm closing the channel. 1731 01:12:28,170 --> 01:12:30,030 You just did something really annoying. 1732 01:12:30,030 --> 01:12:33,048 And Bob's like, if I don't close this channel, 1733 01:12:33,048 --> 01:12:35,340 Alice is going to close the channel on me because Alice 1734 01:12:35,340 --> 01:12:37,970 is going to think I'm the one acting weird. 1735 01:12:37,970 --> 01:12:42,525 So yeah, there's all sorts of weird edge cases. 1736 01:12:45,108 --> 01:12:47,150 There's all sorts of weird stuff that can happen. 1737 01:12:47,150 --> 01:12:49,980 It's definitely more complicated than just the straight up UTXOs 1738 01:12:49,980 --> 01:12:51,050 in Bitcoin. 1739 01:12:51,050 --> 01:12:51,900 Yes? 1740 01:12:51,900 --> 01:12:54,080 AUDIENCE: Couldn't Carol respond to Bob, 1741 01:12:54,080 --> 01:12:56,430 and then Bob be malicious and close the channel? 1742 01:12:56,430 --> 01:12:58,670 And then say, hey, Alice, check it out. 1743 01:12:58,670 --> 01:12:59,800 Carol was malicious. 1744 01:12:59,800 --> 01:13:01,130 TADGE DRYJA: Yep. 1745 01:13:01,130 --> 01:13:01,630 That's OK. 1746 01:13:01,630 --> 01:13:03,588 AUDIENCE: And then, you wouldn't get the blame, 1747 01:13:03,588 --> 01:13:04,940 but Carol presumably-- 1748 01:13:04,940 --> 01:13:06,800 TADGE DRYJA: Bob blames Carol. 1749 01:13:06,800 --> 01:13:08,938 Carol says, no, it was actually Bob. 1750 01:13:08,938 --> 01:13:10,730 From Alice's point of view, like, whatever. 1751 01:13:10,730 --> 01:13:13,220 Like, something got closed. 1752 01:13:13,220 --> 01:13:15,440 There was a cost to adding this HTLC. 1753 01:13:15,440 --> 01:13:18,140 You know, there was a cost to having me stuck 1754 01:13:18,140 --> 01:13:20,340 with this HTLC for five hours. 1755 01:13:20,340 --> 01:13:20,930 Right? 1756 01:13:20,930 --> 01:13:22,640 Something unchained happened. 1757 01:13:22,640 --> 01:13:26,240 So the thing is, having one HTLC stuck for a few hours 1758 01:13:26,240 --> 01:13:28,460 is no big deal. 1759 01:13:28,460 --> 01:13:31,340 After 5:00, Alice just goes to Bob 1760 01:13:31,340 --> 01:13:33,780 and is like, look, well let's clear it. 1761 01:13:33,780 --> 01:13:34,280 Right? 1762 01:13:34,280 --> 01:13:36,822 You don't know R. If you knew R, you would've told me by now, 1763 01:13:36,822 --> 01:13:38,450 so let's just get rid of this thing. 1764 01:13:38,450 --> 01:13:41,380 And Bob's like, yeah, fine. 1765 01:13:41,380 --> 01:13:42,630 And they clear it out. 1766 01:13:42,630 --> 01:13:45,260 So the idea is it's not a big attack 1767 01:13:45,260 --> 01:13:46,520 if you only have one of them. 1768 01:13:46,520 --> 01:13:49,460 You want some cost to performing that. 1769 01:13:49,460 --> 01:13:51,140 And so if Bob closes the channel-- 1770 01:13:51,140 --> 01:13:52,580 whether it's Carol's fault or Bob's fault-- 1771 01:13:52,580 --> 01:13:54,788 Alice is sort of like, look, well something happened, 1772 01:13:54,788 --> 01:13:56,847 so someone's bearing the cost for this. 1773 01:13:56,847 --> 01:13:58,430 So they're not going to keep doing it. 1774 01:13:58,430 --> 01:13:59,240 OK. 1775 01:13:59,240 --> 01:14:01,970 AUDIENCE: So in reality, is it maybe like five hours, 1776 01:14:01,970 --> 01:14:03,578 or is it more like couple minutes? 1777 01:14:03,578 --> 01:14:07,190 TADGE DRYJA: You actually need hours because-- 1778 01:14:07,190 --> 01:14:08,030 oh, other attack. 1779 01:14:08,030 --> 01:14:10,835 AUDIENCE: Yeah. 1780 01:14:10,835 --> 01:14:13,480 TADGE DRYJA: Let's say these were both at 5:00. 1781 01:14:13,480 --> 01:14:15,150 Right? 1782 01:14:15,150 --> 01:14:19,170 And then, Carol closes the channel right at 5:00. 1783 01:14:22,500 --> 01:14:27,000 Right before 5:00 o'clock, Carol closes the channel, uses R, 1784 01:14:27,000 --> 01:14:28,470 grabs it. 1785 01:14:28,470 --> 01:14:31,530 Bob then says, oh shoot, there's R. Alice is like, nuh uh. 1786 01:14:31,530 --> 01:14:35,010 Alice closes the channel right after 5:00 and grabs hers 1787 01:14:35,010 --> 01:14:36,810 by signing with her key. 1788 01:14:36,810 --> 01:14:37,950 And then, Bob's screwed. 1789 01:14:37,950 --> 01:14:38,200 Right? 1790 01:14:38,200 --> 01:14:38,970 Bob's like, shoot. 1791 01:14:38,970 --> 01:14:39,630 Wait. 1792 01:14:39,630 --> 01:14:41,443 Carol just got the money from me using R. 1793 01:14:41,443 --> 01:14:43,110 And then, Alice closed and got the money 1794 01:14:43,110 --> 01:14:45,330 from me using the time out. 1795 01:14:45,330 --> 01:14:47,160 And I didn't get anything. 1796 01:14:47,160 --> 01:14:49,860 I lost the money on this side, and I didn't get the money 1797 01:14:49,860 --> 01:14:50,970 on this side. 1798 01:14:50,970 --> 01:14:54,460 So Bob just had a huge loss there. 1799 01:14:54,460 --> 01:14:57,600 So Bob really wants to make sure that this is later. 1800 01:14:57,600 --> 01:15:00,720 Like, Alice can't get the money until well 1801 01:15:00,720 --> 01:15:03,615 after Carol can get the money with the timeout function. 1802 01:15:03,615 --> 01:15:07,620 Or sorry, well after Bob can get his money with the timeout. 1803 01:15:07,620 --> 01:15:10,070 AUDIENCE: Did Bob set that time though? 1804 01:15:10,070 --> 01:15:11,890 TADGE DRYJA: Yeah. 1805 01:15:11,890 --> 01:15:13,110 Hold on. 1806 01:15:13,110 --> 01:15:14,850 Bob sets this time, yes. 1807 01:15:14,850 --> 01:15:15,990 Then, Alice sets this time. 1808 01:15:15,990 --> 01:15:18,448 AUDIENCE: So he just has to make sure they're [INAUDIBLE].. 1809 01:15:18,448 --> 01:15:21,240 TADGE DRYJA: Yeah, he has to make sure his earlier. 1810 01:15:21,240 --> 01:15:26,730 And continuing that, if Carol makes HTLC today-- 1811 01:15:26,730 --> 01:15:29,260 if she makes it at 3:00 o'clock or whatever-- 1812 01:15:29,260 --> 01:15:31,350 I don't remember what the defaults are 1813 01:15:31,350 --> 01:15:33,690 in the different-- like, I do it all in testnet. 1814 01:15:33,690 --> 01:15:37,080 And so in testnet, I do five blocks because who cares. 1815 01:15:37,080 --> 01:15:39,480 I think in the main net one's people are trying out, 1816 01:15:39,480 --> 01:15:43,350 they do quite a bit more because it's better 1817 01:15:43,350 --> 01:15:48,030 to have your money stuck for a day than to lose it, I guess. 1818 01:15:48,030 --> 01:15:51,740 So you can make different time outs and stuff like that. 1819 01:15:51,740 --> 01:15:53,010 OK, what else? 1820 01:15:53,010 --> 01:15:54,020 I'm, basically, done. 1821 01:15:54,020 --> 01:15:56,270 There's a whole bunch of other cool things you can do. 1822 01:15:56,270 --> 01:16:00,390 And I think I'll talk about that next time. 1823 01:16:00,390 --> 01:16:02,280 Yeah, you can do cross chain swaps. 1824 01:16:02,280 --> 01:16:04,680 So this is a preview of after-- 1825 01:16:04,680 --> 01:16:05,850 just real quick. 1826 01:16:05,850 --> 01:16:07,680 This channel and this channel do not 1827 01:16:07,680 --> 01:16:09,332 need to be on the same blockchain. 1828 01:16:09,332 --> 01:16:11,790 Totally fine for this to be Bitcoin and this to be Litecoin 1829 01:16:11,790 --> 01:16:14,640 or this to be Dogecoin. 1830 01:16:14,640 --> 01:16:16,620 It actually totally works. 1831 01:16:16,620 --> 01:16:18,220 So that's kind of cool. 1832 01:16:18,220 --> 01:16:18,720 Security. 1833 01:16:18,720 --> 01:16:22,140 So you want to monitor your channels in case someone 1834 01:16:22,140 --> 01:16:23,400 tries to rip you off. 1835 01:16:23,400 --> 01:16:26,413 You can outsource that in a nice way where 1836 01:16:26,413 --> 01:16:28,330 you can give it to a third party and say, hey, 1837 01:16:28,330 --> 01:16:29,760 I've got this channel. 1838 01:16:29,760 --> 01:16:30,780 Watch it for me. 1839 01:16:30,780 --> 01:16:31,440 Not only that. 1840 01:16:31,440 --> 01:16:32,040 I've got a channel. 1841 01:16:32,040 --> 01:16:32,760 Watch it for me. 1842 01:16:32,760 --> 01:16:33,750 I'm not going to tell you what channel 1843 01:16:33,750 --> 01:16:35,250 it is, how much money I have. 1844 01:16:35,250 --> 01:16:36,760 Basically, anything. 1845 01:16:36,760 --> 01:16:39,360 And you can still protect it for me. 1846 01:16:39,360 --> 01:16:40,480 So that's, kind of, cool. 1847 01:16:40,480 --> 01:16:42,190 You can anonymously do that. 1848 01:16:42,190 --> 01:16:43,830 Stuck HTLCs, I just talked about. 1849 01:16:43,830 --> 01:16:46,200 Dust and fees gets really ugly. 1850 01:16:46,200 --> 01:16:48,010 There's a lot of cool stuff you can do. 1851 01:16:48,010 --> 01:16:50,310 So I think the schedule is I'll talk 1852 01:16:50,310 --> 01:16:53,970 about the rest of lightning on Monday after spring break, 1853 01:16:53,970 --> 01:16:56,070 and then go into discrete log contracts, which 1854 01:16:56,070 --> 01:17:00,070 is another similar construction on the Wednesday after. 1855 01:17:00,070 --> 01:17:00,570 OK. 1856 01:17:00,570 --> 01:17:03,260 Any questions about all this stuff? 1857 01:17:03,260 --> 01:17:04,998 I'm sure, yeah. 1858 01:17:04,998 --> 01:17:08,060 AUDIENCE: What are the time factors that miners 1859 01:17:08,060 --> 01:17:09,260 pose to this situation? 1860 01:17:09,260 --> 01:17:12,550 TADGE DRYJA: Miners can make time outs not happen. 1861 01:17:12,550 --> 01:17:15,170 If they're coordinated, they can say 1862 01:17:15,170 --> 01:17:18,380 we're just going to not accept this transaction till later. 1863 01:17:18,380 --> 01:17:20,590 So that's bad. 1864 01:17:20,590 --> 01:17:24,080 You know, there's other weird attack factors. 1865 01:17:24,080 --> 01:17:25,640 The one that I worry about most-- 1866 01:17:25,640 --> 01:17:27,560 not most-- the one that I worry about 1867 01:17:27,560 --> 01:17:32,510 is, if you make a backup of your wallet and you restore it, 1868 01:17:32,510 --> 01:17:35,420 you lose all your money. 1869 01:17:35,420 --> 01:17:42,680 So you make a backup here at state two onto your USB stick, 1870 01:17:42,680 --> 01:17:46,120 and you go home, and you drop your laptop in the pool. 1871 01:17:46,120 --> 01:17:47,150 And you're like, shoot. 1872 01:17:47,150 --> 01:17:50,630 Well, good thing I got my backup. 1873 01:17:50,630 --> 01:17:51,140 Well, sorry. 1874 01:17:51,140 --> 01:17:54,200 You make a backup here at work on your USB stick. 1875 01:17:54,200 --> 01:17:56,530 And then, you keep spending money. 1876 01:17:56,530 --> 01:17:58,810 And then, you drop your laptop in the pool. 1877 01:17:58,810 --> 01:18:01,870 And then, you restore from your USB stick to here. 1878 01:18:01,870 --> 01:18:04,030 And then, you try to broadcast this. 1879 01:18:04,030 --> 01:18:07,150 But you've already revealed your private keys. 1880 01:18:07,150 --> 01:18:08,710 And so Bob's just like, what? 1881 01:18:08,710 --> 01:18:09,880 Like, that's red. 1882 01:18:09,880 --> 01:18:11,560 Like, you revealed it. 1883 01:18:11,560 --> 01:18:14,880 And then, he takes all the money. 1884 01:18:14,880 --> 01:18:18,070 So yeah, don't make backups. 1885 01:18:18,070 --> 01:18:21,322 The reason I worry about it is it's very counterintuitive. 1886 01:18:21,322 --> 01:18:23,280 There's nothing in the software that does this. 1887 01:18:23,280 --> 01:18:25,822 The software I can write, like, you know, don't make backups. 1888 01:18:25,822 --> 01:18:29,250 Always only keep this, but you can just copy the files. 1889 01:18:29,250 --> 01:18:31,800 And it seems like the kind of thing people 1890 01:18:31,800 --> 01:18:36,120 might do and put warnings on the read me's and stuff. 1891 01:18:36,120 --> 01:18:37,960 So that's, kind of, a big risk. 1892 01:18:37,960 --> 01:18:40,800 So there's a lot of how do we make this safe. 1893 01:18:40,800 --> 01:18:42,300 And a lot of people criticize it. 1894 01:18:42,300 --> 01:18:44,320 Like, this is too complicated. 1895 01:18:44,320 --> 01:18:46,650 There's enormous communities on the internet 1896 01:18:46,650 --> 01:18:48,090 that hate this and hate me. 1897 01:18:48,090 --> 01:18:50,385 And go to RBTC sometimes. 1898 01:18:50,385 --> 01:18:52,260 They really don't like the Lightning Network. 1899 01:18:54,720 --> 01:18:56,970 On the other hand, it's like, well, you don't like it, 1900 01:18:56,970 --> 01:18:57,620 you don't have to use it. 1901 01:18:57,620 --> 01:18:57,900 Right? 1902 01:18:57,900 --> 01:19:00,025 I'm just running the software for free for you guys 1903 01:19:00,025 --> 01:19:02,130 but anyway. 1904 01:19:02,130 --> 01:19:04,980 But yeah, and you know, there's legitimate, 1905 01:19:04,980 --> 01:19:06,967 like, this is kind of complicated. 1906 01:19:06,967 --> 01:19:08,550 It's not going to work for everything. 1907 01:19:08,550 --> 01:19:14,240 There's all sorts of limits to this too.