WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:09.070 --> 00:00:14.050 Live from San Salvador and Utrecht, this is the Van Wirdum Sjorsnado. 00:00:15.010 --> 00:00:15.490 Hello. 00:00:16.550 --> 00:00:18.070 Hey Sjors, welcome back. 00:00:18.950 --> 00:00:19.650 Thank you. 00:00:19.810 --> 00:00:20.410 It's been a while. 00:00:20.410 --> 00:00:24.360 I mean, I'm not physically back, but yeah. 00:00:25.220 --> 00:00:29.000 I'm the one who's not physically back. I'm still hanging out in El Salvador, 00:00:29.260 --> 00:00:32.280 checking out what's going on here with the new Bitcoin law. 00:00:33.640 --> 00:00:34.380 Sounds fun. 00:00:34.700 --> 00:00:39.600 So yeah, we're doing another episode remote, which always kind of sucks, but 00:00:39.600 --> 00:00:40.740 let's make the best out of it. 00:00:42.860 --> 00:00:43.340 Indeed. 00:00:43.620 --> 00:00:43.960 Sure. 00:00:44.160 --> 00:00:44.660 It should be fun. 00:00:44.960 --> 00:00:47.460 Sure. Today we're discussing BOLT 12. 00:00:48.640 --> 00:00:52.500 Yes. I forgot to prepare any kind of pun for that, but yes. 00:00:52.760 --> 00:00:57.980 Hey, BOLT itself is a pun. The Lightning developers fixed that one for us. 00:00:59.310 --> 00:01:02.910 Yeah, that's true. All right. It stands for our basis of Lightning technology, 00:01:03.210 --> 00:01:07.630 which is comparable to a BIP, as we've discussed in an earlier episode for a 00:01:07.630 --> 00:01:10.410 Bitcoin improvement protocol. But it's also different from a BIP. 00:01:11.750 --> 00:01:17.310 The pun obviously being lightning bolt for those listeners that are particularly 00:01:17.310 --> 00:01:21.550 dense. And yeah, it stands for basis of Lightning technology. And like you 00:01:21.550 --> 00:01:25.190 mentioned, it's like a BIP, but for Lightning specifically, right? 00:01:26.020 --> 00:01:29.860 Yeah, and of course, it makes it really hard to Google anything, right? So if 00:01:29.860 --> 00:01:34.540 you're trying to find out what is a BOLT, and then you add BOLT Lightning, and 00:01:34.540 --> 00:01:38.780 you're just not going to find anything related to the protocol. So it's really smart. 00:01:39.140 --> 00:01:43.700 Right, and so far, there were apparently 11 BOLTs. Is that right? 00:01:44.870 --> 00:01:45.350 Yes. 00:01:45.590 --> 00:01:51.310 So there's basically 11 specifications of how the Lightning protocol works. 00:01:52.300 --> 00:01:58.300 Yeah, exactly. So that is the distinction between BIPs and BOLTs, I would say. 00:01:58.820 --> 00:02:04.460 BOLTs are really a specification, so they're a lot more formal in that sense. So 00:02:04.460 --> 00:02:09.260 usually what they do is somebody proposes a BOLT, and then if there's two 00:02:09.260 --> 00:02:14.680 implementations of different Lightning implementations that support it, then 00:02:14.680 --> 00:02:17.200 it's ready. 00:02:18.060 --> 00:02:23.340 Right. So there were 11 so far and there's now a 12th BOLT. Or is it a proposed 00:02:23.340 --> 00:02:25.000 BOLT or what's the status of this? 00:02:25.670 --> 00:02:28.890 I think it's proposed because the only implementation is in C-Lightning. 00:02:29.370 --> 00:02:33.550 Right. So it would be official if some other implementation adopts the same thing. 00:02:34.150 --> 00:02:35.070 I think so. 00:02:35.490 --> 00:02:40.980 Right. So it's a proposed BOLT and it was proposed by Rusty Russell, I think. 00:02:41.710 --> 00:02:47.450 Yes, he actually gave a presentation about this in September 2019 in Berlin at 00:02:47.450 --> 00:02:50.470 the Lightning conference there, which was fun. 00:02:51.880 --> 00:02:56.980 Right, so 11 BOLTs so far. This could be the 12th BOLT. So the Lightning 00:02:56.980 --> 00:03:02.480 specification or the Lightning protocol could be upgraded or expanded, 00:03:03.020 --> 00:03:08.490 extended. And we're going to explain, you're going to explain mostly. It's going 00:03:08.490 --> 00:03:13.810 to be mostly you, Sjors, this episode, I think. No. And… And everyone knows that 00:03:13.810 --> 00:03:17.770 if the two of you, the two of us, sorry, if the two of us do a Lightning episode, 00:03:17.970 --> 00:03:19.830 these are usually the best episodes. 00:03:22.580 --> 00:03:27.480 I think we can do an okay job at explaining this one. Hopefully. We'll hear. 00:03:27.760 --> 00:03:32.620 All right. Let's see how far we get. So, BOLT 12. What is it, Sjors? Take it away. 00:03:33.680 --> 00:03:37.960 Well, maybe we want to take one step back and talk about BOLT 11 or more 00:03:37.960 --> 00:03:39.040 generally invoices. 00:03:40.060 --> 00:03:45.870 Right. Yes. Because BOLT 12 is essentially a new type of invoice 00:03:45.870 --> 00:03:49.410 or an extension of how invoices work. Is that the right way to put it? 00:03:50.310 --> 00:03:52.250 Yeah, like a meta invoice, I guess. 00:03:52.670 --> 00:03:57.330 Right. So the Lightning Network, the Lightning Protocol currently uses invoices. 00:03:57.730 --> 00:04:02.550 So yes, let's first explain what is a Lightning Invoice. What is this? 00:04:02.850 --> 00:04:07.150 Yeah. So a Lightning Invoice is just a piece of text and it has a computer 00:04:07.150 --> 00:04:12.750 readable, of course. And it has a couple of things in that text. One is the node 00:04:12.750 --> 00:04:18.160 that the transaction needs to be sent to. So a node is just a public key. 00:04:18.800 --> 00:04:23.220 There's usually an amount, like how much satoshis are you expecting? 00:04:24.430 --> 00:04:28.270 And the interesting ingredient there is there's a hash of a secret. 00:04:30.750 --> 00:04:36.590 The hash of the secret. So the idea is that when you're actually paying an 00:04:36.590 --> 00:04:40.910 invoice, you're going to get the actual secret rather than the hash of the 00:04:40.910 --> 00:04:42.850 secret. And that's how this whole chain of... 00:04:44.830 --> 00:04:48.610 HTLCs that we talked about with the Joost Jager. That's kind of how they cascade. 00:04:48.770 --> 00:04:52.760 So those are the three ingredients that are on an invoice. So if you're selling 00:04:52.760 --> 00:04:58.730 me an apple, you tell me how many satoshis you want for the apple, the 00:04:58.730 --> 00:05:02.550 hash of the secret, and what your node is. And you can add a bunch of other 00:05:02.550 --> 00:05:07.570 things to the invoice that are not very important for this conversation, like a 00:05:07.570 --> 00:05:10.030 description and some hints on how to route to you. 00:05:11.530 --> 00:05:16.270 Right, yeah. So an invoice is just a piece of data that tells you what my node 00:05:16.270 --> 00:05:21.290 is, because all nodes on the Lightning Network have their own identifier, which 00:05:21.290 --> 00:05:26.740 you mentioned is a public key, plus the amount, plus a hash, which is sort of the 00:05:26.740 --> 00:05:32.160 magic of how the Lightning Network works. So I communicate this information in an 00:05:32.160 --> 00:05:38.140 invoice to you, and that's how you know how to pay me. That's what an 00:05:38.140 --> 00:05:38.840 invoice is, right? 00:05:39.580 --> 00:05:43.780 Exactly. And then my wallet would just pay that invoice by sending a bunch of 00:05:43.780 --> 00:05:49.660 messages and constructing a payment and doing the routing stuff and all 00:05:49.660 --> 00:05:50.900 that stuff that we talked about earlier. 00:05:51.500 --> 00:05:53.300 Right. So this sounds perfect to me. 00:05:54.770 --> 00:05:59.230 Yeah, it is. It's amazing. And, you know, Lightning has been working. So it's not 00:05:59.230 --> 00:05:59.730 the end of the world. 00:05:59.770 --> 00:06:00.790 So what's the problem? 00:06:02.050 --> 00:06:04.910 Well, there's a couple of them. Why fix what isn't broken, Sjors? 00:06:06.060 --> 00:06:11.520 There's a couple of problems. So let's say you have an apple in your store and 00:06:11.520 --> 00:06:15.600 you have this Lightning invoice and you decide to make the Lightning invoice 00:06:15.600 --> 00:06:19.560 early on. So you want to put it on a sticker and you put the sticker on the 00:06:19.560 --> 00:06:25.140 apple. The problem is you have to set the amount of satoshis. And so by the time 00:06:25.140 --> 00:06:30.660 I go to your shop and pick up the apple, maybe the exchange rate doubled. The 00:06:30.660 --> 00:06:34.580 apple is too expensive and you have to make a new sticker. So volatility 00:06:34.580 --> 00:06:39.520 basically is kind of hard to deal with in this way. It's fine if you make the 00:06:39.520 --> 00:06:42.860 invoice real time, but not if you want to make them in advance and print them out. 00:06:43.900 --> 00:06:48.280 Yeah, we're assuming that a lot of people are not using Bitcoin as a unit of 00:06:48.280 --> 00:06:52.180 account yet. They're still using some kind of fiat currency as a unit of account, 00:06:52.200 --> 00:06:58.010 but they want to be paid in Bitcoin. So you want to be paid $1 in Bitcoin 00:06:58.010 --> 00:07:02.810 for your apple rather than a fixed amount of satoshis in your apple for your 00:07:02.810 --> 00:07:07.710 apple. And that's hard to do with a static Lightning invoice. 00:07:08.640 --> 00:07:14.320 You'd have to create the invoice at the moment of sale, and you can't 00:07:14.320 --> 00:07:16.480 make it in advance. So that's one limitation. 00:07:17.490 --> 00:07:22.130 Yeah, another one, and there is a workaround for that too, of course. None of 00:07:22.130 --> 00:07:26.210 these are end-of-the-world problems. The other one is that this hash of the 00:07:26.210 --> 00:07:30.890 secret that we talked about, you can only use this once. So if you want to have a 00:07:30.890 --> 00:07:35.210 tattoo on your body with a Lightning invoice, that's not a good idea because the 00:07:35.210 --> 00:07:39.610 first person who pays it, then there's a chance it's going to leak and the 00:07:39.610 --> 00:07:40.810 mechanism won't work anymore. 00:07:42.190 --> 00:07:48.090 So then you'd have to print a bunch of QR codes on your skin. If you use the 00:07:48.090 --> 00:07:52.830 henna tattoos, I guess you can do that. There's also another workaround for this 00:07:52.830 --> 00:07:54.370 problem of recurring payments. 00:07:54.530 --> 00:08:00.030 I think it's not technically really that it doesn't work. It's just that it's not 00:08:00.030 --> 00:08:05.570 secure, right? Because the secret needs to be a secret. That's why it's a secret. 00:08:05.990 --> 00:08:10.470 While if you've used it once, then the secret has been sort of used on the 00:08:10.470 --> 00:08:15.970 Lightning Network and therefore… if you create a new invoice with the same hash 00:08:15.970 --> 00:08:20.210 of a secret, then someone else might know the secret and therefore claim funds 00:08:20.210 --> 00:08:22.430 that they weren't supposed to claim. Right? 00:08:23.070 --> 00:08:23.670 Yeah. 00:08:24.050 --> 00:08:30.010 So that's why every invoice should only be used once. So every secret is 00:08:30.010 --> 00:08:35.030 only used once. So you can't use the same invoice for different apples. 00:08:35.490 --> 00:08:40.830 In my apple store, I can't put the same sticker with the same price on every 00:08:40.830 --> 00:08:45.230 apple because once the first person buys an apple, the secret is going to be out 00:08:45.230 --> 00:08:51.370 there and all the other apples. I'm running a big risk of having my apple stolen, basically. 00:08:51.890 --> 00:08:52.630 That's right. 00:08:53.020 --> 00:08:53.580 Right. 00:08:54.140 --> 00:08:59.560 So one solution to that problem that already exists is that instead of making an 00:08:59.560 --> 00:09:05.220 invoice, you only publish your node identifier. And then the customer just 00:09:05.220 --> 00:09:10.880 basically enters the amount themselves and sends it to your node. So you're kind 00:09:10.880 --> 00:09:15.290 of leaving that to the customer. Of course, that's annoying too because... then 00:09:15.290 --> 00:09:18.730 how do you do automatic handling of payments because you're expecting a certain 00:09:18.730 --> 00:09:23.050 amount? And what if it goes wrong? You know, if the customer types the wrong 00:09:23.050 --> 00:09:28.050 amount, that's kind of not ideal, but it's possible. And for donations, it's 00:09:28.050 --> 00:09:31.850 fine, right? For donations, you can have, I guess, a tattoo with your node 00:09:31.850 --> 00:09:36.030 identifier on you, and then people can donate you because it's up to them how 00:09:36.030 --> 00:09:40.210 much they want to send anyway. So there are solutions to that. If you Google, for 00:09:40.210 --> 00:09:41.110 example, KeySend. 00:09:43.000 --> 00:09:48.900 Right. But anyway, so we've now mentioned two downsides of the current 00:09:48.900 --> 00:09:54.740 invoice system. One of them is fiat volatility. The other one is you can't 00:09:54.740 --> 00:09:58.660 really reuse the same invoice in a secure way. Are there more? 00:10:00.690 --> 00:10:03.330 I mean, just sort of the main thing, yeah. 00:10:03.280 --> 00:10:04.240 These are the two… 00:10:03.910 --> 00:10:08.190 Well, the other thing is, but it's not really a downside, but you— you know, an 00:10:08.190 --> 00:10:10.310 invoice can only be used to receive money. 00:10:11.840 --> 00:10:16.180 It can't be used to send money. So you can't do a credit invoice. 00:10:18.290 --> 00:10:22.330 You can do a… Yeah, give me a concrete example of this. When would you want to 00:10:22.330 --> 00:10:24.290 create an invoice to send money? 00:10:24.970 --> 00:10:30.850 A Bitcoin ATM. So if I put $10 into a Bitcoin ATM and I wanted to send 00:10:30.850 --> 00:10:35.770 me that amount in satoshis over the Lightning Network, then the way that works 00:10:35.770 --> 00:10:40.250 right now is that, well, there's some other technologies, but what we just 00:10:40.250 --> 00:10:44.830 described is you as the person using the ATM has to make an invoice for that ATM 00:10:44.830 --> 00:10:47.930 and then the ATM will pay you if the invoice is what it wants. 00:10:49.660 --> 00:10:53.320 And that's not ideal. Ideally, what you want to do is you want to give money to 00:10:53.320 --> 00:10:57.840 the ATM, like a piece of paper, and then it should show you a QR code, and you 00:10:57.840 --> 00:11:01.620 scan that, and then it pays you. So it's a credit invoice. 00:11:03.260 --> 00:11:03.620 Right. 00:11:03.800 --> 00:11:07.220 That's what you'd like to see. And there are some workarounds for this, so it's 00:11:07.220 --> 00:11:08.320 not the end of the world again. 00:11:09.360 --> 00:11:14.540 Right, so the current invoice system, it works for what it needs to do. However, 00:11:14.900 --> 00:11:19.940 it has, we've now mentioned three main limitations. One is you can't create the 00:11:19.940 --> 00:11:25.260 invoice ahead of time, at least if you're pricing stuff in fiat because of the 00:11:25.260 --> 00:11:25.900 fiat volatility. 00:11:27.520 --> 00:11:31.860 The second one is you can't reuse the same invoice because it's not really secure 00:11:31.860 --> 00:11:35.680 because the secret is exposed after the first time. And the third sort of 00:11:35.680 --> 00:11:40.620 downside is that you can't create an invoice to send money. Am I saying it right? 00:11:40.780 --> 00:11:41.380 I think so. 00:11:41.600 --> 00:11:47.340 Yeah. And as far as I know, some or all of these are solved in practice at the, 00:11:47.480 --> 00:11:51.020 not at the protocol layer, but at the application layer with something like 00:11:51.020 --> 00:11:55.940 LNURL. So we can do a whole other podcast going into that. But for now, we're 00:11:55.940 --> 00:12:00.560 going to talk about... a solution at the protocol level, which is called BOLT 12. 00:12:01.370 --> 00:12:07.190 BOLT 12. All right, there we go. So BOLT 12 is, you mentioned, it's 00:12:07.190 --> 00:12:12.650 like a meta invoice. You can consider it like a layer on top of regular invoices 00:12:12.650 --> 00:12:18.580 that communicates not just invoice data, but something on top of that, right? 00:12:19.920 --> 00:12:25.580 It doesn't even communicate the invoice. So in the apple example, the 00:12:25.580 --> 00:12:30.920 BOLT 12 thing, the sticker that you put in your apple, might say, this is an 00:12:30.920 --> 00:12:36.120 apple. This is the identifier of the apple for the store. Maybe it has some 00:12:36.120 --> 00:12:39.260 SKU, some unique number. 00:12:40.800 --> 00:12:46.130 And this is the Lightning node. And please go talk to this Lightning node. So 00:12:46.130 --> 00:12:51.070 then what the customer app will do is it scans the QR code. It sees, okay, this 00:12:51.070 --> 00:12:54.850 is an apple and I have to talk to this other node. It then calls the other node 00:12:54.850 --> 00:12:59.940 and says, please give me an invoice for this apple. And then the node actually 00:12:59.940 --> 00:13:04.220 gives you an invoice for the apple right then, which you can pay. Which means, 00:13:04.300 --> 00:13:10.090 you know, the Lightning node for the store can calculate the exchange rate, for 00:13:10.090 --> 00:13:11.570 example, right at the last moment. 00:13:13.020 --> 00:13:15.700 Yeah. And then it's paid as a regular invoice. 00:13:16.020 --> 00:13:21.880 Right. So BOLT 12 is essentially a specification for a protocol of 00:13:21.880 --> 00:13:27.800 how to contact, well, how to contact a specific node, which would be the node 00:13:27.800 --> 00:13:33.680 you want to pay. And then that node knows how to respond to that request 00:13:33.680 --> 00:13:35.760 by creating an invoice. Is that right? 00:13:36.730 --> 00:13:41.730 Almost. So it's not really how to contact a node because that's sort of known how 00:13:41.730 --> 00:13:47.230 to do that. But it is, or it might actually, I don't know. But it is saying you 00:13:47.230 --> 00:13:50.710 should contact this node because this node is who can give you the invoice. 00:13:52.030 --> 00:13:57.780 So with BOLT 12... You get the info on which 00:13:57.780 --> 00:14:03.640 node to contact and at that point a invoice is created. Therefore we're 00:14:03.640 --> 00:14:08.540 solving the time problem because the invoice is created at the exact time that 00:14:08.540 --> 00:14:14.180 you want to make the payment. Even though the BOLT12 meta invoice was 00:14:14.180 --> 00:14:20.000 stuck on my apple for a while. And we're fixing the secrets problem. 00:14:20.860 --> 00:14:25.980 Because the invoice is created uniquely, even though the sticker was on my apple 00:14:25.980 --> 00:14:29.440 for a while. But Sjors, is there more? 00:14:30.020 --> 00:14:35.380 There is more. So one thing you can do now is subscriptions. So BOLT12 has a 00:14:35.380 --> 00:14:41.160 special way to indicate that this is a subscription. So you can say, please don't 00:14:41.160 --> 00:14:45.800 ask me just for one invoice, but ask me for an invoice every week or every month. 00:14:46.610 --> 00:14:50.930 And it can even say, well, the invoice should be $10 every month rather than, 00:14:50.930 --> 00:14:52.670 say, 10 satoshis every month. 00:14:52.950 --> 00:14:58.550 Right. So if you want to buy 00:14:58.990 --> 00:15:02.510 an apple from me every month, that's the worst example probably. 00:15:03.250 --> 00:15:04.550 Yeah, it's a terrible example. 00:15:04.730 --> 00:15:08.730 If you want to buy an apple from me every month, we can actually automate that. 00:15:10.390 --> 00:15:11.350 Yeah, exactly. 00:15:12.590 --> 00:15:18.190 I guess this does require... So BOLT 12 can sort of 00:15:18.190 --> 00:15:23.870 include that information. It can offer to create 00:15:23.870 --> 00:15:28.130 an invoice every month, but there's still a lot of work to be done on the wallet 00:15:28.130 --> 00:15:32.810 side to actually make this happen in reality. Like BOLT 12 in itself doesn't 00:15:32.810 --> 00:15:33.670 solve this, right? 00:15:34.800 --> 00:15:39.040 No, in particular because if you're talking about sort of an automated payment 00:15:39.040 --> 00:15:44.400 every month in a different exchange rate even, then that creates a few 00:15:44.400 --> 00:15:49.520 problems, right? So, for example, let's say it's automatic, you don't want to 00:15:49.520 --> 00:15:55.100 think about it too much, but then the server side, so let's say the Spotify or 00:15:55.100 --> 00:16:00.850 whatever, they… they create this invoice every month for $10 based on what they 00:16:00.850 --> 00:16:05.090 think the exchange rate is. And then your wallet asks for that invoice once a 00:16:05.090 --> 00:16:07.630 month. It says, hey, do you have a new invoice for me? And the server says, yeah, 00:16:07.670 --> 00:16:13.410 here's one. And then the wallet has to say, well, according to me, it's $10.01. 00:16:14.330 --> 00:16:19.250 And so then you have to say, okay, what percentage of disagreement is okay? That 00:16:19.250 --> 00:16:22.270 sort of stuff would need to be worked out. And what does the wallet do if there's 00:16:22.270 --> 00:16:27.410 not enough balance? Does it nag the user or not? And for mobile wallets, it's 00:16:27.410 --> 00:16:31.630 even more tedious because mobile applications tend to be off in the background. 00:16:32.410 --> 00:16:37.510 So they have to wake up at the right time to ask for new invoices. So there's 00:16:37.510 --> 00:16:41.670 definitely work to be done. But at least specifying what the subscription should 00:16:41.670 --> 00:16:43.770 be, that can be done at the protocol level. 00:16:46.630 --> 00:16:47.450 But there's more. 00:16:47.730 --> 00:16:52.010 Yes, BOLT 12 enables this. There's still a lot of work to be done behind the 00:16:52.010 --> 00:16:57.730 screens. But at least now there's a way to sort of start doing that. And there's 00:16:57.730 --> 00:16:58.930 even more. This is amazing. 00:16:59.090 --> 00:17:03.590 This is amazing. Well, we talked about this Bitcoin ATM. We talked about the 00:17:03.590 --> 00:17:04.230 Bitcoin ATM. 00:17:04.410 --> 00:17:06.190 Yes, that's the problem we haven't solved yet. 00:17:07.040 --> 00:17:12.840 Right. So where I put in $10 and now it's solved because the ATM will 00:17:12.840 --> 00:17:18.020 display a BOLT 12 thing, offer is the technical term, and it will say, 00:17:18.220 --> 00:17:23.990 take my money. Would you like this $10 worth of satoshis? And 00:17:23.990 --> 00:17:29.640 then my wallet, if it understands this, it will create the invoice and give it 00:17:29.640 --> 00:17:35.310 to the ATM and then the ATM pays it. So there we have the reverse flow. So my 00:17:35.310 --> 00:17:38.300 wallet creates an invoice and the ATM sends to it. 00:17:39.140 --> 00:17:39.620 Right. 00:17:40.870 --> 00:17:46.570 So yeah, BOLT 12 is a communication layer that allows wallets to basic— 00:17:46.570 --> 00:17:51.850 or nodes, Lightning nodes, to communicate invoices. I think that's the very short 00:17:51.850 --> 00:17:52.850 way to put it, right? 00:17:53.310 --> 00:17:57.110 Well, except that it is not the communication layer. So that's, I guess, what we 00:17:57.110 --> 00:17:58.370 need to explain next. 00:17:59.890 --> 00:18:01.690 It's more of a meta invoice. 00:18:01.910 --> 00:18:04.590 That's exactly what I was getting to, Sjors. You read my mind. 00:18:04.590 --> 00:18:05.970 Perfect. Exactly. 00:18:06.490 --> 00:18:10.970 So if we're creating a new communication layer or new ways for nodes to 00:18:10.970 --> 00:18:16.260 communicate, how does this actually work? How is this data sent from one 00:18:16.260 --> 00:18:17.760 Lightning node to another? 00:18:19.460 --> 00:18:24.140 Well, it will use an extension of, I think, BOLT 7 00:18:24.140 --> 00:18:29.990 called Onion Messages. So the Lightning Network already uses Onion 00:18:29.990 --> 00:18:35.130 routing to send payments, as I think we've discussed in earlier episodes what 00:18:35.130 --> 00:18:40.230 Onion routing is. So I send a message to the next node or a payment to the next 00:18:40.230 --> 00:18:45.360 node, and then they send it to the node after that, et cetera, et cetera. And 00:18:45.360 --> 00:18:48.620 every node only knows where it came from and the next hop. 00:18:49.580 --> 00:18:55.460 Well, to be more exact, every node knows from which neighboring node it got it 00:18:55.460 --> 00:18:59.380 and which next node, but it doesn't know where the message started or where the 00:18:59.380 --> 00:19:04.520 message will end, right? Or what the message is because it's encrypted on every step. 00:19:05.220 --> 00:19:11.020 Yeah, because as you unwrap, as you unpeel the onion, basically, there's a new 00:19:11.020 --> 00:19:14.540 secret and a new secret and a new secret and only the final destination will know 00:19:14.540 --> 00:19:19.200 precisely what was in there. And there's some tricks to make it look the same 00:19:19.200 --> 00:19:24.260 size. So yeah, you can't see how far along in the route you are. We talked about 00:19:24.260 --> 00:19:28.040 that with Joost Jager with this crazy postal analogy that didn't work. 00:19:28.580 --> 00:19:34.560 Yeah, I remember. So right now, it's already possible to send messages over 00:19:34.560 --> 00:19:39.360 the Lightning network, I think. Is this done by using zero Bitcoin 00:19:40.330 --> 00:19:41.590 payments or no? 00:19:41.590 --> 00:19:45.910 Yeah, either zero Bitcoin payments, or very small payments so what you're 00:19:45.910 --> 00:19:50.210 basically doing is sending a fake payment or a very small payment and then and 00:19:50.210 --> 00:19:54.990 that's using using the usual routing mechanisms that we talked about earlier and 00:19:55.340 --> 00:20:00.000 then next to the payment or even the fake payment there's a message which is 00:20:00.000 --> 00:20:04.880 whatever the message you want to send so this protocol upgrade actually makes 00:20:04.880 --> 00:20:05.920 that more elegant. 00:20:07.720 --> 00:20:11.620 Less resource intensive especially. Because those fake payments... 00:20:11.620 --> 00:20:16.260 Sure, sure, sure. I want to make this clear for myself and for our listeners. 00:20:17.080 --> 00:20:22.100 BOLT 7, so that's, you know, we just discussed BOLT 12. There's another BOLT, 00:20:22.220 --> 00:20:28.220 BOLT 7. BOLT 7 specifies how the messages are currently, what 00:20:28.220 --> 00:20:30.740 we just described, how that currently works. Is that correct or no? 00:20:31.410 --> 00:20:32.470 Yes, exactly. 00:20:32.650 --> 00:20:32.890 Right. 00:20:33.090 --> 00:20:34.170 The whole onion routing thing. 00:20:34.350 --> 00:20:40.550 And what we're going to be discussing now is an extension of BOLT 7 to help BOLT 12? 00:20:41.330 --> 00:20:42.010 That's right. 00:20:42.310 --> 00:20:43.930 Right. Okay. So we're going to discuss it. 00:20:44.030 --> 00:20:46.770 And maybe create the future in general because it's pretty cool. 00:20:46.950 --> 00:20:52.350 Is it a proposed change to BOLT 7 or is it already changed? It's a proposed 00:20:52.350 --> 00:20:53.310 change to BOLT 7. 00:20:53.650 --> 00:20:54.130 Yeah. 00:20:54.430 --> 00:20:56.990 Okay. So how would BOLT 7 be changed? 00:20:57.580 --> 00:21:03.460 Yeah, so it really, I think one way to say is it decouples the messaging from 00:21:03.460 --> 00:21:08.820 the payment side. Because so far when you use this onion routing messaging in 00:21:08.820 --> 00:21:13.900 Lightning, you're actually trying to make a payment. But now this can be 00:21:13.900 --> 00:21:17.960 separate. So you can actually send a message to any node on the network that 00:21:17.960 --> 00:21:23.960 supports this. And even ones that you don't have a payment channel with. So it's 00:21:23.960 --> 00:21:27.120 much easier to come up with a route. And it'll just forward it. 00:21:27.040 --> 00:21:28.890 Right, so right now— 00:21:28.890 --> 00:21:29.750 final destination. 00:21:29.750 --> 00:21:33.150 Right, so right now, if you want to send a message over the Lightning network, 00:21:33.150 --> 00:21:37.430 you're actually using all the payment routes, which are, you know, the payment 00:21:37.430 --> 00:21:43.430 channels. Even though it's a zero Bitcoin payment, you're still 00:21:43.430 --> 00:21:45.910 using the existing payment channels. 00:21:46.630 --> 00:21:51.570 And you're really taxing those channels too, right? You're holding coins in 00:21:51.570 --> 00:21:53.970 reserve and all sorts of complicated things. 00:21:55.300 --> 00:22:01.140 Right, and with this proposed extension to BOLT 7, you wouldn't actually use the 00:22:01.140 --> 00:22:05.580 payment channels anymore. You'd just send messages to other Lightning nodes on 00:22:05.580 --> 00:22:06.140 the network. 00:22:06.620 --> 00:22:11.820 Yeah, and this means that, at least for now, this would be free. As in, any node 00:22:11.820 --> 00:22:15.580 will just relay any message that it's getting. Because [unclear] limited. 00:22:14.880 --> 00:22:20.280 Because so far there was a fee involved? It was just a regular payment channel 00:22:20.280 --> 00:22:21.780 fee type of fee? 00:22:22.550 --> 00:22:26.050 So when you make a payment, every hop you have to pay a little bit for. Now, if 00:22:26.050 --> 00:22:30.090 you have a fake payment, you don't end up actually paying. So it is a problem. 00:22:32.950 --> 00:22:37.590 But if you're making small payments or zero payments, then you are paying all the 00:22:37.590 --> 00:22:39.790 routes in between for the service of relaying a message. 00:22:40.490 --> 00:22:40.890 Right. 00:22:41.090 --> 00:22:47.050 But this new extension does not require that. But the good news is that it is far 00:22:47.050 --> 00:22:47.950 less resource intensive. 00:22:49.850 --> 00:22:53.570 Because a node that receives a message and needs to relay it can do that in one 00:22:53.570 --> 00:22:56.790 go and then it can forget it ever happened. It doesn't have to track anything. 00:22:57.170 --> 00:22:59.150 There's no secrets or all that sort of stuff. 00:22:59.550 --> 00:23:02.030 Right. That's the good news. Is there also bad news? 00:23:02.990 --> 00:23:08.050 Well, the bad news is because it's free. Like, you know, it could be DDoSed. So, 00:23:08.230 --> 00:23:11.830 you know, a node would have to rate limit things like don't send too many 00:23:11.830 --> 00:23:17.440 messages, and it's not guaranteed to arrive. So when you're sending a message 00:23:17.440 --> 00:23:22.640 using this BOLT 7 extension, it may arrive. It's like UDP in the network protocol. 00:23:23.590 --> 00:23:27.230 Right, so if you're currently sending a message over the Lightning network, 00:23:27.230 --> 00:23:31.430 you're using the payment channels, and you're essentially getting a confirmation 00:23:31.430 --> 00:23:37.350 that the message actually got to the recipient. While with this new extension, 00:23:38.030 --> 00:23:43.550 it's not using payment channels, and it's just using other nodes, and it's… 00:23:43.420 --> 00:23:48.000 it doesn't require the same level of resources and that kind of stuff. But you're 00:23:48.000 --> 00:23:52.660 not getting the same level of confirmation. You're not as sure that the message 00:23:52.660 --> 00:23:56.330 made it to the recipient. Is that right? 00:23:57.030 --> 00:24:01.750 Yeah, that's correct. However, if you want to reply, and you probably want to, if 00:24:01.750 --> 00:24:06.950 you're asking for an invoice, because you want the invoice, then in your message 00:24:06.950 --> 00:24:09.470 should be instructions on how to send a message back. 00:24:11.430 --> 00:24:17.390 So basically you just provide another bunch of onions that can be unpeeled on the 00:24:17.390 --> 00:24:20.950 way back. So the person you're talking to does not have to know where the message 00:24:20.950 --> 00:24:21.510 is coming from. 00:24:22.210 --> 00:24:27.250 Yeah. Basically the confirmation that the message ended up with the recipient is 00:24:27.250 --> 00:24:29.170 the fact that you got an invoice back, right? 00:24:29.730 --> 00:24:31.700 That's right. Yeah. 00:24:32.200 --> 00:24:35.860 Right. So does that cover the proposed extension to BOLT 7? 00:24:37.610 --> 00:24:41.470 I think so. I mean, I'm sure there's all sorts of subtle things that... I don't 00:24:41.470 --> 00:24:44.770 know, and we haven't covered, but I think that's the essence. 00:24:45.050 --> 00:24:46.650 If we got the basics, I'm happy. 00:24:49.260 --> 00:24:49.380 Yeah. 00:24:49.860 --> 00:24:53.580 So to reiterate, Sjors, do you want to reiterate? I'm going to reiterate, and 00:24:53.580 --> 00:24:59.420 then you can correct me if I'm wrong. So BOLT12, there's a new proposed BOLT12. 00:24:59.660 --> 00:25:03.640 It's actually implemented in C-Lightning already, I think. 00:25:04.380 --> 00:25:07.260 Yep. But it's not experimental, but yeah. 00:25:07.660 --> 00:25:11.560 Yeah, but that's the only implementation that has, the only Lightning 00:25:11.560 --> 00:25:15.680 implementation that has actually included it so far, right? It's not available 00:25:15.680 --> 00:25:17.800 for mobile wallets or anything like that yet. 00:25:18.320 --> 00:25:19.000 No. 00:25:19.700 --> 00:25:24.470 Right. And this BOLT 12 is an additional 00:25:24.470 --> 00:25:29.510 communication, a meta invoice is how you described it previously, 00:25:29.850 --> 00:25:35.700 that tells... Lightning nodes, which Lightning nodes to 00:25:35.700 --> 00:25:40.740 connect with or to ask for information about an invoice. And this allows for more 00:25:40.740 --> 00:25:42.820 flexibility on the invoices itself. 00:25:43.360 --> 00:25:48.240 That's right. Or in the case of the, you know, sending a payment, 00:25:49.030 --> 00:25:54.350 the BOLT 12 meta invoice basically says who to send the invoice to. 00:25:57.740 --> 00:26:02.140 Right. So in the case of the Bitcoin ATM, the BOLT 12 thing will tell you, okay, 00:26:02.240 --> 00:26:07.200 this is the ATM node. Please send an invoice to this node and we'll pay it. 00:26:08.950 --> 00:26:14.870 Yep. And the main problems it solves is it takes care of the fiat 00:26:14.870 --> 00:26:20.590 volatility. So you can create meta invoices ahead of the time of payment. 00:26:20.870 --> 00:26:26.650 It takes care of the secret. So you can use the same meta invoice for all my 00:26:26.650 --> 00:26:32.000 apples. And like you said, you can use a meta invoice to determine who is 00:26:32.000 --> 00:26:37.180 actually paying who. This is all done using a new extension to the BOLT 7 00:26:37.180 --> 00:26:41.410 messaging protocol that works on a best effort basis. 00:26:43.390 --> 00:26:46.370 Is that it? Did I just summarize it? 00:26:46.840 --> 00:26:47.820 I think so. 00:26:48.890 --> 00:26:53.850 Great. Sjors, I think we're done then. We did— Awesome. We did it. We made 00:26:53.850 --> 00:26:54.490 another episode. 00:26:55.030 --> 00:26:58.730 I think so, too. Let's hope the recording worked. Thank you for listening to the 00:26:58.730 --> 00:26:59.890 Van Wirdum Sjorsnado. 00:27:00.190 --> 00:27:00.890 There you go.