WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:17.490 --> 00:00:22.190 Live from Utrecht, this is Bitcoin Explained. Hey, Sjors. 00:00:22.590 --> 00:00:22.850 Hello. 00:00:23.450 --> 00:00:29.410 First of all, I want to... thank Coinkite, the sponsor 00:00:29.410 --> 00:00:35.310 of our show, for producing a beautiful COLDCARD Q, which Sjors just passed 00:00:35.310 --> 00:00:41.050 me in my hands. Sjors, what is this? I see it has a full QWERTY keyboard. I see 00:00:41.050 --> 00:00:42.830 it's an ECC calculator. 00:00:43.110 --> 00:00:45.170 An elliptic curve cryptography calculator. 00:00:45.370 --> 00:00:49.530 It is a beautiful device. It's unfortunate we don't have a video for our podcast. 00:00:49.670 --> 00:00:51.790 It essentially looks like a Nintendo, I guess. 00:00:53.210 --> 00:00:54.450 You mean a Game Boy? 00:00:54.890 --> 00:00:58.490 Game Boy. See, I did not play that many computer games. 00:00:58.630 --> 00:00:58.850 Clearly. 00:00:59.130 --> 00:01:01.310 Well, I played PC games. Anyhow. 00:01:01.650 --> 00:01:03.010 So this is a hardware wallet? 00:01:03.310 --> 00:01:08.710 Yeah, I believe it's essentially the same as their other COLDCARD wallets. It's 00:01:08.710 --> 00:01:09.450 just bigger. 00:01:09.770 --> 00:01:11.450 Yeah, bigger screen, bigger everything. 00:01:11.830 --> 00:01:15.730 Yeah, but my understanding is that fundamentally it's very similar. So it's not 00:01:15.730 --> 00:01:19.110 like they're introducing completely new security assumptions. 00:01:19.870 --> 00:01:21.710 Right. Did you buy this or did you get this? 00:01:21.660 --> 00:01:25.070 No, I got this one for free. I don't think we got it because we're sponsored. I 00:01:25.070 --> 00:01:27.410 always get them because I test them as a developer. 00:01:28.210 --> 00:01:32.870 Fair enough. All right. Well, that's our sponsor, COLDCARD. They got a Q device. 00:01:33.110 --> 00:01:36.610 You can buy this, right? Online, go to coldcard.com, coincoin.com. 00:01:36.750 --> 00:01:37.010 Probably. 00:01:37.550 --> 00:01:43.130 Something like that. All right. So today, actually, we have another guest. 00:01:43.880 --> 00:01:44.440 Hello. 00:01:44.760 --> 00:01:46.900 Jesse de Wit. He's back. 00:01:47.240 --> 00:01:48.020 Here I am again. 00:01:48.520 --> 00:01:54.260 Maybe for those that didn't listen to the previous episode, you can repeat a 00:01:54.260 --> 00:01:55.420 small introduction of yourself. 00:01:55.840 --> 00:02:00.480 Yeah, a small introduction. Jesse de Wit, I'm a Lightning developer working for Breez. 00:02:01.000 --> 00:02:06.640 Right. So we got you in last episode because we've been getting some requests 00:02:06.640 --> 00:02:10.960 to do Lightning episodes and Sjors and I are sort of getting out of our depth 00:02:10.960 --> 00:02:15.400 with like advanced Lightning topics. So very thankful that you came back. We're 00:02:15.400 --> 00:02:20.880 going to do another Lightning episode. This time we're going to discuss splicing. 00:02:21.560 --> 00:02:24.040 But before we get carried away by the wind... 00:02:24.040 --> 00:02:26.920 Yeah, yeah, there's something else we want to discuss real quick, right, Sjors? 00:02:27.140 --> 00:02:27.600 That's right. 00:02:27.840 --> 00:02:32.940 We made an episode on the Tornado Cash trial at some point. This was episode 69, 00:02:33.280 --> 00:02:38.540 and the trial... Well, the trial actually happened this week. Prior... 00:02:38.540 --> 00:02:38.720 That's right. 00:02:38.980 --> 00:02:42.480 In previous, there were, like, hearings. There were, I don't know... 00:02:42.480 --> 00:02:46.120 Yeah, previously, there were just, like, five or so over the last two years, meta 00:02:46.020 --> 00:02:51.600 hearings. So they were about his pretrial detention, about which documents the 00:02:51.600 --> 00:02:57.500 defense wants, that sort of stuff. And today, no, sorry, this week there was two 00:02:57.500 --> 00:03:03.340 days of the actual trial in Den Bosch with extremely uncomfortable seats. Well, I 00:03:03.340 --> 00:03:06.160 mean, the seats are fine. They have little pillows, but if you have to sit on 00:03:06.160 --> 00:03:07.960 them for eight hours, it's very uncomfortable. 00:03:09.820 --> 00:03:14.800 There was quite a few people in attendance, like multiple journalists, even from 00:03:14.800 --> 00:03:15.940 the mainstream media. 00:03:18.000 --> 00:03:23.980 And lots of, you know, some of his supporters, probably also half the FBI, I 00:03:23.980 --> 00:03:26.000 wouldn't know, but some people in suits. 00:03:26.700 --> 00:03:28.060 That spoke American? 00:03:29.260 --> 00:03:30.640 Maybe, at least they, you know. 00:03:32.160 --> 00:03:37.760 So you attended, and so what I recall, I mean, I was at the hearings, and I was 00:03:37.760 --> 00:03:43.300 at the trial briefly, but not for the full two days like you. And 00:03:43.300 --> 00:03:48.320 what I recall from the hearings at least was that they revealed it really seemed 00:03:48.320 --> 00:03:53.710 like the case was going to boil down to should a DAO be considered 00:03:53.710 --> 00:03:56.530 like a company? No, 00:03:57.070 --> 00:04:01.490 it goes beyond that. They're basically saying the whole DAO is just a little 00:04:01.490 --> 00:04:05.970 fantasy and really the three people were in control of everything. 00:04:06.210 --> 00:04:10.950 I mean, that's kind of what I mean. It's not really decentralized in any meaningful way. 00:04:10.950 --> 00:04:14.850 They don't really care what the company is. They're saying that Tornado Cash, 00:04:14.990 --> 00:04:18.230 whatever that is, whether that's a company or an entity or just a group of 00:04:18.230 --> 00:04:23.580 people, is like a business in the way it's operated, you know, 00:04:24.140 --> 00:04:27.360 as they would, like if they were prosecuting, say, a criminal organization, they 00:04:27.360 --> 00:04:30.440 don't care that it's, you know, Mafia Incorporated doesn't exist, right? 00:04:30.460 --> 00:04:30.640 Yeah. 00:04:30.940 --> 00:04:34.440 So in that sense, they're arguing it's just a business and they're doing things 00:04:34.440 --> 00:04:39.090 for profit and the profit came from pumping the token, if I translate it. 00:04:39.270 --> 00:04:40.750 Yeah, the tornado token. 00:04:40.910 --> 00:04:44.870 Because it's very clear that there was no money coming directly from the 00:04:44.870 --> 00:04:49.510 transactions on the mixer in the way it's designed. We explained that in episode 00:04:49.510 --> 00:04:49.970 69. 00:04:51.370 --> 00:04:54.410 But they said even though there's no direct flow of money, they're still 00:04:54.410 --> 00:04:58.510 profiting from it. But I guess even if they weren't profiting from it, they're 00:04:58.510 --> 00:05:04.240 still allowing mixing to happen, and that itself is enough. So it's a pretty 00:05:04.240 --> 00:05:07.880 fundamental case, I would say. In the beginning, we didn't know if maybe there 00:05:07.880 --> 00:05:13.640 was some gotcha, like something really different that would have made the case. 00:05:14.570 --> 00:05:19.090 For example, they were not running relayers themselves, any of that stuff. 00:05:19.230 --> 00:05:24.210 The original concern, at least, was writing open source code should not be 00:05:24.210 --> 00:05:27.270 illegal, basically whatever people use it for. 00:05:27.530 --> 00:05:32.310 Yeah, so the prosecutor keeps saying that writing open source is fine, it's 00:05:32.310 --> 00:05:38.180 great, we love it, but... If you want to make money with it in any way, 00:05:38.300 --> 00:05:43.360 I guess, then you can't do it. So it's like privacy is legal, but if you make any 00:05:43.360 --> 00:05:47.380 money offering it, it's not legal. That's sort of my takeaway from it. And 00:05:47.380 --> 00:05:52.140 they're trying to make the distinction between VPN privacy, which is like 00:05:52.140 --> 00:05:58.090 communications, and money privacy, which are... objects or money which is treated differently. 00:05:58.630 --> 00:06:04.630 Were there any new insights this week as far as you could say 00:06:04.630 --> 00:06:08.770 or compared to the hearings that I attended? Or was it kind of the same thing, 00:06:08.870 --> 00:06:09.410 just a bit more? 00:06:09.550 --> 00:06:12.570 Well, the hearings you attended were not supposed to be about the case itself at all. 00:06:12.570 --> 00:06:13.670 I mean, I know, but they kind of were. 00:06:13.810 --> 00:06:16.370 Yeah, they were exactly because there's lots of media present. 00:06:18.560 --> 00:06:22.320 I don't know. I don't really think so. It felt to me like it was roughly just, 00:06:22.400 --> 00:06:26.380 you know, going into more detail, explaining which law articles, you know, the 00:06:26.380 --> 00:06:29.560 prosecution would explain, okay, you know, there's this money laundering, 00:06:29.880 --> 00:06:32.820 different articles, and we're not talking about Article A, but we're talking 00:06:32.820 --> 00:06:36.940 about Article B, that sort of clarification. So I took a lot of notes, but I 00:06:36.940 --> 00:06:42.360 really have to take my notes and go talk to an actual legal expert to understand 00:06:42.360 --> 00:06:42.800 the meaning. 00:06:43.310 --> 00:06:43.670 Right. 00:06:43.850 --> 00:06:47.030 Exactly what it said. And then the prosecution always has the advantage they can 00:06:47.030 --> 00:06:52.930 paint a very nice narrative, a story, but the defense does not have that. 00:06:53.150 --> 00:06:57.110 It's not so easy. I mean, of course, they try to explain how open source works 00:06:57.110 --> 00:07:00.770 and that decentralization is a good thing and that privacy is important, that 00:07:00.770 --> 00:07:06.190 sort of stuff. But a lot of the time they just have to spend shooting holes at 00:07:06.190 --> 00:07:09.890 individual arguments of the prosecution. So they have to say, well, if you look 00:07:09.890 --> 00:07:15.630 at Article 64B, you know, the word holding means this and it doesn't mean that. 00:07:15.810 --> 00:07:21.190 And they also have to try 15 different arguments just to see if one of the 15 00:07:21.190 --> 00:07:24.590 works. And that makes it, as the audience, makes it more difficult to understand. 00:07:25.010 --> 00:07:28.950 And especially if you're not a lawyer yourself, it's hard to estimate whether 00:07:28.950 --> 00:07:33.930 just because he says it with conviction doesn't mean it works. And it's important 00:07:33.930 --> 00:07:39.560 to know that we don't have jury trials. So the goal is not to explain things and 00:07:39.560 --> 00:07:45.500 to convince a jury of non-legal people, like in the US. It is merely 00:07:45.500 --> 00:07:49.580 to convince the judges. And the judges have already received, I don't know, a 00:07:49.580 --> 00:07:54.580 million pages of documents and reports and they've all read it. So they also 00:07:54.580 --> 00:07:57.820 already know the arguments that both sides are going to make. So it's kind of a 00:07:57.820 --> 00:08:01.780 performative thing almost, where you have to say it out loud so people can... 00:08:01.650 --> 00:08:05.390 listen to it, but the judges are kind of like, you know, behind the screen, and 00:08:05.390 --> 00:08:06.110 they're listening and they… 00:08:06.110 --> 00:08:11.070 Yeah, and, uh, the verdicts will come in 00:08:11.070 --> 00:08:12.810 May 14th. 00:08:12.810 --> 00:08:16.650 May 14th. All right, last question, so what's… 00:08:17.960 --> 00:08:21.700 I guess we discussed this in the actual episode, episode 69, so we don't have to 00:08:21.700 --> 00:08:26.340 get into it. But the reason you attended is it could have relevance for Bitcoin 00:08:26.340 --> 00:08:27.460 development as well, potentially. 00:08:27.780 --> 00:08:31.040 In the long run, it will. I'm pretty sure about that because it's kind of a 00:08:31.040 --> 00:08:35.920 moving game where the front line is moving and maybe you could say, oh, the front 00:08:35.920 --> 00:08:39.340 line is in shitcoin land. But if you read some of the arguments that the 00:08:39.340 --> 00:08:43.680 prosecutor is making, the really generic arguments like if you make something, 00:08:43.950 --> 00:08:47.710 that is decentralized, the fact that you could have made it centralized, but you 00:08:47.710 --> 00:08:52.270 made it decentralized already means you deliberately did something to aid money 00:08:52.270 --> 00:08:57.090 laundering. So if that argument stands, then, you know, basically Satoshi would 00:08:57.090 --> 00:08:57.850 be screwed. 00:08:58.330 --> 00:08:58.490 Right. 00:08:59.990 --> 00:09:03.350 Because Satoshi could have made a centralized system, right? And he didn't. And 00:09:03.350 --> 00:09:06.030 he made money. Arguably. We don't know if he has any money. 00:09:08.370 --> 00:09:10.650 I mean, he still had to earn it as well, right? 00:09:12.620 --> 00:09:13.740 He still had to mine it. 00:09:15.140 --> 00:09:19.340 Yeah, but he wouldn't have been able to mine it if it didn't exist. I don't know 00:09:19.340 --> 00:09:20.940 what kind of argument would be made there. 00:09:21.320 --> 00:09:22.720 Anyways, thanks for your sacrifice. 00:09:24.340 --> 00:09:28.760 I'm impressed to hear about the cushion situation and that you pulled through 00:09:28.760 --> 00:09:29.180 anyways. 00:09:29.420 --> 00:09:33.000 I found that if you pile some jackets and stuff, then it's a little bit more comfortable. 00:09:33.180 --> 00:09:37.100 You got it all figured out. All right, one more quick note before we actually get 00:09:37.100 --> 00:09:42.160 to splicing. You wanted to mention something about MARA Pool. MARA did this thing 00:09:42.160 --> 00:09:42.980 with the block. 00:09:44.200 --> 00:09:46.960 Which you could see on mempool.space, that's what this is about, right? 00:09:47.040 --> 00:09:51.700 Yeah, if you are into nonsense, then you may have noticed that MARA Pool mined a 00:09:51.700 --> 00:09:56.320 block that if you look at it on mempool.space, it looks like a picture of an M 00:09:56.320 --> 00:09:59.920 just because of the way mempool.space visualizes it. 00:09:59.960 --> 00:10:00.440 It's their logo, yeah. 00:10:00.520 --> 00:10:02.560 If you go to any other website, it won't look like that. 00:10:03.980 --> 00:10:09.020 Point is, they achieve this by putting transactions in a very specific order. All 00:10:09.020 --> 00:10:11.020 these transactions are nonsensical OP_RETURN transactions. 00:10:11.800 --> 00:10:13.380 All of them? Not all of them, right? 00:10:13.380 --> 00:10:14.540 As far as I know, the whole block. 00:10:14.680 --> 00:10:16.160 The whole block was nonsense? 00:10:16.420 --> 00:10:16.560 Yep. 00:10:17.760 --> 00:10:23.380 I'll get to that. So basically, we had episode 84, where we talked about 00:10:23.380 --> 00:10:27.660 about six months ago, MARA Pool mined an invalid block. And the reason they mined 00:10:27.660 --> 00:10:31.340 an invalid block was because they were putting transactions in the wrong order. 00:10:31.560 --> 00:10:37.280 So if transaction A is created and transaction B spends transaction A, they 00:10:37.280 --> 00:10:41.300 must appear in that block in that order. So transaction A first, transaction B 00:10:41.300 --> 00:10:45.280 next. And they just sorted them all by, I don't know, by name or something crazy. 00:10:45.860 --> 00:10:49.180 And so the order was wrong and the block was invalid, and they lost a couple 00:10:49.180 --> 00:10:53.900 hundred thousand dollars. But now, looking back, that they have created this 00:10:53.900 --> 00:10:58.940 graffiti block, I guess, where the order of the transaction is used as a feature, 00:10:59.160 --> 00:11:03.420 my guess is that's what they were sort of trying to get to. That still does not 00:11:03.420 --> 00:11:06.160 explain why they tested that on Mainnet instead of on Testnet. 00:11:08.000 --> 00:11:10.040 They were experimenting back then. 00:11:10.340 --> 00:11:13.540 But the reason, I guess, why they picked OP_RETURN transactions this time is 00:11:13.540 --> 00:11:19.460 because you can just make them all independent and the order doesn't matter. You 00:11:19.460 --> 00:11:23.880 don't get an invalid order. But it would be more, if they want to continue this 00:11:23.880 --> 00:11:28.980 artistic career of theirs, I think it would be better to mine real transactions 00:11:28.980 --> 00:11:32.920 that are actually paying roughly the maximum fee that you would mine, maybe 00:11:32.920 --> 00:11:37.470 slightly less and then order those in a visual pattern. So you do not know in 00:11:37.470 --> 00:11:40.190 advance what the block is going to look like. Your algorithm just has to figure 00:11:40.190 --> 00:11:45.210 out how to take whatever is in the mempool and write copyright Sjors 00:11:45.210 --> 00:11:46.590 on it. 00:11:46.590 --> 00:11:49.850 Yeah, you just got to make sure that the order is still not invalid. 00:11:49.970 --> 00:11:53.630 Exactly. So you have to, exactly. So it's much more, it would require 00:11:53.630 --> 00:11:57.670 significantly more skill. I do not believe it is a good use of anyone's time, but 00:11:57.670 --> 00:11:59.370 if you are into this, please do it well. 00:12:00.390 --> 00:12:05.810 Right, okay. So that sort of explains what was maybe, probably, possibly going on 00:12:05.810 --> 00:12:10.430 in episode 84. So that was a second callback to an earlier episode. Now let's 00:12:10.430 --> 00:12:11.550 make a new episode, Sjors. 00:12:12.250 --> 00:12:12.950 Yes, good idea. 00:12:13.150 --> 00:12:15.930 Yes, sir. You're down to make a new episode? 00:12:16.130 --> 00:12:16.990 Let's make a new episode. 00:12:17.130 --> 00:12:18.590 Let's make one about splicing. 00:12:20.120 --> 00:12:26.060 Okay, so splicing is a concept that exists in Lightning. First, what is 00:12:26.060 --> 00:12:30.380 it? Let's start with a very basic one-sentence explanation. What is splicing? 00:12:30.980 --> 00:12:35.660 Splicing is basically giving you the capability to change the capacity of an 00:12:35.660 --> 00:12:36.420 existing channel. 00:12:37.300 --> 00:12:42.200 Okay, so I have a channel with Sjors, say. There's, I don't know, let's say one 00:12:42.200 --> 00:12:46.860 Bitcoin in that channel. And we can increase that to two Bitcoin or half a 00:12:46.860 --> 00:12:47.980 Bitcoin, increase or decrease. 00:12:48.140 --> 00:12:49.000 Increase or decrease, yeah. 00:12:49.120 --> 00:12:54.720 Yeah, that's what splicing is. And why would 00:12:54.720 --> 00:12:58.980 anyone want to do this? Maybe that's a good follow-up. What's the actual benefit 00:12:58.980 --> 00:13:04.840 here? Why not just open a new channel or why not, I don't know, receive coins in 00:13:04.840 --> 00:13:05.480 the channel? 00:13:06.020 --> 00:13:11.700 Yeah, so a Lightning channel, you basically want the lifetime of a Lightning 00:13:11.700 --> 00:13:17.300 channel to be very long. And during the lifetime of the channel, you want it to 00:13:17.300 --> 00:13:22.030 be operational. And definitely as a routing node, for example, if you want to 00:13:22.030 --> 00:13:26.190 increase the capacity of your channel as a routing node, you want your channel to 00:13:26.190 --> 00:13:30.690 always be available. because otherwise people won't be able to route payments 00:13:30.690 --> 00:13:32.170 over it and you won't make any fees. 00:13:33.950 --> 00:13:39.230 The alternative would be closing and opening a channel or opening an additional 00:13:39.230 --> 00:13:40.130 channel, for example. 00:13:42.470 --> 00:13:46.730 But yeah, it saves a lot in chain fees in the end, basically, as well. 00:13:47.050 --> 00:13:51.950 Why does it save in chain fees versus opening an additional channel? 00:13:52.870 --> 00:13:53.970 What's the benefit? 00:13:53.970 --> 00:13:57.430 It's basically the closing cost that you don't have. 00:13:59.470 --> 00:14:00.270 Because... 00:14:02.500 --> 00:14:07.940 Well, you splice in this channel, so that means maybe we should talk a little bit 00:14:07.940 --> 00:14:09.500 about how splicing works. 00:14:10.040 --> 00:14:13.440 Well, hang on, it makes sense. I mean, eventually you're going to want to close 00:14:13.440 --> 00:14:17.380 the channels, and if you keep opening new channels, that means you have to close 00:14:17.380 --> 00:14:21.440 all the channels, while if you replace the same channel, then you only have to 00:14:21.440 --> 00:14:24.140 close one channel. So that's what you're saving, essentially, right? 00:14:24.280 --> 00:14:24.820 Yeah, that's what you're saving. 00:14:24.820 --> 00:14:28.680 And it's half the transactions in the long run, right? Because closing is one 00:14:28.680 --> 00:14:30.080 transaction, opening is one transaction. 00:14:30.350 --> 00:14:30.830 Right, yeah. 00:14:31.570 --> 00:14:33.650 Though I guess you theoretically could combine them. 00:14:36.620 --> 00:14:39.480 I think you mentioned another reason why this was good. 00:14:40.650 --> 00:14:46.470 Or you want it to always work and the fees are, there's less fees, 00:14:46.650 --> 00:14:47.750 less on-chain transactions. 00:14:47.750 --> 00:14:50.530 Yeah, we covered the part that it always works. Because if you close the channel, 00:14:50.830 --> 00:14:54.530 then nothing works until you've reopened it and waited six blocks. 00:14:54.830 --> 00:14:59.050 Yeah, exactly. Yeah, so if you would close and reopen the channel, yeah, your 00:14:59.050 --> 00:15:04.150 channel is temporarily unavailable. So nobody will be able to route over it. With 00:15:04.150 --> 00:15:10.130 splicing, we'll get into that. You'll be able to keep using the channel while 00:15:10.130 --> 00:15:15.530 you've spent your previous channel, basically. During the splice, you can... 00:15:15.530 --> 00:15:21.430 Okay, why is this like a challenge at all? Why is this a problem? What 00:15:21.430 --> 00:15:22.370 is the challenge here? 00:15:22.450 --> 00:15:26.190 Why wasn't this finished in 2017 like the white paper promised? 00:15:27.870 --> 00:15:31.690 Yeah, or just why isn't this standard? What's even the problem that we're trying 00:15:31.690 --> 00:15:32.210 to solve? 00:15:33.450 --> 00:15:38.990 Um, so there were many design decisions on how to do splicing, like, how do you 00:15:38.990 --> 00:15:42.370 increase the capacity of a channel? Because what a channel, a Lightning channel 00:15:42.370 --> 00:15:45.750 is, it is basically a UTXO on chain. 00:15:46.950 --> 00:15:48.810 So that has a certain capacity. 00:15:49.150 --> 00:15:53.090 Right. It has a fixed capacity. There's no way to add something to an existing 00:15:53.090 --> 00:15:53.690 UTXO. 00:15:53.790 --> 00:15:54.110 No, no. 00:15:54.410 --> 00:15:57.190 Yeah, exactly. So that's the challenge we're trying to solve. 00:15:57.250 --> 00:16:01.430 So that's the challenge we're trying to solve and multiple ways people are trying 00:16:01.430 --> 00:16:06.670 to do that. For example, Rene Pickhardt, he mentioned, maybe we could have like 00:16:06.670 --> 00:16:12.310 two UTXOs in the same channel or there are other design decisions. 00:16:12.310 --> 00:16:14.870 And then replace one at a time, something like that. 00:16:15.440 --> 00:16:15.840 Yeah. 00:16:16.160 --> 00:16:20.060 I mean, this is obviously not what we don't have to get into, but that would be 00:16:20.060 --> 00:16:24.280 the general sort of idea there. Yeah, okay. But that's not what splicing is. 00:16:24.300 --> 00:16:30.200 That's not what splicing is. Because with splicing, what you do is you spend the 00:16:30.200 --> 00:16:31.180 funding transaction. 00:16:33.480 --> 00:16:38.220 So the funding transaction is your channel on-chain, right? And then off-chain, 00:16:38.240 --> 00:16:44.160 you have a bunch of commitment transactions, which are the previous states of 00:16:44.160 --> 00:16:44.960 your Lightning channel. 00:16:45.140 --> 00:16:48.800 Yeah, every time Sjors and I update our channel, we're getting a new off-chain 00:16:48.800 --> 00:16:52.820 transaction that spends from the UTXO, basically. And we're not broadcasting that initially. 00:16:53.080 --> 00:16:56.800 Yeah, and all these transactions are valid transactions, and you would be able to 00:16:56.800 --> 00:17:00.420 broadcast them at any time, but only one of them is the latest, and you will, um, 00:17:00.420 --> 00:17:05.820 yeah… but with splicing, what you do is you spend the funding 00:17:05.820 --> 00:17:07.640 transaction. And... 00:17:09.770 --> 00:17:15.370 With the transaction that spends a funding transaction, you add an input to that 00:17:15.370 --> 00:17:21.150 if you want to increase the channel capacity, or you add an output to that if you 00:17:21.150 --> 00:17:24.170 want to decrease the channel capacity, basically. 00:17:24.490 --> 00:17:29.370 Okay, so we're spending basically all the funds from the channel, from the UTXO, 00:17:29.430 --> 00:17:35.150 to a new UTXO, which then becomes the channel, I would assume, right? 00:17:35.270 --> 00:17:37.020 Yeah. That then becomes the channel, yeah. 00:17:37.160 --> 00:17:40.200 Okay, so from the outside, this would look, but we'll get to that, I guess, 00:17:40.240 --> 00:17:43.180 towards the end. It looks like you're closing the channel and you're just opening 00:17:43.180 --> 00:17:47.260 another channel, but there is magic involved, which means that the existing 00:17:47.260 --> 00:17:48.060 channel continues. 00:17:48.460 --> 00:17:48.900 Yes. 00:17:49.200 --> 00:17:53.940 Yeah, so let's get there, because for now, it would sound like you can't use the 00:17:53.940 --> 00:17:59.780 new channel until the new channel would confirm, or... Kind of, right? 00:18:00.060 --> 00:18:03.500 That's sort of at least where my mind is going to when I hear this. 00:18:04.460 --> 00:18:06.120 Yeah, and you're sort of right. 00:18:06.260 --> 00:18:06.480 Okay. 00:18:07.920 --> 00:18:10.840 Because when we're spending this funding transaction... 00:18:12.910 --> 00:18:18.830 We have to update the states. Every time a new payment will come in after that, 00:18:18.970 --> 00:18:22.770 we'll have to update the states on both of our channels, like our old channel and 00:18:22.770 --> 00:18:26.290 our new channel. We have to update the states on both of them. 00:18:26.570 --> 00:18:31.970 Wait, that's a small note. Of course, I would assume, but please just confirm. So 00:18:31.970 --> 00:18:36.370 when you are splicing, this has to be cooperative between both parties, right? 00:18:36.550 --> 00:18:36.750 Yeah. 00:18:37.130 --> 00:18:41.250 Yeah, okay. So that's the only way you can do it. You have to both agree, we're 00:18:41.250 --> 00:18:45.350 going to update this channel. And that's how you spend the coins from the UTXO to 00:18:45.350 --> 00:18:46.150 the new UTXO. 00:18:46.250 --> 00:18:50.290 And then you have to do duplicate bookkeeping. Because I guess the question is, 00:18:50.530 --> 00:18:54.270 you just made a transaction, but it's in the mempool, and it may or may not 00:18:54.270 --> 00:18:58.610 confirm. If it doesn't confirm, then the splice never happened. So you'd better 00:18:58.610 --> 00:19:02.690 have all the transactions that keep happening while your channel is in this 00:19:02.690 --> 00:19:06.930 phase. You'd better remember all those transactions as if the channel was never 00:19:06.930 --> 00:19:12.420 spliced in. But if it does confirm, well, then the original things didn't happen. 00:19:12.940 --> 00:19:17.400 So somebody could cheat you that way. So you really have to pretend that you have 00:19:17.400 --> 00:19:20.860 two identical channels and update them both at the same time. 00:19:21.000 --> 00:19:25.200 Hang on. I mean, I am following, but I also think you're skipping ahead. 00:19:25.400 --> 00:19:25.580 Okay. 00:19:25.920 --> 00:19:29.480 So let's, I mean, I think what you say sounds right. 00:19:31.050 --> 00:19:35.670 But let's go back to the challenge. The challenge is it's not confirmed yet. So 00:19:35.670 --> 00:19:40.610 how can you use an unconfirmed UTXO as a channel when it's not confirmed? Isn't 00:19:40.610 --> 00:19:41.610 that like a risk, right? 00:19:41.930 --> 00:19:46.630 If we hook into what Sjors was saying, then you had an old channel on chain, 00:19:46.750 --> 00:19:50.810 right? And this channel is on chain and it has these off-chain commitment 00:19:50.810 --> 00:19:56.530 transactions. So these... Off-chain commitment transactions can be broadcast at 00:19:56.530 --> 00:20:01.870 any time and spend our channel. And if that ever happens, then our new 00:20:01.870 --> 00:20:06.330 spliced-in channel that's in the mempool will never be the truth. 00:20:06.870 --> 00:20:11.410 Right, that could become a double spend, essentially. So that could be rejected 00:20:11.410 --> 00:20:15.930 if one of the channel states is broadcast before the splicing transaction is 00:20:15.930 --> 00:20:16.790 confirmed, right? 00:20:16.970 --> 00:20:17.150 Yeah. 00:20:17.290 --> 00:20:19.210 That's what you say. Yeah, okay, I get that. 00:20:19.390 --> 00:20:20.230 Yeah, that's what I'm saying. 00:20:20.530 --> 00:20:20.730 Right. 00:20:21.630 --> 00:20:26.630 So that's one of the scenarios. And the other scenario would be that eventually 00:20:26.630 --> 00:20:29.610 our splicing transaction confirms. 00:20:31.370 --> 00:20:36.590 And maybe that's closed later as well, but let's just assume that the 00:20:36.590 --> 00:20:39.210 splice transaction confirms. 00:20:42.960 --> 00:20:45.580 What you have to do during this period... 00:20:45.580 --> 00:20:46.940 The problem with that... 00:20:46.940 --> 00:20:51.940 Now let's say I have... Before the splice, all the money was on my side. A while 00:20:51.940 --> 00:20:55.900 before the splice, all the money was on my side. But then it moved to your side. 00:20:56.360 --> 00:21:01.950 And then we do the splice. And if the splice then happens, now could I just cheat 00:21:01.950 --> 00:21:06.210 and try to cheat with the original transaction? Because all these punishments 00:21:06.210 --> 00:21:10.210 transactions that you have won't work anymore because we have just created a new 00:21:10.210 --> 00:21:14.170 on-chain transaction. So all these old penalty transactions don't work anymore. 00:21:14.270 --> 00:21:15.690 So that needs to be solved. 00:21:17.640 --> 00:21:20.620 So in the old, you're talking about the old channel? 00:21:20.900 --> 00:21:26.060 Yeah, so I would, you know, can I still cheat with the transactions from before 00:21:26.060 --> 00:21:28.960 the old channel was closed? I know the answer, but I'm asking it. 00:21:29.040 --> 00:21:33.620 You can still cheat with those. Yes, absolutely. But because your peer has the 00:21:33.620 --> 00:21:39.300 revocation key for these transactions, he can then steal all your money in that 00:21:39.300 --> 00:21:44.380 channel. So in that case, if you are stealing from like the old channel, right? 00:21:48.380 --> 00:21:53.060 then your commitment transaction will confirm. And then because you were 00:21:53.060 --> 00:21:57.270 cheating, I can then spend the funds in that channel all for myself. 00:21:57.390 --> 00:22:01.230 But if I understand correctly, after the splice is confirmed, then I can no 00:22:01.230 --> 00:22:04.530 longer cheat with the old transactions, right? Because those old cheat 00:22:04.530 --> 00:22:05.690 transactions won't work anymore. 00:22:06.130 --> 00:22:10.870 Yeah, exactly. Those won't work anymore because UTXO is spent. 00:22:11.750 --> 00:22:14.690 So it's like you have a blank slate basically every time you do this. 00:22:14.930 --> 00:22:20.040 Yeah, so once the splice transaction confirms, you can actually drop all the old 00:22:20.040 --> 00:22:21.220 states that you had. 00:22:22.000 --> 00:22:23.380 Once it confirms, yeah. 00:22:23.640 --> 00:22:26.360 Yeah, once it's deeply confirmed, basically, and you're sure that it won't be 00:22:26.360 --> 00:22:27.100 reorged out. 00:22:27.420 --> 00:22:30.640 But I think the question we were still getting at, or the answer we were still 00:22:30.640 --> 00:22:35.780 getting at, is how can you safely use a channel before it's confirmed? That's the 00:22:35.780 --> 00:22:37.340 key question here, right? 00:22:37.640 --> 00:22:41.820 Yeah, and that's, I guess, the key question. And the trick, how we're doing that, 00:22:41.940 --> 00:22:47.240 is that we're actually using both channels at the same time. We're using... every 00:22:47.240 --> 00:22:52.080 state update that we do to the channel, we're doing them on the old channel and 00:22:52.080 --> 00:22:52.880 on the new channel. 00:22:53.100 --> 00:22:53.520 Right. 00:22:53.780 --> 00:22:56.880 So then what happens if I try to spend more than is in the old channel? 00:22:57.220 --> 00:23:02.340 Yeah, so that won't work during this period. You will only be able to spend... So 00:23:02.340 --> 00:23:08.300 if you added funds to the channel, you will only be able to spend the additional 00:23:08.300 --> 00:23:12.020 funds after the transaction is deeply confirmed. 00:23:12.400 --> 00:23:18.240 Okay, so basically for a while we have like a quantum channel. It could still 00:23:18.240 --> 00:23:23.200 go either way and therefore we're updating both to keep track of each other, keep 00:23:23.200 --> 00:23:24.000 them in balance. 00:23:24.240 --> 00:23:27.380 Yeah, or to scare the regulators, it's a shadow bookkeeping. 00:23:28.620 --> 00:23:32.200 No, no, no, it's not shadow bookkeeping people. 00:23:33.960 --> 00:23:38.020 Anyway, so Sjors and I, if we're updating, if we're splicing and then we keep 00:23:38.020 --> 00:23:40.820 transaction or forwarding transactions, blah, blah, blah, we'll keep using 00:23:40.820 --> 00:23:44.440 Lightning, then we're doing everything double. We're just updating the old 00:23:44.440 --> 00:23:49.700 channel and the new channel until the new channel is confirmed on the chain. Now 00:23:49.700 --> 00:23:52.380 we can forget about the old channel. Now we just have the new channel. 00:23:52.380 --> 00:23:55.960 And while we're waiting, we cannot use the extra capacity that was added because 00:23:55.960 --> 00:23:58.100 we have to take into account the smallest of the two. 00:23:58.360 --> 00:24:00.940 Right. The smallest of the two. Yeah, exactly. Because you could also have 00:24:00.940 --> 00:24:06.220 removed funds and then it's basically the new lower balance that's the limit there. 00:24:06.460 --> 00:24:10.760 Okay. Well, that sounds actually kind of straightforward to me. But I would 00:24:10.760 --> 00:24:15.420 imagine there's a lot more sort of nitty-gritty to, like, how does the rest of 00:24:15.420 --> 00:24:19.640 the network, for example, know that this is the same channel rather than a 00:24:19.640 --> 00:24:23.380 completely new channel? Do they need to know? They need to have the routing 00:24:23.380 --> 00:24:25.280 information, for example, I would say. 00:24:25.340 --> 00:24:29.560 They need to have the routing information, but they won't know that this is the 00:24:29.560 --> 00:24:30.140 same channel. 00:24:30.980 --> 00:24:34.280 Okay. They'll consider it a different channel. 00:24:34.650 --> 00:24:36.110 They'll consider it a different channel. 00:24:36.230 --> 00:24:36.350 Okay. 00:24:36.610 --> 00:24:41.230 But there is a little thing there, and maybe we can skip to that now, because 00:24:41.230 --> 00:24:46.590 your old channel was gossiped through the gossip network, 00:24:46.810 --> 00:24:51.210 and it's a sender that wants to route through your channel. 00:24:53.170 --> 00:24:58.190 He has a graph of the Lightning Network on his local node, and he had that 00:24:58.190 --> 00:25:03.170 channel inside his graph, right? And as soon as you spend that channel on chain, 00:25:03.710 --> 00:25:09.610 he would consider that channel closed. So now the 00:25:09.610 --> 00:25:13.730 sender wouldn't be able to know, wouldn't be able to use your channel because he 00:25:13.730 --> 00:25:19.030 thinks it's closed and the splice transaction hadn't confirmed yet. So in the 00:25:19.030 --> 00:25:21.050 BOLTs, there is a... 00:25:21.050 --> 00:25:24.140 BOLTs means improvement for Lightning. 00:25:24.720 --> 00:25:26.560 Yes, basics of Lightning. 00:25:26.780 --> 00:25:28.820