WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.430 --> 00:00:24.950 Live from Zurich, this is Bitcoin Explained, formerly known as the Van Wirdum 00:00:24.950 --> 00:00:30.450 Sjorsnado. And we have with us today, no Aaron, but we have Rene Pickhardt. 00:00:31.390 --> 00:00:32.290 Hello, nice meeting you. 00:00:32.510 --> 00:00:33.210 Nice to meet you too. 00:00:33.510 --> 00:00:34.210 Thanks for having me. 00:00:34.770 --> 00:00:39.990 You're welcome. So we were chatting yesterday about something you're working on. 00:00:40.620 --> 00:00:44.300 You mean optimally and reliable payment flows on the Lightning Network. 00:00:44.620 --> 00:00:45.800 That is right, yes. 00:00:47.820 --> 00:00:53.320 Yeah, tell me about it. I guess that would be one way to get started. I mean, 00:00:53.500 --> 00:00:57.140 maybe we can do a little bit of background. We've talked about Lightning before 00:00:57.140 --> 00:01:01.800 on the podcast. We've talked a little bit even about routing. So how to get a 00:01:01.800 --> 00:01:07.610 payment from A to B with Joost Jager. And you're working at 00:01:07.610 --> 00:01:10.790 kind of a different approach of doing it, I would say. 00:01:11.350 --> 00:01:17.050 Yeah, you could say so. So in general, if you look at the Lightning Network, you 00:01:17.050 --> 00:01:17.810 have the... 00:01:19.130 --> 00:01:24.730 design principle that you don't know how much liquidity a different node has. So 00:01:24.730 --> 00:01:30.290 if you want to send a payment from A to B, what will happen is you select some 00:01:30.290 --> 00:01:36.210 route through the network, you send out an onion, And at some node, the Onion 00:01:36.210 --> 00:01:39.750 arrives and they might not be able to forward the Onion because they just don't 00:01:39.750 --> 00:01:43.110 have enough liquidity. But you don't know as a sender, you don't know this ahead 00:01:43.110 --> 00:01:43.530 of time. 00:01:43.850 --> 00:01:47.590 Yeah, so maybe we should go a little bit back to the basics of what we just said. 00:01:47.990 --> 00:01:53.970 So every Lightning channel has a certain amount of Bitcoin in it. But the only 00:01:53.970 --> 00:01:58.730 thing that's publicly announced by Nodes is how much... there is in the channel 00:01:58.730 --> 00:02:03.070 in total, but it's like a little abacus, right? Where some of the beads are on 00:02:03.070 --> 00:02:05.790 one side of the channel and some of the coins are on the other side of the 00:02:05.790 --> 00:02:10.270 channel. And what is not communicated publicly is how much coin is on each side 00:02:10.270 --> 00:02:13.990 of the channel for two reasons. One, it's just too much noise to keep updating 00:02:13.990 --> 00:02:18.450 that. And the other is it's just bad for privacy because then somebody looking at 00:02:18.450 --> 00:02:22.350 the network could say, oh, I just saw 20 Satoshi move from that channel to that 00:02:22.350 --> 00:02:26.510 channel to that channel. So in order to prevent that, it's all hidden. But it 00:02:26.510 --> 00:02:30.090 means that when you're trying to send a payment, you don't really know if it's 00:02:30.090 --> 00:02:35.970 going to fit. Because for all the channels on the route 00:02:35.970 --> 00:02:38.550 that you picked, you don't know where these points are. 00:02:38.750 --> 00:02:39.150 Exactly. 00:02:39.810 --> 00:02:43.650 Like what the available balance is. So you kind of have to guess. You have to 00:02:43.650 --> 00:02:47.550 say, well, I'm going to guess it's about 50-50. Half the coins on one side, half 00:02:47.550 --> 00:02:48.430 the coins on the other side. 00:02:49.870 --> 00:02:51.010 And so that's a problem. 00:02:51.550 --> 00:02:54.290 Yeah, that's certainly a strategy you could do. 00:02:55.940 --> 00:03:00.480 But what this means in general is that the Lightning Network as a payment system 00:03:00.480 --> 00:03:06.350 is unreliable. You can't be sure that if you try to 00:03:06.350 --> 00:03:11.610 make a payment that it will arrive for certain. There's a certain chance that the 00:03:11.610 --> 00:03:15.990 payment will fail. So I was for the last two years basically looking at these 00:03:15.990 --> 00:03:19.630 problems and studying the reliability of the Lightning Network or the reliability 00:03:19.630 --> 00:03:23.710 of the payment process. And if you look into the scientific literature, you 00:03:23.710 --> 00:03:28.560 actually find a lot of papers that... already observed that it's unreliable. They 00:03:28.560 --> 00:03:32.840 all talk about success probabilities, right? So what they do is they make 00:03:32.840 --> 00:03:37.380 payments of certain sizes and they realize the smaller a payment is, the more 00:03:37.380 --> 00:03:41.800 likely it is to go through, which intuitively is very... clear right because 00:03:41.800 --> 00:03:44.740 and this is literature about lightning or yeah scientific 00:03:44.740 --> 00:03:47.600 literature where they study payment channel networks the lightning network in 00:03:47.600 --> 00:03:48.820 particular these things right 00:03:48.820 --> 00:03:51.720 well it's good to know that there actually is scientific literature nowadays 00:03:51.720 --> 00:03:52.700 covering yeah 00:03:52.700 --> 00:03:58.600 there's actually a lot um if there wasn't the um covid pandemic i was actually 00:03:58.600 --> 00:04:03.180 planning to do a scientific workshop and invite people from various fields to 00:04:03.180 --> 00:04:07.060 come together so that we could actually form as a scientific community because 00:04:07.060 --> 00:04:12.460 there's actually a lot of research going on But right now it's basically going 00:04:12.460 --> 00:04:15.840 into different fields and people don't really talk to each other. I mean, they 00:04:15.840 --> 00:04:20.080 cite each other and probably they know each other. But from a pure academic 00:04:20.080 --> 00:04:25.500 perspective, there is not that much. community building happened yet. And I think 00:04:25.500 --> 00:04:29.260 we are at the point where this actually really needs to happen. But since the 00:04:29.260 --> 00:04:32.560 pandemic was there, I didn't organize the workshop. But it's coming, hopefully. 00:04:32.780 --> 00:04:34.480 It's a slight delay. This is a multi-decade project. 00:04:34.620 --> 00:04:38.600 A slight delay, yes. So, yeah, but if you look into the literature, they all 00:04:38.600 --> 00:04:42.800 describe the phenomenon. And as I just said, a smaller payment has a higher 00:04:42.800 --> 00:04:46.480 chance to go through, which intuitively is very clear, right? Because you use 00:04:46.480 --> 00:04:50.540 this Abacus model, right, where you have a certain number of beads to be on one 00:04:50.540 --> 00:04:55.860 side. Well, let's say I can make a payment of, say, 100,000 satoshis, but it's 00:04:55.860 --> 00:04:59.640 very clear that I can also make the payment, or could have also made a payment of 00:04:59.640 --> 00:05:03.560 90,000 satoshis. It's not clear that I could have made a payment of 110,000 00:05:03.560 --> 00:05:07.400 satoshis, right? Because on that side of the abacus, there might have been only 00:05:07.400 --> 00:05:10.440 just 105,000 beads, right? So in that case, it doesn't work. 00:05:11.860 --> 00:05:17.240 So these things were well known in the literature, but... I was basically the 00:05:17.240 --> 00:05:21.240 first person who turned this around and said, you know what, if you want to 00:05:21.240 --> 00:05:26.360 select a path, why don't you start with the success probability of a payment and 00:05:26.360 --> 00:05:31.080 you try to find the path that has the highest success probability for you to 00:05:31.080 --> 00:05:35.500 deliver the payment. So you basically compute a probability for every channel in 00:05:35.500 --> 00:05:38.900 the network and assume how likely is it that I can send this amount in this 00:05:38.900 --> 00:05:39.340 direction. 00:05:39.740 --> 00:05:43.640 Right. And this likeliness is just, oh, how would you do that? 00:05:44.100 --> 00:05:48.420 Oh, so it basically depends on the amount that you want to send and the capacity 00:05:48.420 --> 00:05:53.320 of the channel. I mean, there is obviously, if you're a mathematician, an 00:05:53.320 --> 00:05:59.040 infinite amount of ways to derive a probability. But we just use a very 00:05:59.040 --> 00:06:04.440 simple model of basically saying we assume every distribution 00:06:04.440 --> 00:06:09.380 has the same likelihood. So this would mean that 00:06:09.380 --> 00:06:11.310 if you want to... 00:06:12.920 --> 00:06:15.360 If you want to send one Satoshi, 00:06:17.190 --> 00:06:17.730 the likelihood... 00:06:18.370 --> 00:06:22.570 I think the way you explained it yesterday, if I remember correctly, is you don't 00:06:22.570 --> 00:06:25.390 know how much is in there. Could be one Satoshi, could be 10 Satoshi, right? If 00:06:25.390 --> 00:06:29.410 the channel capacity is 10. So you're going to say it's equal odds. So it could 00:06:29.410 --> 00:06:32.630 be one Satoshi, could be 10 Satoshi. We're going to say these odds are all the same. 00:06:32.750 --> 00:06:34.070 Yes, it's like rolling a dice. 00:06:34.270 --> 00:06:39.250 Exactly. And therefore, if you wanted to guess, you have a probability density 00:06:39.250 --> 00:06:41.050 function, I guess is what you described it. 00:06:41.470 --> 00:06:47.070 So what this means is the larger a channel is, the higher the chance is to get 00:06:47.070 --> 00:06:51.410 your payment through, right? So in that sense, larger channels have a higher 00:06:51.410 --> 00:06:54.950 chance to provide the liquidity that you need for a certain amount. Right. They 00:06:54.950 --> 00:06:55.950 become very attractive. 00:06:56.840 --> 00:07:01.880 Okay. And then I guess you extrapolate this observation to… 00:07:02.960 --> 00:07:04.180 To multiple channels? 00:07:04.560 --> 00:07:10.100 Yes, so I do this for every channel in particular, right? And then I can 00:07:10.100 --> 00:07:14.920 basically solve the shortest path problem the same way how nodes currently do 00:07:14.920 --> 00:07:19.930 this. But currently nodes try to optimize for the total fees that they pay. But 00:07:19.930 --> 00:07:24.430 what I said is, hey, we could optimize for the likelihood, right? So you find the 00:07:24.430 --> 00:07:27.910 path that is actually the most likely path. So taking all those probabilities 00:07:27.910 --> 00:07:33.390 into consideration. So yeah, we published that in March this year. And I had the 00:07:33.390 --> 00:07:38.110 feeling, even though we did some simulations and provided some strong evidence 00:07:38.110 --> 00:07:43.150 that pathfinding is getting much better. people didn't really pick this up too heavily. 00:07:43.690 --> 00:07:45.770 They didn't pay attention to your publication? 00:07:46.410 --> 00:07:50.670 Well, I shared it on the lightning dev mailing list and I got one reply which was 00:07:50.670 --> 00:07:55.070 basically a clarification question. But I didn't see implementations picking it 00:07:55.070 --> 00:07:55.790 up too heavily. 00:07:57.330 --> 00:08:01.110 And there was an open question in the paper and also in the mailing list post 00:08:01.110 --> 00:08:06.730 where I said there's actually a question to be answered, which is how do we 00:08:06.730 --> 00:08:11.450 actually want to split payments, right? Because if you look at this probabilistic 00:08:11.450 --> 00:08:17.340 view, what you see is if the… As we just discussed, 00:08:17.500 --> 00:08:20.680 if the amount gets smaller, the payment is more likely. But the other thing that 00:08:20.680 --> 00:08:25.340 you see is the more channels you involve into a payment, your likelihood also 00:08:25.340 --> 00:08:27.900 decreases and it decreases exponentially. 00:08:28.280 --> 00:08:29.800 Your likelihood of success. 00:08:29.980 --> 00:08:31.160 Your likelihood of success, yes. 00:08:32.650 --> 00:08:36.510 Well, and that's not because of the capacity. That's because of the reliability, right? 00:08:36.930 --> 00:08:40.250 Yeah, that's because of the reliability. That's because, I mean, every time you 00:08:40.250 --> 00:08:44.450 have a certain success probability for every channel, and in order for the entire 00:08:44.450 --> 00:08:48.310 payment to be successful, it has to be successful at every channel. And this just 00:08:48.310 --> 00:08:50.770 means that you multiply all these probabilities together. 00:08:51.090 --> 00:08:55.550 Right. Okay, so we're still talking about the probability of it fitting, 00:08:55.890 --> 00:09:00.390 basically. So if you have decided to, you know, you can send a payment through... 00:09:00.950 --> 00:09:05.890 a single line of hops essentially yeah or you can split it up as a multi it's 00:09:05.890 --> 00:09:10.390 called multi-path um through multiple routes to the final destination you split 00:09:10.390 --> 00:09:14.270 the amount between them but the trade-off there is the more channels that are 00:09:14.270 --> 00:09:18.410 involved the more likely it is that one of those will not have the capacity that 00:09:18.410 --> 00:09:22.110 you thought it would have that is that is the sort of the easy form of failure 00:09:22.110 --> 00:09:28.090 so so so the observation is So if you send the payment across one line, you have 00:09:28.090 --> 00:09:32.190 a certain success probability for the entire payment to arrive. If you split it 00:09:32.190 --> 00:09:36.750 into, let's say, two paths, well, each of these paths probably has a higher 00:09:36.750 --> 00:09:41.130 success probability. But the probability for both of those paths to be likely 00:09:41.130 --> 00:09:46.010 might be lower than actually just sending this payment across one line. So there 00:09:46.010 --> 00:09:49.970 was this question of... How do I split and when do I split? So in this original 00:09:49.970 --> 00:09:53.550 paper, we already tackled this, but we assumed that we split the payment into 00:09:53.550 --> 00:09:58.330 equal amounts. And we could actually provide a formula in saying, look, if the 00:09:58.330 --> 00:10:02.870 payment has a certain size, you want to start splitting the payment. But we 00:10:02.870 --> 00:10:05.930 already knew from looking at the graph, it doesn't make sense to split the 00:10:05.930 --> 00:10:10.690 payment in equal size chunks. And if you, again, look at current implementations, 00:10:10.910 --> 00:10:14.410 they try to send the payment. And if they discover it's too large, if it fails, 00:10:14.550 --> 00:10:18.210 they start splitting it, but they just split it into two halves or they split it 00:10:18.210 --> 00:10:23.710 in more chunks, but equal size, right? So this is kind of like... 00:10:24.300 --> 00:10:25.480 obviously non-optimal. 00:10:25.660 --> 00:10:27.320 That is something that I observed, yes. 00:10:27.460 --> 00:10:32.860 Oh yeah, it could potentially be better anyway. So I guess the... Yeah, 00:10:33.080 --> 00:10:35.840 there's two questions that you want to answer, right? Should you split the 00:10:35.840 --> 00:10:38.820 payment at all? And if you split it, how should you split it? And it's not 00:10:38.820 --> 00:10:44.760 obvious that the naive solution of just try to do it in one go unless it fits and 00:10:44.760 --> 00:10:48.680 then otherwise splitting it equally, that's not necessarily the best solution. 00:10:48.920 --> 00:10:50.890 Yeah. Yeah, exactly. 00:10:51.090 --> 00:10:53.470 So you proceeded with that in your research? 00:10:53.650 --> 00:10:58.190 Yeah, so I actually started looking into this question more thoroughly in January 00:10:58.190 --> 00:11:02.950 this year. And while publishing the other paper, I started talking more and more 00:11:02.950 --> 00:11:05.150 with Stefan Richter, who is also from Germany. 00:11:06.540 --> 00:11:10.620 And he was actually listening very carefully. And at some point in time, he was 00:11:10.620 --> 00:11:15.160 basically pointing out, Rene, you are reinventing the wheel. The problem that 00:11:15.160 --> 00:11:18.660 you're solving is a min-cost flow problem. Here's the literature. Look into this. 00:11:18.780 --> 00:11:20.420 Solutions are actually well known to this. 00:11:20.700 --> 00:11:22.340 Whose problem? 00:11:23.190 --> 00:11:24.750 It's a min-cost flow problem. 00:11:24.890 --> 00:11:27.990 Oh, a min-cost flow. Yeah, I thought that was a Russian, like a min-cost flow. 00:11:28.130 --> 00:11:33.950 No, sorry. Okay, minimum cost flow. So basically, you have a flow of funds from A to B. 00:11:34.070 --> 00:11:34.330 Yes. 00:11:34.630 --> 00:11:37.170 And there's a certain cost associated with that. 00:11:37.730 --> 00:11:39.810 To transport the funds at every edge, yes. 00:11:39.990 --> 00:11:44.090 Yeah, and this cost could be, I guess, what is that in Lightning? Satoshis, right? 00:11:44.310 --> 00:11:49.490 Yeah, so the cost could be, for example, the fees that you have to pay to use a 00:11:49.490 --> 00:11:53.790 channel. which is very natural because you also want to have a cheap payment. But 00:11:53.790 --> 00:11:57.170 you could also translate the probability into a cost and you could just optimize 00:11:57.170 --> 00:12:01.630 for the probability. So what we're basically saying is just in general, if you 00:12:01.630 --> 00:12:05.590 want to make a payment, it's actually a transportation problem. Many people talk, 00:12:05.730 --> 00:12:09.090 when they talk routing, they talk about pathfinding problems. But what we are 00:12:09.090 --> 00:12:13.110 saying, it's a transportation problem. We have a certain supply of Satoshis. 00:12:13.270 --> 00:12:17.110 That's me, the sender. If I want to send them to you, it's yours. You have a 00:12:17.110 --> 00:12:20.470 demand for them. You issued an invoice, right? So now there's the question, can I 00:12:20.470 --> 00:12:24.630 transport those Satoshis through the network, right? And this is an extremely 00:12:24.630 --> 00:12:29.930 well-studied problem from logistics for the last 50 years. There's many people in 00:12:29.930 --> 00:12:33.870 English language, it's called operations research, because I think it originated 00:12:33.870 --> 00:12:40.030 from military questions. And there are algorithms to solve this, right? 00:12:40.090 --> 00:12:43.170 That's great news. We should clarify a little bit what kind of costs we're 00:12:43.170 --> 00:12:48.320 dealing with in Lightning. Because we talked about the, well, first of all, each 00:12:48.320 --> 00:12:51.680 channel will have a certain fee rate that's set by the node, how much you're 00:12:51.680 --> 00:12:54.780 charging. And they also have a base fee, but we'll get into that later. 00:12:54.900 --> 00:12:55.100 Sure. 00:12:55.960 --> 00:13:00.520 Without wanting to dox your clothing. But there's also what we talked about, the 00:13:00.520 --> 00:13:05.320 risk of simple failure as in not enough capacity. And you'll simply, in the best 00:13:05.320 --> 00:13:08.720 case, when there's not enough capacity, you very quickly get a reply back saying, 00:13:08.840 --> 00:13:12.140 hey, there's not enough capacity. So you want to minimize the odds of that 00:13:12.140 --> 00:13:17.480 happening in general. But a very important thing is that there's another kind of 00:13:17.480 --> 00:13:22.040 failure, which is the my payment is stuck failure. And in Lightning that is like 00:13:22.040 --> 00:13:26.100 the horror scenario where you won't actually really know that your payment is stuck. 00:13:27.720 --> 00:13:31.100 because you're not getting a message back. But there can be two reasons you're 00:13:31.100 --> 00:13:35.220 not getting a message back. One is it did succeed, and the other side is waiting 00:13:35.220 --> 00:13:39.740 for all the parts to combine. So if you're splitting a payment up, as soon as the 00:13:39.740 --> 00:13:43.680 other side gets all the parts, then it says, okay, done. So you get a whole bunch 00:13:43.680 --> 00:13:48.110 of messages back. So that could be the reason why you're still waiting on a 00:13:48.110 --> 00:13:51.210 reply. The other is that it actually failed and then you have to wait multiple 00:13:51.210 --> 00:13:55.690 days and close the channel on chain and incur fees and all that type of horror. So 00:13:55.690 --> 00:13:59.090 a remote channel could have failed but a remote channel could just decide not to 00:13:59.090 --> 00:14:03.500 forward it because it acts maliciously. or it's misconfigured right I mean these 00:14:03.500 --> 00:14:07.200 are also sources of errors I mean that could also happen yes 00:14:07.200 --> 00:14:11.820 yeah and so those are things you really want to avoid because they're like very 00:14:11.820 --> 00:14:15.220 high pain situations but in the model that you're talking about you could just 00:14:15.220 --> 00:14:19.220 assign some sort of price to them so you could say like I really never want this 00:14:19.220 --> 00:14:24.160 to happen so I'll put the maximum weight to that not happening and in that case 00:14:24.160 --> 00:14:28.820 what you want to optimize for is the fewest number of channels that your payment 00:14:28.820 --> 00:14:32.560 goes through. So that could be an argument to make it a single payment if that is 00:14:32.560 --> 00:14:33.240 possible. 00:14:34.910 --> 00:14:38.850 And then the other factors could also push it towards a single payment or a split 00:14:38.850 --> 00:14:41.170 number of payments. So 00:14:41.170 --> 00:14:45.550 what you're basically referring to is the question of how do you assign a cost to 00:14:45.550 --> 00:14:50.130 the... problem, right? If I want to solve a minimum cost flow, I have to know a 00:14:50.130 --> 00:14:53.850 cost function, right? And it's very reasonable to take the routing fees, as you 00:14:53.850 --> 00:14:58.570 mentioned. It's also very reasonable to take the success probabilities, but there 00:14:58.570 --> 00:15:03.690 might be other features that we include into the cost function. And our research 00:15:03.690 --> 00:15:08.950 does not claim to know the perfect cost function. We just claim to know here's a 00:15:08.950 --> 00:15:12.730 cost function that currently works well. And this is the kind of problem you want 00:15:12.730 --> 00:15:17.270 to solve, right? But there's a lot of research to be done in the future to 00:15:17.270 --> 00:15:20.950 actually design a better cost function. And depending on your cost function, you 00:15:20.950 --> 00:15:23.570 would split the payment differently because, I mean, this defines your 00:15:23.570 --> 00:15:24.390 optimization goal. 00:15:24.920 --> 00:15:29.080 Exactly. And I think this will bring us to the hairy issue that is on your 00:15:29.080 --> 00:15:33.020 t-shirt. Because at least if you look at the fees, the way it works in Lightning 00:15:33.020 --> 00:15:36.240 right now, there is something called the base fee, which is a fixed amount that 00:15:36.240 --> 00:15:40.680 you pay for every payment that goes through your channel. And there is a fee 00:15:40.680 --> 00:15:44.780 rate, which is simply a percentage of the amount that's being sent. And notice 00:15:44.780 --> 00:15:48.960 it's different than what we're used to on the Bitcoin base chain. On the Bitcoin 00:15:48.960 --> 00:15:52.600 base chain, you're paying per byte that you're sending, independent of the value 00:15:52.600 --> 00:15:58.060 that you're sending. And there's no setup cost. It's basically per byte. Although 00:15:58.060 --> 00:16:01.080 in practice, of course, you can't make a transaction that's that small. 00:16:02.540 --> 00:16:08.420 But on Lightning, the payment is based on the amount. And the reason for 00:16:08.420 --> 00:16:13.680 that, I guess, one reason for that is because your channel, once all the coins 00:16:13.680 --> 00:16:17.280 are on one side of the channel, you then have to rebalance it somehow, send those 00:16:17.280 --> 00:16:22.090 coins back. to the other side or create a whole new channel which has a cost on 00:16:22.090 --> 00:16:27.430 chain. So you want there to be some incentive to not drain the channel or not to 00:16:27.430 --> 00:16:29.970 move all the coins to one side. You want to be compensated for that because 00:16:29.970 --> 00:16:32.810 that's where your actual cost is going to be. Whereas on Bitcoin, the cost is 00:16:32.810 --> 00:16:37.670 bandwidth for processing transactions. So it makes sense to charge it per byte 00:16:37.670 --> 00:16:39.870 rather than per value. So 00:16:39.870 --> 00:16:43.710 I understand in Bitcoin, it's very clear why you would charge per byte. I mean, 00:16:43.790 --> 00:16:49.190 that makes a lot of sense to me because the block size is the limiting factor 00:16:49.190 --> 00:16:52.750 here, right? So you want to basically pay for how much space you use inside the 00:16:52.750 --> 00:16:53.190 blockchain. 00:16:53.390 --> 00:16:53.530 Yeah. 00:16:54.470 --> 00:16:58.450 Whereas in Lightning, it makes sense to somehow tie this to the amount because as 00:16:58.450 --> 00:17:02.580 you just said, the channel drains, right? then you can't route anymore. So that 00:17:02.580 --> 00:17:03.040 makes sense. 00:17:03.260 --> 00:17:06.960 Yeah, so channel capacity is the bottleneck, or at least that's sort of assumed here. 00:17:07.120 --> 00:17:12.010 Yeah. So initially in the protocol, as you mentioned, there was also the base 00:17:12.010 --> 00:17:15.850 fee, which is just the fixed fee, which you also noted Bitcoin transactions do 00:17:15.850 --> 00:17:19.250 not have. So they are just linear in the size, whereas Lightning payments are not 00:17:19.250 --> 00:17:25.060 just linear in the amount, but also have this like fixed cost. And 00:17:25.060 --> 00:17:29.500 the interesting observation is, I just mentioned, there are well-known algorithms 00:17:29.500 --> 00:17:34.000 to solve those min-cost flow problems. But it turns out that the computational 00:17:34.000 --> 00:17:38.260 time that you need very much depends on the structure of the fee function or the 00:17:38.260 --> 00:17:43.660 cost function. So there are, in general, in mathematics, I mean, there are way 00:17:43.660 --> 00:17:47.540 more, but three ones that are being studied. There are non-linear functions, 00:17:47.780 --> 00:17:53.070 there are convex functions, and there are linear functions. And for linear 00:17:53.070 --> 00:17:57.990 functions, the problem is ridiculously easy to solve. For convex functions, we 00:17:57.990 --> 00:18:02.910 can do it. And for nonlinear functions, the problem is very complex to solve. 00:18:03.170 --> 00:18:06.510 Yeah, but I think you mentioned that it's not just that it has to be linear, 00:18:06.510 --> 00:18:12.950 because a linear function could be just 0 plus A plus BX plus, well, yeah. 00:18:13.570 --> 00:18:14.290 AX plus B. 00:18:15.680 --> 00:18:21.620 Yeah. I guess, yeah, not all exponential, not all like powers of 00:18:21.620 --> 00:18:24.260 two you can do, right? You can't do like x to the third. 00:18:25.480 --> 00:18:31.460 So we're jumping into a nitty point of mathematics that the term linear actually 00:18:31.460 --> 00:18:35.620 has two semantics in math. One semantics is if you come from a perspective of 00:18:35.620 --> 00:18:36.440 polynomials. 00:18:36.640 --> 00:18:38.140 Yeah, I was thinking polynomials. 00:18:38.340 --> 00:18:42.800 Then a x plus b would be considered linear. But the way how I talk about 00:18:42.800 --> 00:18:48.550 linearity is, that in the same way as Schnorr signatures are linear, right? It 00:18:48.550 --> 00:18:52.190 doesn't matter if you do the addition, right? So if you have a function f of x, 00:18:52.470 --> 00:18:58.400 you do f of a plus b. It's the same as f of a plus f of b. 00:18:58.700 --> 00:19:02.240 And this doesn't work with the base fee because now you have to pay the base fee 00:19:02.240 --> 00:19:04.380 twice if you execute the function twice. 00:19:04.840 --> 00:19:10.200 So in other words, these super fancy algorithms that exist out there in the 00:19:10.200 --> 00:19:15.420 literature are able to handle a polynomial where the only thing is x, basically. 00:19:15.980 --> 00:19:21.900 So this base fee becomes a problem because it's this offset. Basically, if you 00:19:21.900 --> 00:19:27.750 look at a y-axis and an x-axis... You're looking at a diagonal line that starts 00:19:27.750 --> 00:19:32.970 at zero. That's what you can handle. If the diagonal line starts at one or two, 00:19:33.190 --> 00:19:38.070 something, then you can no longer handle it. And, well, then, you know, you can 00:19:38.070 --> 00:19:41.910 try to sort of ignore that problem by, I don't know, either pretending that this 00:19:41.910 --> 00:19:46.850 base fee doesn't exist and then just find the best route and filter some of the 00:19:46.850 --> 00:19:50.830 base fees. Or you can suggest to people in the Lightning Network to get rid of 00:19:50.830 --> 00:19:54.860 the base fee. And I guess the third solution would be to find this genius 00:19:54.860 --> 00:19:59.460 mathematician that can actually just solve it with a base fee if people really, 00:19:59.500 --> 00:20:03.540 really care about the base fee. Yeah. And that is, I guess, some discussion about that. 00:20:04.280 --> 00:20:09.000 So that was a surprise for us because we didn't anticipate this discussion. We 00:20:09.000 --> 00:20:13.060 were very afraid to publish the results. Because in earlier days, there was 00:20:13.060 --> 00:20:18.420 always this criticism coming from the Bitcoin Cash community that the Lightning 00:20:18.420 --> 00:20:21.320 routing is like an unsolved problem. And if it would be solved, it would be 00:20:21.320 --> 00:20:23.040 NP-complete and all these things, right? 00:20:24.480 --> 00:20:29.180 Well, I mean, now it turns out that with the current goal that nodes have to 00:20:29.180 --> 00:20:33.680 optimize for just the fees, the problem actually is NP-complete, right? And we 00:20:33.680 --> 00:20:38.980 were very afraid to actually publish this because we thought we would get a lot 00:20:38.980 --> 00:20:44.130 of ridicule from this community, but that community didn't care at all. However, 00:20:44.450 --> 00:20:47.770 we asked before, why was the base fee actually introduced to the Lightning 00:20:47.770 --> 00:20:52.570 Network Protocol? And Rusty Russell, a Lightning developer who worked at the spec 00:20:52.570 --> 00:20:56.070 at that time, and I think who actually put it there, said there was no particular 00:20:56.070 --> 00:20:59.230 reason. At that time, there was just many discussions of how we want to do this. 00:20:59.390 --> 00:21:03.450 And that was basically a compromise among developers. But there's no security 00:21:03.450 --> 00:21:07.190 reason. There's no privacy reason. There's no like, it's not desperately needed, 00:21:07.390 --> 00:21:11.530 right? So we thought, well, that's good then, right? Because now we figure out 00:21:11.530 --> 00:21:16.200 that if we drop the base fee, and set it to zero, well, then lightning routing 00:21:16.200 --> 00:21:21.020 becomes actually a very feasible and easy to compute optimization problem. But 00:21:21.020 --> 00:21:24.660 after we published this, there were actually a lot of people from within the 00:21:24.660 --> 00:21:30.640 community who provided arguments, which up to this day, I 00:21:30.640 --> 00:21:34.500 do not fully understand. But there's discussion, yes. 00:21:35.080 --> 00:21:40.520 Okay, well, it's good to know there's discussion. And I think... We've given a 00:21:40.520 --> 00:21:44.380 nice outline now of this whole proposal and some of the issues. And you're 00:21:44.380 --> 00:21:46.460 wearing a nice shirt that says zero base fee. 00:21:46.760 --> 00:21:50.880 I didn't buy this shirt. Some people from the community gave it to me. So it's 00:21:50.880 --> 00:21:53.980 actually really funny I want to mention this here. I went to a German speaking 00:21:53.980 --> 00:21:59.010 podcast together with Stefan and we talked about our paper. And as soon as the 00:21:59.010 --> 00:22:03.450 episode aired, one member of the German Bitcoin community posted a screenshot to 00:22:03.450 --> 00:22:08.690 Twitter and said, I just set zero base fee to all my channels. And Stefan and I, 00:22:08.790 --> 00:22:12.010 we talked to each other and we're like, we wrote this paper and we didn't do it 00:22:12.010 --> 00:22:16.110 on our own node. That's kind of embarrassing. And from that on, basically 00:22:16.110 --> 00:22:19.870 originated in Germany. A lot of people started setting their base fee to zero. 00:22:20.190 --> 00:22:20.570 Okay. 00:22:21.110 --> 00:22:25.570 And now I think it's 30% of the network already who do this, which is really good 00:22:25.570 --> 00:22:29.230 because if I do my routing decisions, I actually use those channels and I like 00:22:29.230 --> 00:22:33.550 those channels more. So if they even charge a higher fee rate, that's okay for me 00:22:33.550 --> 00:22:35.270 because they do a good service for the network. 00:22:35.530 --> 00:22:39.050 Making the math easier. Okay. Is there anything else you want to add for now? 00:22:41.700 --> 00:22:47.680 I want to say that... There is ongoing mainnet tests that have been happening. So 00:22:47.680 --> 00:22:52.440 we have been able to deliver 0.36 Bitcoin over the Lightning Network, which I 00:22:52.440 --> 00:22:57.260 think is a really large amount. And we tested this against any implementation 00:22:57.260 --> 00:23:01.620 that was out there on the same node, basically. And we haven't been able with 00:23:01.620 --> 00:23:06.360 those nodes out of the box to deliver the amount. So because, I mean, I was 00:23:06.360 --> 00:23:10.810 talking about an optimization problem. What we know is we know the best solution. 00:23:11.070 --> 00:23:15.370 What wasn't clear before is, is the best solution actually good enough, right? 00:23:15.570 --> 00:23:20.410 And it turns out it makes a huge difference to do this. So this is one thing. And 00:23:20.410 --> 00:23:24.630 the other thing that I want to mention is there is a whole different problem with 00:23:24.630 --> 00:23:27.670 respect to reliability, and we touched this briefly, which are these stuck 00:23:27.670 --> 00:23:32.870 payments. And they are really a big issue. But luckily, we're coming to a Schnorr 00:23:32.870 --> 00:23:36.990 and Taproot world where we can switch to PTLCs and create something like 00:23:36.990 --> 00:23:41.770 cancelable payments or redundant payments. And in that sense, we can actually 00:23:41.770 --> 00:23:47.380 start to handle those problems where... nodes are just not forwarding amounts and 00:23:47.380 --> 00:23:49.340 basically disturbing the payment process. 00:23:49.580 --> 00:23:52.880 Right, because as a user, you don't know if the payment is actually going to fail 00:23:52.880 --> 00:23:57.500 or not, and you'd like to be able to explicitly cancel it, and then you can swap 00:23:57.500 --> 00:24:01.440 out that particular part of the payment with just a new payment, essentially. 00:24:01.640 --> 00:24:04.720 Well, you said a user, actually, the node should do this secretly for you. The 00:24:04.720 --> 00:24:07.680 user shouldn't interfere into this, but even the node doesn't know it. 00:24:09.490 --> 00:24:11.390 Okay. Perfect, yeah. That's all? 00:24:11.910 --> 00:24:12.330 Yeah. 00:24:12.790 --> 00:24:15.870 Okay. Well, thank you for coming all the way to Zurich for this podcast. 00:24:16.170 --> 00:24:16.630 Thank you too. 00:24:16.970 --> 00:24:19.910 And do you want people to find you somewhere? 00:24:20.810 --> 00:24:25.050 They can find me on the mailing list on Twitter, on GitHub. I'm just out there. 00:24:25.390 --> 00:24:29.830 Okay. Well then, dear listener, thank you for listening to Bitcoin Explained.