1 00:00:00,200 --> 00:00:04,700 This is epicenter episode 273 with guest Christian Decker. 2 00:00:19,300 --> 00:00:21,800 This episode of epicenter is brought to you by top-down 3 00:00:22,000 --> 00:00:24,100 experience. A new way of firing has topped 4 00:00:24,100 --> 00:00:27,300 out delivers only the top, three percent of applicants, including 5 00:00:27,500 --> 00:00:29,100 highly skilled blocked and Engineers. 6 00:00:29,300 --> 00:00:32,299 If you're looking to scale your team with a very best talent 7 00:00:32,400 --> 00:00:38,300 visit top.com / epicenter, and by Microsoft Azure, do you have 8 00:00:38,300 --> 00:00:41,400 an idea for a blockchain at but are worried about the time and 9 00:00:41,400 --> 00:00:44,100 cost? We'll take develop the new Azure 10 00:00:44,100 --> 00:00:46,700 blockchain dev kit is a free. Download that brings together 11 00:00:46,700 --> 00:00:48,700 the tools. You need to get your first app 12 00:00:48,700 --> 00:00:53,500 running in less than 30 minutes. Learn more at aka.ms/offweb the 13 00:00:53,500 --> 00:00:59,200 center. Hi, and welcome to episode of my 14 00:00:59,200 --> 00:01:01,900 name is Ryan. Faran crane, my name is Sonia 15 00:01:01,900 --> 00:01:04,099 Agarwal. So we're here today with 16 00:01:04,099 --> 00:01:07,300 Christian Decker. He's been on the podcast before 17 00:01:07,300 --> 00:01:09,600 and we're going to speak a lot about the lightning Network. 18 00:01:09,600 --> 00:01:13,800 So this is really exciting. I think one of the Things when 19 00:01:13,800 --> 00:01:19,000 we did our kind of recap of last year that I brought out with all 20 00:01:19,000 --> 00:01:22,200 I really want to do more Bitcoin episodes, the seems to be, it's 21 00:01:22,200 --> 00:01:24,900 just more momentum there. And so many interesting things 22 00:01:24,900 --> 00:01:27,900 happening and we have been sort of under covering Bitcoins. 23 00:01:27,900 --> 00:01:30,900 I'm really glad that. Now we've done another Bitcoin 24 00:01:30,900 --> 00:01:34,000 episode and two in a row. In fact, two in a row. 25 00:01:34,000 --> 00:01:36,200 Yes. Yes, yeah. 26 00:01:36,200 --> 00:01:37,900 Joking. Before the episode maybe have to 27 00:01:37,900 --> 00:01:40,000 put the big comeback in name but no. 28 00:01:41,600 --> 00:01:45,400 Yeah. So I'm I feel very excited about 29 00:01:45,400 --> 00:01:47,500 Bitcoin and if it was a great conversation to learn a bit 30 00:01:47,500 --> 00:01:49,100 about lightning. Yeah. 31 00:01:49,100 --> 00:01:51,300 Definitely. You know, lightning is such a 32 00:01:51,300 --> 00:01:53,400 big project and you know we haven't actually done a 33 00:01:53,400 --> 00:01:56,700 lightning episode on epicenter since like 2015. 34 00:01:56,700 --> 00:01:59,600 So this is really good because it got a lot of updates on the 35 00:01:59,600 --> 00:02:02,700 status and development and so really great episode. 36 00:02:03,700 --> 00:02:06,200 So you mentioned, you also have some announcements, may you 37 00:02:06,208 --> 00:02:09,300 going to give it talk tomorrow. Yeah. 38 00:02:09,300 --> 00:02:13,600 So there's a panel in Berkeley being held by block tonight 39 00:02:13,600 --> 00:02:16,300 Berkeley in order old and an organization. 40 00:02:16,300 --> 00:02:20,500 I used to be part of it's called blockchain for social impact. 41 00:02:20,500 --> 00:02:23,800 And so it should be a very interesting panel talking with a 42 00:02:23,900 --> 00:02:26,000 bunch of different people. Some people from the open Money 43 00:02:26,000 --> 00:02:28,300 initiative, we're going to be there talking a lot about, you 44 00:02:28,308 --> 00:02:31,700 know, Venezuela and stuff. But should just overall be 45 00:02:31,700 --> 00:02:35,700 really interesting panel to Tomorrow, or I guess if this 46 00:02:35,700 --> 00:02:39,600 episode coming out tomorrow today on the 6th February 6th in 47 00:02:39,600 --> 00:02:43,800 Berkeley California and if you can't make it out, you know, the 48 00:02:43,800 --> 00:02:46,000 recording will be available and will probably tweet it out from 49 00:02:46,000 --> 00:02:49,000 our epicenter, Twitter account, cool. 50 00:02:49,000 --> 00:02:51,200 And then let's go to the conversation with question. 51 00:02:53,600 --> 00:02:55,300 Hi. We heard today with Christian 52 00:02:55,300 --> 00:02:58,300 Decker, he has been on the podcast before it was actually 53 00:02:58,300 --> 00:03:01,200 quite some time ago think about three years. 54 00:03:01,200 --> 00:03:05,200 Three and a half years ago where we did an episode with him about 55 00:03:05,600 --> 00:03:08,600 a paper, he had written called duplex payment channel. 56 00:03:08,600 --> 00:03:13,700 So if you want to check out that episode that's number 106. 57 00:03:14,100 --> 00:03:19,400 So and and he's been working on bitcoin for a long time. 58 00:03:19,400 --> 00:03:24,300 He was the first person to do a PhD about Bitcoin And then he 59 00:03:24,300 --> 00:03:27,800 did a bunch of academic papers including this work on payment 60 00:03:27,800 --> 00:03:30,500 channels, which was, you know, very much related to what kind 61 00:03:30,500 --> 00:03:34,500 of similar to lightning in many ways and then Christian joint 62 00:03:35,000 --> 00:03:38,700 shortly after we did the podcast, he joined the block 63 00:03:38,700 --> 00:03:42,700 stream team and he's been doing a lot of work on. 64 00:03:42,700 --> 00:03:44,800 I think, primarily lightning for Block stream. 65 00:03:44,800 --> 00:03:49,000 So we're excited that question on today and and have a chance 66 00:03:49,000 --> 00:03:52,100 to dive into lightning where I think so much has happened and 67 00:03:52,100 --> 00:03:55,000 of course. Yeah, we've done a few episodes, 68 00:03:55,000 --> 00:03:59,800 but actually they're mostly in 2015 so long time ago. 69 00:03:59,800 --> 00:04:01,700 So yeah, thanks so much for coming on kitchen. 70 00:04:02,000 --> 00:04:04,900 Yeah, thanks so much for having me excited to be back. 71 00:04:05,100 --> 00:04:08,900 It's been a while. Yeah, it has been a while so 72 00:04:08,900 --> 00:04:11,600 people should go to the last episode in here, this more 73 00:04:11,600 --> 00:04:14,000 detail but maybe we can just briefly recap. 74 00:04:14,200 --> 00:04:16,300 So how did you originally get into Bitcoin? 75 00:04:16,300 --> 00:04:20,500 And how did you end up doing like the first PhD error on the 76 00:04:20,500 --> 00:04:24,800 topic? I was doing a master in 77 00:04:24,800 --> 00:04:29,500 distributed computing and distributed systems back in 2009 78 00:04:29,900 --> 00:04:33,900 and I stumbled over this strange small paper and I thought wait 79 00:04:33,900 --> 00:04:40,600 this is this is interesting. And so I've I went to the online 80 00:04:40,600 --> 00:04:43,600 firms and research there and, and start discussing with 81 00:04:43,600 --> 00:04:48,000 people, and for a long time, it was just just sort of this thing 82 00:04:48,000 --> 00:04:49,900 that was in my, in the back of my mind. 83 00:04:50,500 --> 00:04:57,700 And then at some point in 2012, it was about time to to choose a 84 00:04:57,707 --> 00:05:03,600 topic for my PhD and I decided that Bitcoin might be worth 85 00:05:03,600 --> 00:05:07,000 giving it a shot. And since nobody was Thing that 86 00:05:07,000 --> 00:05:10,500 Bitcoin might still be around and three years time, which is 87 00:05:10,500 --> 00:05:13,400 the usual time. It takes for a PhD to complete. 88 00:05:13,400 --> 00:05:18,600 I was was careful to set to make it blockchain and Bitcoin and 89 00:05:19,600 --> 00:05:24,600 sort of line up a whole slew of different topics that we might 90 00:05:24,700 --> 00:05:28,100 try to bring it to look at and including scalability. 91 00:05:28,600 --> 00:05:31,600 And it turns out that. Yeah, the the whole scalability 92 00:05:31,600 --> 00:05:35,500 topic was really popular and that's what I basically did my 93 00:05:35,500 --> 00:05:42,400 my entire page. Jion and it ended up being being 94 00:05:42,400 --> 00:05:49,400 successful in 2016 and I was I was worried the first PhD in 95 00:05:49,500 --> 00:05:55,600 about Bitcoin and world and yeah, been working on that stuff 96 00:05:55,600 --> 00:05:59,800 ever since. So, you said you started the PHD 97 00:05:59,800 --> 00:06:02,100 in 2012 though like working on it. 98 00:06:02,200 --> 00:06:05,700 Yeah. And and already back, then you 99 00:06:05,700 --> 00:06:09,500 say, scale, Goldie was kind of a very popular topic. 100 00:06:09,900 --> 00:06:12,500 Oh yeah. I mean it, it was among other 101 00:06:12,500 --> 00:06:17,800 things, one of the parts that I outlined in sort of my pitch to 102 00:06:17,800 --> 00:06:21,200 my professor, that I want of topics that I wanted to discuss 103 00:06:22,100 --> 00:06:24,400 the scalability topic was very much in mind. 104 00:06:25,300 --> 00:06:29,800 It is. I mean, we were distributed 105 00:06:29,800 --> 00:06:31,700 computing in distributed systems group. 106 00:06:31,700 --> 00:06:35,600 So scalability quite quickly comes to mind. 107 00:06:35,600 --> 00:06:39,900 When when When you're talking about this kind of system, and 108 00:06:40,800 --> 00:06:44,100 from just looking from the outside, it was pretty clear 109 00:06:44,100 --> 00:06:50,200 that this will not scale to infinite transactions and 110 00:06:50,200 --> 00:06:54,500 infinite participants in at least in its current form. 111 00:06:56,000 --> 00:07:01,200 And that's also something that we, that we discovered while 112 00:07:01,200 --> 00:07:04,700 working on it that yes, scaling scaling blockchains is hard. 113 00:07:05,300 --> 00:07:09,800 So, Yeah, we we ended up sort of sidestepping the entire 114 00:07:10,000 --> 00:07:15,100 scalability to discussion and and going for systems that 115 00:07:15,400 --> 00:07:19,600 squeeze more out of the resources that we have and 116 00:07:19,600 --> 00:07:22,800 that's where basically payment channels and duplex micropayment 117 00:07:22,800 --> 00:07:26,800 channels and lightning came came from basically using the 118 00:07:26,800 --> 00:07:29,200 resources that we have in a more efficient way. 119 00:07:30,800 --> 00:07:34,200 Very cool. And so the last time you were on 120 00:07:34,200 --> 00:07:38,300 the show, we you were on talking about duplex payment channels 121 00:07:38,300 --> 00:07:40,600 and so you were still working on your thesis back then. 122 00:07:41,700 --> 00:07:43,300 So. And then, you know, very soon 123 00:07:43,300 --> 00:07:45,700 after that episode, you decided to join block stream. 124 00:07:45,900 --> 00:07:48,900 How do you know what made you decide to go join them and like, 125 00:07:49,300 --> 00:07:51,600 instead of like, you know, any of the other companies working 126 00:07:51,600 --> 00:07:55,300 the space and how did you shift your work from your duplex work 127 00:07:56,000 --> 00:08:01,300 into lightning specifically? The idea to join the lightning 128 00:08:01,300 --> 00:08:04,900 effort was pretty pretty and easy one. 129 00:08:05,700 --> 00:08:09,400 I mean for duplex Market premium channels, I was sort of sort of 130 00:08:09,400 --> 00:08:13,800 the sole person pushing for it and there's little value in in 131 00:08:13,900 --> 00:08:17,800 having two competing systems sort of splitting users among 132 00:08:17,800 --> 00:08:21,100 them the true utility from from such a payment Network come. 133 00:08:21,100 --> 00:08:25,000 There really comes from there, being one, big Network where 134 00:08:25,000 --> 00:08:28,000 everybody every participant can speak to every other purchase. 135 00:08:28,200 --> 00:08:30,800 And right. So splitting, the splitting the 136 00:08:30,800 --> 00:08:35,000 community into into smaller. Parts is not not ideal. 137 00:08:36,000 --> 00:08:39,100 And secondly, they're there. Well, duplex my criminal and 138 00:08:39,100 --> 00:08:42,900 channels and lightning hat have really different trade-offs. 139 00:08:44,000 --> 00:08:48,800 I think at the time lightning had had way better trade-offs 140 00:08:48,800 --> 00:08:50,700 than duplex America premium channels. 141 00:08:51,400 --> 00:08:55,800 And that, that is a parent from from just looking at sort of the 142 00:08:56,300 --> 00:08:59,100 unchain footprint. That Smoked ham and channels 143 00:08:59,100 --> 00:09:03,500 have compared to a lightning Channels with duplex 144 00:09:03,500 --> 00:09:06,100 micropayment channels. We had tens of transactions that 145 00:09:06,100 --> 00:09:08,800 we needed to settle in a certain period of time. 146 00:09:08,800 --> 00:09:11,500 Whereas in lightning we just have to settle one transaction 147 00:09:12,600 --> 00:09:19,600 that is so lightning is more complex but at the same time it 148 00:09:19,700 --> 00:09:23,100 it sort of uses the scarce resources a bit more efficient 149 00:09:24,000 --> 00:09:27,100 that is not to say that that we can't claw back, some of the 150 00:09:27,800 --> 00:09:29,500 good. Parts of duplex Mark Fuhrman 151 00:09:29,500 --> 00:09:35,000 channels, and that's part of what what we published last year 152 00:09:36,200 --> 00:09:39,600 with this L to proposal, which maybe we will talk about later. 153 00:09:40,800 --> 00:09:43,400 So like, you know, L2 is sort of like a lot of your duplex were 154 00:09:43,400 --> 00:09:45,400 kind of, like, making its way back into lightning. 155 00:09:45,400 --> 00:09:49,600 Is that a fair way of saying that it's heavily inspired by by 156 00:09:49,600 --> 00:09:51,100 the duplex micro conventional stuff? 157 00:09:51,100 --> 00:09:58,100 Yes, it's sort of is going back one step and looking at how we 158 00:09:58,100 --> 00:10:01,800 would structure blockchain if we wanted to have native payment 159 00:10:01,800 --> 00:10:05,200 channels on top of it and then basically realizing that, yeah, 160 00:10:05,500 --> 00:10:08,600 the stuff that we just need to change in Bitcoin is really tiny 161 00:10:08,600 --> 00:10:13,400 and And sort of everything else followed naturally from there 162 00:10:13,900 --> 00:10:18,800 and we sort of can get back some of the nice features of a duplex 163 00:10:18,800 --> 00:10:21,000 microphone Channels with able to them later. 164 00:10:21,700 --> 00:10:27,900 So now this is maybe a tricky task but I think I suspect a lot 165 00:10:27,900 --> 00:10:32,300 of listeners are familiar with lightning on this kind of very 166 00:10:32,300 --> 00:10:34,500 abstract level, or they certainly have heard of 167 00:10:34,500 --> 00:10:37,300 lightning. But they may not have a good 168 00:10:37,300 --> 00:10:39,700 understanding of how it works now. 169 00:10:40,000 --> 00:10:43,400 Going into too much detail here like how you explain lightning 170 00:10:43,400 --> 00:10:45,200 to somebody who lets say understands Bitcoin? 171 00:10:45,200 --> 00:10:47,300 Well, but doesn't understand lightning. 172 00:10:48,300 --> 00:10:52,900 Sure. Yeah, so like liking channels, 173 00:10:52,900 --> 00:10:56,500 basically construction of a payment Channel and the payment 174 00:10:56,500 --> 00:11:00,300 channel is nothing else than a relationship between two. 175 00:11:00,300 --> 00:11:04,900 Endpoints basically deciding on how to settle certain balance. 176 00:11:04,900 --> 00:11:10,100 So, the usual example, I give is that I go to a bar and I put ten 177 00:11:10,100 --> 00:11:14,000 dollar bill on the counter and as long as this ten-dollar bill 178 00:11:14,000 --> 00:11:18,400 is on the counter me and the Barista, basically, we Worried 179 00:11:18,400 --> 00:11:20,700 that this ten-dollar bill can't move. 180 00:11:21,000 --> 00:11:24,200 And now it's it's all about initially. 181 00:11:24,300 --> 00:11:27,900 These ten dollars that are mine and then I want to transact with 182 00:11:27,900 --> 00:11:34,800 the Barista and so we we incrementally decide on on how 183 00:11:34,800 --> 00:11:38,400 to split these ten bucks. So if I buy very cheap beer for 184 00:11:38,400 --> 00:11:42,500 one dollar, then sort of our agreement, is that out of these? 185 00:11:42,500 --> 00:11:48,100 $10 $1 is his and nine are mine. Then I buy one more and then I'm 186 00:11:48,108 --> 00:11:51,500 basically two dollars or his and eight are mine. 187 00:11:52,800 --> 00:11:56,600 Notice that the dollar bill never moves. 188 00:11:56,600 --> 00:12:00,100 During all of this, all of this, I only give the Barista the 189 00:12:00,100 --> 00:12:05,500 assurance that if I were to, if we were to settle, then he would 190 00:12:05,500 --> 00:12:10,400 get his two dollars and much of the much of the complicated 191 00:12:10,400 --> 00:12:16,500 parts of the protocol are are about basically assuring my 192 00:12:16,500 --> 00:12:18,000 counterparty that. Yes. 193 00:12:18,100 --> 00:12:23,800 If, if nothing goes, if in any case in any possible outcome, he 194 00:12:23,800 --> 00:12:28,600 will get his money and I will get mine and that we can't sort 195 00:12:28,600 --> 00:12:33,400 of renege on what our, what our latest state was basically, if 196 00:12:33,400 --> 00:12:37,400 I, if I promised him two dollars, then he will get two 197 00:12:37,400 --> 00:12:41,200 dollars and we can't go back to a previous state where I had 198 00:12:41,200 --> 00:12:45,300 nine, and he had only had one. So this is basically just the 199 00:12:45,300 --> 00:12:47,700 idea of a channel where we have some funds. 200 00:12:48,100 --> 00:12:51,100 That are locked up or allocated to our Channel and now we 201 00:12:51,100 --> 00:12:57,100 discuss repeatedly on how we want to settle this and that's 202 00:12:57,100 --> 00:13:00,300 that sort of an old idea that we had for a long time. 203 00:13:00,400 --> 00:13:05,600 Basically already in 2011 we had the the Spielman a 204 00:13:05,600 --> 00:13:09,200 unidirectional Channel construction, which allowed us 205 00:13:09,200 --> 00:13:13,700 to sort of send money into this one direction and never never 206 00:13:13,700 --> 00:13:17,300 receive it back. With the with duplex, Mark 207 00:13:17,300 --> 00:13:19,800 payment channels and the lightning Network subtle. 208 00:13:19,800 --> 00:13:23,200 We have a construction where we can send back the money back and 209 00:13:23,200 --> 00:13:26,600 forth in both directions in a secure way. 210 00:13:26,600 --> 00:13:31,900 Such that we can, we can always be sure that that will get our 211 00:13:31,900 --> 00:13:37,900 what is, what is due to us. Now with lightning lightning is 212 00:13:38,000 --> 00:13:41,100 the first part. The network part is a second 213 00:13:41,100 --> 00:13:44,800 part, right? If I, if I open a Channel with 214 00:13:45,000 --> 00:13:50,100 the Barista can only interact with that Barista, but if, if we 215 00:13:50,100 --> 00:13:54,300 were to create a network of these payment channels and make 216 00:13:54,300 --> 00:13:58,200 sure that through a transitive relationship, I can reach any 217 00:13:58,200 --> 00:14:00,200 other party, a party in the network. 218 00:14:00,400 --> 00:14:04,200 Then we could basically say, hey I will give you one dollar if 219 00:14:04,200 --> 00:14:07,800 you forward this one dollar to the next person in the chain. 220 00:14:07,800 --> 00:14:11,200 And next person the chain in the next person, in the chain, until 221 00:14:11,200 --> 00:14:15,900 we eventually reach our the or intended target and Only then we 222 00:14:15,900 --> 00:14:20,900 can we have this entire chain of promises that there are them 223 00:14:20,900 --> 00:14:23,600 fulfilled, there's ways to do that. 224 00:14:24,000 --> 00:14:29,700 But really those are those are two parts parts of the protocol 225 00:14:30,000 --> 00:14:32,700 that make up the lightning Network, the payment channels 226 00:14:32,700 --> 00:14:37,900 themself. And this way of sending payments 227 00:14:37,900 --> 00:14:44,400 over multiple hops in this network, So the lightning white 228 00:14:44,400 --> 00:14:46,100 paper. I'd original lightning, right? 229 00:14:46,100 --> 00:14:49,300 We were so, I think around for years ago, that was, it came 230 00:14:49,300 --> 00:14:52,700 out. So, has this idea changed a lot 231 00:14:52,700 --> 00:14:55,300 since then, you know, as as people work, maybe some of 232 00:14:55,300 --> 00:14:59,400 things turned out wrong or like, how current is the white paper 233 00:14:59,400 --> 00:15:04,200 from back then. It's very much the same and 234 00:15:04,200 --> 00:15:06,100 completely different at the same time. 235 00:15:07,000 --> 00:15:10,200 I think the, the basic ideas are still there. 236 00:15:10,200 --> 00:15:15,300 The Revolutionary idea of constructing a payment Channel 237 00:15:15,300 --> 00:15:20,400 and then sort of had the way we do in validation of all states 238 00:15:21,400 --> 00:15:26,500 is still very much there. What, what, what changed is 239 00:15:26,500 --> 00:15:30,500 basically, a lot of the fine detail in that. 240 00:15:30,600 --> 00:15:35,200 In a protocol, which was even not in the white paper itself or 241 00:15:35,700 --> 00:15:39,200 was later changed because, well, we found more efficient ways to 242 00:15:39,200 --> 00:15:45,400 do it. So I think the basic idea that 243 00:15:45,400 --> 00:15:49,600 was presented in and the white paper is still still valid and 244 00:15:49,600 --> 00:15:54,400 is still there, however, the actual implementation and the 245 00:15:54,400 --> 00:15:58,700 actual protocol as it is right now, I would probably not try to 246 00:15:58,700 --> 00:16:04,200 infer from that from that paper. Because it's it's very light on 247 00:16:04,300 --> 00:16:07,100 the DD, act sort of details that you need to implement stuff. 248 00:16:07,100 --> 00:16:10,600 So for that, I would definitely suggest people go and read the 249 00:16:10,600 --> 00:16:13,900 specification that we wrote up during the last two and a half 250 00:16:13,900 --> 00:16:17,200 years now. And while that's still very 251 00:16:17,200 --> 00:16:20,800 technical, it's way more complete than than the white 252 00:16:20,800 --> 00:16:23,200 paper. Yeah, I do a lot of, like, 253 00:16:23,200 --> 00:16:27,000 Implement, you know, I keep up a lot like the plasma world. 254 00:16:27,000 --> 00:16:31,100 So I can see something very similar there where the Original 255 00:16:31,100 --> 00:16:33,900 plasma paper from Joseph. Bun is like, you know, very 256 00:16:33,900 --> 00:16:37,000 interesting idea is the very light on the details and so then 257 00:16:37,100 --> 00:16:39,200 that's where like, you know, we have all this implementation 258 00:16:39,200 --> 00:16:42,500 work still to do, and spec work to do so, very cool. 259 00:16:43,400 --> 00:16:47,900 And so, you know, I guess when we had this episode with Joseph 260 00:16:47,900 --> 00:16:52,000 poon and tags back in 2015. And then we also had one with 261 00:16:52,000 --> 00:16:56,400 Adam back in 2015 and he was, you know, we were talking about 262 00:16:56,400 --> 00:16:59,500 lightning and he basically mentioned that like, oh, you 263 00:16:59,500 --> 00:17:04,200 know, lightning is Couple months out for five months out, and so 264 00:17:04,200 --> 00:17:06,900 what happened there? Yeah. 265 00:17:06,900 --> 00:17:09,000 So that was a very interesting episode. 266 00:17:09,000 --> 00:17:13,700 I think one of the, one of the things that nobody was expecting 267 00:17:13,700 --> 00:17:18,000 is that there was nobody that actually wanted to implement 268 00:17:18,000 --> 00:17:25,000 anything in this, so attached. And Joseph, basically wrote this 269 00:17:25,000 --> 00:17:28,500 paper. And then only much later decided 270 00:17:28,500 --> 00:17:33,000 to create a company lightning. Labs to actually go ahead and 271 00:17:33,000 --> 00:17:36,600 implement this. And in the meantime, blog 272 00:17:36,600 --> 00:17:41,300 stream, had hired Rusty, Russell, my, my colleague who 273 00:17:41,300 --> 00:17:45,600 got started on the, on the see lightning implementation and 274 00:17:45,600 --> 00:17:50,100 only when people sort of showed interest in that only then 275 00:17:50,100 --> 00:17:54,500 Joseph and and attach decided, hey that there's, there's 276 00:17:55,100 --> 00:17:58,400 there's a good way to create a company out of this. 277 00:17:59,600 --> 00:18:04,200 So I I think that the first part of the answer is that nobody was 278 00:18:04,200 --> 00:18:08,400 there to sort of actually start implementing it and sort of the 279 00:18:08,400 --> 00:18:12,400 was some hesitation in wanting to create this. 280 00:18:13,700 --> 00:18:18,200 And the second part is that right from the get-go. 281 00:18:18,200 --> 00:18:24,100 We had this this this desire to create a specification that was 282 00:18:24,100 --> 00:18:28,000 sort of implementation agnostic. And so this is this is not just 283 00:18:28,000 --> 00:18:30,500 one team that is trying to hack together. 284 00:18:30,600 --> 00:18:35,300 Other client as quickly as possible and sort of taking 285 00:18:35,300 --> 00:18:38,500 shortcuts on the protocol side. But this is very much a 286 00:18:38,500 --> 00:18:42,100 community effort where we have multiple implementations, that 287 00:18:42,400 --> 00:18:46,100 that try to come up with the most efficient. 288 00:18:46,100 --> 00:18:51,100 And most clear way to build this this protocol and then implement 289 00:18:51,100 --> 00:18:55,300 it so that obviously takes time but there's there's a lot of 290 00:18:55,300 --> 00:18:59,500 learnings we learned along the way and there was a lot of 291 00:18:59,500 --> 00:19:02,900 experience there was All along, experimentation phase before we 292 00:19:02,900 --> 00:19:08,300 met in 2016 and Milan for the first spec meeting where we 293 00:19:08,300 --> 00:19:10,300 said, okay? Yes, we want to, we want to 294 00:19:10,308 --> 00:19:16,700 create a cohesive specification and we want to make we want to 295 00:19:16,900 --> 00:19:21,300 put that effort into. Actually make this multi 296 00:19:21,300 --> 00:19:24,600 implementation Network rather than everybody just going their 297 00:19:24,600 --> 00:19:29,000 own way. So what was some of the design 298 00:19:29,000 --> 00:19:32,400 choices around like, you know, deciding to go with this multi 299 00:19:32,400 --> 00:19:34,700 implementation model? Instead of like, you know, 300 00:19:34,700 --> 00:19:38,200 everyone kind of focusing their efforts on see lightning. 301 00:19:38,200 --> 00:19:43,300 And why did we decide to go down this multi implementation route? 302 00:19:43,300 --> 00:19:49,400 Well, there's there's a lot to be learned from from sort of 303 00:19:49,400 --> 00:19:51,700 creating multiple, implementations, right? 304 00:19:51,700 --> 00:19:55,000 We have, we have more people that come in and look at things 305 00:19:55,000 --> 00:19:58,600 from it, are from a different. And angle it also forced us to 306 00:19:58,600 --> 00:20:03,800 have this experimentation phase before the Milan meeting where 307 00:20:03,800 --> 00:20:05,300 everybody just went their own way. 308 00:20:05,300 --> 00:20:09,300 And then sort of, we came back and sort of merged all of our 309 00:20:10,100 --> 00:20:12,200 lessons that we learned along the way. 310 00:20:12,400 --> 00:20:15,700 And then we threw everything away and then just started with 311 00:20:15,700 --> 00:20:24,400 real specification sort of a semi clean slate and sort of yes 312 00:20:24,400 --> 00:20:27,400 Justice. Just this and the advantage is 313 00:20:27,400 --> 00:20:32,400 basically that we that we have this, this very cohesive sort of 314 00:20:32,408 --> 00:20:34,900 specification that comes out of it. 315 00:20:35,500 --> 00:20:40,000 And the other side is that having a single implementation, 316 00:20:40,000 --> 00:20:44,300 sort of you have a single implementation that sort of 317 00:20:44,300 --> 00:20:46,300 tries, everything and does nothing. 318 00:20:46,300 --> 00:20:51,600 Well, whereas with the current ecosystem, we have, we have a 319 00:20:51,600 --> 00:20:55,900 clear, which are very much a sink with their client. 320 00:20:56,100 --> 00:20:58,000 There which are very much focused. 321 00:20:58,000 --> 00:21:02,400 On mobile clients, we have lightning Labs that are with 322 00:21:02,400 --> 00:21:08,000 their lnd are very much focused on desktop users and their see 323 00:21:08,000 --> 00:21:12,900 lightning, which is mostly for aiming for power users. 324 00:21:12,900 --> 00:21:17,000 That, that sort of need a lot of customization customizability 325 00:21:17,300 --> 00:21:21,100 and so, there's different different goals we have 326 00:21:22,100 --> 00:21:25,200 different Target audiences, but we still have this 327 00:21:25,200 --> 00:21:27,900 interoperability. A tea that gives that is given 328 00:21:27,900 --> 00:21:31,100 out to us by the, by the specification. 329 00:21:31,100 --> 00:21:34,500 That is implementation agnostic. It's also good to have the all 330 00:21:34,500 --> 00:21:38,200 of this written down and not in for, in the form of an 331 00:21:38,200 --> 00:21:40,700 implementation. Otherwise, it gets really hard 332 00:21:40,700 --> 00:21:43,600 to reason about Right, that's interesting. 333 00:21:43,600 --> 00:21:46,700 I mean, we just said we did an episode with like Jameson law, 334 00:21:46,700 --> 00:21:49,400 but I think last week where we had some of that discussion 335 00:21:49,400 --> 00:21:52,100 around, you know, Bitcoin not having a specification, right in 336 00:21:52,100 --> 00:21:55,000 having this kind of, you know, single client. 337 00:21:55,000 --> 00:21:58,600 And I mean, it certainly. Yeah, I think that sounds, that 338 00:21:58,600 --> 00:22:01,000 sounds like a great a path to take. 339 00:22:01,700 --> 00:22:03,300 Now you mentioned the specification is that 340 00:22:03,300 --> 00:22:08,100 specification finished or is it still something that's being 341 00:22:08,100 --> 00:22:11,600 worked on? We've been wanting to tag 342 00:22:11,600 --> 00:22:14,600 version 1.0 for the last three months. 343 00:22:14,600 --> 00:22:18,500 I think it's not been done so far because there's always 344 00:22:18,500 --> 00:22:22,200 somebody who has who has an open pull requests about spelling. 345 00:22:22,900 --> 00:22:26,700 But that is point, really, the most of the changes that are 346 00:22:26,700 --> 00:22:32,400 applied to the version 1.0 are are about wording and we we hope 347 00:22:32,400 --> 00:22:35,200 to be able to tag version 1.0 soon. 348 00:22:36,400 --> 00:22:41,600 All of the implementations that sort of Started at this, this 349 00:22:42,100 --> 00:22:47,100 process with us, half compatibility with version 1.0 350 00:22:47,700 --> 00:22:51,700 and we are already working on on features for 1.1, but we'd like 351 00:22:51,700 --> 00:22:55,900 to have this version 1.0. I would out of the gate and sort 352 00:22:55,900 --> 00:23:00,100 of be able to concentrate on the next big thing that we might 353 00:23:00,100 --> 00:23:03,300 want to build in there. So not yet. 354 00:23:03,300 --> 00:23:10,900 But soon as his two weeks hiring is stressful. 355 00:23:11,300 --> 00:23:13,700 Let's face it, it's a long process of sifting through 356 00:23:13,700 --> 00:23:16,000 resumes and interviewing candidates, without any 357 00:23:16,000 --> 00:23:18,500 guarantee of quality, but it doesn't have to be this way. 358 00:23:18,700 --> 00:23:21,600 Companies all over the place are experiencing a new way of hiring 359 00:23:21,600 --> 00:23:23,200 with top. Tell if you go to their 360 00:23:23,200 --> 00:23:25,800 trustpilot page, you'll see that of the hundreds of people that 361 00:23:25,800 --> 00:23:29,300 have left reviews, over 98% were four or five star ratings, 362 00:23:29,600 --> 00:23:33,200 including one guy who wants to give his developer bear hug That 363 00:23:33,200 --> 00:23:36,100 says a lot top, dog, gets all this great feedback because they 364 00:23:36,100 --> 00:23:38,200 focus on their clients. And their top priority is 365 00:23:38,200 --> 00:23:40,600 quality. They only accept the top three 366 00:23:40,600 --> 00:23:43,700 percent of applicants including highly skilled blockchain 367 00:23:43,700 --> 00:23:46,300 Engineers. One of these Engineers is 368 00:23:46,300 --> 00:23:49,400 Roddick, ostrowski Roddick has experience as a lead software, 369 00:23:49,400 --> 00:23:52,700 engineer and data scientists for Sony and Expedia, then he 370 00:23:52,700 --> 00:23:55,400 discovered blockchain, and he became totally consumed with 371 00:23:55,400 --> 00:23:57,800 etherium. He worked as a consultant for 372 00:23:57,800 --> 00:24:01,000 the firm start on chain and is time-lock tap when the top 373 00:24:01,000 --> 00:24:04,200 quarter consensus you Port an identity blockchain hackathon, 374 00:24:05,200 --> 00:24:07,500 then he expanded his reach through top towel. 375 00:24:07,500 --> 00:24:10,100 He worked with a bunch of clients on projects, such as 376 00:24:10,100 --> 00:24:13,000 smart, contract development, and a POC that leverages blockchain. 377 00:24:13,300 --> 00:24:16,100 If you want to hire Engineers like Roddick for your team, go 378 00:24:16,100 --> 00:24:20,400 to top towel.com epicenter for a no risk trial a top tile. 379 00:24:20,400 --> 00:24:23,200 Director of engineering will deliver your next higher in as 380 00:24:23,200 --> 00:24:26,100 fast as 48 hours and you'll get a thousand dollar credit when 381 00:24:26,100 --> 00:24:29,000 you decide to hire. We'd like to thank top towel for 382 00:24:29,000 --> 00:24:31,300 their support of epicenter. Okay. 383 00:24:31,300 --> 00:24:34,600 So we had like this slow beginning and then the 384 00:24:34,600 --> 00:24:38,500 specification work started in 2016 and Milan. 385 00:24:38,500 --> 00:24:41,200 And now it's kind of at the point of coming to closure. 386 00:24:41,400 --> 00:24:44,900 If you look overall at the history of work on Lightning, 387 00:24:45,600 --> 00:24:51,200 where has progress been fast and good and what have been, maybe 388 00:24:51,200 --> 00:24:55,000 some obstacles that ended up taking a lot of time. 389 00:24:56,400 --> 00:25:00,100 So I think overall the the progress has been has been 390 00:25:01,500 --> 00:25:05,900 rather quick and and obstacle free. 391 00:25:06,100 --> 00:25:11,100 There have been a few cases where we noticed that our 392 00:25:11,100 --> 00:25:15,300 initial Simple Solution wasn't clever enough. 393 00:25:16,200 --> 00:25:20,500 For example, one one thing that continuously comes back to haunt 394 00:25:20,500 --> 00:25:26,300 us is that we chose to sort of Punt on a more complex It's 395 00:25:26,300 --> 00:25:29,200 gossip protocol, in which we exchange information about 396 00:25:29,200 --> 00:25:33,300 Channel, existing channels and existing nodes because we wanted 397 00:25:33,300 --> 00:25:37,200 to, we said, okay, we want to have a simple version first and 398 00:25:37,200 --> 00:25:39,800 then we will revisit that once we have. 399 00:25:41,300 --> 00:25:45,900 Once we have gathered enough information about the situation, 400 00:25:46,300 --> 00:25:49,300 this has turned out to be a bit more complicated than we 401 00:25:49,300 --> 00:25:51,300 expected. Simply because the gossip 402 00:25:51,300 --> 00:25:55,100 protocol is a very chatty. And especially on mobile nodes. 403 00:25:55,100 --> 00:26:02,000 This, this chattiness is not desirable, but I think other 404 00:26:02,000 --> 00:26:08,900 than that, Most of the stuff went, went quite okay, with, I 405 00:26:08,900 --> 00:26:15,500 mean between between the between the start of the standardization 406 00:26:15,500 --> 00:26:21,900 which was in September. 2016 2 bus block stream opening the the 407 00:26:21,900 --> 00:26:26,800 blocks Jimmy store there was little over a year and we 408 00:26:26,800 --> 00:26:30,000 basically had a rewrite of the entire client and so that the 409 00:26:30,000 --> 00:26:35,900 other teams, so I'm Happy with the progress we had so far. 410 00:26:36,800 --> 00:26:40,500 Now, there's quite a few people who say this isn't going fast 411 00:26:40,500 --> 00:26:43,100 enough, but you always have these people, right? 412 00:26:44,900 --> 00:26:47,000 So could you tell us a little bit about this? 413 00:26:47,100 --> 00:26:50,500 You know this roll out phase that happened for lightning now. 414 00:26:50,500 --> 00:26:54,400 So I remember, you know, I was in Berlin about like, you know, 415 00:26:54,400 --> 00:26:56,600 last spring and you know, there's a whole block stream 416 00:26:56,600 --> 00:26:58,700 store and that was like, you know, the first time anyone 417 00:26:58,700 --> 00:27:01,500 could buy anything with lightning and like use it. 418 00:27:01,500 --> 00:27:04,000 And you know, the see lightning client came out around the same 419 00:27:04,000 --> 00:27:05,800 time. I use that opportunity to buy 420 00:27:05,800 --> 00:27:08,100 the shirt. I'm wearing From the Block 421 00:27:08,100 --> 00:27:10,300 stream lightning store. So I was pretty excited. 422 00:27:10,300 --> 00:27:12,800 I got to be one of like the first early users of lightning. 423 00:27:13,300 --> 00:27:15,900 So, how is you know, the Roll out happened over the past 424 00:27:15,900 --> 00:27:19,900 couple of past year or so and how every scene like adoption. 425 00:27:21,600 --> 00:27:26,800 Yeah, so we get, we get asked quite a lot quite often when is 426 00:27:27,000 --> 00:27:30,700 lightning the network going to launch and my usual usual reply. 427 00:27:30,700 --> 00:27:35,800 Is it is launched. So, we had this, we had this 428 00:27:35,800 --> 00:27:43,300 very slow and incremental rollout, where we basically 429 00:27:43,300 --> 00:27:48,300 created the client and sort of got some users on board, that, 430 00:27:48,300 --> 00:27:51,200 that were really Technical, and that just wanted to play. 431 00:27:51,300 --> 00:27:54,900 Stuff. And before, before the blocks 432 00:27:54,900 --> 00:27:58,500 Cream Store launched last year, we encourage everybody to 433 00:27:58,500 --> 00:28:00,800 basically use test net and testing it only. 434 00:28:00,800 --> 00:28:05,100 In fact, all of our clients are still defaulting to test net. 435 00:28:05,100 --> 00:28:08,800 If you start them today, simply because we didn't, we didn't 436 00:28:08,800 --> 00:28:12,900 want to, to have people lose their money and sort of lose 437 00:28:12,900 --> 00:28:16,200 interest. Because of that, this is, this 438 00:28:16,200 --> 00:28:21,300 was a release early days software after all and We 439 00:28:21,308 --> 00:28:24,800 wouldn't feel comfortable losing user money at that point in 440 00:28:24,800 --> 00:28:28,100 time. It basically we had a group of 441 00:28:28,100 --> 00:28:32,300 people that were tech-savvy and there were sort of hacking their 442 00:28:32,300 --> 00:28:36,500 way around the clients himself and we're sort of experimenting 443 00:28:36,500 --> 00:28:40,300 on Main and already. And at some point we just 444 00:28:40,300 --> 00:28:45,300 decided, hey, this is this is sort of, this is sort of getting 445 00:28:45,300 --> 00:28:51,800 ahead of us and yes, we'd like to open we'd like to going to 446 00:28:51,800 --> 00:28:58,300 shop where you can actually buy items for real Bitcoins and sort 447 00:28:58,300 --> 00:29:03,800 of get that feedback from Maine that users are self and sort of 448 00:29:03,900 --> 00:29:08,700 get gov experiences on Magnet or self by operating the store. 449 00:29:08,900 --> 00:29:14,000 And so in, I think it was January 16th, we basically 450 00:29:14,200 --> 00:29:18,400 published that we have the running version of woocommerce, 451 00:29:18,800 --> 00:29:21,800 with a lightning with a see lightning back end. 452 00:29:22,500 --> 00:29:26,000 And you could actually go ahead and buy stuff like you did, for 453 00:29:26,000 --> 00:29:29,000 example, and many other people did. 454 00:29:31,100 --> 00:29:36,400 And it was sort of this slow and incremental rollout where you 455 00:29:36,400 --> 00:29:41,900 actually have to know a lot of a lot of tech in order to get to 456 00:29:41,900 --> 00:29:46,200 get to use it. And we always accompanied this 457 00:29:46,200 --> 00:29:52,500 with the, with this sort of hashtag Reckless, which was, was 458 00:29:52,700 --> 00:29:56,000 there to signify? Hey, by the way, this is Alpha 459 00:29:56,000 --> 00:29:58,100 State software. Please don't use this for any 460 00:29:58,100 --> 00:30:03,100 cut sort of real money just for Just for what every year, feel, 461 00:30:03,100 --> 00:30:06,000 okay, losing. If the software is broken, for 462 00:30:06,000 --> 00:30:11,800 example, and while we were while we were gathering more and more 463 00:30:11,800 --> 00:30:15,700 feedback, and we're fixing more and more books, we sort of we're 464 00:30:15,700 --> 00:30:19,200 also able to increase our confidence into the 465 00:30:19,500 --> 00:30:24,300 implementations themself. And so over this time we started 466 00:30:24,300 --> 00:30:27,100 making it easier and easier for users to get started on 467 00:30:27,100 --> 00:30:30,800 lightning. And this is all part of this 468 00:30:30,800 --> 00:30:33,700 slow and incremental rollout that we wanted. 469 00:30:35,100 --> 00:30:38,000 And it's been working great, so far. 470 00:30:38,400 --> 00:30:44,400 So there will will know will not be an official launch date for 471 00:30:44,400 --> 00:30:46,700 lightning Network. It has been launched over a year 472 00:30:46,700 --> 00:30:52,600 ago and people have been joining whenever whenever I feel like 473 00:30:52,600 --> 00:30:55,900 investing a bit of time and eventually we hope to make it 474 00:30:55,900 --> 00:31:02,200 easy enough for just everybody to be able to come and play with 475 00:31:02,200 --> 00:31:05,900 it. Are there any known cases of 476 00:31:05,900 --> 00:31:09,100 anyone, losing any money on made neck because of bugs in the 477 00:31:09,100 --> 00:31:12,800 software? I know that there is one that I 478 00:31:12,800 --> 00:31:19,800 cost which is basically we had this, the situation where a user 479 00:31:19,800 --> 00:31:25,900 of ours was reacted to a cheat attempt from his counterparty. 480 00:31:26,400 --> 00:31:30,000 And we ended up with this very strange situation where he got 481 00:31:30,100 --> 00:31:34,300 the other person's money, which is what is expected, right? 482 00:31:34,300 --> 00:31:38,900 He tried to cheat, so I steal his money basically but he 483 00:31:38,900 --> 00:31:45,900 didn't get his own money. Back which turns out I forgot to 484 00:31:45,900 --> 00:31:53,100 add a field to a database so I tried to buy him a beer for 485 00:31:53,100 --> 00:31:58,400 those 10 euros that he lost. And instead he insisted on 486 00:31:58,400 --> 00:32:01,900 buying me a beer because he had a lot of fun with while playing 487 00:32:02,300 --> 00:32:07,600 and while he still lost some money, we kept this these limits 488 00:32:07,600 --> 00:32:12,000 low enough that we could do this sort of of I buy you a beer and 489 00:32:12,000 --> 00:32:17,700 we're sort of even, right? And now we've had a lot of luck 490 00:32:17,700 --> 00:32:21,800 with with the community members. Nobody really lost a lot of 491 00:32:21,800 --> 00:32:28,000 money and everybody just played along very nicely and sort of 492 00:32:28,100 --> 00:32:32,600 this into the fousey azzam that I just wanted to sort of buy you 493 00:32:32,600 --> 00:32:36,800 a beer, because I caused the buck that lost you money and he 494 00:32:36,800 --> 00:32:40,200 insisting that I should get a beer instead that would do. 495 00:32:40,400 --> 00:32:45,600 Something that this happens that is very sort of Representative 496 00:32:45,600 --> 00:32:50,000 for the feeling in the community, currently, it's very 497 00:32:50,000 --> 00:32:54,600 collaborative. Now, I remember in the past, one 498 00:32:54,600 --> 00:32:58,300 of the concerns that people had about lightning was that there 499 00:32:58,308 --> 00:32:59,800 was the idea, okay? You're going to have two 500 00:32:59,800 --> 00:33:04,100 different channels and it's good if you channels very powerful if 501 00:33:04,100 --> 00:33:06,700 it's connected with many, right? So you have you're going to have 502 00:33:06,700 --> 00:33:11,600 these hubs and then there is this process where okay I want 503 00:33:11,600 --> 00:33:14,200 to pay sunny but we don't have a directional right? 504 00:33:14,200 --> 00:33:19,100 So we have to go through some some route and then that route 505 00:33:19,100 --> 00:33:22,100 you generally go through, you know, particular. 506 00:33:22,300 --> 00:33:24,500 Bigger hubs. And so there was this fear that 507 00:33:24,500 --> 00:33:27,400 okay is enlightening, any be a very centralized Network. 508 00:33:27,400 --> 00:33:29,700 There's going to be a few companies that will, you know, 509 00:33:29,700 --> 00:33:32,200 have these big hubs, everyone will go to them. 510 00:33:32,500 --> 00:33:35,500 Well, what are your thoughts? First of all on whether or not 511 00:33:35,500 --> 00:33:40,000 this is a problem, the aspect of decentralization in lightning 512 00:33:40,700 --> 00:33:43,400 and kind of the role of hubs. Yeah. 513 00:33:43,400 --> 00:33:48,800 So that's that's a point that comes up, rather often, and I 514 00:33:48,800 --> 00:33:51,100 often get the feeling that people are scared of 515 00:33:51,100 --> 00:33:53,800 centralization. But for the wrong reasons, 516 00:33:53,900 --> 00:33:57,400 because if we have a participant in a Network that has a lot of 517 00:33:57,900 --> 00:34:02,700 channels open and that has sort of a lot of liquidity in his 518 00:34:02,700 --> 00:34:06,600 channels and therefore, connects a lot of people in the network 519 00:34:07,000 --> 00:34:09,900 then that's that. First of all, is a service to 520 00:34:09,900 --> 00:34:14,400 the to the network Itself. By by enabling this, this 521 00:34:14,400 --> 00:34:17,500 multi-hop routing from many points to many other points. 522 00:34:18,199 --> 00:34:22,100 Its first and foremost a downside because well, suddenly 523 00:34:22,300 --> 00:34:25,000 You become a single point of failure, if you run this up, 524 00:34:25,000 --> 00:34:28,699 right? And that's, that's the thing, 525 00:34:28,699 --> 00:34:33,900 that that I am worried about in, with these, if the network turns 526 00:34:33,900 --> 00:34:39,100 out to be centralized Hub, sort of, gather, a lot of, a lot of 527 00:34:39,100 --> 00:34:41,800 responsibility on their shoulders, and if they go down 528 00:34:42,000 --> 00:34:47,900 then suddenly the network is a lot lot lot, worse than them 529 00:34:47,900 --> 00:34:55,500 before, but I don't think Is a big issue and, which a lot of 530 00:34:55,500 --> 00:35:02,100 people point to is this idea of big hubs being being able to the 531 00:35:02,100 --> 00:35:07,300 anonymize people and sort of profiling, their users, we have 532 00:35:07,400 --> 00:35:10,200 in the in the protocol. Specification itself, we have 533 00:35:10,200 --> 00:35:15,600 the an onion routing protocol, which allows allows us to sort 534 00:35:15,600 --> 00:35:20,000 of hide the origin and the destination for for all the 535 00:35:20,000 --> 00:35:21,800 payments we perform in the network. 536 00:35:22,300 --> 00:35:26,900 All a big Hub sees is that okay? I got the payment from the left, 537 00:35:27,400 --> 00:35:31,300 I decrypted and I have my instructions from that packet 538 00:35:31,300 --> 00:35:34,400 and I know where to forward it on my right. 539 00:35:35,400 --> 00:35:40,400 They don't learn anything about who the original sender was 540 00:35:40,400 --> 00:35:43,200 because well he only learns who the next. 541 00:35:43,300 --> 00:35:46,600 The previous hop from the left was and he will not learn 542 00:35:46,600 --> 00:35:49,100 anything about the actual recipient of the payment 543 00:35:49,100 --> 00:35:52,100 because, well, all he learned was who the next guy is? 544 00:35:52,500 --> 00:35:54,500 It could be, the next guy is a recipient. 545 00:35:54,500 --> 00:35:57,900 But well, he doesn't learn anything about that, he doesn't 546 00:35:57,900 --> 00:36:00,900 learn his position in the road. He doesn't learn how many people 547 00:36:00,900 --> 00:36:03,800 are before him or after him, quick question on that. 548 00:36:03,800 --> 00:36:06,500 So is this onion routing? That's something that like, all 549 00:36:06,500 --> 00:36:09,600 of the clients do by default or is that something you kind of 550 00:36:09,600 --> 00:36:13,100 have to, you know, optionally choose, if you care about 551 00:36:13,100 --> 00:36:16,600 privacy a lot? No, this is this is the only way 552 00:36:16,600 --> 00:36:21,100 that we currently Implement sending coins on the lightning 553 00:36:21,100 --> 00:36:23,300 Network. If you're using the lightning 554 00:36:23,300 --> 00:36:25,900 Network, you are using the onion routing protocol. 555 00:36:26,400 --> 00:36:31,400 And even if even if you have a direct connection to your to 556 00:36:31,400 --> 00:36:34,900 your recipient, he will not learn that you are the original 557 00:36:34,900 --> 00:36:39,800 sender. So this is, we decided to to 558 00:36:39,800 --> 00:36:43,600 make the onion routing mandatory exactly because if it's an 559 00:36:43,600 --> 00:36:48,900 opt-in feature, then people might might not know that they 560 00:36:48,900 --> 00:36:52,100 should use it or they might opt out from using it. 561 00:36:52,200 --> 00:36:59,100 Because well, crypto is hard. So by making it by making it 562 00:36:59,100 --> 00:37:02,300 mandatory every client has to implement it and every client 563 00:37:02,300 --> 00:37:05,100 will use it for every single payment there is. 564 00:37:05,500 --> 00:37:10,800 And this creates this creates a bigger set of users, in which we 565 00:37:10,800 --> 00:37:16,000 in, which has an individual user can hide in So, but what I was 566 00:37:16,000 --> 00:37:23,400 saying is that the so the the central Hub will not learn a lot 567 00:37:23,400 --> 00:37:26,900 about you. Unless you are your only 568 00:37:26,900 --> 00:37:30,000 connection is going to be the Hub because well then you can't 569 00:37:30,000 --> 00:37:34,100 say hey I got this from some guy that sent it to me but they will 570 00:37:34,100 --> 00:37:38,400 know that it's you which is why we encourage people to actually 571 00:37:38,400 --> 00:37:42,000 open multiple connections at least to have this, this 572 00:37:42,000 --> 00:37:45,100 plausible deniability that At. Yeah, I'm not the original 573 00:37:45,100 --> 00:37:47,100 sender. I received it from some other 574 00:37:47,100 --> 00:37:53,300 guy further down the line. So the Hub doesn't learn a lot a 575 00:37:53,300 --> 00:37:59,700 lot about about Privacy Information, but it does 576 00:37:59,700 --> 00:38:06,200 concentrate a lot of connections on it and it represents a single 577 00:38:06,200 --> 00:38:10,200 point of failure, which is what I care about. 578 00:38:11,100 --> 00:38:16,200 There are reasons for helps to emerge and there's reasons for 579 00:38:16,200 --> 00:38:20,400 hops, not to emerge, maybe we can go into that later if you if 580 00:38:20,408 --> 00:38:24,700 you want it. This episode of epicenter is 581 00:38:24,700 --> 00:38:27,700 brought to you by Microsoft and the Azure blockchain workbench. 582 00:38:27,900 --> 00:38:30,400 Getting your block chain from the Whiteboard to production can 583 00:38:30,400 --> 00:38:32,200 be a big undertaking in something. 584 00:38:32,200 --> 00:38:35,100 As simple as connecting your blockchain to iot devices or 585 00:38:35,100 --> 00:38:37,900 existing Erp. Systems is a project in itself. 586 00:38:38,500 --> 00:38:40,200 Well, the folks at Microsoft had you covered. 587 00:38:40,500 --> 00:38:43,000 You already know about the Azure blockchain workbench and how 588 00:38:43,000 --> 00:38:45,300 easy it makes bootstrapping your Block Chain network 589 00:38:45,300 --> 00:38:48,000 pre-configured with all the cloud services you need for your 590 00:38:48,000 --> 00:38:50,700 Enterprise app. Their new development kit is the 591 00:38:50,700 --> 00:38:54,200 IFTTT for blockchains. Want to collect data from 592 00:38:54,200 --> 00:38:58,000 someone in a remote location via SMS and half that data package 593 00:38:58,000 --> 00:39:00,300 in a transaction for your hyper Ledger fabric. 594 00:39:00,300 --> 00:39:03,200 Blockchain the development kit allows you to build this 595 00:39:03,200 --> 00:39:06,400 integration in just a few steps in a simple drag-and-drop 596 00:39:06,400 --> 00:39:09,300 interface, here is another great example, perhaps your 597 00:39:09,300 --> 00:39:12,800 institution, working with etherium and rely on CSV file 598 00:39:12,800 --> 00:39:16,000 sent by email one. Click in the dev kit and you can 599 00:39:16,000 --> 00:39:19,100 parse these files and have two data embedded in transactions, 600 00:39:19,900 --> 00:39:23,200 whatever you're working with the dev kit can read transform Me 601 00:39:23,300 --> 00:39:26,300 and act on the data to learn more and to build your first 602 00:39:26,300 --> 00:39:30,500 application and less than 30 minutes visit aka.ms/offweb 603 00:39:30,500 --> 00:39:33,900 Ascender and be sure to follow them on Twitter at msft. 604 00:39:34,000 --> 00:39:37,600 Blockchain we'd like to thank Microsoft and Azure for their 605 00:39:37,600 --> 00:39:42,000 support of epicenter. So with this onion routing, so 606 00:39:42,200 --> 00:39:44,300 does it like similar to how in tour? 607 00:39:44,300 --> 00:39:49,200 Do we like select a bunch of extra random nodes to also send 608 00:39:49,200 --> 00:39:50,900 to like is part of our path or do? 609 00:39:50,900 --> 00:39:54,500 We just like you know, take the most efficient Half route that 610 00:39:54,500 --> 00:39:57,500 we can find but the the nodes along that route. 611 00:39:57,500 --> 00:40:00,100 Don't know who the other participants are. 612 00:40:00,800 --> 00:40:02,800 Yes. So the the structure is very 613 00:40:02,800 --> 00:40:08,800 similar with the two exceptions. One is that in tour? 614 00:40:08,800 --> 00:40:13,400 You can actually select any any participants in the network to 615 00:40:13,400 --> 00:40:17,600 be the next hop in your route. This is not possible in 616 00:40:17,600 --> 00:40:21,100 lightning. Lightning, the the Hops have to 617 00:40:21,100 --> 00:40:23,500 match the actual channels exist Listing. 618 00:40:23,500 --> 00:40:28,700 So if I, if I only have a channel open to you, then I 619 00:40:28,700 --> 00:40:32,400 can't sort of go around you and then sent back to you. 620 00:40:32,600 --> 00:40:37,400 So our onion routing hops have to coincide with actual channels 621 00:40:37,400 --> 00:40:40,900 existing. And as for your question about 622 00:40:41,000 --> 00:40:46,500 whether we choose always the most efficient route, we do 623 00:40:46,500 --> 00:40:51,000 randomized routes in such a way that if there, if there is a 624 00:40:51,500 --> 00:40:54,900 way, if there is a shortest route, From point A, to B, we 625 00:40:54,900 --> 00:40:59,500 might not use that exactly because that might might leak 626 00:40:59,500 --> 00:41:02,000 information about who the original sender and whose were 627 00:41:02,000 --> 00:41:06,300 original recipient is we randomize inside of bounds. 628 00:41:06,300 --> 00:41:11,700 However, so we will select. We will select routes that are 629 00:41:11,700 --> 00:41:15,600 up to a certain percentage worse than the optimal route. 630 00:41:16,000 --> 00:41:18,900 I see I guess and I guess that kind of leads into, you know, 631 00:41:18,900 --> 00:41:21,500 the other the next question, you know, one of the most common 632 00:41:21,800 --> 00:41:25,500 questions we You often hear around like lightning is this 633 00:41:25,500 --> 00:41:29,200 question of routing and how we can make this efficient and you 634 00:41:29,200 --> 00:41:32,500 know, does this mean we need Global routing tables and stuff? 635 00:41:32,600 --> 00:41:35,500 So you know could you like maybe like you know address some of 636 00:41:35,500 --> 00:41:38,100 the concerns there and are they valid? 637 00:41:38,400 --> 00:41:41,600 It's just something that like you know lightning yet to be 638 00:41:41,600 --> 00:41:44,100 figured out or yeah. Sure. 639 00:41:44,400 --> 00:41:49,100 So the the current routing protocol is basically solved 640 00:41:49,100 --> 00:41:51,900 based routing. So what we do is we create we 641 00:41:51,900 --> 00:41:55,400 gossip among the It's about which channels exist and which 642 00:41:55,400 --> 00:41:58,200 notes exist. We exchanged messages that 643 00:41:58,200 --> 00:42:01,800 basically say, hey, there's a channel between me and Brian. 644 00:42:02,600 --> 00:42:05,500 There is a channel between me and Sonny. 645 00:42:06,300 --> 00:42:11,200 And, and by gossiping, we incrementally, learn about which 646 00:42:11,200 --> 00:42:14,600 channels are in there. And so we create our local view 647 00:42:14,600 --> 00:42:17,000 of the network. And based on this local view, we 648 00:42:17,000 --> 00:42:22,500 can then select a route from A to B without involving any third 649 00:42:22,500 --> 00:42:27,300 party. That has, that has the huge 650 00:42:27,300 --> 00:42:32,600 advantage that you basically don't tell anybody who the who 651 00:42:32,600 --> 00:42:35,300 the endpoints are. But it has the downside that we 652 00:42:35,300 --> 00:42:39,900 need, so we can do routing decisions locally, but it has a 653 00:42:39,908 --> 00:42:42,500 downside that we actually have to maintain this local view of 654 00:42:42,500 --> 00:42:45,100 the network. There is a few different 655 00:42:45,100 --> 00:42:50,400 constructions where we that are under consideration or we're 656 00:42:50,400 --> 00:42:54,800 under consideration for how we can improve To be more 657 00:42:54,800 --> 00:42:57,900 efficient. And these usually come down to 658 00:42:57,900 --> 00:43:04,600 land-based Landmark base and and Rendezvous based routing. 659 00:43:05,300 --> 00:43:09,300 So, both of these basically say hey there is some very prominent 660 00:43:09,300 --> 00:43:14,500 no nodes in the network that everybody sort of knows how to 661 00:43:14,500 --> 00:43:19,900 get to and how to get from them. And let's just, let's just meet 662 00:43:19,900 --> 00:43:22,700 at this very well known location in network. 663 00:43:23,100 --> 00:43:26,300 And I will tell you how to route from that point to me. 664 00:43:26,300 --> 00:43:30,300 And, you know, how to create the the first half of this route and 665 00:43:30,300 --> 00:43:32,400 then we can collaboratively construct. 666 00:43:32,400 --> 00:43:38,200 This, this road, this has the downside of of creating these of 667 00:43:38,200 --> 00:43:42,100 needing these well-known points in a network and how we select 668 00:43:42,100 --> 00:43:45,500 these is. It's not, it's not that clear 669 00:43:45,500 --> 00:43:49,100 yet. But currently the sort of, 670 00:43:49,100 --> 00:43:52,200 everybody had a nose, the internet work, seems to be 671 00:43:52,200 --> 00:43:54,100 working. Well, And Rusty had a few 672 00:43:54,100 --> 00:43:57,500 numbers. I think that up to million 673 00:43:57,500 --> 00:44:01,400 channels, we should be able to sort of squeeze that in a few 674 00:44:01,400 --> 00:44:05,700 hundred mix of data. So not a huge problem right now. 675 00:44:06,000 --> 00:44:11,600 It's actually luxury problem if we get there and I guess we'll 676 00:44:11,600 --> 00:44:15,400 cross that bridge one. So I once we're there that is to 677 00:44:15,400 --> 00:44:20,400 be said one thing that we might add here is that not all 678 00:44:20,400 --> 00:44:22,800 channels and not all nodes are public. 679 00:44:23,100 --> 00:44:29,100 So, we tend to We tend to announce channels that that 680 00:44:29,100 --> 00:44:33,000 might be used for routing for other people, but if we are just 681 00:44:33,000 --> 00:44:36,900 an end device, that sort of is a client to the rest of the 682 00:44:36,900 --> 00:44:40,400 network, then we will not allow announce them and that is 683 00:44:40,400 --> 00:44:43,400 something that the eclair wallet does. 684 00:44:43,400 --> 00:44:47,500 It doesn't announce its its channels to The Wider public 685 00:44:47,500 --> 00:44:51,600 because well, they're running on a mobile and mobile phone and 686 00:44:51,600 --> 00:44:54,700 they might not be stable enough To actually guarantee that there 687 00:44:54,700 --> 00:44:58,900 are there, when users want to route through them, and the way 688 00:44:58,900 --> 00:45:02,400 we handle those is basically, we add some information into 689 00:45:02,400 --> 00:45:07,200 invoices. So that I say, hey, I'd like to 690 00:45:07,200 --> 00:45:10,700 be paid 10 bucks for you. And here's how you can reach me. 691 00:45:10,700 --> 00:45:15,600 Basically just giving them a, what's called a route hint to 692 00:45:15,600 --> 00:45:16,800 tell them, hey, there's a channel. 693 00:45:16,800 --> 00:45:19,500 You might might want to use if you want to pay me. 694 00:45:19,500 --> 00:45:25,100 And sort of there is this, this Be well, connected and public 695 00:45:25,100 --> 00:45:29,500 core Network that that routes payments from everybody to 696 00:45:29,500 --> 00:45:32,000 everybody else. And then there is this, this 697 00:45:32,600 --> 00:45:38,500 Theory network of devices that come online and go offline very 698 00:45:38,500 --> 00:45:43,800 quickly and are not as reliable and they sort of represent the 699 00:45:43,800 --> 00:45:47,900 endpoints of users that do not want to wrote, but just want to 700 00:45:47,900 --> 00:45:52,900 use this network as, as a client great, I would love to die in. 701 00:45:53,100 --> 00:45:55,900 Little bit. This is the economics of 702 00:45:55,900 --> 00:46:00,100 lightning Network. So in particular, in writing 703 00:46:00,100 --> 00:46:07,700 Bitcoin you the demand the fees you pay, you know, tends to be 704 00:46:07,700 --> 00:46:10,300 based on the the size of the transaction. 705 00:46:11,300 --> 00:46:15,500 So the size in terms of the data, you know, not in terms of 706 00:46:15,500 --> 00:46:17,700 value. Now in lightning, right. 707 00:46:17,700 --> 00:46:22,400 Because using up some Bitcoin door locked, this is different 708 00:46:22,400 --> 00:46:25,100 and It's going to be proportional to the amount 709 00:46:25,100 --> 00:46:26,500 transferred. Is that correct? 710 00:46:26,500 --> 00:46:30,400 Or they're like other determines that will influence transaction 711 00:46:30,400 --> 00:46:34,500 fees. So in the reason why we use, we 712 00:46:34,500 --> 00:46:38,500 use weight-based fees and Bitcoin is basically because the 713 00:46:38,500 --> 00:46:42,500 the contended resource, in this case, is the blog space, right? 714 00:46:42,900 --> 00:46:46,200 And so users, that should that use more of. 715 00:46:46,200 --> 00:46:48,800 It should pay more. Basically, that's the rationale 716 00:46:48,800 --> 00:46:53,900 behind it in enlightening. It's the That resource is 717 00:46:53,900 --> 00:46:56,800 channel capacity. So if I have a 10 dollar Channel 718 00:46:56,800 --> 00:47:02,600 open with you and I send 9 over, then I basically unbalanced my 719 00:47:02,600 --> 00:47:06,000 channel in such a way that well any future payments that that 720 00:47:06,000 --> 00:47:09,500 I'm on a might want to pay through that channel are are at 721 00:47:09,500 --> 00:47:13,700 a disadvantage. So what we do is we did we have 722 00:47:13,700 --> 00:47:18,400 this, we have a proportional fee that basically is denominated in 723 00:47:18,400 --> 00:47:23,200 millions of Satoshi /, Satoshi and sort of. 724 00:47:23,200 --> 00:47:27,100 So the minimum fee you can you can have is zero or one 725 00:47:27,100 --> 00:47:30,300 millionth of a Satoshi for every Satoshi transferred. 726 00:47:31,000 --> 00:47:33,600 Yes. Oh, so the, the scarce resource 727 00:47:33,600 --> 00:47:36,500 here is the capacity that we have in these channels 728 00:47:36,500 --> 00:47:40,900 themselves, give any idea how these fees are going to develop 729 00:47:40,900 --> 00:47:42,500 one. You know, the Network's live. 730 00:47:42,500 --> 00:47:46,700 So you mentioned, okay, this is minimum default of 1 million for 731 00:47:48,100 --> 00:47:52,400 Satoshi, but you know, is it going to be that the more 732 00:47:52,400 --> 00:47:56,900 transactions take place? The lower the fees will be or 733 00:47:58,300 --> 00:48:00,000 how do you think it's going to play out? 734 00:48:00,800 --> 00:48:04,400 So my expectation is that the more transactions we have, the 735 00:48:04,408 --> 00:48:08,400 more balanced these channels become simply because of the 736 00:48:09,100 --> 00:48:12,700 sort of moving away from It balance channel is a random 737 00:48:12,700 --> 00:48:17,500 event and sort of any transaction that modifies that 738 00:48:17,500 --> 00:48:21,300 balance is, is sort of a random a two-dimensional random walk on 739 00:48:21,300 --> 00:48:27,300 that event. So my expectation is that fees 740 00:48:27,300 --> 00:48:33,300 will be minimal and and sort of we just there to compensate 741 00:48:33,300 --> 00:48:37,400 people for the capital expenditure they had to create 742 00:48:37,400 --> 00:48:41,500 this channel. So if I have if I have 100 Of 743 00:48:41,500 --> 00:48:43,600 course, I can. I have a choice of investing 744 00:48:43,600 --> 00:48:48,700 that in and stock, or I can forego that option and create a 745 00:48:48,700 --> 00:48:51,000 channel instead. So, there is some cost to 746 00:48:51,000 --> 00:48:55,600 operating a node and that cost should be compensated by users 747 00:48:55,600 --> 00:48:57,900 taking advantage of this of this cost. 748 00:48:58,400 --> 00:49:02,900 I don't think that there will be, there will be big hubs, that 749 00:49:02,900 --> 00:49:06,200 can leverage higher fees because it's very easy to create 750 00:49:06,200 --> 00:49:10,900 alternative routes around. These helps and sort of just a 751 00:49:10,900 --> 00:49:13,600 little Lil Bit less than than the huge feasts. 752 00:49:13,600 --> 00:49:17,400 And so you create this race to the bottom for people that that 753 00:49:17,400 --> 00:49:20,400 leverage, that want to leverage High fees. 754 00:49:21,400 --> 00:49:25,100 And we'd like to actually encourage people to look for 755 00:49:25,100 --> 00:49:27,700 these kinds of strategic positions where they can open a 756 00:49:27,700 --> 00:49:32,800 channel and sort of just undercut, the, The Hub as long 757 00:49:32,800 --> 00:49:38,700 as the capital expenditure is not is not a still covered by 758 00:49:38,700 --> 00:49:42,700 the fees that may collect. So, I guess, We will we will go 759 00:49:42,700 --> 00:49:47,400 to a fee level. That is very minimal and just 760 00:49:47,400 --> 00:49:50,600 covers the capital expense. You have for open channel. 761 00:49:53,000 --> 00:49:57,200 So let's say now in the future a lot, there's a lot of sort of 762 00:49:57,200 --> 00:50:00,700 one of the interesting topics currently especially in the 763 00:50:00,700 --> 00:50:04,200 theorem right. Is it decentralized Finance or 764 00:50:04,200 --> 00:50:08,500 defy and of trend right now? A lot of things that taken under 765 00:50:08,500 --> 00:50:11,300 this umbrella, you know, things like maker, where you can put up 766 00:50:11,300 --> 00:50:14,400 ether and then you can get up some out, some stable coin. 767 00:50:15,500 --> 00:50:18,400 And so it's generally a perception there and I think 768 00:50:18,400 --> 00:50:21,800 it's a correct perspective perception that there's going to 769 00:50:21,808 --> 00:50:24,700 be a lot of ways. To actually use crypto and like 770 00:50:24,700 --> 00:50:26,400 earn money. Whether that's like that you can 771 00:50:26,400 --> 00:50:29,700 stake it, or maybe you can use it at some sort of security Bond 772 00:50:30,500 --> 00:50:32,700 or you know this. You be able to lend it. 773 00:50:33,200 --> 00:50:36,400 And now, presumably that's also going to happen in Bitcoin right 774 00:50:36,400 --> 00:50:39,500 where you can, maybe lend Bitcoin. 775 00:50:39,700 --> 00:50:43,300 And you know they have different ways of earning some money on 776 00:50:43,300 --> 00:50:46,300 it. You think that's also one way to 777 00:50:46,300 --> 00:50:49,200 think about lightning, maybe I is a normal Bitcoin users, you 778 00:50:49,200 --> 00:50:51,800 know, down the line in two years or something, I'll be able to 779 00:50:51,800 --> 00:50:55,500 say, okay, I'm I'm taking my, I take a Bitcoin or Take 5 780 00:50:55,500 --> 00:50:58,000 Bitcoins, I put it in some lightning channels. 781 00:50:58,000 --> 00:51:02,100 Now, it's use is writing payment and I make like, I don't know, 782 00:51:02,100 --> 00:51:05,800 three percent a year or four percent a year, in terms of, you 783 00:51:05,800 --> 00:51:09,200 know, earning more Bitcoin for basically providing that Capital 784 00:51:09,200 --> 00:51:12,500 there. I don't I don't think liking 785 00:51:12,500 --> 00:51:15,000 channels are a good investment at all. 786 00:51:16,000 --> 00:51:19,900 It's basically just if you if you look at it from an 787 00:51:19,900 --> 00:51:24,000 investment side then and you want to leverage higher fees, 788 00:51:24,300 --> 00:51:28,300 you're basically creating this island of high fees around you 789 00:51:28,700 --> 00:51:32,900 and people that that are happy to maybe only take two and a 790 00:51:32,900 --> 00:51:37,000 half percent will position position himself right next to 791 00:51:37,000 --> 00:51:42,400 you and sort of undercut you I think fees should mostly be 792 00:51:42,400 --> 00:51:49,300 thought of as amortization for your own investment for your own 793 00:51:49,300 --> 00:51:52,700 needs. When a as a user of the of the 794 00:51:52,700 --> 00:51:56,300 lightning Network, they're probably not a great business 795 00:51:56,300 --> 00:52:02,200 model to make money. So I can, if I make regular user 796 00:52:02,200 --> 00:52:06,900 of the lightning Network, and I want to sort of reduce my my my 797 00:52:06,900 --> 00:52:12,200 fee expenses for payments that I perform Then, I can route 798 00:52:12,200 --> 00:52:15,800 payments for other people and every all the feast that I that 799 00:52:15,800 --> 00:52:20,900 I gather, I can then spend on my own expenses in the Latin 800 00:52:20,900 --> 00:52:23,200 Network. So it's more of an amortization 801 00:52:23,200 --> 00:52:28,400 of fees that I incur as a user rather than I put some money in 802 00:52:28,400 --> 00:52:30,300 there. And then I pull it out again and 803 00:52:30,300 --> 00:52:32,900 then suddenly it's been multiplied. 804 00:52:34,700 --> 00:52:37,400 It's a recently. There was this guy, Andreas 805 00:52:37,400 --> 00:52:40,800 break and I think, and, you know, he was operating lots of 806 00:52:40,800 --> 00:52:44,500 lightning channels and, yeah, I think it was around 50 percent 807 00:52:44,500 --> 00:52:47,800 of all of the Bitcoin in the lightning Network at one point 808 00:52:48,000 --> 00:52:50,700 and of course, lightning is very early in this, you know, there's 809 00:52:50,700 --> 00:52:53,100 no will. So it's may be dangerous to 810 00:52:53,100 --> 00:52:56,500 extrapolate from his experience to like what is lightning going 811 00:52:56,500 --> 00:53:00,600 to look like when when it's kind of really functional really 812 00:53:00,600 --> 00:53:04,400 being used but I mean, I think I guess. 813 00:53:04,600 --> 00:53:08,200 That was one of two takeaways that you know he write it all of 814 00:53:08,200 --> 00:53:11,800 those payments and he made like a fraction of a dollar. 815 00:53:12,500 --> 00:53:15,400 Are there any other kind of interesting takeaways or lessons 816 00:53:15,400 --> 00:53:17,500 that you felt? Like I was kind of learned by 817 00:53:17,500 --> 00:53:21,000 people like him that are operating lightning channels 818 00:53:21,000 --> 00:53:23,800 today in terms of how it's going to play out. 819 00:53:23,800 --> 00:53:29,000 Once there is real adoption. I guess I guess Andreas 820 00:53:29,000 --> 00:53:33,700 bracken's experiment was was really early on and probably 821 00:53:33,700 --> 00:53:36,100 you're right that that extrapolating from from his 822 00:53:36,100 --> 00:53:41,700 experiences is not, it's not really feasible but only 823 00:53:41,700 --> 00:53:46,000 recently there has been a. There has been a huge operator 824 00:53:46,000 --> 00:53:52,700 of lightning notes called Ellen big.com, which has opened a lot 825 00:53:52,700 --> 00:53:56,900 of high-volume channel to a lot of people in the network and 826 00:53:57,500 --> 00:54:04,200 They, they recently published an article about how many how many 827 00:54:04,200 --> 00:54:07,500 transaction fees they have gathered, and how many, I think 828 00:54:07,500 --> 00:54:09,700 they also expose, how many transactions they have 829 00:54:09,700 --> 00:54:12,500 forwarded. And it turns out they didn't 830 00:54:12,500 --> 00:54:18,900 make a lot of money from it. Now, that could be that they're 831 00:54:18,900 --> 00:54:23,100 not positioning themselves so well or that the, the the sort 832 00:54:23,100 --> 00:54:27,300 of fee structure they had is suboptimal, but I think that It 833 00:54:27,308 --> 00:54:32,000 sort of adds adds more credibility to the fees will not 834 00:54:32,000 --> 00:54:36,300 be gigantic, right? Again, these these players could 835 00:54:36,300 --> 00:54:40,900 increase the their local setting for fees, but that also 836 00:54:40,900 --> 00:54:43,800 decreases the probability of people actually routing through 837 00:54:43,800 --> 00:54:48,700 them. And I think, yeah, this this is 838 00:54:48,700 --> 00:54:54,000 sort of two separate experiences the distance of half a year that 839 00:54:54,000 --> 00:54:57,200 show that the fees are not are not really there. 840 00:54:58,000 --> 00:55:02,100 To be made. And people people find their 841 00:55:02,100 --> 00:55:05,500 cheap ways to to route in the in the lightning Network. 842 00:55:06,900 --> 00:55:11,000 So, another question I have about routing is a few months 843 00:55:11,000 --> 00:55:14,300 ago, I was talking to Zuko Wilcox about some lightning 844 00:55:14,300 --> 00:55:18,700 stuff and one of the points he brought up to me, was that he 845 00:55:18,700 --> 00:55:22,700 believes that there's a griefing attack possible where, you know, 846 00:55:22,700 --> 00:55:26,600 you can like send paint, you can send payments yourself and, you 847 00:55:26,607 --> 00:55:29,300 know, cause a lot of people along the route to lock up some 848 00:55:29,300 --> 00:55:32,600 capital and then you suddenly decide to not send any payments 849 00:55:32,600 --> 00:55:36,800 and, you know, you never have to pay any fees for this or any. 850 00:55:36,900 --> 00:55:40,100 Thing. And so you know and you could 851 00:55:40,100 --> 00:55:43,100 just keep dosing, the lightning Network and causing people to do 852 00:55:43,100 --> 00:55:46,000 lockups and then just like failing the transaction. 853 00:55:46,000 --> 00:55:49,400 So is this a legitimate concern? Or is this like an address 854 00:55:49,400 --> 00:55:52,700 tissue? It is it is definitely a concern 855 00:55:52,700 --> 00:55:57,300 that we have. It's possible to lock up funds 856 00:55:57,300 --> 00:56:02,300 for certain periods of times. If you do it too long, then your 857 00:56:02,300 --> 00:56:06,200 channel will shut down which is going to cost you some money. 858 00:56:06,300 --> 00:56:10,600 But Four minutes or hours, at a time, it's definitely possible 859 00:56:10,600 --> 00:56:14,700 to lock up funds. It's something that that we are 860 00:56:15,200 --> 00:56:20,100 hoping to address by by adding fees outside of the transferred 861 00:56:20,100 --> 00:56:21,900 amount. So whether or not a payment 862 00:56:21,900 --> 00:56:27,400 succeeds, there is a fee involved, but as it as it stands 863 00:56:27,400 --> 00:56:30,200 currently, it's not, it's not been addressed. 864 00:56:31,500 --> 00:56:35,400 How would that outside of the payment amount like fee payment 865 00:56:35,400 --> 00:56:37,900 be done? Like how would that happen? 866 00:56:37,900 --> 00:56:41,800 Technically, so the reason why this griefing attack is free 867 00:56:41,800 --> 00:56:45,900 currently, is that basically what what we do is, we include 868 00:56:45,900 --> 00:56:51,300 the fee, in the, in the transfer itself, meaning that if the 869 00:56:51,300 --> 00:56:54,700 transfer fails, then the fees will get rolled back as well. 870 00:56:56,400 --> 00:57:02,700 So that, that turns out It didn't it enables number of 871 00:57:02,700 --> 00:57:06,200 nasty things. One is the griefing attack and 872 00:57:06,200 --> 00:57:10,600 the other one is, is basically free probing of the network by 873 00:57:10,600 --> 00:57:14,800 sending sending payments that are that do not match an 874 00:57:14,800 --> 00:57:21,000 invoice, that is to be paid. However, the solution that we 875 00:57:21,000 --> 00:57:27,900 that we propose is basically, to have this fee, be should flow 876 00:57:27,900 --> 00:57:30,200 whether or not the success of the transactions. 877 00:57:30,500 --> 00:57:33,500 It's are not. So basically what we what we 878 00:57:33,500 --> 00:57:40,400 currently do is if I want, if I want to send 9 satoshi's to to 879 00:57:40,400 --> 00:57:45,300 Brian through Sunny, then I will send 10 to you with the prom. 880 00:57:45,400 --> 00:57:49,700 I will promise tend to you if you send the nine onwards Brian. 881 00:57:50,800 --> 00:57:54,800 And if that if the last top doesn't succeed, you don't get 882 00:57:54,800 --> 00:57:58,200 any anything, right. You don't get your one Satoshi 883 00:57:58,500 --> 00:58:03,500 in fees and The, the solution that we are considering is 884 00:58:03,500 --> 00:58:06,500 basically that I will send you one Satoshi. 885 00:58:06,700 --> 00:58:09,900 I will send you 9 satoshi's and those nine satoshi's. 886 00:58:09,900 --> 00:58:15,500 You will get when, when, when you forward them to, to brine. 887 00:58:15,700 --> 00:58:17,800 So that's sort of an out-of-band fee. 888 00:58:17,800 --> 00:58:23,600 That allows us to have that to, to force people to pay something 889 00:58:23,600 --> 00:58:26,900 whether or not this this payment succeeds or not. 890 00:58:28,300 --> 00:58:32,200 So would you here? Make it so that you know, let's 891 00:58:32,200 --> 00:58:37,800 say Sonny sonny get some fee anyway but he gets a larger fee 892 00:58:38,000 --> 00:58:42,600 in case he actually routes the payment or otherwise what's the 893 00:58:42,600 --> 00:58:48,000 incentive to yes. So so so my example was flawed 894 00:58:48,000 --> 00:58:52,600 because I started with 10 and 9 and didn't have any room to 895 00:58:52,600 --> 00:58:56,000 split that one but yes, of course it would be. 896 00:58:56,100 --> 00:59:01,000 It should be 11. On one, you get a front and 10, 897 00:59:01,000 --> 00:59:05,000 you get, when the routing completes and then sort of heat 898 00:59:05,000 --> 00:59:08,200 the 10th, he only gets when routing the nine onwards. 899 00:59:08,700 --> 00:59:12,000 It does sound like a pretty clean solution. 900 00:59:12,400 --> 00:59:15,100 Well, let's speak a little bit about sort of the technical 901 00:59:15,100 --> 00:59:17,800 roadmap for lightning. So you may be mentioned, briefly 902 00:59:17,800 --> 00:59:23,300 L2, which is kind of a proposal upgrade proposal that you worked 903 00:59:23,300 --> 00:59:26,000 on and published. I think last April, can you talk 904 00:59:26,000 --> 00:59:28,800 a little bit about what? Altitude mean for lightning. 905 00:59:30,500 --> 00:59:36,300 Yeah. So L 2 is sort of the 2.0 future 906 00:59:37,200 --> 00:59:40,200 and what we're currently working on is 1.1. 907 00:59:40,700 --> 00:59:46,100 So L 2 is is it is new construction of payment channels 908 00:59:46,100 --> 00:59:48,500 that is much simpler and reconnects. 909 00:59:48,500 --> 00:59:50,900 In fact to the duplex micropayment Channel idea. 910 00:59:51,500 --> 00:59:55,700 I say 2.0 because we actually require a change to the Bitcoin 911 00:59:55,700 --> 00:59:58,100 scripting language called C cash. 912 00:59:58,100 --> 01:00:01,800 No input. Which Looks like we might get 913 01:00:01,900 --> 01:00:04,500 eventually. I'm not really good at making 914 01:00:04,500 --> 01:00:07,700 predictions when it comes to that ever since s activation. 915 01:00:08,300 --> 01:00:11,900 And and once we, once we have see cash, no input. 916 01:00:11,900 --> 01:00:15,600 We can actually build. L2, which is this, which is this 917 01:00:15,800 --> 01:00:19,800 simpler construction, which we basically can say, we can say, 918 01:00:19,800 --> 01:00:23,600 okay, my current state is, if we go back to the Barista, my 919 01:00:23,600 --> 01:00:27,300 current state is, you get to and I get 8 and then we update a 920 01:00:27,308 --> 01:00:31,200 couple of times and then we have five and five, And we can forget 921 01:00:31,200 --> 01:00:34,700 all all the states we have before which is currently not 922 01:00:34,700 --> 01:00:38,100 possible with lightning. We're in lightning, we have to 923 01:00:38,100 --> 01:00:41,400 keep part of the state for oral previous States. 924 01:00:41,400 --> 01:00:46,600 So we can react in a correct way to whatever or current party 925 01:00:46,600 --> 01:00:51,600 might do in in L2. We have this last state which 926 01:00:51,600 --> 01:00:55,800 basically trumps everything that has ever been before and and 927 01:00:55,800 --> 01:00:59,900 allows us to override, whatever, whatever or counterparty might 928 01:00:59,900 --> 01:01:01,800 do. With just keeping the latest 929 01:01:01,800 --> 01:01:05,100 State. Yeah, I add and Robinson and 930 01:01:05,100 --> 01:01:08,500 Lalu have a pet. I believe going on that whether 931 01:01:08,500 --> 01:01:11,300 Sig has no input will be in by 2021. 932 01:01:14,000 --> 01:01:17,200 Oh, and yeah. Roasting also has an elbow 933 01:01:17,200 --> 01:01:19,800 construction, which is so, which is interesting, which is a chick 934 01:01:19,800 --> 01:01:23,300 sick from stock that also is a soft work. 935 01:01:23,300 --> 01:01:28,500 And it, we might, we might end up compete with two competing 936 01:01:28,500 --> 01:01:31,100 proposals again, and then sort, Of hash it out. 937 01:01:31,100 --> 01:01:33,500 Which one is the cleaner? And which one is the more 938 01:01:33,500 --> 01:01:37,600 flexible one? But yeah, but there there's 939 01:01:37,600 --> 01:01:40,400 there is quite a lot of quite a few things we can do and 940 01:01:40,600 --> 01:01:44,100 hopefully see cash. No input is less controversial 941 01:01:44,100 --> 01:01:46,200 than some other stuff that has come before. 942 01:01:46,800 --> 01:01:49,600 And I'm pretty sure it is because I wrote a proposal, and 943 01:01:49,600 --> 01:01:52,500 it's seriously like three lines of code. 944 01:01:52,800 --> 01:01:57,200 It's really simple. See, also mentioned multi-party 945 01:01:57,200 --> 01:02:03,000 channels, what are those And how would they change the lightning 946 01:02:03,000 --> 01:02:06,700 Network? Yes, so the current construction 947 01:02:06,700 --> 01:02:10,200 basically is with lightning channels, we have only two party 948 01:02:10,200 --> 01:02:15,300 channels meaning that I can only trade my coins with one other 949 01:02:15,300 --> 01:02:19,500 person and we have to settle our, our state among ourselves. 950 01:02:20,300 --> 01:02:23,800 This is due to the construction of lightning, which basically 951 01:02:23,800 --> 01:02:28,300 means that for every state, that the counterparty might publish, 952 01:02:28,300 --> 01:02:33,200 I need to have a need to have this reaction ready. 953 01:02:33,200 --> 01:02:37,400 So, if we add more Than more than one counterparty. 954 01:02:37,600 --> 01:02:41,300 Suddenly we have this, this explosion of possible Miss 955 01:02:41,300 --> 01:02:44,800 behaviors. And and we have to keep our keep 956 01:02:44,800 --> 01:02:49,300 track of a lot of state with L2 having the last state, basically 957 01:02:49,300 --> 01:02:51,400 Trump. Everything that came before it 958 01:02:52,200 --> 01:02:58,200 we don't, we don't need to have a Custom, Tailor to reaction to 959 01:02:58,200 --> 01:03:01,700 whatever our current parties do. And this also means that we 960 01:03:01,700 --> 01:03:04,600 suddenly have we suddenly don't care anymore. 961 01:03:04,700 --> 01:03:07,100 More about which counterparty misbehaves. 962 01:03:07,300 --> 01:03:10,600 We can just use our trump card which is the latest State and 963 01:03:10,600 --> 01:03:12,600 just override whatever happened in between. 964 01:03:13,400 --> 01:03:17,100 So, all of the sudden, it becomes possible for us three on 965 01:03:17,100 --> 01:03:21,700 the, on the, on the, on the chat basically have one shared 966 01:03:21,700 --> 01:03:27,200 Channel and we can freely move, move funds from anybody to 967 01:03:27,200 --> 01:03:28,900 anybody else on the same channel. 968 01:03:29,500 --> 01:03:34,500 So, and we have constructions, where we can go to 15 or 15 or 969 01:03:35,600 --> 01:03:40,000 Once we have once we have snore signatures, we can we can go to 970 01:03:40,000 --> 01:03:45,200 arbitrary number of participants and that basically means that we 971 01:03:45,200 --> 01:03:50,300 D emphasize a bit, the Reliance on multi-hop payments because if 972 01:03:50,900 --> 01:03:56,200 if I am in a group that moves funds around often between the 973 01:03:56,200 --> 01:03:59,400 its own participants, we don't need to leave the boundaries of 974 01:03:59,400 --> 01:04:03,200 our single Channel but we can adjust balances just by us. 975 01:04:03,600 --> 01:04:07,000 So, if Go over there. Go back to this example where we 976 01:04:07,000 --> 01:04:12,200 three now have have one channel open and I put ten dollars in 977 01:04:13,100 --> 01:04:18,300 and you both have zero in that. I can I can decide to send 92 978 01:04:18,300 --> 01:04:23,800 sunny and 12 Brine and basically our latest state is 0 for me, 979 01:04:23,900 --> 01:04:30,600 one for Brian and 944 sunny. And and if we want to if we want 980 01:04:30,600 --> 01:04:34,300 to send back any of this money we can we can do so without 981 01:04:34,300 --> 01:04:38,200 ever. involving some other channel, in The Wider Network, 982 01:04:39,600 --> 01:04:42,800 And this creates a whole lot of interesting. 983 01:04:43,700 --> 01:04:47,800 Interesting scenarios we can do we certainly can we can suddenly 984 01:04:47,800 --> 01:04:52,600 no longer not only transfer Bitcoins but we might be able to 985 01:04:52,600 --> 01:04:57,000 transfer unique assets among herself because one of the one 986 01:04:57,000 --> 01:05:00,800 of the principal assumptions in the lightning network is that it 987 01:05:00,800 --> 01:05:03,900 doesn't matter which coins, you get exactly. 988 01:05:05,400 --> 01:05:09,700 All coins are fungible. So if I send one Bitcoin, Sunny 989 01:05:09,700 --> 01:05:14,800 and sunny forwards it to you, then then the coin that you 990 01:05:14,800 --> 01:05:16,900 receive is not the one that I sent, right? 991 01:05:17,600 --> 01:05:22,400 Whereas in a multi-party channel, we can actually handle 992 01:05:22,400 --> 01:05:25,600 unique assets among ourselves, so I can actually send you one 993 01:05:25,600 --> 01:05:28,700 Bitcoin, and the one that is going to arrive at your 994 01:05:28,700 --> 01:05:32,200 location. Your on your balance is going to 995 01:05:32,200 --> 01:05:36,800 be the same Bitcoin that I sent. And so, if you were to, for 996 01:05:36,800 --> 01:05:42,300 example, create crypto kitties on, On one gigantic payment 997 01:05:42,300 --> 01:05:44,000 Channel. We could actually send these 998 01:05:44,000 --> 01:05:47,400 unique assets among ourselves without ever involving the 999 01:05:47,400 --> 01:05:50,800 blockchain without ever involving any party outside of 1000 01:05:50,800 --> 01:05:55,000 the channel itself. Two of the features I have, you 1001 01:05:55,000 --> 01:05:59,300 know, I read about a little bit, which sounded interesting to me, 1002 01:05:59,500 --> 01:06:03,600 were one of them was this idea that you could do a comic 1003 01:06:03,600 --> 01:06:07,900 multi-channel sent. So let's say, I have like, you 1004 01:06:07,900 --> 01:06:11,700 know, five channels of to bitcoin each but I'm trying to 1005 01:06:11,700 --> 01:06:15,200 send 10 Bitcoin, I can somehow have a system in which I can 1006 01:06:15,200 --> 01:06:20,900 atomically send all of them. And so I will make the full 1007 01:06:20,900 --> 01:06:23,600 payment or not. Is this something that Method 1008 01:06:23,600 --> 01:06:24,900 right now. Or is this like a future 1009 01:06:24,900 --> 01:06:28,500 upgrade? Yeah. 1010 01:06:28,500 --> 01:06:32,900 So that's that's part of the, the 1.1 push that we started in 1011 01:06:32,900 --> 01:06:35,600 November. During our second spec meeting. 1012 01:06:35,600 --> 01:06:40,500 This basically gave us a chance to pull up all the features that 1013 01:06:40,500 --> 01:06:43,400 we thought about but didn't want to have in the first version 1014 01:06:43,400 --> 01:06:46,800 because well that would have postpone the release of of the 1015 01:06:46,800 --> 01:06:51,200 spec itself. So now we dug up all of the nice 1016 01:06:51,200 --> 01:06:52,900 features that we that we thought about. 1017 01:06:53,200 --> 01:06:57,200 And that we know are possible right now, but haven't inspect 1018 01:06:57,200 --> 01:06:59,300 yet. And one of these is indeed the, 1019 01:06:59,300 --> 01:07:04,000 the the atomic multi-party payment, the multi-part payment 1020 01:07:04,700 --> 01:07:09,100 and, and as you as you said, it allows us to basically bundle 1021 01:07:09,100 --> 01:07:13,500 the capacity of multiple of our channels to create to perform 1022 01:07:13,500 --> 01:07:16,900 one big payment instead of instead of being limited by the 1023 01:07:16,900 --> 01:07:19,500 capacity of our biggest Channel, basically. 1024 01:07:21,000 --> 01:07:23,100 And the other one I was interested. 1025 01:07:23,300 --> 01:07:27,500 It was splicing where it is, could you maybe describe that 1026 01:07:27,500 --> 01:07:30,300 and is that also in this like 1.1 spec? 1027 01:07:30,800 --> 01:07:35,300 Oh definitely splicing. Basically is an idea, I had a 1028 01:07:35,300 --> 01:07:41,000 few during the first big meeting and it basically allows us to to 1029 01:07:41,200 --> 01:07:46,400 close the channel and reopen it in the same transaction and sort 1030 01:07:46,400 --> 01:07:52,100 of add new funds to it or or move funds out of the channel 1031 01:07:52,500 --> 01:07:55,500 without the Channel, ever becoming becoming an avoid 1032 01:07:55,700 --> 01:07:59,800 unavailable. So the idea here is basically 1033 01:07:59,800 --> 01:08:02,700 that if we have a channel and its really unbalanced and you 1034 01:08:02,700 --> 01:08:05,500 own all the funds, but I want to use this channel to send you 1035 01:08:05,500 --> 01:08:08,000 some money. Then I can basically take some 1036 01:08:08,000 --> 01:08:11,300 other coins. I have lying around on chain, we 1037 01:08:11,300 --> 01:08:17,800 can agree to perform a splice and I can add these funds during 1038 01:08:17,800 --> 01:08:22,300 this close and open operation to our to the channel balances. 1039 01:08:23,700 --> 01:08:29,399 So that allows us to to move funds from unchain into channels 1040 01:08:29,399 --> 01:08:32,600 that already exists and the child remains operational while 1041 01:08:32,600 --> 01:08:36,200 we do. So and the the counterpart to, 1042 01:08:36,200 --> 01:08:40,500 this is what we call a splice out which basically allows us to 1043 01:08:40,600 --> 01:08:45,300 I have I have a lot of Bitcoins on my side and I'd like to for 1044 01:08:45,300 --> 01:08:49,000 example perform and unchain payment, then we agree to 1045 01:08:49,000 --> 01:08:53,800 perform a splice out and part of this close and Open transaction. 1046 01:08:53,800 --> 01:08:57,399 Is that part of the funds that were aware owned by me, will go 1047 01:08:57,399 --> 01:09:01,700 to a new output, which is then destined for my, for my own 1048 01:09:01,700 --> 01:09:05,100 chain on chain payment recipient. 1049 01:09:05,500 --> 01:09:10,500 And these these two proposals, the, the, multi-part payment and 1050 01:09:10,500 --> 01:09:15,300 the and the splicing are part of a wider initiative where we try 1051 01:09:15,300 --> 01:09:19,800 to sort of hide many of the technical details of, of the 1052 01:09:19,800 --> 01:09:23,899 lightning Network in such a way that That it becomes more 1053 01:09:23,899 --> 01:09:29,800 intuitive for users to to use lightning because what what 1054 01:09:29,800 --> 01:09:32,800 multi-party payment? Basically allows us is a 1055 01:09:32,808 --> 01:09:37,500 multi-part payment, I should say allows us to do is not care 1056 01:09:37,500 --> 01:09:40,899 anymore about the elegant, how we allocated funds to a channel. 1057 01:09:41,200 --> 01:09:45,500 If I have, if I have 10 one Bitcoin channels or have 1110 1058 01:09:45,899 --> 01:09:49,600 Bitcoin Channel, it doesn't make any difference for me because I 1059 01:09:49,600 --> 01:09:53,700 have I have this, I can bundle the If you have multiple 1060 01:09:53,700 --> 01:09:59,600 channels, so I don't care about channels anymore, and the splice 1061 01:09:59,600 --> 01:10:04,300 in and splice out proposal. Basically removes this barrier 1062 01:10:04,300 --> 01:10:07,600 between unchain funds and off chain funds because all of the 1063 01:10:07,600 --> 01:10:12,000 sudden my off chain funds that are are that are allocated to a 1064 01:10:12,000 --> 01:10:15,100 lightning Channel. I can still use to make online 1065 01:10:15,400 --> 01:10:18,500 on chain payments. So the ultimate goal for us is 1066 01:10:18,500 --> 01:10:22,200 to basically create a wallet that displays one balance to 1067 01:10:22,200 --> 01:10:23,100 you. Whether Either. 1068 01:10:23,100 --> 01:10:26,200 And that, that basically contains both your unchain 1069 01:10:26,200 --> 01:10:30,200 balance as well as your off chain balance and have channels 1070 01:10:30,700 --> 01:10:34,100 be handled automatically in the background sort of removing 1071 01:10:34,100 --> 01:10:39,800 this, this sort of complex issue of having to explain to your 1072 01:10:39,800 --> 01:10:43,800 users, what what channel is and how to best open and create and 1073 01:10:43,800 --> 01:10:48,000 how to allocate them and all of these thorny details, that users 1074 01:10:48,000 --> 01:10:51,900 currently have to deal with. That sounds really fantastic. 1075 01:10:51,900 --> 01:10:55,300 Actually, I think that was always a little bit, my concern. 1076 01:10:55,300 --> 01:10:58,300 I had, you know, it's a okay. How do you manage these channels 1077 01:10:58,300 --> 01:11:02,100 or now you have this too many funds in there and now you want 1078 01:11:02,100 --> 01:11:04,600 to take some out again into close the channel, but that 1079 01:11:04,600 --> 01:11:07,800 sounds like a very clean way of managing that. 1080 01:11:07,800 --> 01:11:11,000 Yeah. It's, I mean, it's it's still 1081 01:11:11,000 --> 01:11:15,600 early days and so, all of these technical details are really 1082 01:11:15,600 --> 01:11:19,000 hard to explain to users which is why we currently concentrate 1083 01:11:19,000 --> 01:11:23,000 mostly on. Savvy users, that, that sort of 1084 01:11:23,000 --> 01:11:28,500 want to dig into the technical details and at halftime to to 1085 01:11:28,500 --> 01:11:31,900 dedicate to researching these issues and these topics. 1086 01:11:31,900 --> 01:11:37,600 But the end goal really is to create a software that takes 1087 01:11:37,600 --> 01:11:40,000 care of all of these details for you. 1088 01:11:40,000 --> 01:11:44,200 And all you have to care about is basically, do I have enough 1089 01:11:44,200 --> 01:11:48,600 money to buy my coffee, whether that's on chain or off chain, or 1090 01:11:48,600 --> 01:11:51,200 do I have enough? That should all be handled in 1091 01:11:51,200 --> 01:11:55,200 the background without you ever having to learn about it, if you 1092 01:11:55,200 --> 01:12:02,000 want to, that's great. But you shouldn't have to So 1093 01:12:02,400 --> 01:12:06,200 I'll say this that I'm not, I haven't done too much Bitcoin 1094 01:12:06,200 --> 01:12:09,600 development but I've done that a couple of payment channel 1095 01:12:09,600 --> 01:12:14,600 implementations on ethereum and on the cosmos SDK. 1096 01:12:15,100 --> 01:12:18,200 And so one of the things I questions I have is like how 1097 01:12:18,200 --> 01:12:21,800 much of the complexity of, you know, lightning development is 1098 01:12:21,808 --> 01:12:26,000 coming from like limitations in the Bitcoin State machine and 1099 01:12:26,000 --> 01:12:29,300 like for my and like you know, also look the statefulness of 1100 01:12:29,300 --> 01:12:32,700 like other systems seems to like also A lot of additional 1101 01:12:32,700 --> 01:12:35,200 functionality where you can do, you know. 1102 01:12:36,300 --> 01:12:39,400 So there's a, there's a proposal called Sprites channels, which 1103 01:12:39,400 --> 01:12:42,900 makes it easier to close, like defunct routes. 1104 01:12:43,500 --> 01:12:46,500 There's a, you know, I think it's easier to make much more 1105 01:12:46,500 --> 01:12:49,500 powerful watchtowers and stuff. So even when it comes to 1106 01:12:49,500 --> 01:12:54,500 bitcoin, what is the benefit of deploying a lightning Network on 1107 01:12:54,500 --> 01:12:58,300 the main chain versus, for example, creating a side chain 1108 01:12:58,300 --> 01:13:00,500 to bitcoin and deploying the lightning Network. 1109 01:13:00,500 --> 01:13:03,800 They are aware r that side chain may have more State V 1110 01:13:03,800 --> 01:13:08,300 capabilities. Yeah, so regarding a second 1111 01:13:08,300 --> 01:13:12,800 Point, why deployed on the Bitcoin main chain is? 1112 01:13:13,100 --> 01:13:14,800 Well, basically our users are there. 1113 01:13:14,800 --> 01:13:19,900 That's where people get the most usability, the most utility 1114 01:13:19,900 --> 01:13:23,300 from, and that's where we want to use it. 1115 01:13:23,300 --> 01:13:25,900 Ourself. Right, adding adding side. 1116 01:13:25,900 --> 01:13:30,700 Chains is great for to add to add special functionality that 1117 01:13:30,700 --> 01:13:34,100 you can't do in Bitcoin or that we haven't figured out how to do 1118 01:13:34,100 --> 01:13:40,200 in Bitcoin. Itself just yet but it's it's 1119 01:13:40,800 --> 01:13:43,200 it's a hurdle to get users on board, right? 1120 01:13:44,600 --> 01:13:48,800 Whereas Bitcoin, if you already have Bitcoin you can use 1121 01:13:48,800 --> 01:13:55,700 lighting right now, as for the, the need for State fullness and 1122 01:13:55,700 --> 01:13:59,100 the need for more advanced smart contracts. 1123 01:13:59,100 --> 01:14:03,200 We find time and time again, that it turns out that we can 1124 01:14:03,200 --> 01:14:07,100 backport a lot of stuff. Not that come from the state 1125 01:14:07,100 --> 01:14:13,300 channels and the etherium community into into Bitcoin, 1126 01:14:13,500 --> 01:14:18,600 maybe in a bit more complex way. But we can, we can often do 1127 01:14:18,600 --> 01:14:24,600 without the added complexity of, of, actually running a stateful 1128 01:14:24,600 --> 01:14:30,700 chain such as a theorem, one of these examples for, is that I 1129 01:14:30,700 --> 01:14:34,900 gave a lecture in Stanford last year after publishing L2 and it 1130 01:14:35,000 --> 01:14:41,500 it and just before the, before the lecture itself, I was 1131 01:14:41,500 --> 01:14:47,900 challenged to to see if I could Implement L2 in solidity and it 1132 01:14:47,900 --> 01:14:52,400 turns out it's something that we can do in like 20 lines of code 1133 01:14:52,900 --> 01:15:00,400 and the code actually looks a lot like like Raiden so suddenly 1134 01:15:00,400 --> 01:15:04,000 suddenly we had this very roundabout way of creating 1135 01:15:04,000 --> 01:15:07,600 something that was Made for ethereum and back ported into 1136 01:15:07,600 --> 01:15:14,100 Bitcoin itself without all the additional costs and and sort of 1137 01:15:14,100 --> 01:15:16,700 heaviness that comes with a theorem. 1138 01:15:17,600 --> 01:15:20,400 I'm not going to make a lot of friends by saying this, but I 1139 01:15:20,400 --> 01:15:23,500 consider a theorem great test net for Bitcoin. 1140 01:15:25,900 --> 01:15:28,200 Yes, that makes sense. Like, you know, I was just 1141 01:15:28,200 --> 01:15:31,800 really thinking that, you know, I really how I see like you know 1142 01:15:31,800 --> 01:15:34,900 what my vision would be. Like, I really want to see a 1143 01:15:35,000 --> 01:15:40,100 Special side chain, that's designed for lightning and state 1144 01:15:40,100 --> 01:15:42,800 Channel networks. Just be deployed as soft worked 1145 01:15:42,800 --> 01:15:47,600 in as an official site. Merge mind chained to an 1146 01:15:47,600 --> 01:15:51,800 official drivetrain to bitcoin. That's, you know it's whole 1147 01:15:51,800 --> 01:15:55,300 purpose is designed to be a lightning Network and you know, 1148 01:15:55,300 --> 01:15:59,600 it could be in a semi official capacity and hopefully you ex 1149 01:15:59,600 --> 01:16:02,400 can kind of like, you know, hide a lot of that away. 1150 01:16:02,400 --> 01:16:05,300 Just so, you know, just like you mentioned you're trying to A lot 1151 01:16:05,300 --> 01:16:08,600 of the complexity away from the users anyway, so hopefully that, 1152 01:16:08,600 --> 01:16:12,400 that, that special drag chain can be hit at complex can also 1153 01:16:12,400 --> 01:16:13,900 be hidden away from users as well. 1154 01:16:13,900 --> 01:16:19,200 I wouldn't actually be sure that that a special side chain would 1155 01:16:19,200 --> 01:16:25,600 be more suited for for payment channels then then Bitcoin 1156 01:16:25,600 --> 01:16:30,500 itself simply because when the way I came up with or we came up 1157 01:16:30,500 --> 01:16:35,000 with L2, is by taking my taking a step back and looking at At 1158 01:16:35,008 --> 01:16:38,700 what, what sort of the minimal set of features that we need 1159 01:16:38,708 --> 01:16:44,700 from a blockchain to make to to create a block chain that is 1160 01:16:44,700 --> 01:16:48,000 purpose-built for payment channels and it turns out this 1161 01:16:48,000 --> 01:16:52,700 the difference between this idealized payment Channel 1162 01:16:52,700 --> 01:16:56,300 enabling blockchain and the currently deployed. 1163 01:16:56,300 --> 01:16:59,900 Bitcoin network is really just this one see cash. 1164 01:16:59,900 --> 01:17:04,800 So I'm not sure I could come up with a with a side. 1165 01:17:05,000 --> 01:17:08,400 In or drive chain, that is better suited for payment 1166 01:17:08,400 --> 01:17:11,400 channels than Bitcoin with C cash. 1167 01:17:11,400 --> 01:17:16,200 No input. For example, And this this sort 1168 01:17:16,200 --> 01:17:21,000 of convergence between between e, theorem where you actually 1169 01:17:21,000 --> 01:17:26,400 have all of the all of the flexibility and where you have, 1170 01:17:26,500 --> 01:17:31,900 where people have come up with Raiden and L2, which comes from 1171 01:17:31,900 --> 01:17:36,600 this, more constrained version of a blockchain where we don't 1172 01:17:36,600 --> 01:17:39,900 have all of this flexibility. And we still have very much the 1173 01:17:39,900 --> 01:17:44,400 same. The same result is is for me. 1174 01:17:44,600 --> 01:17:48,000 Very much approve of that. Yeah, this this is the 1175 01:17:48,000 --> 01:17:50,300 functionality. We need we don't need more. 1176 01:17:52,300 --> 01:17:58,200 So, let's wrap up and well, before we wrap up briefly, look 1177 01:17:58,200 --> 01:18:03,400 out a little bit. Now, I think currently, when 1178 01:18:03,400 --> 01:18:06,300 people were writing these sort of 2018 reviews, you know, 1179 01:18:06,300 --> 01:18:09,200 lightning was often coming up and say, okay, lightning is seen 1180 01:18:09,200 --> 01:18:10,900 a lot of. Well, then, you know, this 1181 01:18:10,900 --> 01:18:14,200 really progress, there's more momentum building and now you 1182 01:18:14,200 --> 01:18:16,700 have, you know, two million dollars or something like that, 1183 01:18:16,700 --> 01:18:19,700 there are held worth of Bitcoins are held in lightning channels. 1184 01:18:20,000 --> 01:18:23,300 So what's your You know, what's your expectation about? 1185 01:18:23,300 --> 01:18:27,700 Where will be a year from now? You know at the you know what 1186 01:18:27,700 --> 01:18:31,100 kind of will we see no real traction with people using 1187 01:18:31,100 --> 01:18:33,800 lightning for payment? Or what do you think is kind of 1188 01:18:33,800 --> 01:18:38,500 the timeline that lightning and option will take? 1189 01:18:39,500 --> 01:18:42,700 I should probably preface this by saying that I'm really bad at 1190 01:18:42,700 --> 01:18:48,300 making predictions. And I'm, I'm always I'm always 1191 01:18:48,300 --> 01:18:53,100 amazed about how quickly all of this has has materialized. 1192 01:18:53,100 --> 01:18:56,900 I would not have expected to have 20,000 channels and 600 1193 01:18:56,900 --> 01:18:58,800 Bitcoins in the lightning Network. 1194 01:18:58,800 --> 01:19:04,800 At this point, it's been a very frightening ride but also very 1195 01:19:05,300 --> 01:19:10,100 sort of self-affirming, right? Me so far. 1196 01:19:11,100 --> 01:19:15,200 And as for predictions, I would probably guess it's more of the 1197 01:19:15,200 --> 01:19:19,900 same. I'm hoping the network will 1198 01:19:19,900 --> 01:19:23,200 continue to grow at the current Pace. 1199 01:19:24,000 --> 01:19:29,900 It doesn't have to accelerate in my opinion and I would love to 1200 01:19:29,900 --> 01:19:34,900 see to see some, some real-world adoption with, with some games 1201 01:19:34,900 --> 01:19:39,100 coming out with some, with some Merchants accepting lightning. 1202 01:19:39,200 --> 01:19:44,400 Going with with some yeah. Just just give by a go back to 1203 01:19:44,400 --> 01:19:51,500 this, to this use of Bitcoin as a currency and sort of opening 1204 01:19:51,500 --> 01:19:55,600 up new use cases as we go along on the spec side. 1205 01:19:55,600 --> 01:19:57,800 I can I can probably speculate a bit more. 1206 01:19:58,400 --> 01:20:01,900 We have this, we have this 1.1 roadmap which we are currently 1207 01:20:01,900 --> 01:20:07,900 implementing and hopefully we will we will be able to to say 1208 01:20:07,900 --> 01:20:10,800 in the next year or so. At that we accomplished every 1209 01:20:10,800 --> 01:20:13,700 single point of that. And then that we now need a new 1210 01:20:13,700 --> 01:20:16,000 meeting to to fix the next roadmap. 1211 01:20:17,500 --> 01:20:22,800 But yeah, that's, that's probably all I can say when when 1212 01:20:22,800 --> 01:20:25,500 it comes to a predictions. I'm as I said, I'm not really 1213 01:20:25,500 --> 01:20:27,600 good at that. Cool. 1214 01:20:27,700 --> 01:20:30,500 Well and pasting. Thanks so much for coming on. 1215 01:20:30,500 --> 01:20:33,400 It was real pleasure to you know, catching up on Lightning. 1216 01:20:33,400 --> 01:20:35,100 I think it is. Certainly something that excites 1217 01:20:35,100 --> 01:20:39,300 me a lot to see how this is going to is going to play out 1218 01:20:39,700 --> 01:20:42,500 and yeah. So lets you know, let's keep 1219 01:20:42,500 --> 01:20:44,700 following it and I'm sure it's not the last episode about 1220 01:20:44,700 --> 01:20:48,100 lightning that we've done here. There's like so much, sure, no 1221 01:20:48,100 --> 01:20:53,600 problem, pleasure being here. Thank you for joining us on this 1222 01:20:53,600 --> 01:20:56,000 week's episode. We release new episodes every 1223 01:20:56,000 --> 01:20:57,900 week. You can find And subscribe to 1224 01:20:57,907 --> 01:21:01,700 the show on iTunes Spotify, YouTube SoundCloud or wherever 1225 01:21:01,700 --> 01:21:04,100 you listen to podcast. And if you have a Google home or 1226 01:21:04,100 --> 01:21:06,900 Alexa device, you can tell it to listen to the latest episode of 1227 01:21:06,907 --> 01:21:10,700 the epicenter podcast, go to epicenter dot TV /, subscribe 1228 01:21:10,700 --> 01:21:13,500 for a full list of places where you can watch and listen, while 1229 01:21:13,500 --> 01:21:15,800 you're there, be sure to sign up for the newsletter so you get 1230 01:21:15,800 --> 01:21:18,000 new episodes in your inbox as they're released. 1231 01:21:18,800 --> 01:21:21,200 If you want to interact with us, the guests or other podcast 1232 01:21:21,200 --> 01:21:24,000 listeners you Can follow us on Twitter and please leave us a 1233 01:21:24,000 --> 01:21:26,100 review on iTunes. It helps people find the show 1234 01:21:26,300 --> 01:21:29,500 and we're always happy to read them, but thanks so much and we 1235 01:21:29,500 --> 01:21:30,900 look forward to being back next week.