WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:16.240 --> 00:00:21.340 Live from Utrecht, this is Bitcoin, Explained. Hey, Sjors. 00:00:21.680 --> 00:00:22.120 Hello. 00:00:22.540 --> 00:00:23.100 How have you been? 00:00:23.640 --> 00:00:25.040 Not bad. It's only been three months. 00:00:26.700 --> 00:00:30.320 Was our last episode also a Bitcoin Core release episode, perhaps? 00:00:30.480 --> 00:00:32.140 No, no, no. We talked about silent payments. 00:00:32.540 --> 00:00:37.980 Oh, that's right. Yes, that is right. Well, this time we're going to discuss the 00:00:37.980 --> 00:00:40.480 new Bitcoin Core release because there is one. 00:00:40.640 --> 00:00:42.320 Version 28.0. 00:00:43.040 --> 00:00:48.820 First, here's a message from our sponsor, Coinkite. [unclear] put a bunch of 00:00:48.820 --> 00:00:50.180 presents here for me to look at. 00:00:50.380 --> 00:00:50.980 That's right. 00:00:52.370 --> 00:00:53.990 This looks like a battery. 00:00:54.290 --> 00:00:59.510 Yeah, this is a 9-volt battery. You know, the square-shaped battery for people 00:00:59.510 --> 00:01:00.870 who don't know what they look like. 00:01:01.070 --> 00:01:01.970 A Duracell battery. 00:01:02.170 --> 00:01:05.840 And then there's a little device next to it. Um, that is I believe called 00:01:05.840 --> 00:01:09.940 COLDPOWER which you can connect to the nine volt battery and then it can power 00:01:09.940 --> 00:01:14.840 any USB device, but you know probably the USB device you want to power with it 00:01:15.160 --> 00:01:16.700 is the COLDCARD 00:01:16.700 --> 00:01:22.540 Um, I yes, wait, so this is a Coinkite product 00:01:22.540 --> 00:01:23.640 that I'm holding right now? 00:01:23.640 --> 00:01:24.060 Yes. 00:01:24.060 --> 00:01:29.940 And oh, I see. I can… Wait, I have to maybe so what? Okay, 00:01:29.940 --> 00:01:34.900 yes. It's very unfortunate in moments like these that we don't have any video 00:01:34.900 --> 00:01:40.580 with our podcast. Okay, so I'm now attaching this little USB 00:01:40.580 --> 00:01:41.400 device. 00:01:41.520 --> 00:01:45.540 You should do it closer to the mic and then we can play the game that they do in 00:01:47.200 --> 00:01:50.700 Qmusic called Het Geluid, the sound, and then you have to guess what sound it is. 00:01:50.740 --> 00:01:55.240 This is a very Dutch in-joke. Okay, so now I connected the battery to the thingy, 00:01:55.380 --> 00:01:56.400 and now what? Now it's charging? 00:01:56.760 --> 00:02:01.420 No, no, that's just a USB port. Now you can connect a USB cable to that and then 00:02:01.420 --> 00:02:05.680 the COLDCARD to it, and then you have your hardware wallet getting power. Not so 00:02:05.680 --> 00:02:10.580 much charging, because I don't think it has a battery, but just it has power, so 00:02:10.580 --> 00:02:14.260 you can turn it on and you can move your files from the hardware wallet to the 00:02:14.260 --> 00:02:18.970 computer without... having this device connected to a USB port 00:02:19.540 --> 00:02:20.920 of the computer. 00:02:22.620 --> 00:02:28.140 I have absolutely no idea what's going on here. But I also don't want to linger 00:02:28.140 --> 00:02:32.840 on it for 10 minutes. They're not paying us enough for that. It's a very cool 00:02:32.840 --> 00:02:35.820 device, though. It's called the COLDPOWER. 00:02:35.940 --> 00:02:40.240 But I think they primarily want to sell more COLDCARDs, their hardware wallets. 00:02:40.380 --> 00:02:44.940 Okay, COLDCARDs. Wait, but I got something else as well. Here is the TAPSIGNER. 00:02:45.460 --> 00:02:46.880 What is this, Sjors? 00:02:47.760 --> 00:02:52.140 You can tap it and then it signs things. I think it's just kind of like an extra key. 00:02:52.140 --> 00:02:53.220 It just has your private key on it? 00:02:53.340 --> 00:02:57.620 Yeah, that wouldn't be your savings private key, obviously. It could be just one 00:02:57.620 --> 00:02:58.280 of many keys. 00:02:59.620 --> 00:03:03.320 And this is another Coinkite product. Coinkite's making all sorts of stuff 00:03:03.320 --> 00:03:06.660 nowadays, Sjors. I remember when they were just making hardware wallets. 00:03:06.860 --> 00:03:07.560 They're the Opendimes. 00:03:08.860 --> 00:03:09.300 Yeah. 00:03:11.240 --> 00:03:13.480 I mean, they've been at it for a long time, actually. 00:03:14.940 --> 00:03:18.300 Rodolfo was at the 2014 conference in Amsterdam. 00:03:18.700 --> 00:03:19.900 Oh, that's 10 years ago. 00:03:20.060 --> 00:03:24.100 Yeah, I don't remember what he was like. He was already selling stuff and 00:03:24.100 --> 00:03:29.000 building thingies and gadgets and who knows what. I don't think it was 00:03:29.000 --> 00:03:31.980 hardware wallets. Maybe it was actually back then. I don't know. And then here we 00:03:31.980 --> 00:03:36.980 got the calculator looking. Hardware Wallet as well. 00:03:37.200 --> 00:03:37.540 The Q. 00:03:37.860 --> 00:03:43.160 The Q. Okay. This is way more than they paid for. Let's get to 00:03:43.160 --> 00:03:44.680 the actual episode here. 00:03:44.800 --> 00:03:49.740 Well, there's another fun news, which is that how do I say this? Aaron stacks 00:03:49.740 --> 00:03:51.780 sats. Aaron stacks sats. 00:03:52.020 --> 00:03:53.840 Aaron stacks sats. 00:03:54.180 --> 00:04:00.000 Because we have connected you in Fountain so that the 00:04:00.000 --> 00:04:04.500 sats that are streamed now also go to you. So you didn't have to set up your own node. 00:04:04.660 --> 00:04:09.240 I think we need to make more episodes for that to actually return some dividends. 00:04:09.600 --> 00:04:11.320 I haven't seen anything come in, I think. 00:04:11.560 --> 00:04:13.280 No, because we haven't done an episode since. 00:04:13.280 --> 00:04:13.840 Okay, there we go. 00:04:13.980 --> 00:04:14.840 And they're not a sponsor. 00:04:15.300 --> 00:04:17.340 Apparently people aren't paying us for doing nothing. 00:04:17.620 --> 00:04:18.640 The podcasting 2.0 stuff. 00:04:18.700 --> 00:04:20.580 So let's get to the actual episode here, Sjors. 00:04:20.740 --> 00:04:21.140 Yes, sir. 00:04:22.960 --> 00:04:23.300 Bitcoin Core 28. 00:04:24.890 --> 00:04:30.250 We've mentioned in basically every other Bitcoin Core new release episode that 00:04:30.250 --> 00:04:34.090 there is a new Bitcoin Core release every half year. People know that by now, 00:04:34.310 --> 00:04:39.110 which means that whatever is done... at a certain time goes in. If it's not done 00:04:39.110 --> 00:04:42.450 yet, then it doesn't go in. You know, this is kind of different with some other 00:04:42.450 --> 00:04:46.390 software products: you will release a new version when some sort of new feature 00:04:46.390 --> 00:04:49.730 is done. Bitcoin Core, nope, every half year, there's just whatever is done is in 00:04:49.730 --> 00:04:54.110 there. So we're going to discuss what's in there this time. There is, uh, there 00:04:54.110 --> 00:04:56.850 are some at least slightly interesting things in there. 00:04:57.450 --> 00:04:57.890 Yes. 00:04:58.150 --> 00:04:58.550 I would say. 00:04:59.090 --> 00:05:00.850 I'd say it's quite a lot of interesting things. 00:05:01.030 --> 00:05:05.330 Yeah, it's like an actual upgrade. Sometimes it seems sort of like a maintenance 00:05:05.330 --> 00:05:10.810 upgrade. Now there's some actual new stuff here. We'll start off with what is, at 00:05:10.810 --> 00:05:15.050 least in my personal opinion, the least interesting one. I don't know why we're 00:05:15.050 --> 00:05:15.830 even discussing this. 00:05:15.850 --> 00:05:16.870 I think it's one of my favorites. 00:05:17.130 --> 00:05:17.930 The testnet one. 00:05:18.200 --> 00:05:20.400 Testnet 4. That's right, ladies and gentlemen. 00:05:20.620 --> 00:05:24.460 Why are we talking about Testnet? Testnet is not Bitcoin. Anyway, so there's a 00:05:24.460 --> 00:05:27.780 new Testnet. Sjors wants to talk about the new Testnet. What's new with the new 00:05:27.780 --> 00:05:28.180 Testnet? 00:05:28.360 --> 00:05:34.300 Well, there's two things in there. One is there were recently block storms, also 00:05:34.300 --> 00:05:36.500 known as the Lopocalypse. 00:05:38.120 --> 00:05:40.100 It's hard to pronounce, actually. It's easier to write. 00:05:41.560 --> 00:05:44.440 That is harder to pronounce than you would think. 00:05:45.690 --> 00:05:49.530 Jameson Lopp was just trolling everyone with just a single laptop producing 00:05:49.530 --> 00:05:55.170 hundreds of thousands of blocks, making Testnet 3 unusable for people with bad 00:05:55.170 --> 00:06:01.090 software, but also generally not easy to use. And it was exploiting a 00:06:01.090 --> 00:06:06.270 bunch of well-known vulnerabilities in Testnet 3 specifically. The problem with 00:06:06.270 --> 00:06:10.790 Testnet fundamentally, and we'll never be able to fix that, is that it cannot 00:06:10.790 --> 00:06:15.810 fully rely on proof of work the way Bitcoin does because all the proof of work is 00:06:15.810 --> 00:06:21.130 on Bitcoin. And if it was the same as Bitcoin, it would be a shitcoin and it 00:06:21.130 --> 00:06:21.790 would be attacked. 00:06:23.450 --> 00:06:28.330 I mean, the problem, of course, is that performing proof of work actually costs, 00:06:28.710 --> 00:06:33.250 requires you to perform proof of work. There's actual energy you have to expend. 00:06:33.610 --> 00:06:36.890 And the reason miners do that on Bitcoin is because they get paid for it in 00:06:36.890 --> 00:06:42.250 Bitcoin. While testnet, which is designed to not be worth anything, and if it 00:06:42.250 --> 00:06:47.850 does get worth, you know, if people start valuing it, they reset it, you know, 00:06:47.950 --> 00:06:51.250 they being the developer. So it's like designed to not have any value, so 00:06:51.250 --> 00:06:55.470 therefore there's actually no... incentive to perform proof of work. 00:06:55.590 --> 00:07:00.610 Yeah, and even if there was, which indeed, you know, sort of the rule is that if 00:07:00.610 --> 00:07:06.590 that happens, if people start valuing testnet coins, then it gets reset. There's 00:07:06.590 --> 00:07:09.950 just a new testnet, which is what's happening, and part of the reason is because 00:07:09.950 --> 00:07:14.930 people started selling testnet 3 coins. But it was also just becoming harder and 00:07:14.930 --> 00:07:19.470 harder to use, and one of the weaknesses in the testnet 3, so in order to deal 00:07:19.470 --> 00:07:21.310 with this lack of incentives, 00:07:23.420 --> 00:07:28.460 Testnet has a few extra rules that keep it somewhat workable in the face of 00:07:28.460 --> 00:07:34.180 miners messing with the network. In particular, what could happen without these 00:07:34.180 --> 00:07:39.520 rules is a miner decides to put a giant ASIC farm on Testnet 3, 00:07:39.940 --> 00:07:43.720 increase the difficulty to some really, really high difficulty, and then 00:07:43.720 --> 00:07:48.410 disappear. And then if you're just at home trying to test something with your 00:07:48.410 --> 00:07:53.370 CPU, you just cannot mine a block anymore. And so Testnet had a rule that after 00:07:53.370 --> 00:07:58.250 20 minutes, you could do it anyway at a very low difficulty. 00:07:59.410 --> 00:08:03.570 And it was a bunch of these rules. And they were such that they were creating a 00:08:03.570 --> 00:08:08.190 mess because it was too easy to mine hundreds of thousands of blocks very 00:08:08.190 --> 00:08:13.440 quickly. And Testnet 4 fixes that. At least fixes it somewhat because 00:08:13.440 --> 00:08:14.860 fundamentally you can't really fix it. 00:08:16.160 --> 00:08:18.560 Yeah, okay. So how does testnet4 fix it? 00:08:19.690 --> 00:08:25.340 I don't know. I forgot. It basically adds a few more constraints to the 00:08:25.340 --> 00:08:31.240 timestamp. I think one of the problems was that you would... So after 20 00:08:31.240 --> 00:08:34.440 minutes, you were able to mine a block at difficulty 1, which is the lowest 00:08:34.440 --> 00:08:39.660 difficulty. And then what you would do is the last block in the difficulty period 00:08:39.660 --> 00:08:43.910 would also be 1. And then... you would keep doing that, then the difficulty would 00:08:43.910 --> 00:08:47.510 permanently be 1. So it wouldn't be temporary for 20 minutes, it would just be 00:08:47.510 --> 00:08:51.950 permanent. And so I think the new rule is that the block at the edge of the 00:08:51.950 --> 00:08:57.460 difficulty period has to be the normal difficulty. So the downside is that if 00:08:57.460 --> 00:09:03.360 some ASIC drives up the difficulty, you can mine blocks. after 20 minutes, 00:09:03.580 --> 00:09:07.660 but not the first block of the difficulty period. So some ASIC will have to come 00:09:07.660 --> 00:09:12.880 around once every two weeks to produce one block if this happens, but they can't 00:09:12.880 --> 00:09:14.360 then lower the difficulty permanently. 00:09:16.330 --> 00:09:16.810 Okay. 00:09:17.110 --> 00:09:18.590 Because the problem is once the difficulty... 00:09:18.590 --> 00:09:22.510 I hope you can excuse me for kind of not being very interested in all the 00:09:22.510 --> 00:09:27.170 adversarial ways that testnet can be abused. I want to just move on to actual 00:09:27.170 --> 00:09:27.830 Bitcoin here. 00:09:28.150 --> 00:09:29.750 Yeah. This is fundamental. 00:09:29.870 --> 00:09:33.190 I mean, if you think there's something to add for our listener that might find 00:09:33.190 --> 00:09:37.080 this interesting, go ahead. But I'm done with the testnet stuff, Sjors. 00:09:37.550 --> 00:09:39.290 Well, then you want to talk about the time warp fix? 00:09:39.290 --> 00:09:41.770 Yes, let's go to the... Oh, no, that is still testnet. 00:09:42.010 --> 00:09:44.170 Yeah. But it’s a bit [unclear]… 00:09:43.300 --> 00:09:46.060 Okay, I thought we were already there. Go for it. 00:09:46.420 --> 00:09:49.600 Well, the time warp fix is something we talked about in the great consensus 00:09:49.600 --> 00:09:50.540 cleanup episode. 00:09:50.900 --> 00:09:51.360 Yes. 00:09:51.560 --> 00:09:56.440 So it's useful to try that on testnet, simply because maybe one day we want to 00:09:56.440 --> 00:09:58.800 use it on mainnet, but that's not the immediate plan here. 00:10:00.440 --> 00:10:04.580 And one practical reason why it's being deployed on testnet is because the time 00:10:04.580 --> 00:10:07.940 warp attack is another way to very quickly mine all the coins, 00:10:09.370 --> 00:10:13.200 like mine the whole subsidy. So you want to prevent that. We definitely want to 00:10:13.200 --> 00:10:17.720 prevent that on mainnet, because that's just bad. But on testnet, it's also 00:10:17.720 --> 00:10:21.140 important to prevent it, because otherwise someone's going to mine all 21 million 00:10:21.140 --> 00:10:24.560 coins on testnet, and then we have to make another testnet. 00:10:28.550 --> 00:10:29.950 Which is totally fine. 00:10:30.900 --> 00:10:35.120 For you, yeah, but it's a pain in the butt to make a new testnet. There's actual 00:10:35.120 --> 00:10:36.160 work involved. 00:10:36.400 --> 00:10:42.240 Okay. So there is a time warp fix that is part of the Great Consensus Cleanup, 00:10:42.260 --> 00:10:47.560 which we discussed just two episodes ago. So everyone 00:10:47.560 --> 00:10:53.380 still has that fresh in their memory. Exactly. You know, January 2022 or 00:10:53.380 --> 00:10:54.660 whenever the last episode was. 00:10:54.760 --> 00:10:55.300 Two weeks ago. 00:10:56.740 --> 00:11:00.600 But that has been rolled out on testnet. So in a way, it's also being tested now, 00:11:00.620 --> 00:11:02.940 I guess. You can sort of see it that way. 00:11:03.340 --> 00:11:08.260 Yeah, and it already led to some discussion. Some people argued that this fix is 00:11:08.260 --> 00:11:12.780 not good enough, not even for mainnet. And so it's good to have this code out 00:11:12.780 --> 00:11:15.820 there. When code is actually out there, people are more likely to look at it and 00:11:15.820 --> 00:11:16.360 critique it. 00:11:17.730 --> 00:11:18.090 Good. 00:11:18.970 --> 00:11:22.010 But one thing that's important to point out, I already kind of said it, but 00:11:22.010 --> 00:11:26.590 oftentimes when there's a software proposal, people hash out the whole software 00:11:26.590 --> 00:11:29.670 proposal, then they agree, then they deploy it on testnet, then they deploy it on 00:11:29.670 --> 00:11:33.310 mainnet. That's not what's happening here. This is just a test on testnet. It's 00:11:33.310 --> 00:11:36.830 not like the test that we're about to do this on mainnet. 00:11:37.260 --> 00:11:42.360 Yeah, there's actually a practical reason to use this on testnet right now. 00:11:42.540 --> 00:11:45.500 That's the reason it's on testnet right now, not to test it for mainnet. 00:11:45.800 --> 00:11:49.800 Well, it's there to test in case we want it for mainnet, but it's not like the 00:11:49.800 --> 00:11:52.860 typical software test on testnet is really like, okay, we think this is 00:11:52.860 --> 00:11:56.260 completely ready. Whereas in this case, we don't think that. 00:11:57.380 --> 00:12:00.470 Right. Okay. Done with testnet? 00:12:00.890 --> 00:12:01.330 Yes. 00:12:01.590 --> 00:12:03.780 Awesome. Let's go to Bitcoin. 00:12:04.650 --> 00:12:05.770 Talk about the mempool. 00:12:06.170 --> 00:12:07.130 Yeah, so there's an actual... 00:12:07.130 --> 00:12:10.210 Well, the mempool isn't really the blockchain either. So do you care? Are you 00:12:10.210 --> 00:12:11.070 going to fall asleep again? 00:12:12.510 --> 00:12:15.050 Mempool definitely counts. Mempool counts as Bitcoin. 00:12:15.450 --> 00:12:15.590 Okay. 00:12:15.790 --> 00:12:16.990 Mempool is sort of... 00:12:16.990 --> 00:12:18.190 You heard it here first. 00:12:19.460 --> 00:12:25.180 I count it. I count it. I care about the mempool for reasons that we're going to 00:12:25.180 --> 00:12:31.100 explain right now. So there has been sort of a package of 00:12:31.100 --> 00:12:33.480 upgrades, which also includes a package. 00:12:36.210 --> 00:12:41.270 It's true, though. So the problem in a nutshell and the reason that this is 00:12:41.270 --> 00:12:44.370 needed, I think, correct me if I'm wrong. 00:12:46.300 --> 00:12:52.120 So in case there are any listeners that don't know this, every Bitcoin node has a 00:12:52.120 --> 00:12:57.140 mempool, and the mempool collects transactions that are then included in blocks. 00:12:57.540 --> 00:13:01.260 So there's sort of like a waiting room for transactions until they're actually 00:13:01.260 --> 00:13:05.400 included in the blockchain. So if you are a miner, then you're actually mining 00:13:05.400 --> 00:13:07.620 from the mempool of your node, essentially. 00:13:08.040 --> 00:13:11.860 Yeah. There's no one mempool. Everybody has their own mempool, but all the 00:13:11.860 --> 00:13:16.380 mempools... tend to be very similar, especially the top of the mempool, the thing 00:13:16.380 --> 00:13:18.040 that's probably going to be mined next. 00:13:18.260 --> 00:13:24.140 Right. But there is a problem, namely that mempools are also limited 00:13:24.140 --> 00:13:29.520 in size. It depends per person or per node how big that size is exactly, but 00:13:29.520 --> 00:13:33.900 ultimately a mempool also has a size, in the same way that a Bitcoin block has a 00:13:33.900 --> 00:13:38.260 maximum size. So if your transaction doesn't have 00:13:38.260 --> 00:13:43.530 enough fee, then it will actually drop out of people's mempools. 00:13:43.670 --> 00:13:43.930 Yeah. 00:13:44.740 --> 00:13:50.100 Now, this is a real problem, especially for second-layer protocols like 00:13:50.100 --> 00:13:55.740 Lightning, where sometimes you need to get a 00:13:55.740 --> 00:14:00.660 transaction that is sort of pre-made, pre-signed. You need to get it into a 00:14:00.660 --> 00:14:04.640 block, but first of all, you need to get it into a mempool to get it into a 00:14:04.640 --> 00:14:10.360 block. Now, if the fee is too low to get it into a block, but it at least gets 00:14:10.360 --> 00:14:14.330 into the mempool, you can fix that with this trick called... Child pays for parent 00:14:14.330 --> 00:14:17.790 Or with replace by fee depending on the type of transaction. 00:14:17.790 --> 00:14:21.750 Right, but in this case we're talking about child pays for parent mostly right? 00:14:21.750 --> 00:14:23.350 for the fix we're going to discuss right now. 00:14:23.350 --> 00:14:26.970 Yeah, because if you're talking about Lightning what often happens is that you 00:14:26.970 --> 00:14:31.090 and your channel partner agree about a transaction. You pre-sign it, and so at 00:14:31.090 --> 00:14:33.830 the moment you sign it you don't know what the mempool fees are going to be in 00:14:33.830 --> 00:14:39.430 the future. And so the only way to, if there's some conflict or you can't find 00:14:39.430 --> 00:14:44.110 the other side, the only way to get your transaction then included to get it in 00:14:44.110 --> 00:14:47.130 the mempool at all is that it must have enough fees to make it in the mempool 00:14:47.130 --> 00:14:52.110 period. And to bump it, you cannot replace it because you don't have the, 00:14:52.210 --> 00:14:56.460 yeah, you can't RBF a transaction because the other side has to do the same 00:14:56.460 --> 00:15:01.860 thing. And so child pays for parent is then the only way to get it included in 00:15:01.860 --> 00:15:03.760 the next block or to even get it in the mempool. 00:15:03.760 --> 00:15:09.210 Yeah, so in other words, if I want to get my money out of a Lightning payment 00:15:09.210 --> 00:15:15.190 channel then I can do that uh and then if the transaction fee of 00:15:15.190 --> 00:15:19.870 me doing that is not high enough because this was all like pre-done then what I 00:15:19.870 --> 00:15:23.770 can do is okay you know what, I'll just spend that money that I'm sending to 00:15:23.770 --> 00:15:27.850 myself, anyways and I'll spend it in a new transaction also to myself, and I'll 00:15:27.850 --> 00:15:33.830 include a higher fee, and then you know, nodes will figure out that okay if we 00:15:33.830 --> 00:15:37.610 include both of these transactions in a block then we get both of these fees. So 00:15:37.610 --> 00:15:43.110 that usually works unless if that first transaction where I'm originally getting 00:15:43.110 --> 00:15:47.210 my money out of this Lightning payment channel, if that transaction doesn't even 00:15:47.210 --> 00:15:52.850 have enough fee to fit in people's mempools, then I also can't claim it with this 00:15:52.850 --> 00:15:58.450 child pays for parent trick because now this child that I'm using, the child 00:15:58.450 --> 00:16:01.730 payment that I'm using to claim the money, isn't referring to something that 00:16:01.730 --> 00:16:05.410 other nodes know about because the parent transaction... The first transaction 00:16:05.410 --> 00:16:10.930 already fell out of their mempool. So the idea to fix that is that 00:16:10.930 --> 00:16:16.330 I should be able to tell other nodes on the network, hey, I want to pay 00:16:16.330 --> 00:16:20.930 for this transaction as well. So please consider both of these transactions. I 00:16:20.930 --> 00:16:24.030 know that the first transaction doesn't have enough fee for your mempool. I know 00:16:24.030 --> 00:16:27.970 that. But look, I got another transaction. Please consider them both. 00:16:27.870 --> 00:16:29.410 Yeah, and a nice thing… 00:16:28.990 --> 00:16:31.070 That's what we're trying to accomplish here. 00:16:31.250 --> 00:16:35.170 Yeah, and if you can do that, then... One benefit is that when you open a 00:16:35.170 --> 00:16:39.830 Lightning channel, you can use a very low fee by default because you know you can 00:16:39.830 --> 00:16:43.070 just add whatever fees are needed later. And you don't have to think about the 00:16:43.070 --> 00:16:48.770 absolute worst case inscription-type mempool situation. Yeah, 00:16:48.890 --> 00:16:53.450 just assume an easy mempool. So it would be nice if this was possible, but 00:16:53.450 --> 00:16:54.230 currently it isn't. 00:16:54.640 --> 00:16:58.760 Yeah, I'll repeat this one more time to make it very simple, hopefully, in case 00:16:58.760 --> 00:17:02.640 there's still someone out there doesn't understand. So when it comes to including 00:17:02.640 --> 00:17:08.350 transactions into blocks, transactions are potentially considered... in 00:17:08.350 --> 00:17:12.090 combinations. Like if one transaction spends from another, then the fees are sort 00:17:12.090 --> 00:17:15.470 of added up and a miner will figure, okay, if I include them all, then I get 00:17:15.470 --> 00:17:15.950 enough fees. 00:17:16.130 --> 00:17:18.030 Yeah, and the miner has an incentive to do that, of course. 00:17:18.170 --> 00:17:22.810 Yeah, so the goal is to accomplish a similar logic for the mempool. So nodes will 00:17:22.810 --> 00:17:26.650 also see, okay, we're going to consider these transactions as a combination of 00:17:26.650 --> 00:17:31.510 transactions rather than each individually. Okay, so that's what we're trying to 00:17:31.510 --> 00:17:35.600 achieve here. You know, I'm saying we... that's what Bitcoin Core developers are 00:17:35.600 --> 00:17:36.220 trying to achieve. 00:17:36.560 --> 00:17:41.080 Yeah, some Bitcoin Core developers, not me per se, but I try to understand what they're doing. 00:17:41.280 --> 00:17:46.680 Right, and now in Bitcoin Core 28, there's been some actual good progress on 00:17:46.680 --> 00:17:49.080 this goal. 00:17:49.420 --> 00:17:53.200 Yeah, we've got four buzzwords basically, and we'll try to explain them. 00:17:53.340 --> 00:17:59.340 So the first one you wrote down is one parent, one child packages. 00:18:00.180 --> 00:18:00.660 Yes. 00:18:01.720 --> 00:18:02.860 Yeah, go on. 00:18:03.340 --> 00:18:08.960 Yeah, so the most simple example, which is the example you gave, is you have one 00:18:08.960 --> 00:18:14.240 parent, for example, this Lightning close thing, and one child, which is your fee 00:18:14.240 --> 00:18:20.100 bump. And that is a special case of a package, the simplest possible package. 00:18:21.280 --> 00:18:25.320 So basically support has been added to Bitcoin Core to handle that very specific 00:18:25.320 --> 00:18:25.760 case 00:18:27.270 --> 00:18:33.220 using, under the hood, something called the orphanage. As far 00:18:33.220 --> 00:18:34.080 as I understand it. 00:18:34.440 --> 00:18:40.340 So there is actually a part of the Bitcoin Core code that is called 00:18:40.340 --> 00:18:40.980 the orphanage. 00:18:41.100 --> 00:18:45.280 Yes. And remember when Roger Ver said that Bitcoin Core kills babies? Well, it 00:18:45.280 --> 00:18:48.900 turns out Bitcoin Core kills a lot of them because the orphanage doesn't really 00:18:48.900 --> 00:18:49.640 work. 00:18:49.740 --> 00:18:54.600 It was actually true. Okay. So what is the orphanage and how does it work? How 00:18:54.600 --> 00:18:55.420 does it not work? 00:18:56.320 --> 00:18:59.720 I'm a little vague on this, so if you really, truly, deeply want to understand 00:18:59.720 --> 00:19:04.120 this, you should look at everything Gloria Zhao has been writing on various 00:19:04.120 --> 00:19:05.280 mailing lists and other places, 00:19:05.800 --> 00:19:07.940 which explains in more detail. 00:19:08.080 --> 00:19:09.800 But roughly the idea is this. 00:19:12.530 --> 00:19:16.390 So you and I are exchanging transactions. You want to close your channel. You 00:19:16.390 --> 00:19:20.530 want to send me those transactions, right? And so the first thing you do is you 00:19:20.530 --> 00:19:24.810 tell me, hey, I have some new transactions. Namely, and then you don't give me 00:19:24.810 --> 00:19:28.750 the full transaction. You just give me some identifier of them. So you give me a 00:19:28.750 --> 00:19:32.910 list and I look at that list and I say, well, okay, send them to me. So then 00:19:32.910 --> 00:19:34.430 you're sending me the full transactions. 00:19:35.870 --> 00:19:39.980 But... And so this would be the Lightning close transaction that you want to send 00:19:39.980 --> 00:19:44.760 me and the child that you want to send me. However, before we did any of that, I 00:19:44.760 --> 00:19:48.220 told you, like, I'm not interested in transactions that are paying a very low fee. 00:19:49.600 --> 00:19:53.740 And so the Lightning action transaction, let's say, is below that level, but your 00:19:53.740 --> 00:19:54.440 child is above it. 00:19:54.520 --> 00:19:59.020 So you're, for example, saying, I only want transactions that at least pay three 00:19:59.020 --> 00:20:00.260 sats per byte. 00:20:00.580 --> 00:20:06.110 And so you being very nice, you don't send me the... The thing that you actually 00:20:06.110 --> 00:20:11.070 want to include, you just sent me the child. And that child then goes into the 00:20:11.070 --> 00:20:15.690 orphanage, into my orphanage, because I recognize that this transaction looks 00:20:15.690 --> 00:20:21.270 interesting, seems to pay a lot of fees, but I don't know the parent. So then a 00:20:21.270 --> 00:20:26.450 while later, probably a fraction of a second later, I ask you... could you please 00:20:26.450 --> 00:20:32.430 give me this parent? And you say, sure. You didn't send it before because 00:20:32.430 --> 00:20:36.430 the fee rate, but now because I'm asking you, if I'm asking you, you're going to 00:20:36.430 --> 00:20:40.250 send it to me regardless. And so I look at it and say, well, this doesn't pay 00:20:40.250 --> 00:20:41.690 enough fees and I just throw it away. 00:20:41.830 --> 00:20:42.110 Sure. 00:20:42.350 --> 00:20:46.660 And then later on, the child is also thrown out of the orphanage. That's how it 00:20:46.660 --> 00:20:47.240 used to work. 00:20:47.360 --> 00:20:48.040 That's rough. 00:20:48.660 --> 00:20:52.120 You know, life on the blockchain is rough and life in the mempool is even rougher. 00:20:53.130 --> 00:20:58.650 Oh my god. So you request the parent of that poor child and I send you the parent 00:20:58.650 --> 00:21:00.970 and you still throw them both away? 00:21:01.270 --> 00:21:01.470 Yes. 00:21:02.430 --> 00:21:03.830 Do you at least throw them away together? 00:21:04.310 --> 00:21:10.030 No, probably separately. So anyway, so that is, as far as I 00:21:10.030 --> 00:21:14.250 understand, really the thing that is being fixed. So you could say it's a bit of 00:21:14.250 --> 00:21:18.410 a hack. It doesn't really scale towards more complicated groups of transactions. 00:21:18.410 --> 00:21:22.770 But this one child, one parent use case is very useful already, for the example 00:21:22.770 --> 00:21:28.340 we just discussed. So I believe the main thing that this release changes is 00:21:28.340 --> 00:21:32.630 that... And when you're sending this parent, this time it will look at it and 00:21:32.630 --> 00:21:36.170 say, oh, look at that. If I combine this parent with this child that I have here 00:21:36.170 --> 00:21:40.050 in the orphanage, it does pay enough. Let me accept that and let me forward it to 00:21:40.050 --> 00:21:44.960 peers the same way, who then repeat the same process, if they're all upgraded. So 00:21:44.960 --> 00:21:49.460 as long as there is a bunch of upgraded nodes between you and the miner, they 00:21:49.460 --> 00:21:50.740 will finally get both of them. 00:21:50.820 --> 00:21:52.540 This is a very wholesome upgrade then. 00:21:52.840 --> 00:21:53.180 Yes. 00:21:53.200 --> 00:21:54.340 I'm very happy with this one. 00:21:54.340 --> 00:21:56.240 But it is also a bit of a duct tape solution. 00:21:56.900 --> 00:21:57.300 Why? 00:21:57.740 --> 00:22:02.500 Well, the orphanage is not really designed to handle the generic case of 00:22:02.500 --> 00:22:08.320 thousands of packages, etc. And you can quite easily overwhelm it. So 00:22:08.320 --> 00:22:10.860 if you send, let's say, instead of... 00:22:10.860 --> 00:22:11.960 It's a small orphanage. 00:22:11.960 --> 00:22:16.720 It's a very small orphanage. So if you're sending a thousand children, 00:22:17.100 --> 00:22:22.580 then the orphanage is going to throw away all but the last five. 00:22:23.360 --> 00:22:24.380 Right, so 00:22:24.380 --> 00:22:25.980 it's a hard knock life. 00:22:25.980 --> 00:22:29.280 It's a hard life on the mempool, even harder than on the blockchain. 00:22:30.780 --> 00:22:34.500 So basically what you're saying is 00:22:34.850 --> 00:22:40.430 the adversarial you know person in the Bitcoin 00:22:40.430 --> 00:22:46.230 network can intentionally create all kinds of transactions that don't even 00:22:46.230 --> 00:22:46.750 have 00:22:48.830 --> 00:22:50.230 a parent or a child. 00:22:50.310 --> 00:22:54.470 Well, they might have it, but you're just, yeah, you're never going to ask for it 00:22:54.470 --> 00:22:59.210 because there's too many orphans at the same time. Stuff like that. So, as far as 00:22:59.210 --> 00:23:03.230 I understand it, there needs to be a better mechanism to really deal with this 00:23:03.230 --> 00:23:07.930 problem of one parent, one child, and multiple parents, multiple children. But 00:23:07.930 --> 00:23:12.310 this, you know... Hopefully it's good enough that under most circumstances you 00:23:12.310 --> 00:23:14.350 will get your Lightning close transactions to a miner. 00:23:14.810 --> 00:23:19.730 But there might be a better solution. Tomorrow. Tomorrow. 00:23:20.690 --> 00:23:21.510 I don't know. 00:23:21.870 --> 00:23:24.390 I'm making Annie references, Sjors. 00:23:25.400 --> 00:23:25.940 Okay. 00:23:26.380 --> 00:23:27.000 Orphanage. 00:23:28.240 --> 00:23:30.540 Never mind. We're moving on to the next point. 00:23:31.880 --> 00:23:34.620 There are V3 transactions. 00:23:35.200 --> 00:23:36.120 Yeah, and so... 00:23:36.120 --> 00:23:37.200 Version three transactions. 00:23:37.360 --> 00:23:41.100 Yeah, and so that's just a field in the transaction that says number three, where 00:23:41.100 --> 00:23:42.920 it currently usually says number two. 00:23:44.450 --> 00:23:45.790 So you may wonder... 00:23:45.790 --> 00:23:49.270 So the transactions are the same, now they just are version three. Okay, what does it mean? 00:23:49.270 --> 00:23:51.550 Yeah, and that doesn't apply to all transactions, it applies to special 00:23:51.550 --> 00:23:53.990 transactions that care about the following. 00:23:55.190 --> 00:24:00.420 TRUC. And so... TRUC stands for, was it again, 00:24:00.580 --> 00:24:05.720 topologically constrained until confirmation. Topologically constrained until 00:24:05.720 --> 00:24:09.540 confirmation. So in other words, there are topologies, so how transactions relate 00:24:09.540 --> 00:24:14.980 to each other. There are rules for that in the mempool, not in the blockchain. So 00:24:14.980 --> 00:24:15.920 it's until confirmation. 00:24:17.650 --> 00:24:23.010 And you may wonder what rules? Well, roughly, it needs to be a one child, one 00:24:23.010 --> 00:24:26.490 parent pair. Exactly that special case that we just talked about. 00:24:28.610 --> 00:24:32.190 And then the other rule, I believe, is that the child cannot be more than 10 00:24:32.190 --> 00:24:34.030 kilobytes or 10 kilo-vbytes. 00:24:35.650 --> 00:24:41.330 And this just means that if you opt into this version number, there are a lot of 00:24:41.330 --> 00:24:45.750 shenanigans that somebody trying to keep you out of the mempool or keep you from 00:24:45.750 --> 00:24:49.350