WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:16.460 --> 00:00:18.980 Live from Utrecht, this is Bitcoin 00:00:18.980 --> 00:00:20.420 Explained. 00:00:20.740 --> 00:00:21.200 Hey Sjors. 00:00:21.580 --> 00:00:21.960 Hello. 00:00:22.420 --> 00:00:23.180 Welcome back. 00:00:23.500 --> 00:00:24.980 Welcome back. It's just been a few days. 00:00:25.890 --> 00:00:31.210 Yeah, well, this episode is delayed by like two weeks. We were supposed to record 00:00:31.210 --> 00:00:37.490 this at MIT in Massachusetts at the Bitcoin Expo, which you did attend. 00:00:37.810 --> 00:00:41.730 I did attend it and I did join some panels there. 00:00:43.010 --> 00:00:44.450 But we couldn't do the podcast. 00:00:44.910 --> 00:00:48.490 Yeah, we were supposed to do the podcast on stage. Big spectacle. 00:00:48.970 --> 00:00:52.930 But you got deported to El Salvador, and it was complicated to get you out there. 00:00:53.250 --> 00:00:58.310 It was a long story, Sjors. I'm surprised you didn't get deported to El Salvador. 00:00:58.790 --> 00:00:59.490 I'm happy. 00:00:59.690 --> 00:01:05.110 You look like MS-13. I mean, that's what people usually say when I say, yeah, I 00:01:05.110 --> 00:01:09.590 record a podcast with Sjors, and they say, oh, that's the MS-13 guy? And I have 00:01:09.590 --> 00:01:13.550 to explain, no, no, he just looks like that. He's actually a Bitcoin Core 00:01:13.550 --> 00:01:13.990 developer. 00:01:14.590 --> 00:01:15.230 All right. 00:01:15.910 --> 00:01:18.400 Well, somehow you made it back. 00:01:18.620 --> 00:01:19.560 I made it back. 00:01:19.880 --> 00:01:24.000 So we're going to record an episode on Bitcoin Core 29. 00:01:24.300 --> 00:01:24.860 That's right. 00:01:25.080 --> 00:01:28.980 Which means it's been about six months since the previous Bitcoin Core release. 00:01:29.280 --> 00:01:29.980 That's right. 00:01:30.560 --> 00:01:36.680 And as usual, that means there's some new features which we're going to discuss. 00:01:37.180 --> 00:01:38.080 Yep, that's right. 00:01:39.710 --> 00:01:44.560 Let's just get into it. What's up? Yeah, we have a sponsor. 00:01:44.920 --> 00:01:45.580 That's right. 00:01:45.840 --> 00:01:51.800 We are being sponsored by our very generous contributors to the show, Coinkite, 00:01:52.080 --> 00:01:57.220 who produce the COLDCARD hardware wallet. Right now I'm holding the... 00:01:57.220 --> 00:01:58.480 I think it's called the Q. 00:01:58.760 --> 00:02:02.200 COLDCARD Q, which looks like a big calculator. 00:02:02.540 --> 00:02:03.440 Or BlackBerry. 00:02:04.810 --> 00:02:06.490 You can store your Bitcoin on it. 00:02:07.780 --> 00:02:10.300 Have you actually used it or is it just laying around here? 00:02:10.740 --> 00:02:11.600 This one. 00:02:11.820 --> 00:02:12.040 Yeah. 00:02:12.950 --> 00:02:14.310 I'm not going to answer that question. 00:02:15.410 --> 00:02:18.060 Smart. I'll take that as a yes. 00:02:19.420 --> 00:02:20.820 I will check that it's still here. 00:02:22.310 --> 00:02:27.740 All right. So there's a new Bitcoin Core release. And then what we're going to do 00:02:27.740 --> 00:02:30.760 is we're going to highlight some features that are in this Bitcoin Core release. 00:02:31.540 --> 00:02:36.220 There's a bunch of features, including bug fixes and all kinds of smaller stuff. 00:02:36.360 --> 00:02:41.100 But we highlighted some features that are at least kind of worth discussing for a 00:02:41.100 --> 00:02:41.580 couple of minutes. 00:02:41.760 --> 00:02:46.040 I think they are. I mean, I had to convince you of some of them. But, yeah. 00:02:46.800 --> 00:02:50.120 I mean, you know, none of them are major of course, but 00:02:50.120 --> 00:02:51.920 I think some of them are major. 00:02:52.200 --> 00:02:57.360 Okay, let's get into it. So the first one is called UPnP has dropped. 00:02:57.960 --> 00:03:01.000 That's right. And by has dropped, I mean has been dropped. 00:03:01.510 --> 00:03:05.250 I mean, it's, wait, oh yeah, it's not included anymore. 00:03:05.250 --> 00:03:06.090 Yeah, it's removed. That's what that means. 00:03:06.290 --> 00:03:10.300 Yeah, I was thinking dropping, like, you know, dropping a new album. Yeah, 00:03:10.300 --> 00:03:10.560 exactly. 00:03:10.830 --> 00:03:15.690 The Bitcoin Core developers have dropped UPnP. Okay, it's no longer in Bitcoin 00:03:15.690 --> 00:03:16.270 Core, actually. 00:03:16.410 --> 00:03:16.550 Exactly. 00:03:16.750 --> 00:03:17.370 That's what it means. 00:03:17.550 --> 00:03:17.670 Yeah. 00:03:17.790 --> 00:03:18.970 So what is UPnP? 00:03:19.390 --> 00:03:25.230 Yeah, so UPnP is and was a way for you to make your Bitcoin node at home or 00:03:25.390 --> 00:03:31.360 wherever it is, reachable from the outside. Because typically, so when 00:03:31.360 --> 00:03:35.500 you're on a server, your node will find other peers to connect to, but it will 00:03:35.500 --> 00:03:39.060 also listen for other peers that want to connect to it. And if you're sitting on 00:03:39.060 --> 00:03:43.160 Amazon somewhere in a server park, that tends to just work. But if you're sitting 00:03:43.160 --> 00:03:49.100 at home, most routers or your home create a firewall and anybody 00:03:49.100 --> 00:03:53.460 that tries to connect to you will not succeed. You can connect to anybody you 00:03:53.460 --> 00:03:58.020 want. but nobody can connect to you as sort of a standard safety measure because 00:03:58.020 --> 00:04:02.120 they don't want, you know, random hackers to connect to random insecure Windows 00:04:02.120 --> 00:04:03.700 computers that you might be running. 00:04:04.040 --> 00:04:09.480 Yeah, okay, so... Because I always kind of wondered about this. Well, I always 00:04:09.480 --> 00:04:14.320 sort of knew the answer, but this confirms it. Like in my case, I 00:04:14.320 --> 00:04:20.600 do run Bitcoin Core, but I just downloaded the software, run it on my computer. 00:04:21.960 --> 00:04:27.640 But in my case, that means that I'm not actually sharing blocks or transactions 00:04:27.640 --> 00:04:29.120 with other nodes because... 00:04:29.120 --> 00:04:33.660 You are. However, you're not receiving connections. So if you make a connection 00:04:33.660 --> 00:04:38.580 to another node... you will send and receive blocks and transactions. So it's not 00:04:38.580 --> 00:04:43.400 about, you're not a leecher, basically, as they used to call that in Torrent 00:04:43.400 --> 00:04:47.760 jargon. You are sharing just as much. It doesn't really matter whether you are, 00:04:47.960 --> 00:04:52.140 whether who initiates the connection. It's just that. If nobody in the world is 00:04:52.140 --> 00:04:57.640 listening and everybody's trying to connect, then they have nowhere to connect 00:04:57.640 --> 00:04:59.140 to. So somebody needs to listen. 00:04:59.480 --> 00:05:04.980 Right, that's it. In your case, I don't know if you run a Node with or without 00:05:04.980 --> 00:05:05.540 the firewall. 00:05:06.380 --> 00:05:08.640 Yeah, so I run multiple nodes that you can reach. 00:05:08.960 --> 00:05:12.680 Right, so then my node, because I never changed any settings, right? I just, 00:05:12.860 --> 00:05:17.720 well, I changed some settings, but not this setting. So I basically run it out of 00:05:17.720 --> 00:05:22.580 the box. So then I am connecting to you. So then I'm sharing blocks and 00:05:22.580 --> 00:05:27.080 transactions with you that I might also get from like another source that is 00:05:27.080 --> 00:05:31.880 doing the same thing. But I will not connect to another Aaron. because the other 00:05:31.880 --> 00:05:35.860 Aaron is also running it out of the box. So I have no way of connecting to him 00:05:35.860 --> 00:05:40.920 and he has no way of connecting to me. So then, yeah, I mean, isn't that a 00:05:40.920 --> 00:05:44.280 problem? Like, isn't it a problem that if there's just too few, if there's too 00:05:44.280 --> 00:05:49.720 many Aarons and too few Sjorses, that it just becomes a form of centralization 00:05:49.720 --> 00:05:53.640 because everyone is running, you know, it becomes basically like a hub and spoke 00:05:53.640 --> 00:05:55.440 network, I guess would be the technical term. 00:05:55.600 --> 00:06:00.760 Yes, now we're nowhere near that point. because there are many, many thousands of 00:06:00.760 --> 00:06:05.640 nodes that are listening. So there's no shortage. However, we talked about in an 00:06:05.640 --> 00:06:09.600 earlier episode about ASMAP, which is like a map of the internet of which 00:06:09.600 --> 00:06:13.800 providers. And one of the things that Bitcoin Core wants to do in the future is 00:06:13.800 --> 00:06:18.660 to have more diverse connections. And I don't mean that in a DEI sense. I mean 00:06:18.660 --> 00:06:22.280 that in a sense of you should not have all your connections to Amazon. You should 00:06:22.280 --> 00:06:27.680 have one connection to Amazon, maybe one to Google, one to some ISP in Kenya, one 00:06:27.680 --> 00:06:33.620 to some ISP in Germany. So that if somebody is trying to mess with you, it's very 00:06:33.620 --> 00:06:37.720 difficult for them because they have to somehow pretend to be a lot of different 00:06:37.720 --> 00:06:42.840 internet providers in the world. And if we do that, and that means that the 00:06:42.840 --> 00:06:44.300 number of nodes that are listening... 00:06:45.880 --> 00:06:50.040 The nodes that are listening now that are sitting on Amazon and Google, exactly 00:06:50.040 --> 00:06:54.160 the kind of places where it's easy to set that up, they will get fewer 00:06:54.160 --> 00:06:59.840 connections. And all the nodes in obscure apartments 00:06:59.840 --> 00:07:04.680 and... random countries will get a lot more connections. And it could be, 00:07:04.860 --> 00:07:07.900 depending on the simulation, that that's too much, that you would start 00:07:07.900 --> 00:07:10.420 overloading the more obscure places. 00:07:10.900 --> 00:07:13.820 Yeah, because there's only one guy in Kenya running a node. 00:07:14.080 --> 00:07:14.320 Exactly. 00:07:14.500 --> 00:07:17.280 So that everyone wants to connect to the one guy in Kenya node. 00:07:17.460 --> 00:07:18.820 Yes, because it's not Amazon. 00:07:19.040 --> 00:07:19.180 Yeah. 00:07:19.460 --> 00:07:23.000 So in order to prevent that, it's probably necessary to increase the number of 00:07:23.000 --> 00:07:24.260 listening nodes at least somewhat. 00:07:25.490 --> 00:07:29.410 Now, so there are two kinds of nodes that listen by default. 00:07:30.690 --> 00:07:36.500 One is... Oh, sorry. No, let me rephrase that. There 00:07:36.500 --> 00:07:41.440 is another node that listens by default, which is a Tor node. Because if you set 00:07:41.440 --> 00:07:47.350 up Tor, you set it up usually to also use a hidden service. And it turns out that 00:07:47.350 --> 00:07:52.470 projects like Umbrel will do that automatically for you. And that's easier. But 00:07:52.470 --> 00:07:55.490 those are only on Tor, so it's not that useful if you're not on Tor. 00:07:55.750 --> 00:07:59.370 Yeah, they would only connect to other Tor users. 00:07:59.590 --> 00:08:02.970 And if you're running in a data center, then typically everything is just wide 00:08:02.970 --> 00:08:05.030 open, so everybody can connect to you. 00:08:06.330 --> 00:08:09.850 But there's also a tool that used to be included in very early versions of 00:08:09.850 --> 00:08:13.650 Bitcoin Core called UPnP. And what this would do is it would look for your 00:08:13.650 --> 00:08:16.810 router. So from the inside, it would look at the router and say, hey, router, 00:08:16.970 --> 00:08:21.530 please open this port for me, open this door, so that everybody who wants to talk 00:08:21.530 --> 00:08:22.370 to me can talk to me. 00:08:23.830 --> 00:08:28.490 And that worked. UPnP is the setting you use if you want to be a listening node. 00:08:29.010 --> 00:08:33.090 It was, yes. And so this was introduced quite a while ago, and that's why there 00:08:33.090 --> 00:08:36.970 are, from the beginning, there were quite a few listening nodes. I think it was 00:08:36.970 --> 00:08:41.570 on by default. So everybody who downloaded Bitcoin Core would... If possible, 00:08:41.810 --> 00:08:44.310 punch a hole in their router and start listening. 00:08:44.570 --> 00:08:45.390 Right, okay, yeah. 00:08:45.610 --> 00:08:50.780 Or in their firewall, I guess. Problem is that UPnP as a software package was 00:08:50.780 --> 00:08:56.160 extremely insecure. There were multiple bugs found in it. That would, say, allow 00:08:56.160 --> 00:08:59.000 somebody to take over your computer and steal your coins. 00:09:00.660 --> 00:09:01.740 That sounds bad. 00:09:02.120 --> 00:09:07.900 Yes, exactly. And so this was not removed, but it was turned off by default. 00:09:08.500 --> 00:09:11.780 So as a result, for many, many years, if you installed a new version of Bitcoin 00:09:11.780 --> 00:09:16.300 Core, it would simply not do any of this unless you turned it on yourself at your own risk. 00:09:16.480 --> 00:09:18.520 Do you know when this change was made? 00:09:18.740 --> 00:09:20.780 Many, many years ago. Probably 2012. 00:09:21.730 --> 00:09:24.550 Okay, so if I had downloaded... 00:09:24.550 --> 00:09:28.970 If you had downloaded Bitcoin in 2011 or something like that, you would be listening. 00:09:29.110 --> 00:09:29.270 Right. 00:09:29.630 --> 00:09:33.790 If you were still running a node from 2011, you would be listening and you would 00:09:33.790 --> 00:09:34.190 be hacked. 00:09:35.600 --> 00:09:37.040 But yeah, you could. 00:09:38.480 --> 00:09:40.200 So, you know, it's been... 00:09:40.200 --> 00:09:44.380 In any case, this setting was called, I mean, it's still called UPnP 00:09:44.620 --> 00:09:45.000 Yes. 00:09:45.140 --> 00:09:47.560 And this was removed. 00:09:47.780 --> 00:09:53.180 Yes. And in recent years, we've added a whole new system to it. I'll skip some 00:09:53.180 --> 00:09:55.860 intermediate steps. So basically, we added something called Port Control 00:09:55.860 --> 00:10:01.320 Protocol, PCP, which is a much more modern way of doing the same thing, of asking 00:10:01.320 --> 00:10:05.700 your router to please open it. But it is much simpler in terms of code. 00:10:05.880 --> 00:10:09.160 Therefore, we're a little less worried about any security vulnerabilities there. 00:10:09.960 --> 00:10:11.800 But still not turned on by default. 00:10:13.150 --> 00:10:17.950 So nothing really changes. You still, if you download Bitcoin Core and you have 00:10:17.950 --> 00:10:23.720 the GUI, there's a settings dialog and you can click on basically PCP now. Where 00:10:23.720 --> 00:10:26.120 it used to say UPnP, it now says PCP. 00:10:28.880 --> 00:10:34.160 Okay, maybe you just said it, but is PCP new in this Bitcoin Core release? 00:10:34.380 --> 00:10:34.640 Yes. 00:10:34.840 --> 00:10:38.100 Okay, and that's why now UPnP has been removed. 00:10:38.950 --> 00:10:44.190 Yes, exactly. It's essentially a replacement. And then perhaps we'll turn it on 00:10:44.190 --> 00:10:47.110 by default in the future. I mean, that's something that has to be considered 00:10:47.110 --> 00:10:49.510 somewhat carefully because it would impact a lot of different nodes. 00:10:50.740 --> 00:10:56.220 Okay, but the functionality has not changed so far. It's just 00:10:56.220 --> 00:10:58.720 fewer bugs, presumably. 00:10:59.420 --> 00:11:02.580 Now, the bugs that were originally found were fixed, but the problem is, of 00:11:02.580 --> 00:11:05.680 course, if you found multiple really bad bugs in a project, do you still want to 00:11:05.680 --> 00:11:08.920 use it? Maybe not, because maybe you didn't find all of them. 00:11:09.240 --> 00:11:11.980 And did I understand correctly that... 00:11:13.250 --> 00:11:19.150 PCP, either PCP itself or the integration of PCP. Okay, first question. 00:11:19.430 --> 00:11:22.390 Is PCP a Bitcoin-specific project? 00:11:22.630 --> 00:11:22.870 No. 00:11:23.030 --> 00:11:23.250 Okay. 00:11:23.490 --> 00:11:27.170 No, it's a general project, simply just like UPnP, which was not a Bitcoin 00:11:27.170 --> 00:11:31.330 -specific project. It was used by torrent clients, all that sort of stuff, to be 00:11:31.330 --> 00:11:34.790 able to open your ports automatically. Games tend to use this stuff like this. 00:11:35.150 --> 00:11:40.880 Right. And then, did I understand that? Then the integration of PCP into 00:11:40.880 --> 00:11:42.940 Bitcoin Core was done by Wladimir van der Laan? 00:11:43.080 --> 00:11:48.120 That's right, yes. And he actually re-implemented it. So he rewrote the code 00:11:48.120 --> 00:11:51.080 specifically in C++. So that's kind of nice. 00:11:51.540 --> 00:11:55.260 Right. Yeah, that's cool. Nice to hear that Wladimir is back at it. 00:11:55.700 --> 00:11:55.920 Yep. 00:11:56.080 --> 00:11:59.720 In case there's listeners that don't know, Wladimir was the lead developer of 00:11:59.720 --> 00:12:02.770 Bitcoin Core for eight years? 00:12:03.130 --> 00:12:03.950 Very long time. 00:12:03.990 --> 00:12:08.050 Yeah, a whole while. Took a step back. So very nice to hear that he's back at it. 00:12:08.540 --> 00:12:12.980 Well, not back at the annoying work of being a maintainer, but simply doing the... 00:12:12.980 --> 00:12:13.500 Contributing. 00:12:13.660 --> 00:12:15.240 Doing the interesting stuff. Yeah, exactly. 00:12:16.860 --> 00:12:21.240 Okay, the next one has definitely the coolest name out of the list. 00:12:21.580 --> 00:12:22.440 Ephemeral Dust. 00:12:22.900 --> 00:12:24.580 There we go. Although, 00:12:26.430 --> 00:12:31.200 yeah, no, that's got to be the coolest one. Okay, Ephemeral Dust. What does it 00:12:31.200 --> 00:12:32.600 do? What is it? What are we talking about? 00:12:32.780 --> 00:12:36.900 It's a new Finnish metal band started by Martti Malmi. No. 00:12:37.140 --> 00:12:38.200 Embedded in Bitcoin Core? 00:12:38.840 --> 00:12:39.280 Exactly. 00:12:39.390 --> 00:12:40.450 Plays by default? 00:12:40.450 --> 00:12:45.290 I guess embedded in Bitcoin Core would also be a nice metal band name but 00:12:45.290 --> 00:12:50.730 in any case basically the idea we've talked about 00:12:50.730 --> 00:12:56.170 child pays for parent kind of situations in the mempool back in our episode about 00:12:56.170 --> 00:13:00.230 version 28 which I think is just two episodes ago so for you it would have been 00:13:00.230 --> 00:13:02.450 20 minutes ago if you're listening to the whole series in one go 00:13:03.370 --> 00:13:08.990 Child pays for parent means you are receiving a transaction, but the fee is so 00:13:08.990 --> 00:13:13.810 low that it's just sort of hanging around in the mempool. kind of being 00:13:13.810 --> 00:13:18.110 unconfirmed in your wallet. And then the way you can solve that is to actually 00:13:18.110 --> 00:13:23.790 spend these coins to yourself with a higher fee in the new transaction. And then 00:13:23.790 --> 00:13:27.830 miners will sort of make the overall calculation that if they include both 00:13:27.830 --> 00:13:31.950 transactions, both the original transaction to you, as well as the new 00:13:31.950 --> 00:13:36.790 transaction you just made to yourself with the same coins, then they're both 00:13:36.790 --> 00:13:40.880 getting confirmed and your coins are finally... In your wallet. 00:13:41.120 --> 00:13:44.780 Exactly. So you have to bring some of your own coins in order to pay the fees for 00:13:44.780 --> 00:13:47.940 the transaction that you want to receive. Now, in your example, it was still in 00:13:47.940 --> 00:13:51.420 the mempool. But imagine the fees are so low that they're not even in the 00:13:51.420 --> 00:13:57.000 mempool. Then you have to relay them together because nobody's mempool will 00:13:57.000 --> 00:14:00.780 accept it if the fee of the original is too low. And this is called package 00:14:00.780 --> 00:14:05.310 relay, which we covered in that episode. So you relay two packages, two 00:14:05.310 --> 00:14:09.610 transactions as a package. And then every node along the way can reason about it 00:14:09.610 --> 00:14:13.430 and say, hey, okay, this is fine. This should be interesting enough for a miner 00:14:13.430 --> 00:14:13.930 to include. 00:14:14.210 --> 00:14:18.990 Yeah, so basically nodes would start to use... How far are we with this? I know 00:14:18.990 --> 00:14:20.430 we covered it in previous episodes. 00:14:20.730 --> 00:14:23.770 Yeah, we covered most of this, but this might be useful to go to the basics. 00:14:23.910 --> 00:14:26.890 That's what a package is. And the only form of packages that Bitcoin Core 00:14:26.890 --> 00:14:32.090 supports is one parent, one child. And that has simply to do with the fact that 00:14:32.090 --> 00:14:34.770 it's complicated to reason about anything bigger than that. 00:14:34.930 --> 00:14:37.210 Well, that was included in the previous Bitcoin Core release. 00:14:37.350 --> 00:14:37.730 Yes, in 28. 00:14:38.150 --> 00:14:43.790 Yeah, so, I mean, the idea then is basically that nodes will use a similar 00:14:43.790 --> 00:14:44.710 -ish... 00:14:47.070 --> 00:14:52.530 strategy as miners. Like miners already make this calculation and now nodes have 00:14:52.530 --> 00:14:56.330 been starting to make a similar calculation to decide if transactions show up in 00:14:56.330 --> 00:14:57.490 the mempool. Yes. 00:14:57.790 --> 00:15:03.350 And so then the part where dust comes in, part of the ephemeral part, is that, 00:15:03.390 --> 00:15:07.570 well, there's other rules that don't allow you to relay stuff in the mempool. And 00:15:07.570 --> 00:15:11.430 one of them is if you're creating an output that is too small. It used to be like 00:15:11.430 --> 00:15:17.060 543 bytes. sorry, sats, if you had an output that was less than 543 00:15:17.060 --> 00:15:21.760 sats, nodes would say, this is dust, I'm not going to relay it. It's valid in the 00:15:21.760 --> 00:15:25.060 blockchain, but I'm not going to relay it. That was just basically a way to 00:15:25.060 --> 00:15:28.620 prevent somebody from creating lots of very small outputs. And the UTXO set that 00:15:28.620 --> 00:15:32.150 are just wasting everybody's memory, or whatever they're wasting. 00:15:34.470 --> 00:15:40.100 And so... If you have a one-child-one-parent construction, but the child is... 00:15:40.100 --> 00:15:43.760 Basically, the parent has a bunch of dust as the output, and the child is 00:15:43.760 --> 00:15:48.250 consuming the dust, and then paying their own fees. So they might be paying 00:15:48.250 --> 00:15:52.250 enough fees, but because there's dust involved, the nodes would still reject it, 00:15:52.450 --> 00:15:57.810 because they don't like dust. And the ultimate example of dust is a zero output. 00:15:58.340 --> 00:15:59.980 Yeah, which is apparently possible. 00:16:00.600 --> 00:16:05.340 Yes, yeah, definitely. There was, I think, a year ago, back when everybody was, 00:16:06.160 --> 00:16:08.180 you know, remember this ordinals inscriptions hype? 00:16:08.400 --> 00:16:08.660 Mm-hmm. 00:16:09.100 --> 00:16:12.780 So the ordinals inscriptions, they come up with this set of rules that are not 00:16:12.780 --> 00:16:15.760 consensus rules, so just their own rules, and it would count, like, you know, you 00:16:15.760 --> 00:16:19.640 are sat number one, sat number two, yadda yadda yadda. And it turns out, I think 00:16:19.640 --> 00:16:23.640 they didn't take account of the possibility to have a transaction that has zero 00:16:23.640 --> 00:16:26.180 sats as an input and zero sats as an output. 00:16:27.910 --> 00:16:31.970 Somebody made one as a joke, like just sent it directly to a miner because it's 00:16:31.970 --> 00:16:37.030 consensus valid, even though it's not standard. And so all their tools were off 00:16:37.030 --> 00:16:40.670 by one. Because the numbering system was broken, basically. 00:16:41.170 --> 00:16:45.750 Okay, so you can, because I didn't, I don't know, I don't think I knew this. You 00:16:45.750 --> 00:16:49.710 can apparently, in Bitcoin, spend zero Bitcoin. 00:16:50.010 --> 00:16:50.410 Yes. 00:16:50.610 --> 00:16:55.150 To an address that then receives zero Bitcoin. That's like a valid transaction. 00:16:55.390 --> 00:16:56.790 Yeah, and you're paying zero fees. 00:16:57.090 --> 00:17:01.810 And zero fees, yeah. So as long as a miner includes that in a block, then 00:17:01.810 --> 00:17:04.770 everyone's going to say, yeah, makes sense. Zero, zero to zero. 00:17:04.770 --> 00:17:07.970 Yes, and of course miners have no financial. good financial reason to do that 00:17:07.970 --> 00:17:11.510 unless they're being paid out of band so we don't want to encourage this but yeah 00:17:11.510 --> 00:17:14.430 you can fill a whole block with just zero fee transactions as far as I know. 00:17:14.430 --> 00:17:15.090 Okay, what's… 00:17:15.090 --> 00:17:15.690 Zero amount. 00:17:15.690 --> 00:17:20.490 And I know we were getting there but what is the what's the benefit of making 00:17:20.490 --> 00:17:23.650 because there is apparently an actual benefit to doing this sometimes 00:17:23.650 --> 00:17:29.210 so I think the easiest example would be a Lightning transaction or so we you and 00:17:29.210 --> 00:17:32.950 I have a Lightning channel And there's two ways we can close it. One is we are 00:17:32.950 --> 00:17:36.470 online together and we decide to close it cooperatively. We look at the fee 00:17:36.470 --> 00:17:40.050 market and we just make a transaction that closes the channel, pays enough fees, done. 00:17:40.330 --> 00:17:40.530 Yeah. 00:17:40.890 --> 00:17:44.670 But the other scenario is one of us is not offline or one of us is trying to cheat. 00:17:45.010 --> 00:17:46.470 But one of us is offline. 00:17:47.350 --> 00:17:51.450 Yeah, sorry, is offline, is not online. One of us is trying to cheat some 00:17:51.450 --> 00:17:55.650 scenario like that where we cannot cooperate. That means we have to broadcast the 00:17:55.650 --> 00:17:59.230 transaction that we signed in the past. So we previously got together when we 00:17:59.230 --> 00:18:03.330 were still buddies. We signed this transaction and we say, this closes the 00:18:03.330 --> 00:18:04.250 channel for both of us. 00:18:05.680 --> 00:18:09.960 However, we don't know when or if we're going to use this transaction. So we have 00:18:09.960 --> 00:18:11.520 no idea how much fees to put in this thing. 00:18:13.390 --> 00:18:16.730 So what Lightning nodes in the beginning had to do is just pick the worst case 00:18:16.730 --> 00:18:19.810 possible fee and that was kind of annoying because you're reserving a lot of 00:18:19.810 --> 00:18:25.420 money for a case that might never happen. So what you can do instead is you 00:18:25.420 --> 00:18:30.760 add zero fees to this transaction and you say this has to be paid by a child. So 00:18:30.760 --> 00:18:35.420 it's like bring your own fees. That way we don't have to decide in advance what 00:18:35.420 --> 00:18:41.210 the fees are going to be. And if this scenario occurs... you or I want to close 00:18:41.210 --> 00:18:45.620 the channel, we add one of our own inputs to it, and that pays for the fees. 00:18:46.280 --> 00:18:51.580 Yeah, right. So basically, you and I establish a Lightning channel, 00:18:51.760 --> 00:18:57.500 and the closing transaction, in case one of us is 00:18:57.500 --> 00:19:03.340 unresponsive, in case Sjors ends up in the El Salvadoran prison, then I 00:19:03.340 --> 00:19:08.990 can still broadcast the Lightning transaction with the zero fee. And the way I 00:19:08.990 --> 00:19:14.290 get that included in an actual block is to take some of my own coins, spend these 00:19:14.290 --> 00:19:19.610 to myself, child pays for parents style. But in that transaction also includes 00:19:19.610 --> 00:19:23.870 that zero, zero to zero with zero fee transactions. So now that's part of one 00:19:23.870 --> 00:19:24.270 transaction. 00:19:24.430 --> 00:19:26.410 And it's not just zero fees, it's also zero amount. 00:19:26.830 --> 00:19:28.150 Yeah, exactly. Zero to zero. 00:19:28.290 --> 00:19:32.870 Yeah, exactly. So the nice thing is you have a transaction that is creating an 00:19:32.870 --> 00:19:36.610 output that is zero, which is dust. and you have a transaction that spends the 00:19:36.610 --> 00:19:39.930 dust. And so this transaction that creates dust normally would not get broadcast 00:19:39.930 --> 00:19:45.910 because it is dust. But this thing called ephemeral dust is saying, well, as long 00:19:45.910 --> 00:19:49.650 as you're creating dust and immediately removing the dust, we're going to allow 00:19:49.650 --> 00:19:54.810 that. And so that's being relayed, and it's hopefully being mined as a pair. So 00:19:54.810 --> 00:19:56.230 in the end, there's no dust. 00:19:56.510 --> 00:20:02.110 Okay, so what's new here is, I think we're talking here about the relay 00:20:02.110 --> 00:20:08.090 policy of Bitcoin Core now takes this into account. My Bitcoin 00:20:08.090 --> 00:20:12.630 Core node or your Bitcoin Core node or anyone else's Bitcoin Core node, as long 00:20:12.630 --> 00:20:16.590 as they upgrade it to Bitcoin Core 29, of course, they will actually look at 00:20:16.590 --> 00:20:20.640 these transactions in tandem and they will say, okay, that's a dust transaction, 00:20:20.970 --> 00:20:25.810 but because it's immediately being spent as well, it's fine. This is not going to 00:20:25.810 --> 00:20:30.970 create an extra UTXO in my database or anyone else's database. In other words, 00:20:31.150 --> 00:20:32.130 it's ephemeral. 00:20:32.790 --> 00:20:33.310 Exactly. 00:20:34.580 --> 00:20:36.440 Now we know why it has such a cool name. 00:20:36.860 --> 00:20:41.500 Yeah, and my understanding is that there are some fancy future protocols people 00:20:41.500 --> 00:20:47.100 have in mind, like LN-Symmetry, etc., where you might have a series of 00:20:47.100 --> 00:20:52.320 transactions for whatever reason, like three in a row. And it's nice if all three 00:20:52.320 --> 00:20:56.540 of them are the exact same amount versus, you know, transaction one is a little 00:20:56.540 --> 00:20:58.820 bit lower than transaction two is a little bit lower than transaction three 00:20:58.820 --> 00:21:02.080 because they're all paying for their own fees. Makes it easier to reason about if 00:21:02.080 --> 00:21:06.750 the amounts stay identical. And so for those kind of constructs, ephemeral dust 00:21:06.750 --> 00:21:09.210 is also useful to have, but that's for the future. 00:21:09.570 --> 00:21:11.250 Okay. And just to wrap this up. 00:21:11.410 --> 00:21:14.450 And apparently Lightning devs are super happy with this ephemeral dust stuff. 00:21:14.860 --> 00:21:19.780 Well, that's how I wanted to wrap it up, basically. The practical benefit of this 00:21:19.780 --> 00:21:25.620 is that so far, if you wanted to make a Lightning channel, 00:21:25.760 --> 00:21:30.660 then you kind of had to be on the safe side and include a high fee for the 00:21:30.660 --> 00:21:34.800 fallback transaction because you don't know how high fees are going to be in the 00:21:34.800 --> 00:21:40.680 future. So you're likely going to overpay on fees if you use this fallback 00:21:40.680 --> 00:21:45.770 mechanism. And now with this, you can just... make the exact right fee for 00:21:45.770 --> 00:21:48.570 depending on how much in the rush you are. 00:21:48.790 --> 00:21:49.830 And it means you can also use more. 00:21:49.830 --> 00:21:53.870 In other words, you can use lower fees for closing Lightning channels. 00:21:53.870 --> 00:21:58.090 Yeah, and it means in general you can use more of your channel because if you're, 00:21:58.090 --> 00:22:02.070 you know, reserving 10% of your channel for a worst case fee, you can't actually 00:22:02.070 --> 00:22:02.610 spend that. 00:22:03.070 --> 00:22:07.970 Right, yeah. I see, yeah. So it improves the Lightning network in... 00:22:09.740 --> 00:22:14.520 That way. Lower fees and therefore more actual liquidity on Lightning itself. 00:22:14.600 --> 00:22:19.220 The little caveat there is that you do have to bring your own UTXO. So if you 00:22:19.220 --> 00:22:22.700 have a Lightning wallet that only has a channel, now things get a little bit more 00:22:22.700 --> 00:22:26.420 complicated because how are you actually going to do the child pay for parents if 00:22:26.420 --> 00:22:31.460 you don't have any children? But, you know, the rabbit hole does not end here, 00:22:31.460 --> 00:22:32.820 but it is a lot better this way. 00:22:32.920 --> 00:22:37.620 You need to have at least one other UTXO or another channel in the same wallet. 00:22:38.020 --> 00:22:38.720 Yeah, maybe. 00:22:39.680 --> 00:22:42.300 I guess that could work, depending on how it's designed. 00:22:43.820 --> 00:22:49.750 Okay, that was Ephemeral Dust. Then we go to a slightly less cool 00:22:49.750 --> 00:22:55.810 name. Still pretty cool, but less cool. Block Reserved Weight. 00:22:57.050 --> 00:22:57.530 Yes. 00:22:57.690 --> 00:22:59.870 What is the update here? Block Reserved Weight. 00:23:00.330 --> 00:23:05.490 Yeah, so basically a little background here is Bitcoin Core is able to make block 00:23:05.490 --> 00:23:10.570 templates that miners can use to create a block, basically. And Bitcoin Core 00:23:10.570 --> 00:23:13.430 tries to stuff as many transactions as it can into a block to give you the 00:23:13.430 --> 00:23:17.610 maximum fees. However, as a miner, you need to bring your own Coinbase 00:23:17.610 --> 00:23:20.570 transaction. That's just how the protocol works. 00:23:20.710 --> 00:23:25.570 Yeah, that's the transaction that pays the coins, the new coins and the fees to 00:23:25.570 --> 00:23:26.130 the miners. 00:23:26.150 --> 00:23:31.210 It does that. It might also have some commitments to various, like, what's it 00:23:31.210 --> 00:23:33.070 called? Like co-mining. 00:23:34.470 --> 00:23:36.150 Do you mean like the OCEAN thing? 00:23:36.710 --> 00:23:40.270 Not OCEAN thing, but usually there's all these other protocols that you're mining 00:23:40.270 --> 00:23:41.370 on, so merge mining. 00:23:41.530 --> 00:23:41.890 Sure, yeah. 00:23:42.050 --> 00:23:45.070 So there may be other stuff in the Coinbase that Bitcoin Core just doesn't do for 00:23:45.070 --> 00:23:49.540 you. So what that means is that Bitcoin Core does not know how big the Coinbase 00:23:49.540 --> 00:23:53.080 transaction is going to be. Therefore, it doesn't precisely know how much 00:23:53.080 --> 00:23:56.500 transactions it can actually put in your block. Because the Coinbase does count 00:23:56.500 --> 00:24:01.400 towards the limit, as does the header. You don't want to forget that. 00:24:03.020 --> 00:24:08.520 So it used to be that Bitcoin Core, I think, tried to reserve 4,000 00:24:08.520 --> 00:24:14.250 bytes for this. Basically just like here, okay, I'll just not use 4,000 bytes and 00:24:14.250 --> 00:24:14.990 then you should be okay. 00:24:16.710 --> 00:24:21.190 Accidentally, that was increased to 8,000 bytes. So it wasn't a complete accident 00:24:21.190 --> 00:24:24.810 because the commit that did that, the pull request that did that had a comment 00:24:24.810 --> 00:24:28.030 saying, oh, I think we're doing it twice now. And then the reaction was, yeah, it's fine. 00:24:29.140 --> 00:24:33.760 That's the attitude I like to hear from the Bitcoin Core developers that are 00:24:33.760 --> 00:24:36.180 building the future of money. 00:24:36.500 --> 00:24:40.940 Well, it's better to be safe than sorry. But basically, you know, some miners 00:24:40.940 --> 00:24:44.020 really want to squeeze out every last bit because the downside is, you know, if 00:24:44.020 --> 00:24:49.840 we reserve 8,000 bytes by default, but you only need, I don't know, 00:24:50.890 --> 00:24:55.440 500 bytes for your Coinbase. kind of, you know, you're throwing away some 00:24:55.440 --> 00:24:56.280 potential fees there. 00:24:56.560 --> 00:25:01.000 Yeah, you're leaving, you have unnecessary headroom. 00:25:01.280 --> 00:25:03.820