WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.400 --> 00:00:22.320 Live from Utrecht, this is Bitcoin. 00:00:23.120 --> 00:00:23.560 Explained. 00:00:23.820 --> 00:00:24.180 Hey, Sjors. 00:00:24.440 --> 00:00:24.640 Hello. 00:00:24.960 --> 00:00:25.280 Hey, Sam. 00:00:25.700 --> 00:00:26.040 Hello. 00:00:26.460 --> 00:00:27.460 We have another guest, Sjors. 00:00:27.640 --> 00:00:28.340 Hello, Sam. Welcome. 00:00:28.880 --> 00:00:29.180 Thank you. 00:00:29.320 --> 00:00:29.700 Wouters, 00:00:31.100 --> 00:00:31.540 who are you? 00:00:31.880 --> 00:00:34.860 I'm a Bitcoin research analyst at River Financial. 00:00:35.420 --> 00:00:36.960 All right. What is River Financial? 00:00:37.220 --> 00:00:42.500 It's a US-based Bitcoin-focused company. Offers brokerage. Offers like zero fee 00:00:42.500 --> 00:00:47.860 DCA. So no fees on recurring orders. And offers hosted mining services. And 00:00:47.860 --> 00:00:50.540 increasingly, we're starting to do more with the Lightning Network. We first 00:00:50.540 --> 00:00:55.780 integrated it in 2019. And now we're offering a new product around it as well. 00:00:56.020 --> 00:00:56.700 Around Lightning. 00:00:57.300 --> 00:01:01.060 All right. What are you doing here? Why are you in Sjors's living room with us now? 00:01:01.420 --> 00:01:05.860 Well, it's an honor to be here, I'd say. Yeah, recently released a report around 00:01:05.860 --> 00:01:08.920 our learnings from the Lightning Network, the insights that we gathered from 00:01:08.920 --> 00:01:13.660 running some of the highest capacity nodes in a network. And basically you 00:01:13.660 --> 00:01:16.620 reached out to me and you were like, well, it would be interesting to have a 00:01:16.620 --> 00:01:19.840 podcast about this. We talked briefly at Bitcoin Amsterdam about it, awesome 00:01:19.840 --> 00:01:22.300 conference. And yeah, we'd love to share more. 00:01:23.040 --> 00:01:26.260 All right. Sjors, what do you think? Sam's here now. Do you want to do it? 00:01:26.600 --> 00:01:26.980 Sounds good. 00:01:27.200 --> 00:01:28.660 Might as well discuss the report. 00:01:29.000 --> 00:01:29.380 Yep. 00:01:29.820 --> 00:01:35.400 First of all, though, we did an episode about the Lightning LND 00:01:35.400 --> 00:01:41.140 bug. So that was the last episode two weeks ago. And I think there is an update 00:01:41.140 --> 00:01:41.700 about that. 00:01:42.080 --> 00:01:42.300 Yes. 00:01:42.540 --> 00:01:47.860 So to start off, we kind of speculated in the episode itself what the exact 00:01:47.860 --> 00:01:52.160 cause was. And we mentioned that we weren't 100% sure. 00:01:52.380 --> 00:01:53.700 But we were 100% correct. 00:01:53.960 --> 00:01:55.140 We were not correct? 00:01:55.360 --> 00:01:56.000 No, we nailed it. 00:01:57.630 --> 00:01:59.150 Did you, Sjors? Did you nail it? 00:01:59.650 --> 00:02:04.270 Well, roughly. Anyway, we speculated on a few different possibilities. But yeah, 00:02:04.370 --> 00:02:07.730 it turns out that especially we were talking about what happens when you're not 00:02:07.730 --> 00:02:12.330 actually using btcd as a full node. You're just using Bitcoin Core as a full 00:02:12.330 --> 00:02:17.270 node, yet your Lightning node still stops and you're using LND as a Lightning 00:02:17.270 --> 00:02:22.210 node. And the reason that happens is because LND uses parts of btcd because btcd 00:02:22.210 --> 00:02:26.850 is not just a node, it's also a library of components that you can use. And so if 00:02:26.850 --> 00:02:30.430 you're using one of those components, even though you're not using btcd as your 00:02:30.430 --> 00:02:34.930 node, you still rely on how those components check certain rules about blocks 00:02:34.930 --> 00:02:38.550 that they should probably not check or at least should check correctly if they 00:02:38.550 --> 00:02:41.360 do. So those components broke. 00:02:42.240 --> 00:02:47.020 Right. So it's basically because LND was using code from btcd. 00:02:47.240 --> 00:02:47.520 Yeah. 00:02:47.840 --> 00:02:52.960 Okay. Got it. That's clear enough. But there's been another bug this week. 00:02:53.160 --> 00:02:53.420 Yes. 00:02:53.980 --> 00:02:56.120 LND nodes crashed again. Is that right? 00:02:56.360 --> 00:03:00.300 Yes. As the song by Britney Spears goes, oops, I did it again. The same person 00:03:00.300 --> 00:03:05.360 crafted another special transaction, put it in a Bitcoin block and voila, all the 00:03:05.360 --> 00:03:09.500 LND nodes crashed. Now, in this case, there are a few differences. I mean, in 00:03:09.500 --> 00:03:13.890 general, it was the same kind of bug. It was like a Bitcoin transaction that was 00:03:13.890 --> 00:03:18.850 perfectly valid, though a bit weird, and in such a way that Bitcoin Core nodes 00:03:18.850 --> 00:03:23.310 would be perfectly happy with it. But, [unclear], the btcd-based nodes or 00:03:23.310 --> 00:03:27.150 libraries that use btcd code would not be happy with it and would stop, 00:03:27.490 --> 00:03:28.090 basically. 00:03:28.920 --> 00:03:34.740 Right well so last time the reason was that there was a limit on the witness size 00:03:34.740 --> 00:03:39.340 of SegWit transactions and then the Taproot transactions don't have that limit 00:03:39.340 --> 00:03:44.260 but for the blocks that that come in People should listen to the last episode, 00:03:44.400 --> 00:03:48.260 but I'm getting to the point where my question is, so was it exactly the same? 00:03:48.380 --> 00:03:49.240 Wasn't the bug fixed? 00:03:49.480 --> 00:03:54.000 Yeah, that specific bug was fixed, but it was another difference in 00:03:54.000 --> 00:03:57.820 interpretation out there, which had to do with another limit that was slightly 00:03:57.820 --> 00:03:59.240 different in LND. 00:03:59.750 --> 00:04:03.530 I see. So it was a very similar bug, but not the same bug. 00:04:03.790 --> 00:04:05.670 The same kind of bug, but it was a different one. 00:04:05.790 --> 00:04:11.730 Okay, but the last time LND nodes crashed, it was an accident, I think, right? 00:04:11.870 --> 00:04:15.610 It could have been an accident. We don't know. The second time was definitely not 00:04:15.610 --> 00:04:16.110 an accident. 00:04:16.390 --> 00:04:19.930 This time was not an accident. So this time this developer, and I think his name 00:04:19.930 --> 00:04:22.510 was Burak, if I'm remembering that correctly. 00:04:23.770 --> 00:04:27.610 And I actually I'm sure I remember that correctly because you told me five 00:04:27.610 --> 00:04:32.390 minutes ago my memory isn't that bad he did it presumably by accident last time 00:04:32.390 --> 00:04:38.050 so this time he did it intentionally he was looking for bugs and he 00:04:38.050 --> 00:04:38.850 exploited that. 00:04:38.850 --> 00:04:43.370 Well the transaction has a message in the OP_RETURN that says something along the 00:04:43.370 --> 00:04:48.470 lines of haha you should be using C-Lightning so it was you know very clearly an 00:04:48.470 --> 00:04:52.950 attempt to to cause a problem there which is not very nice but it can happen. 00:04:53.960 --> 00:04:59.940 Right. So have you guys have had any problem with this? Did this 00:04:59.940 --> 00:05:00.620 affect you at all? 00:05:01.340 --> 00:05:06.140 Well, we run multiple nodes and I believe the developers were immediately on top 00:05:06.140 --> 00:05:10.040 of it. And I think like upgraded the nodes, made sure that there were no issues. 00:05:10.160 --> 00:05:14.800 And I believe there was no downtime on the API that we have either. So altogether 00:05:14.800 --> 00:05:19.060 it was, it went pretty smooth. So fortunately not too many issues, but could have 00:05:19.060 --> 00:05:20.000 been worse for sure. 00:05:20.470 --> 00:05:25.450 Yeah that sounds lucky because it would have it did stop a lot of nodes yes. 00:05:25.960 --> 00:05:30.260 So hang on though but so this bug was also fixed by now within a couple of hours 00:05:30.260 --> 00:05:30.920 it sounds like? 00:05:30.920 --> 00:05:32.080 I believe it was pretty quick. 00:05:32.080 --> 00:05:35.660 Yeah and then it was basically fixed before it affected you? 00:05:35.660 --> 00:05:36.480 Believe so yeah. 00:05:36.480 --> 00:05:40.320 Okay so but that does obviously mean you need to pay attention? 00:05:40.320 --> 00:05:41.780 Yes yeah for sure. 00:05:41.780 --> 00:05:45.830 Yeah Okay, I think that's also the type of stuff we're going to discuss in this episode. 00:05:45.870 --> 00:05:49.850 Yeah, and I guess the failure could depend on exactly the details of your setup, 00:05:49.890 --> 00:05:54.750 which I don't think you know in that much detail, but... I think it would stop 00:05:54.750 --> 00:05:59.730 processing new blocks, but if the channels are still there, those channels might 00:05:59.730 --> 00:06:03.510 keep working. So that's maybe why it didn't go down, something like that. There's 00:06:03.510 --> 00:06:05.970 a couple of other details about this exploit that might be worth mentioning 00:06:05.970 --> 00:06:11.270 before we move on. One of them is that this transaction was a so-called non 00:06:11.270 --> 00:06:15.730 -standard transaction. And that means that it is a weird transaction that is 00:06:15.730 --> 00:06:20.590 valid, but nodes will not relay it by default. So if you see this transaction in 00:06:20.590 --> 00:06:24.350 your mempool, you will not send it to your neighbors. Which begs the question of 00:06:24.350 --> 00:06:29.340 how did this transaction ever find a miner? And this mechanism is mostly a safety 00:06:29.340 --> 00:06:31.760 mechanism to prevent you from accidentally throwing away your money. 00:06:31.900 --> 00:06:36.620 Not only how does it find a miner, but even why would a miner itself include it then, right? 00:06:36.920 --> 00:06:40.500 Yeah, because miner software would, again, generally not include those things 00:06:40.500 --> 00:06:44.540 because it has to do with some safety mechanisms for soft forks that if you don't 00:06:44.540 --> 00:06:48.040 include non-standard transactions, that's a double negative, but if you don't 00:06:48.040 --> 00:06:52.770 include non-standard transactions... then you will probably not get screwed at 00:06:52.770 --> 00:06:56.790 the next soft fork if the rules change. That's the way. We've talked about that 00:06:56.790 --> 00:07:00.510 in some other episodes. We'll skip that now. But basically, so the way he got it 00:07:00.510 --> 00:07:05.070 in there was just emailing this pool and just asking them to please include it. 00:07:05.150 --> 00:07:08.350 And it included a nice $750 transaction fee. 00:07:09.680 --> 00:07:10.040 Interesting. 00:07:10.340 --> 00:07:14.440 Now, it was a very, very large transaction. I think it was half a megabyte. So 00:07:14.440 --> 00:07:18.380 this was 26 Satoshi per byte, which is a high fee, but not an absurd fee rate. 00:07:18.680 --> 00:07:22.480 But the total fee was pretty high. So yeah, that's how it got included. And once 00:07:22.480 --> 00:07:24.940 it's in a block, nodes will simply accept it. 00:07:27.050 --> 00:07:31.990 All right. I don't want to dwell on the topic, but I guess now my... curiosity 00:07:31.990 --> 00:07:36.430 has been sparked like what what's the incentive for Burak to even do this I I 00:07:36.430 --> 00:07:41.630 mean I know there is this sort of controversy about LND maybe being too dominant 00:07:41.630 --> 00:07:43.510 on the network is that why? 00:07:43.510 --> 00:07:48.330 I don't know there could be my guess would be without having spent too much time 00:07:48.330 --> 00:07:52.470 it's like there's two ways you can deal with security issues when you when you 00:07:52.470 --> 00:07:58.020 see a product that you think is not secure you can contact the developers of that 00:07:58.020 --> 00:08:03.740 product and disclose carefully what the bugs are and be very, very patient. So it 00:08:03.740 --> 00:08:08.060 could take months for them to address it. Or you can go out and simply break 00:08:08.060 --> 00:08:11.760 their product in public and create sort of a warning signal to the general 00:08:11.760 --> 00:08:15.420 public. Now, that last thing could be warranted under some really extreme 00:08:15.420 --> 00:08:18.700 circumstances, but I think this was too early for that. But it may have been 00:08:18.700 --> 00:08:21.940 something like that, like telling the world, like, hey, be careful. Lightning is 00:08:21.940 --> 00:08:26.250 not as mature as you think it is. Things can still break. I don't think it's the 00:08:26.250 --> 00:08:31.010 right way to do it, so responsible disclosure would require you to do these things. 00:08:32.410 --> 00:08:36.810 Contact developers directly be very very patient about stuff and then even if you 00:08:36.810 --> 00:08:39.850 did want to do a public demonstration of the vulnerability I would say do it on 00:08:39.850 --> 00:08:43.530 testnet so that you know you can show that you have this thing that can crash 00:08:43.530 --> 00:08:46.910 nodes but it only crashes test nodes and not real nodes. 00:08:46.910 --> 00:08:51.970 Okay I'm gonna move over move on to the report very soon but first of all because 00:08:51.970 --> 00:08:55.690 I don't think this is in the report but now that I mentioned it Sam do you have 00:08:55.690 --> 00:09:00.430 any insights about which types of nodes are used on the Lightning network? 00:09:01.470 --> 00:09:05.740 At all? It is mostly LND, for example, right? 00:09:06.000 --> 00:09:09.340 I think largely, yeah. It's a very popular one, indeed. 00:09:09.740 --> 00:09:10.960 Yeah, but you don't have any... 00:09:10.960 --> 00:09:12.220 No, I don't have any statistics. 00:09:12.220 --> 00:09:13.500 There wouldn't even be any statistics. 00:09:13.500 --> 00:09:14.140 Exactly, yeah. 00:09:14.280 --> 00:09:15.240 I guess, I would assume. 00:09:15.460 --> 00:09:19.220 Well, my guess is you could figure it out, but I've looked at mempool.space. They 00:09:19.220 --> 00:09:22.540 have a new Lightning Explorer, and they don't show the node type. So I guess 00:09:22.540 --> 00:09:26.280 you'd have to pay attention to some subtle behaviors to guess whether somebody 00:09:26.280 --> 00:09:29.760 has a C-Lightning node or an LND node or an Eclair node. 00:09:30.640 --> 00:09:31.040 Yeah. 00:09:31.890 --> 00:09:36.250 Okay but also I do know that most of the mobile wallets are based on LND 00:09:37.820 --> 00:09:42.580 yes and that's probably the majority of nodes but not maybe not the majority of 00:09:42.580 --> 00:09:43.180 visible nodes. 00:09:44.460 --> 00:09:50.400 Anyway anyways okay moving on Sam, your report it's called 00:09:50.400 --> 00:09:55.240 insights from the fourth largest Lightning network node yes and I think you 00:09:55.240 --> 00:09:57.280 briefly mentioned it already but let's 00:09:59.490 --> 00:10:04.850 start again by why did you write this report why does this report exist yeah what 00:10:04.850 --> 00:10:05.870 is it and why does it exist. 00:10:05.870 --> 00:10:10.870 Yeah so the report's focus is to share data and essentially as the title says 00:10:10.870 --> 00:10:15.630 share insights about what we've learned from the Lightning network and When we 00:10:15.630 --> 00:10:19.150 initially had a look at sort of where things were at when I joined the company 00:10:19.150 --> 00:10:23.310 earlier this year, Lightning was starting to pick up quite significantly in terms 00:10:23.310 --> 00:10:25.390 of activity as we could see in the data. 00:10:26.790 --> 00:10:30.290 We have a team of four Lightning developers and I just saw them sharing things in 00:10:30.290 --> 00:10:35.210 Slack. And being enthusiastic about the progress. And I figured like, I haven't 00:10:35.210 --> 00:10:39.170 really seen anything like this out there too much. So we started discussing like, 00:10:39.230 --> 00:10:42.610 hey, could we, you know, like share some of these insights with people? And there 00:10:42.610 --> 00:10:46.550 are people who have been sharing data, which is great, but not much from larger 00:10:46.550 --> 00:10:51.230 nodes or bigger companies, anything like that. So we figured, what if we make a 00:10:51.230 --> 00:10:56.380 report and share what... we think people might be interested in as a first pass 00:10:56.380 --> 00:11:00.580 sort of to see what is the interest from the industry what is the interest from 00:11:00.580 --> 00:11:03.740 the market where do they think it might be interesting to learn more about 00:11:03.740 --> 00:11:07.800 Lightning and the way we operate it or the way they could operate it and then 00:11:07.800 --> 00:11:10.660 potentially repeat the report in the future with some learnings with more 00:11:10.660 --> 00:11:14.740 insights but the focus was very much on data sharing because it's very difficult 00:11:14.740 --> 00:11:19.660 for I believe anyway for people to work on this kind of system and to improve it 00:11:19.660 --> 00:11:24.550 if they don't really have a lot of statistics about Like, you know, why payments 00:11:24.550 --> 00:11:28.850 are failing to give an obvious thing of how users are actually experiencing the 00:11:28.850 --> 00:11:32.210 Lightning Network. You have to do a lot of in-person conversations with people, I 00:11:32.210 --> 00:11:36.150 guess, a lot of qualitative research. And that's quite time intensive if you're a 00:11:36.150 --> 00:11:40.130 developer who wants to, you know, build systems. You're not necessarily a 00:11:40.130 --> 00:11:42.430 [unclear] market researcher. 00:11:42.690 --> 00:11:47.230 And you might be running a non-custodial service where you're not spying on your 00:11:47.230 --> 00:11:50.590 customers enough to see what problems they're running into. Or you might be, you 00:11:50.590 --> 00:11:53.490 know, building a node. And you don't even have a help desk. 00:11:53.890 --> 00:11:53.990 Yeah. 00:11:54.170 --> 00:11:54.730 So yeah. 00:11:55.150 --> 00:11:58.610 Yeah, definitely. So we were trying to figure out like what would be the best 00:11:58.610 --> 00:12:02.070 format to share this. The report is relatively brief. I believe it's about 20 00:12:02.070 --> 00:12:06.590 pages and lots of images and graphs in there to just make it accessible to 00:12:06.590 --> 00:12:10.750 people. So to River clients who might not all have necessarily used the Lightning 00:12:10.750 --> 00:12:14.750 Network before or really learned much about it. So it also keeps them in mind a 00:12:14.750 --> 00:12:18.570 little bit, makes it accessible for non-technical people. And yeah, the focus was 00:12:18.570 --> 00:12:21.630 sharing data. And what we're now already seeing is that other people are sort of 00:12:21.630 --> 00:12:25.350 jumping in, starting to share their insights too, based on some of the metrics 00:12:25.350 --> 00:12:28.830 that we shared. And it's starting to get a conversation going, which is really 00:12:28.830 --> 00:12:32.770 what we were hoping to see there. And hopefully this can help developers who want 00:12:32.770 --> 00:12:37.470 to improve Lightning to gather more data and insights so that they improve 00:12:37.470 --> 00:12:40.870 Lightning and essentially everyone benefits because it's definitely in our 00:12:40.870 --> 00:12:45.290 interest to see Lightning succeed. And we're trying to do what we can to help there. 00:12:45.710 --> 00:12:51.590 And to be very clear what you did specifically, this is the data from 00:12:51.590 --> 00:12:55.930 your own node. You didn't collect data from other nodes or users. This is just... 00:12:56.820 --> 00:13:00.860 You guys have one of the biggest nodes and this is your experience. That's what it is, right? 00:13:00.860 --> 00:13:04.620 Yeah, we actually have two nodes in the top 10 by capacity. So how much Bitcoin 00:13:04.620 --> 00:13:08.300 is on there. But initially, the second one was in the process of being built up. 00:13:08.420 --> 00:13:11.620 So it wasn't up there yet. But by the end, when I was done with the report, we 00:13:11.620 --> 00:13:16.000 also had number five or six, I believe, by capacity. The data is all from there. 00:13:16.200 --> 00:13:20.060 I would love to, in the future, start aggregating data for more providers. And 00:13:20.060 --> 00:13:22.840 I've seen some comments on Twitter of people being like, yeah, but this is just 00:13:22.840 --> 00:13:27.280 what operators are saying. How can we trust that? And it's like well you could 00:13:27.280 --> 00:13:30.860 you know you could lie about how many transactions you're processing and make all 00:13:30.860 --> 00:13:34.600 kinds of things up to make it look bigger than it is but eventually it's going to 00:13:34.600 --> 00:13:38.480 catch up with you if you pretend to do like 10 times the number of transactions 00:13:38.480 --> 00:13:42.140 that you're currently doing and everyone else shares their data and nobody gets 00:13:42.140 --> 00:13:46.990 close to what you're doing then It looks kind of dicey. So mostly I believe at 00:13:46.990 --> 00:13:50.230 the current stage of Lightning, people are very invested in seeing it succeed in 00:13:50.230 --> 00:13:54.350 the long run. So like you don't necessarily have to trust everything and you can 00:13:54.350 --> 00:13:59.390 put like 17 asterisks in the report saying like this is all like self-reported 00:13:59.390 --> 00:14:03.230 data from all of these users. But across this many users, these are the insights 00:14:03.230 --> 00:14:03.950 we can gather. 00:14:05.860 --> 00:14:11.080 Okay, so the way we're going to handle the report is we're not going to... 00:14:11.500 --> 00:14:17.020 deal with it page by page we're gonna select some subtopics that we've found of 00:14:17.020 --> 00:14:21.860 particular interest maybe in context of a more technical podcast so let's start 00:14:21.860 --> 00:14:24.780 with the most important question how much money are you making? 00:14:26.030 --> 00:14:27.450 Well, me personally? 00:14:28.050 --> 00:14:31.210 No, no, I'm not asking about your salary. I'm asking about the fees. 00:14:31.410 --> 00:14:36.890 I know it was a joke. Yeah, no. So the focus of the company isn't to make as much 00:14:36.890 --> 00:14:41.070 money as possible on Lightning. The focus is to help grow it. So currently the 00:14:41.070 --> 00:14:46.850 returns are about 1.15% per year. And in the report itself, I also compared this 00:14:46.850 --> 00:14:51.110 to some other users that have sort of shared their data. Some of them earn like 00:14:51.110 --> 00:14:55.730 5% to 10% per year which is already a pretty significant number but there's 00:14:55.730 --> 00:14:59.890 likely some kind of plateau in there where if you add more capacity to your node 00:14:59.890 --> 00:15:02.590 you're not going to be able to reach those numbers because there's not enough 00:15:02.590 --> 00:15:06.230 activity on the network for you to get those kind of returns with that much 00:15:06.230 --> 00:15:11.290 Bitcoin so there's a that's a little asterisk there so for River it's 1.15 at the 00:15:11.290 --> 00:15:15.810 moment but the focus is much more on reliability of the of the Lightning 00:15:15.810 --> 00:15:16.850 integration that we have 00:15:16.850 --> 00:15:17.890 Right yeah. 00:15:17.890 --> 00:15:20.870 I think one of the things you pointed out in the report was to say like companies 00:15:20.870 --> 00:15:25.700 can optimize for very different things so they could optimize for revenue but if 00:15:25.700 --> 00:15:29.960 they have clients they may want to and they make money from those clients in very 00:15:29.960 --> 00:15:32.920 different ways they want to make sure that the clients just have the best 00:15:32.920 --> 00:15:37.340 experience when they use Lightning even if that's not profitable at all so and 00:15:37.340 --> 00:15:40.560 that also I guess in the marketplace means that you're competing with people who 00:15:40.560 --> 00:15:45.900 do not optimize for profit so that means that fees might stay quite low but we'll 00:15:45.900 --> 00:15:47.820 have to see how that goes yeah. 00:15:49.200 --> 00:15:49.560 Definitely. 00:15:54.460 --> 00:16:00.320 What is the most work so to say, in operating a node? Is it 00:16:00.320 --> 00:16:04.000 managing liquidity? That would be my guess. That's sort of where most of the 00:16:04.000 --> 00:16:05.440 effort goes into. Is that right or no? 00:16:05.680 --> 00:16:09.580 Yeah, I think that's fair to say. As a node operator, I mentioned we have a team 00:16:09.580 --> 00:16:13.400 of four developers. They're not spending all day closing and opening channels and 00:16:13.400 --> 00:16:17.080 managing liquidity. That would be very extensive. They're very focused on 00:16:17.080 --> 00:16:22.760 building out the infrastructure that we are offering to other companies. So 00:16:22.760 --> 00:16:26.230 that's where the majority of the work goes. Managing liquidity as you mentioned 00:16:26.230 --> 00:16:29.730 and opening and closing channels that does take up some time especially if you 00:16:29.730 --> 00:16:34.050 want to have successful routes if you want high reliability so there's a bit of 00:16:34.050 --> 00:16:38.450 vetting involved there in sort of the nodes that you want to connect to because 00:16:38.450 --> 00:16:43.190 if you just connect to A random hobbyist that will send one transaction per month 00:16:43.190 --> 00:16:47.670 doesn't really have much liquidity, doesn't really put any effort into it. It's 00:16:47.670 --> 00:16:50.810 kind of difficult as a company to justify that because you're locking up capital 00:16:50.810 --> 00:16:54.770 in a very inefficient place with no track record. So there's a little bit of 00:16:54.770 --> 00:16:58.070 vetting. It's not very strict. And our CEO has also mentioned on Twitter, like 00:16:58.070 --> 00:17:01.990 we're looking into ways to make this a bit more flexible. So there is a whitelist 00:17:01.990 --> 00:17:05.530 at the moment. And only if you're on there, you can open and close channels. But 00:17:05.530 --> 00:17:09.940 it ensures that... there's a high reliability for transactions to get routed and 00:17:09.940 --> 00:17:13.880 that's ultimately what we want to focus on to get it reliable enough for 00:17:13.880 --> 00:17:17.700 companies to want to consider accepting Lightning as a payment for example. 00:17:17.700 --> 00:17:23.530 So how does the vetting work what are the factors you you 00:17:23.530 --> 00:17:25.010 weigh when it comes to vetting? 00:17:25.360 --> 00:17:28.980 Yeah for example some of the things I mentioned like how long has this node been 00:17:28.980 --> 00:17:32.440 there like is there some kind of track record how many connections do they have 00:17:32.440 --> 00:17:36.100 how much Bitcoin capacity do they have essentially is there some kind of minimum 00:17:36.100 --> 00:17:40.520 for the channel size it's not very large but it's not like you're opening and 00:17:40.520 --> 00:17:44.400 closing channels for just a few dollars because there are already like so many of 00:17:44.400 --> 00:17:49.020 those out there so I think those are some of the main reasons main things and I'm sure… 00:17:49.020 --> 00:17:53.460 Like how does this actually work is this is there someone sitting there looking 00:17:53.460 --> 00:17:58.120 at these things or is it automated and by the way I will notice right now so we 00:17:58.120 --> 00:18:02.600 had a discussion yesterday before we did a podcast where I mentioned [unclear] as 00:18:02.600 --> 00:18:05.840 well but for me it's definitely true I haven't been keeping up with Lightning 00:18:05.840 --> 00:18:10.900 very closely at all for the past couple of years like I see I'm somehow way more 00:18:10.900 --> 00:18:15.300 interested in Bitcoin base chain always have been so it's very possible that I'm 00:18:15.300 --> 00:18:18.600 asking very beginner questions just so the listeners know and you know. 00:18:18.850 --> 00:18:22.910 I don't pay super much attention to Lightning, but I do run my own node. But I 00:18:22.910 --> 00:18:27.610 don't pay much attention to the node either. I will open new channels if I make a 00:18:27.610 --> 00:18:31.190 payment and it doesn't go through. That's sort of a reminder to me, okay, I 00:18:31.190 --> 00:18:33.790 should probably open a channel there. Or if people complain that they can't buy 00:18:33.790 --> 00:18:36.210 my book. But other than that, yeah. 00:18:36.850 --> 00:18:39.830 So the question was is there actually someone sitting there looking at these 00:18:39.830 --> 00:18:41.670 things or is this some automated process? 00:18:41.670 --> 00:18:46.490 Yeah no it is a human process very much so because there's just like too many 00:18:46.490 --> 00:18:50.890 things to consider etc it's too early stage in the future I could potentially see 00:18:50.890 --> 00:18:54.170 it automated but that goes for for many of the processes they're currently 00:18:54.170 --> 00:18:57.750 manually doing it's it's just a matter of time before a lot of that will get 00:18:57.750 --> 00:19:01.450 automated and needs to be automated because if you know if companies want to run 00:19:01.450 --> 00:19:05.170 Lightning it's kind of unlikely that they'll want to have a full-time employee 00:19:05.170 --> 00:19:09.410 just sitting there managing channels and liquidity. It's just not realistic in 00:19:09.410 --> 00:19:14.110 many cases. So for your note there, like on Lightning knowledge, like I'm also 00:19:14.110 --> 00:19:18.610 not a developer. I'm not a technical person. So I do spend time looking at 00:19:18.610 --> 00:19:22.630 Lightning because... similar to Bitcoin like it gives off a lot of energy like 00:19:22.630 --> 00:19:25.150 Bitcoin in the early days it gives off a lot of energy there's a lot of people 00:19:25.150 --> 00:19:29.610 excited about it it's really interesting to learn more about so I try to keep up 00:19:29.610 --> 00:19:31.450 to date but I'm definitely no expert either. 00:19:31.450 --> 00:19:37.270 So if there if if it's currently such a manual process to manage liquidity 00:19:37.270 --> 00:19:42.290 for example does that mean in effect that how centralized is the network now is 00:19:42.290 --> 00:19:46.750 it really dominated by a few big players like River that actually have someone 00:19:46.750 --> 00:19:48.710 doing this because they can afford to do it? 00:19:49.580 --> 00:19:53.940 Well, if you take a look at some of these node operators that are sharing their 00:19:53.940 --> 00:19:59.080 data on Twitter publicly, I believe Goldsatz is a quite well-known one who just 00:19:59.080 --> 00:20:02.400 shares all of his strategies, all of his approaches. There's quite a lot of other 00:20:02.400 --> 00:20:06.860 Lightning enthusiasts like it who just share how they do things. And for them, 00:20:06.960 --> 00:20:10.600 since they're earning higher returns, they can also potentially actually be an 00:20:10.600 --> 00:20:15.220 income stream. But generally they mention like it's a couple hours per week work 00:20:15.220 --> 00:20:19.220 for his approach, for example, that gives a bit of an idea for people like how 00:20:19.220 --> 00:20:22.000 much work is this actually. But this is, of course, someone who is very 00:20:22.000 --> 00:20:24.980 experienced, really knows what they're doing. If you're not that kind of person, 00:20:24.980 --> 00:20:28.020 there's probably quite a learning curve. It will take you a while to get to that 00:20:28.020 --> 00:20:32.120 point. So then it's a significant time investment, which, yeah, of course, 00:20:32.260 --> 00:20:35.640 changes the entire picture for people. But to your question, like is it 00:20:35.640 --> 00:20:39.620 centralized at the moment? From everything I've seen, like all the data I've 00:20:39.620 --> 00:20:43.020 looked into, And there was also a really nice visualization that I added to the 00:20:43.020 --> 00:20:47.140 report from a Twitter user called PyMoment, which was a visualization of the 00:20:47.140 --> 00:20:50.820 Lightning Network. And you could see how essentially there's dozens and dozens of 00:20:50.820 --> 00:20:55.120 different routes that any given transaction could take, like through sort of the 00:20:55.120 --> 00:20:58.740 major nodes out there. And there will be many sub-routes that will be longer, 00:20:58.920 --> 00:21:02.700 that might be less reliable, etc. So in that regard, for the current size of the 00:21:02.700 --> 00:21:07.000 Lightning Network, I would say it looks pretty dang decentralized. It could be 00:21:07.000 --> 00:21:08.520 far more decentralized, of course. 00:21:09.720 --> 00:21:12.980 To sort of bootstrap the network from the ground up, it makes sense to have a 00:21:12.980 --> 00:21:17.560 very reliable experience for people so that they can enjoy the benefits of the 00:21:17.560 --> 00:21:21.120 network. And then as it grows bigger and bigger, I'm sure people will also become 00:21:21.120 --> 00:21:24.300 more vocal about centralization and that type of thing. 00:21:24.660 --> 00:21:30.260 Right. And I guess the other cost in managing liquidity, so we've just discussed 00:21:30.260 --> 00:21:34.580 the human cost. The other cost would be on-chain fees, I guess, because you have 00:21:34.580 --> 00:21:36.280 to open and close channels. Is that right? 00:21:36.560 --> 00:21:38.180 Yeah, for sure. And I think... 00:21:38.180 --> 00:21:43.000 Right now, surely that's very low. So that could change into the future. What are 00:21:43.000 --> 00:21:43.960 the expectations there? 00:21:44.220 --> 00:21:48.240 Yeah, for sure. Like, I mean, nobody knows how expensive it's going to get in 00:21:48.240 --> 00:21:50.640 what kind of timeframe. Yeah, he does. 00:21:50.960 --> 00:21:53.320 How expensive is it going to get 20 years from now? 00:21:53.820 --> 00:21:55.440 Less than 21 million Bitcoin. 00:21:55.720 --> 00:21:56.300 So disappointing. 00:21:58.430 --> 00:21:59.610 Okay, we have an estimate. 00:22:00.840 --> 00:22:00.960 Yeah. 00:22:01.240 --> 00:22:01.960 Sorry, Sam, go on. 00:22:02.080 --> 00:22:07.940 No, no problem. Think... like what it might be an issue for in the future if you 00:22:07.940 --> 00:22:11.380 want to get more people who set up routing nodes where they actually earn returns 00:22:11.380 --> 00:22:16.080 that's like that requires some technical skill it requires a lot of trial and 00:22:16.080 --> 00:22:19.940 error and setting up channels trying to find optimal routes where you can 00:22:19.940 --> 00:22:23.740 actually make some money so if you have to open and close a lot of channels to 00:22:23.740 --> 00:22:28.580 get to the optimal setup but transaction fees are quite high then you could have 00:22:28.580 --> 00:22:32.440 sort of a upfront cost that you would need to pay to actually get to that success 00:22:32.440 --> 00:22:35.910 point But in a way, I mentioned this in a report as well, it's not that 00:22:35.910 --> 00:22:39.230 dissimilar from someone who wants to build up a successful YouTube channel, for 00:22:39.230 --> 00:22:42.430 example. You need to invest in some equipment. You need to really put in a lot of 00:22:42.430 --> 00:22:48.190 time and effort to make really good videos. And by doing that, you invest a 00:22:48.190 --> 00:22:51.310 little bit in it, but it can then give you returns. So I actually see it quite 00:22:51.310 --> 00:22:55.850 similar to that where the best content creators, they don't talk into their 00:22:55.850 --> 00:23:00.330 iPhone. They have a proper microphone and some good lighting, etc. And that just 00:23:00.330 --> 00:23:03.990 makes a massive difference. So I see this play out in the future quite similar 00:23:03.990 --> 00:23:08.070 for Lightning. However, that argument goes only so far. You know, if transaction 00:23:08.070 --> 00:23:12.750 fees become hundreds of dollars, then it becomes pretty expensive to become a 00:23:12.750 --> 00:23:15.930 successful routing operator, a node operator. 00:23:16.210 --> 00:23:20.550 Well, it goes both ways, right? If transaction fees on-chain are $100, well, that 00:23:20.550 --> 00:23:26.230 implies that everybody who tries to use Bitcoin has to pay that $100. So that 00:23:26.230 --> 00:23:30.110 means a lot more people will try to use Lightning and they'll be happy to pay $20 00:23:30.110 --> 00:23:31.590 Lightning routing fees. 00:23:31.790 --> 00:23:35.510 Yeah, for sure. But what it changes essentially is that the upfront cost to 00:23:35.510 --> 00:23:39.410 become a successful routing node, that would rise, that would become potentially 00:23:39.410 --> 00:23:44.110 less accessible to someone who doesn't have a bit of a budget to invest in this. 00:23:44.290 --> 00:23:47.930 So that's the only thing. But is that a big threat to the decentralization of the 00:23:47.930 --> 00:23:48.370 network? 00:23:48.530 --> 00:23:53.370 But I'm not even sure about that, right? Because it's all about the money, the 00:23:53.370 --> 00:23:56.910 returns you're making. On the capital that you're investing. So if you're putting 00:23:56.910 --> 00:24:02.880 up $1,000 and you start making $300 a year, then it's actually better than 00:24:02.880 --> 00:24:07.220 it is now. So maybe those high fees just mean that you get more return on your 00:24:07.220 --> 00:24:11.220 investment and you don't have to be a big operator. You could be a small operator. 00:24:11.600 --> 00:24:13.700 Yeah, there's definitely many facets to it, I think. 00:24:15.990 --> 00:24:21.050 You mentioned, and again, well, maybe I should stop mentioning this myself. I was 00:24:21.050 --> 00:24:26.470 just going to say this might be a very beginning question again. But you said, so 00:24:26.470 --> 00:24:31.550 there's particular routes you could be on that would make more money than other 00:24:31.550 --> 00:24:37.370 routes. Would the way to figure that out be just trial and error? Sorry, 00:24:37.610 --> 00:24:42.070 trial and error. Just try it out and see what works? Or are there other ways to 00:24:42.070 --> 00:24:43.250 sort of figure it out beforehand? 00:24:43.730 --> 00:24:48.590 From my understanding so far that's how a lot of people do it so when I mentioned 00:24:48.590 --> 00:24:51.870 earlier that we're trying to share a lot of interesting data that people might be 00:24:51.870 --> 00:24:55.110 interested in the number one request is obviously from people like what are your 00:24:55.110 --> 00:24:58.670 most profitable routes but the tricky thing there when you share that publicly is 00:24:58.670 --> 00:25:04.060 you get all these people who copy the exact same setups And by doing that, the 00:25:04.060 --> 00:25:07.100 profit for everyone declines and ultimately everyone's disappointed because some 00:25:07.100 --> 00:25:10.400