WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:19.920 --> 00:00:22.340 Live from Utrecht, this is Bitcoin. 00:00:23.220 --> 00:00:23.660 Explained. 00:00:24.660 --> 00:00:26.880 Sjors, are we still making a bi-weekly podcast? 00:00:28.100 --> 00:00:31.980 I mean, it depends on what you mean by bi. It's more like a feeling, right? 00:00:32.720 --> 00:00:36.020 We make a podcast when we feel about it these days. Is that the rule? 00:00:36.460 --> 00:00:40.200 No, it's also when we're not traveling or sick or whatever. 00:00:40.460 --> 00:00:44.380 Or we don't have a good idea for a podcast. This is a good moment actually to 00:00:44.380 --> 00:00:48.820 maybe make a call to our audience. Like we will take requests for topics or at 00:00:48.820 --> 00:00:52.960 least we will consider requests for topics. If any of our listeners have good 00:00:52.960 --> 00:00:57.960 ideas of things that they want to have explained by us, just let us know on 00:00:57.960 --> 00:01:01.140 Twitter and we will consider it. Okay. Right, Sjors? 00:01:01.460 --> 00:01:02.040 Oh, that's true. 00:01:02.800 --> 00:01:08.060 All right. So, yeah, last one was, I guess, a month ago. I don't know when this 00:01:08.060 --> 00:01:11.400 one is going to be published because I think our editor is now traveling. He's in Amsterdam. 00:01:11.880 --> 00:01:12.540 Oh, okay. 00:01:12.800 --> 00:01:16.320 He's coming to our meetup tonight. We're recording this on, what is it, 00:01:16.460 --> 00:01:16.900 Wednesday? 00:01:17.260 --> 00:01:19.420 Wednesday, 20th of April. 00:01:19.620 --> 00:01:23.600 Yeah, and there will be the biggest meetup in Europe, in all of Europe, in 00:01:23.600 --> 00:01:27.980 Amsterdam tonight, Sjors. Okay. Isn't that exciting? We recently discovered that 00:01:27.980 --> 00:01:31.320 it's probably the biggest one in Europe. So now that's our main marketing push. 00:01:31.840 --> 00:01:34.620 Interesting. I guess that's because there's nothing happening in Prague at the moment? 00:01:36.660 --> 00:01:41.180 Because they have pretty big meetups. I mean, we didn't fact check it, but I 00:01:41.180 --> 00:01:42.460 think it's the biggest one in Europe. 00:01:42.640 --> 00:01:46.520 But you mean the biggest Bitcoin meetup, which then meets some narrow definition 00:01:46.520 --> 00:01:48.380 of Bitcoiner. Or Bitcoin? 00:01:49.240 --> 00:01:53.260 Just the biggest Bitcoin meetup we know of. I don't think we're doing very narrow 00:01:53.260 --> 00:01:53.860 definitions. 00:01:54.280 --> 00:01:57.880 I mean, there's Bitcoin Wednesday, which has nothing to do with Bitcoin. 00:01:58.160 --> 00:02:01.860 Right. Yeah, that's also an Amsterdam. I mean, is that bigger than ours? 00:02:02.300 --> 00:02:02.980 I don't know. 00:02:03.160 --> 00:02:03.560 Who knows? 00:02:03.760 --> 00:02:03.880 Could be. 00:02:04.260 --> 00:02:06.920 All right, let's get to the actual meat of this episode. 00:02:07.140 --> 00:02:07.400 Indeed. 00:02:07.980 --> 00:02:12.040 We are going to discuss... We'll probably have this published, I think, on the 00:02:12.040 --> 00:02:16.460 day that Bitcoin Core 23 is released because that's what we're going to be 00:02:16.460 --> 00:02:19.230 discussing. Bitcoin Core 23. 00:02:19.630 --> 00:02:22.230 That's always a bit of a risky statement because it can take a while before it 00:02:22.230 --> 00:02:25.490 gets released. But hopefully it'll be at the same time. 00:02:25.670 --> 00:02:30.130 At the time we're recording this, we're on release candidate 5. I don't think 00:02:30.130 --> 00:02:33.530 there's been many Bitcoin Core releases that required more than 5 release 00:02:33.530 --> 00:02:34.170 candidates, right? 00:02:34.830 --> 00:02:35.110 Indeed. 00:02:35.590 --> 00:02:39.670 By the way, this is not in the show notes, but maybe that's a good starting 00:02:39.670 --> 00:02:42.570 point. Sjors, what is actually a release candidate? 00:02:43.310 --> 00:02:48.080 Well, it's a candidate for a release. To put it simply, so basically 00:02:48.080 --> 00:02:53.360 it's a way for the Bitcoin Core developers or really any software project to give 00:02:53.360 --> 00:02:57.380 experienced user a chance to test the software. 00:02:58.000 --> 00:02:59.900 Right. And what are they testing it for? 00:03:00.060 --> 00:03:02.620 Well, they're testing something that's going to be as close to the final version 00:03:02.620 --> 00:03:07.450 as possible. In fact, the very last release candidate is eventually copied and 00:03:07.450 --> 00:03:08.570 called the actual release. 00:03:08.730 --> 00:03:14.130 Yeah, so in this case, release candidate 5, I think they're basically guys like 00:03:14.130 --> 00:03:20.090 you, Bitcoin Core developers and other expert users maybe, they're sort 00:03:20.090 --> 00:03:22.010 of trying out the software looking for bugs. 00:03:22.510 --> 00:03:26.670 Yeah, exactly. Or changes that are not correctly documented. So for example, if 00:03:26.670 --> 00:03:30.670 you're running a... say, a Bitcoin ATM or something, and you're relying on a 00:03:30.670 --> 00:03:34.690 Bitcoin Core node to do all sorts of automated stuff, then you would test the new 00:03:34.690 --> 00:03:38.250 release candidate to make sure that all the automated stuff you were relying on 00:03:38.250 --> 00:03:43.370 still works and there's not some subtle change that causes your ATM to send free 00:03:43.370 --> 00:03:44.250 money to its users. 00:03:44.450 --> 00:03:49.090 Right. And that lasts for like about a week. And then if no issues are found, the 00:03:49.090 --> 00:03:53.450 latest release candidate is essentially rebranded to whatever the new Bitcoin 00:03:53.450 --> 00:03:54.050 Core release is. 00:03:54.290 --> 00:03:59.490 I mean, there is an actual new release made. But it has the same code in it. The 00:03:59.490 --> 00:04:02.170 only thing that changes then is the version number. So yeah. 00:04:02.550 --> 00:04:08.530 Right. Okay. So Bitcoin Core 23, that's where we're at. For those that don't know 00:04:08.530 --> 00:04:12.930 this, Bitcoin Core releases a new Bitcoin Core release every six months, more or 00:04:12.930 --> 00:04:18.550 less. And the new Bitcoin Core release will basically just include whatever was 00:04:18.550 --> 00:04:22.790 ready at that time. Bitcoin Core doesn't wait for specific features. It's just 00:04:22.790 --> 00:04:25.750 once every six months, whatever's ready is in there, right? 00:04:25.950 --> 00:04:26.410 Yeah, that's right. 00:04:26.800 --> 00:04:30.700 Okay, so we're going to discuss some of the most notable changes. 00:04:32.030 --> 00:04:33.170 Let's begin. 00:04:34.430 --> 00:04:40.010 First, we're going to begin with... There's something 00:04:40.010 --> 00:04:41.630 about ports. 00:04:42.010 --> 00:04:47.810 Yes. Yeah, so as you may or may not know, Bitcoin Core listens to other 00:04:47.810 --> 00:04:52.510 nodes, if it's on a public network, on port number 8333. 00:04:52.710 --> 00:04:57.560 Yeah, and by listens, you basically mean just communicate with, right? Or what’s [unclear]… 00:04:58.270 --> 00:05:02.670 Listening means that it is listening to the outside world, so you can actually 00:05:02.670 --> 00:05:06.530 connect to it if you're in the outside world. A node could also just be on the 00:05:06.530 --> 00:05:09.630 internet, but not listen to anyone in the world, so you might not know where it 00:05:09.630 --> 00:05:12.130 is, and even if you send a message to it, it won't hear you. 00:05:12.350 --> 00:05:16.150 Right. So if I'm running a Bitcoin Core node and it's a listening node, which is 00:05:16.150 --> 00:05:17.090 like a setting. 00:05:17.670 --> 00:05:21.630 It's actually the default. However, in your home situation, it's not going to 00:05:21.630 --> 00:05:22.410 listen by default. 00:05:22.650 --> 00:05:22.750 Right. 00:05:22.810 --> 00:05:26.270 That's not because of a setting in Bitcoin Core, but other reasons we'll probably get into. 00:05:26.370 --> 00:05:29.550 Yeah, we'll get into that in a bit. But essentially, if I'm running a Bitcoin 00:05:29.550 --> 00:05:32.510 Core listening node, let's just call it that for now. 00:05:33.890 --> 00:05:38.730 And you, Sjors, you're also running a node, and if you want to communicate with 00:05:38.730 --> 00:05:42.130 my node, if you want to connect with my node then you're going to connect with my 00:05:42.130 --> 00:05:45.530 node on port 8333 right? So far so good? 00:05:45.530 --> 00:05:46.050 That's right. 00:05:46.050 --> 00:05:48.850 Okay, so what is a port? What does this actually mean? 00:05:48.850 --> 00:05:53.330 So a port is part of the I believe it's a TCP protocol, 00:05:55.590 --> 00:06:00.270 The TCP IP protocol, basically. So the idea is an IP address is where the 00:06:00.270 --> 00:06:05.870 computer is. That's what it tells you. And the port is actually just a thing 00:06:05.870 --> 00:06:09.130 inside of the messages that you're sending it to it. So, you know, the internet 00:06:09.130 --> 00:06:13.010 uses packages. And these packages, they have a certain structure, and the 00:06:13.010 --> 00:06:17.030 beginning of the package says, okay, this is the port I want to communicate on. 00:06:17.110 --> 00:06:21.350 So it's just a convention, a kind of a way to talk to different services on the 00:06:21.350 --> 00:06:26.710 same machine. So one server on the internet might run a web server, and it might 00:06:26.710 --> 00:06:31.050 also run an email server, and it might run a Bitcoin node. And so one convention 00:06:31.050 --> 00:06:35.760 you'll use is if you want to talk to the web server, talk to port 80 or port 443. 00:06:35.920 --> 00:06:40.820 If you want to talk to the FTP server, talk to port 21. If you want to talk to 00:06:40.820 --> 00:06:45.300 the Bitcoin node, talk to port 8333. So it's just, it's kind of like if you're 00:06:45.300 --> 00:06:50.300 sending somebody a letter and you write down the number of whatever the, you 00:06:50.300 --> 00:06:51.120 know, the office they're in. 00:06:51.360 --> 00:06:55.200 Or the name in that case, right? You know, there's several people living on the 00:06:55.200 --> 00:06:58.620 same address and then the name actually specifies who it's for. 00:06:59.140 --> 00:07:03.750 Yeah, maybe two. Yeah. And these are conventions, right? So IP addresses are a 00:07:03.750 --> 00:07:05.790 scarce resource. They're distributed across the world. 00:07:07.130 --> 00:07:10.930 So there are some centralization involved there. But when it comes to ports, 00:07:11.550 --> 00:07:16.030 there are standards and conventions out there, but your machine decides what it 00:07:16.030 --> 00:07:19.190 does on which port. There's nobody on the outside can tell you what to do. It's 00:07:19.190 --> 00:07:20.850 just a very bad idea to use the wrong port. 00:07:20.990 --> 00:07:24.810 So your computer connects with my computer. It tells my computer I'm going to use 00:07:24.810 --> 00:07:28.790 port 8333, which is just conventionally 00:07:30.220 --> 00:07:35.440 specification of something we chose. And at that point, my computer knows, oh, 00:07:35.520 --> 00:07:38.420 that means he wants to connect to Bitcoin Core, right? 00:07:38.700 --> 00:07:42.840 Yeah, because Bitcoin Core told your computer that it wants to listen on that port. 00:07:42.980 --> 00:07:48.660 Right, and that's the convention, but there's a problem with this? 00:07:49.020 --> 00:07:54.220 Yeah, so one thing is that internet providers and others can filter the internet 00:07:54.220 --> 00:07:57.880 traffic. And one way you can filter the internet traffic is just by looking at 00:07:57.880 --> 00:08:01.700 which port a package is going to, because that's very easy to see, it's at the 00:08:01.700 --> 00:08:06.230 start of each package, and you usually have to check that anyway for other 00:08:06.230 --> 00:08:10.210 reasons. So one thing an internet provider could do is to say well, we don't like 00:08:10.210 --> 00:08:13.310 Bitcoin, let's just block port 8333 specifically. 00:08:13.310 --> 00:08:19.270 Right so in a very sort of Bitcoin hostile future where perhaps Bitcoin is banned 00:08:19.270 --> 00:08:24.710 or whatever and ISPs want to stop people from using Bitcoin this would be one way 00:08:24.710 --> 00:08:25.470 for them to do it. 00:08:25.470 --> 00:08:28.490 Yeah this would be the easiest the lowest hanging fruit way to do it. It's 00:08:28.490 --> 00:08:33.830 certainly not um A very effective way to do it. But it's one start. It's 00:08:33.830 --> 00:08:35.410 certainly also not the only thing they can do. 00:08:35.590 --> 00:08:39.930 And the reason it's not very effective is because we have the option to just use 00:08:39.930 --> 00:08:41.490 different ports. Is that right? 00:08:41.770 --> 00:08:45.250 So that's the cat and mouse game. So if they make that move, then the second move 00:08:45.250 --> 00:08:49.430 is okay. We just start using other ports. But in order to prepare for that 00:08:49.430 --> 00:08:54.750 situation, I guess, one of the changes that are in the new version is that... 00:08:54.520 --> 00:08:58.280 Bitcoin nodes will connect to other nodes that have a different port. 00:08:58.440 --> 00:09:00.320 So they don't do that now? 00:09:00.560 --> 00:09:04.940 They will do it if you tell it to. But one thing we talked about in the earlier 00:09:04.940 --> 00:09:08.060 episode is that your node keeps a list of other nodes that it could connect to. 00:09:08.660 --> 00:09:13.700 And from that list, it tends to pick nodes that have port 8333, and only if that 00:09:13.700 --> 00:09:18.120 fails after a long time, then it'll try other ports. And that's the preference 00:09:18.120 --> 00:09:22.180 that's being removed now. So it'll just try any other node, regardless of what 00:09:22.180 --> 00:09:25.780 port it has. Which means that if we move to such a future where nodes are 00:09:25.780 --> 00:09:29.560 listening on different ports... it's not, you know, it's going to be less 00:09:29.560 --> 00:09:29.960 friction. 00:09:30.200 --> 00:09:35.840 Right. So right now you're running a node Sjors, and by default, your node will 00:09:35.840 --> 00:09:41.340 try to connect to other nodes and then we'll prioritize port 8333 nodes. And so 00:09:41.340 --> 00:09:46.320 if I'm running a node on another port, then, and everyone is like you, then I 00:09:46.320 --> 00:09:49.740 will just not have any inbound connections from other nodes because everyone's 00:09:49.740 --> 00:09:52.540 sort of ignoring me because I'm not using 8333. Is that right? 00:09:52.720 --> 00:09:52.880 Yeah. 00:09:53.280 --> 00:09:57.060 Right. And this is changing now. This is changing new Bitcoin Core where you 00:09:57.060 --> 00:10:01.720 won't prioritize 8333. You'll just connect to whatever node. 00:10:02.000 --> 00:10:07.140 Yeah, exactly. And there is, I think, a list of nodes, a list of ports that we 00:10:07.140 --> 00:10:12.280 don't connect to because it could be perceived as an attack. But I think that 00:10:12.280 --> 00:10:13.120 list is pretty short. 00:10:13.380 --> 00:10:17.920 Right. Okay. So this is basically preparing for a potential dystopian future 00:10:17.920 --> 00:10:19.400 where Bitcoin is very much... 00:10:19.400 --> 00:10:22.950 I mean, Bitcoin is... always preparing for potentially dystopian issues 00:10:22.950 --> 00:10:25.790 Yeah but just to clarify that for listeners… 00:10:25.790 --> 00:10:29.490 Yeah but also to clarify this you know this is not gonna make the difference. 00:10:29.490 --> 00:10:33.910 It's like just one chess move, and and the counter move is pretty obvious. So 00:10:33.910 --> 00:10:37.090 there's all sorts of ways for internet providers to see that you're running a 00:10:37.090 --> 00:10:40.810 Bitcoin node not just the port you're on. Okay but that's the easiest way, and 00:10:40.810 --> 00:10:42.410 you know uh enemies are lazy. 00:10:42.410 --> 00:10:47.070 So okay well so that covers that change correct? Yeah all right 00:10:47.810 --> 00:10:49.730 Let's move on to the next point. 00:10:51.250 --> 00:10:55.430 CJ... Sorry, I'm mispronouncing it already. CJDNS. 00:10:56.640 --> 00:11:01.850 Yeah. Yeah, I have no idea what it really is, to be honest. It's kind of in the 00:11:01.850 --> 00:11:06.590 list of you have Tor and I2P that we talked about. And it's not a complete 00:11:06.590 --> 00:11:10.510 replacement of these things, but it's sort of similar-ish. 00:11:10.910 --> 00:11:15.710 So it's some kind of anonymity network that you can use if you want to use the 00:11:15.710 --> 00:11:17.270 internet more privately. 00:11:17.670 --> 00:11:22.490 Exactly. And so if you know what that is, now you can use it with Bitcoin Core. I 00:11:22.490 --> 00:11:24.790 think that will be the first step to put it. 00:11:25.020 --> 00:11:29.820 So Bitcoin Core has included support for CJDNS. 00:11:29.940 --> 00:11:34.320 That's right. And so in the beginning, so a couple of episodes ago, we talked 00:11:34.320 --> 00:11:38.720 about the address gossip messages and how it used to be that we could communicate 00:11:38.720 --> 00:11:44.680 IPv4 addresses, IPv6 addresses and... tor v2 addresses and that you know 00:11:44.680 --> 00:11:48.280 it wasn't possible to communicate Tor v3 addresses because they were too long, 00:11:48.280 --> 00:11:53.760 and so they come up with a new standard called address message format number two, 00:11:53.760 --> 00:11:59.020 which was which allowed you to send addresses of very different sizes and very 00:11:59.020 --> 00:12:02.760 easily add new networks to that, and this is just one of the new networks that's 00:12:02.760 --> 00:12:07.090 added to it. So these nodes can you can't just use it, You can also gossip them 00:12:07.090 --> 00:12:08.310 around and things like that. 00:12:08.870 --> 00:12:09.030 Right. 00:12:10.270 --> 00:12:16.150 Details about CJDNS itself is not something that we can provide to the listener, 00:12:16.250 --> 00:12:20.970 I think. No. That's sort of outside of our, or at least outside of my expertise 00:12:20.970 --> 00:12:22.710 and I think outside of yours as well. 00:12:22.890 --> 00:12:22.970 Yeah. 00:12:23.470 --> 00:12:28.210 Okay. But it's, Bitcoin Core supports a new privacy or is it new? Do you know if it's new? 00:12:28.430 --> 00:12:29.250 I don't think it's new. 00:12:29.610 --> 00:12:35.010 Okay. It just supports an additional privacy network if you want to use it. 00:12:35.430 --> 00:12:35.970 Great. 00:12:36.270 --> 00:12:36.490 Yep. 00:12:36.710 --> 00:12:37.390 I like it, Sjors. 00:12:37.910 --> 00:12:38.290 Next. 00:12:38.650 --> 00:12:39.090 Next. 00:12:41.550 --> 00:12:47.290 Yeah, so there's an upgrade in the fee estimation algorithm in Bitcoin 00:12:47.290 --> 00:12:52.810 Core. Yep. So obviously, whenever you want to make a transaction, Bitcoin Core 00:12:52.810 --> 00:12:58.710 has this option to increase or decrease the fee depending on how fast you 00:12:58.710 --> 00:13:02.730 want your transaction to confirm, which depends on things like how many 00:13:02.730 --> 00:13:06.960 transactions are in the mempool or how many... how high fees were in recent 00:13:06.960 --> 00:13:09.460 blocks, I think. These are sort of some of the inputs. 00:13:09.720 --> 00:13:13.760 Yeah, I think it looks at... Yeah, exactly. I think it looks at how high fees 00:13:13.760 --> 00:13:17.540 were in recent blocks, but it also checks how long it took before it first saw it 00:13:17.540 --> 00:13:20.540 in a mempool and when it was in a block. I'm not exactly sure. 00:13:20.960 --> 00:13:21.340 Right. 00:13:22.580 --> 00:13:28.430 So that has been upgraded to include RBF, replaced by fee transactions 00:13:28.430 --> 00:13:28.890 is that right? 00:13:28.890 --> 00:13:33.650 Yeah you could call it an upgrade I mean initially it would just consider all 00:13:33.650 --> 00:13:37.730 transactions in the mempool but then when RBF was introduced I think it was 00:13:37.730 --> 00:13:43.730 decided to not to ignore those RBF fee bumps so fee bump is like you increase the 00:13:43.730 --> 00:13:48.400 fee of an existing transaction And in the beginning, I guess developers were not 00:13:48.400 --> 00:13:53.180 sure whether miners would actually play along with that game. So like actually 00:13:53.180 --> 00:13:57.040 replace the transactions. And so because they weren't sure about that, it was a 00:13:57.040 --> 00:14:00.400 bit risky to take those fees into account because you didn't know if those fees 00:14:00.400 --> 00:14:05.800 actually mattered or not. But they do. And more people are using RBF. So now the 00:14:05.800 --> 00:14:11.940 fee estimation takes into account the fees of the transactions whose fee was bumped. 00:14:11.940 --> 00:14:17.440 Right and so to be more or to be very clear about that, the the fees we're 00:14:17.440 --> 00:14:20.380 talking about here the RBF transactions we're talking about here are essentially 00:14:20.380 --> 00:14:26.060 other people's RBF transactions. Yeah right so to reiterate that really 00:14:26.060 --> 00:14:31.510 quick, RBF you know you send a transaction, and it's taking longer to confirm 00:14:31.510 --> 00:14:35.350 than you anticipated or for some reason you're in more of a rush all of a sudden, 00:14:35.350 --> 00:14:40.110 then you have the option to basically resend the same transaction to the network 00:14:40.110 --> 00:14:45.870 but include a higher fee this time, and that newer transaction should sort of 00:14:45.870 --> 00:14:49.770 override the older transaction. The miners should pick that one because it has 00:14:49.770 --> 00:14:55.400 higher fee essentially. Exactly so then So the transactions that are going to be 00:14:55.400 --> 00:15:01.400 confirmed in blocks essentially have higher fees now if all miners will adopt or 00:15:01.400 --> 00:15:06.500 accept these RBF transactions. And therefore, your own transaction, if you're 00:15:06.500 --> 00:15:10.300 going to send it, would also require a bit of a higher fee. And that's now taken 00:15:10.300 --> 00:15:10.880 into account. 00:15:11.140 --> 00:15:15.240 Yeah. I mean, just the one nuance there is not necessarily that the fees will 00:15:15.240 --> 00:15:19.100 actually go up, right? Because people will make more conservative estimates and 00:15:19.100 --> 00:15:24.620 then increase them. Effectively, fees might be lower. But yeah, basically you 00:15:24.620 --> 00:15:27.600 have to take them into account. You have to look at what transactions actually go 00:15:27.600 --> 00:15:28.120 into the block. 00:15:28.400 --> 00:15:33.100 Well, your own estimate, the estimates that your Bitcoin Core client makes, like 00:15:33.100 --> 00:15:37.390 let's say I want to have my fee... Sorry, I want to have my transaction confirmed 00:15:37.390 --> 00:15:43.110 within 24 hours. Now that it is taken into account RBF transactions 00:15:43.110 --> 00:15:48.250 from other people should mean that my fee estimation will be slightly higher now, right? 00:15:48.350 --> 00:15:51.010 Well, that's what I thought yesterday too. But now that I think about it, I think 00:15:51.010 --> 00:15:55.710 that's not actually true. Because RBF transactions, what it's saying is it's now 00:15:55.710 --> 00:16:00.810 including transactions that have been fee bumped. But I don't know if it 00:16:00.810 --> 00:16:06.090 previously excluded those transactions or excluded transactions that were using 00:16:06.090 --> 00:16:07.770 the RBF flag, but were not fee bumped. 00:16:08.400 --> 00:16:10.060 I don't get that at all. 00:16:10.650 --> 00:16:15.370 So there's three kinds of transactions, right? There's transactions that don't 00:16:15.370 --> 00:16:19.810 use RBF at all. There's transactions that set the RBF flag, but don't bump the 00:16:19.810 --> 00:16:23.610 fee. And there's transactions that have now a higher fee. 00:16:23.870 --> 00:16:24.130 Yes. 00:16:25.030 --> 00:16:27.950 Yeah, so the transactions that now have a higher fee are always higher than the 00:16:27.950 --> 00:16:33.250 ones that don't. So yeah, I guess you're right. It would increase the price, the 00:16:33.250 --> 00:16:34.010 fee estimates slightly. 00:16:34.190 --> 00:16:36.750 It would have to, right? There's no way it can be lower if it's going to take 00:16:36.750 --> 00:16:38.350 into account RBF transactions. 00:16:39.050 --> 00:16:39.410 Yeah. 00:16:40.540 --> 00:16:43.820 You know, it might stay the same in some cases. It's either the same or higher. 00:16:44.000 --> 00:16:48.260 It depends. If it was discounting all RBF transactions, regardless of whether the 00:16:48.260 --> 00:16:51.830 fee was bumped or not, then it's different. Because if the algorithm was only 00:16:51.830 --> 00:16:56.110 looking at transactions that don't have the RBF flag at all, And now it's also 00:16:56.110 --> 00:16:59.170 looking at transactions that do have the RBF flag. Well, those might be all 00:16:59.170 --> 00:17:00.130 systematically lower. 00:17:00.710 --> 00:17:04.490 Yeah, I guess that's true. But that would be a strange policy if that was the case. 00:17:05.010 --> 00:17:07.950 It may be, but that would be a good reason to revert it. So I guess we should 00:17:07.950 --> 00:17:09.210 have read the pull request a bit better. 00:17:10.450 --> 00:17:11.450 You can do so yourself. 00:17:11.670 --> 00:17:17.530 In either case, that's kind of a detail. The important thing is RBF transactions 00:17:17.530 --> 00:17:22.790 are now taken into account for fee estimation. Essentially, to summarize that in 00:17:22.790 --> 00:17:26.310 one sentence, Fee estimation should be a bit better now. 00:17:27.010 --> 00:17:27.150 Yep. 00:17:27.490 --> 00:17:27.710 All right. 00:17:28.090 --> 00:17:28.730 Let's talk about Tether. 00:17:29.470 --> 00:17:30.550 Let's talk about Tether. 00:17:31.760 --> 00:17:33.000 Sjors, you want to talk about Tether? 00:17:33.920 --> 00:17:36.700 Yeah. Is it actually Tether? USDC? 00:17:37.880 --> 00:17:42.340 Oh, you know, that's another one, right? Tether should be USDT or 00:17:42.340 --> 00:17:44.400 something like that. 00:17:44.440 --> 00:17:48.520 Well, anyway. Oh, it is USDT. I actually just wrote it wrong in the show notes. 00:17:48.600 --> 00:17:52.750 Yeah, it's USDT. But it doesn't stand for Tether. It stands for User Space 00:17:52.750 --> 00:17:55.190 Statically Defined Tracing for Bitcoin Core. 00:17:55.630 --> 00:18:00.490 Aha, it's only now that I understand your pun then. You made a pun in the show 00:18:00.490 --> 00:18:05.910 notes. That's great. We're back to puns. We need more puns in our show, but make 00:18:05.910 --> 00:18:07.930 the pun again because maybe people didn't get it. 00:18:08.090 --> 00:18:11.830 No, that's fine. They can re-listen to the episode. And I kind of ruined it 00:18:11.830 --> 00:18:16.130 anyway. So anyway, so the basic idea here is that I don't really understand what 00:18:16.130 --> 00:18:22.010 the basic idea is, but trace points are tools that developers can 00:18:22.010 --> 00:18:26.770 use, but also people who want to monitor their own node can use to get really 00:18:26.770 --> 00:18:32.490 fine-grained statistics out of their node. So for example, you can ask your node 00:18:32.490 --> 00:18:36.490 for things. You can call the node RPC. You can say, okay, give me the list of 00:18:36.490 --> 00:18:39.710 blocks you have or give me the list of peers you have. There's a RPC call for that. 00:18:41.360 --> 00:18:45.080 And you can read log files, and that tells you something. But this is just 00:18:45.080 --> 00:18:49.440 another way to get more detailed information. So one of the details you can get 00:18:49.440 --> 00:18:54.620 is every message that every node ever sends to you. So all of your peers keep 00:18:54.620 --> 00:18:58.740 sending you all sorts of messages. And now there's a better tool that you can use 00:18:58.740 --> 00:19:00.960 to kind of track those messages in a database. 00:19:01.340 --> 00:19:07.270 Okay, well, let's... break this down a little bit. First of all this seems to 00:19:07.270 --> 00:19:12.130 me this sounds like something this is useful for developers specifically right? 00:19:12.130 --> 00:19:14.690 Or is this something users are going to use for some reason? 00:19:14.690 --> 00:19:19.930 I would say developers but also say researchers, like you know Jameson Lopp for 00:19:19.930 --> 00:19:24.540 example when he does all these analysis of whatever is going on. He could use 00:19:24.540 --> 00:19:29.320 this or I think security researchers might find this interesting because they 00:19:29.320 --> 00:19:32.840 could run a bunch of nodes and check all the message traffic that's coming at 00:19:32.840 --> 00:19:38.220 those nodes and maybe identify attacks by something subtle, right? So sometimes, 00:19:38.520 --> 00:19:42.320 like we talked about an attack on the Bitcoin peer-to-peer network a few episodes 00:19:42.320 --> 00:19:46.400 ago where people were announcing fake nodes. And that's something you probably 00:19:46.400 --> 00:19:50.260 wouldn't be able to detect if you just... looked at you know if you just start 00:19:50.260 --> 00:19:55.360 your Bitcoin Core GUI it doesn't get hot, or it doesn't scream at you, yet there 00:19:55.360 --> 00:19:58.140 is an attack going on. So these kind of tools would make it much easier to see 00:19:58.140 --> 00:19:59.320 that this attack is going on. 00:19:59.320 --> 00:20:04.880 Okay, so one small step back just for my own understanding and I guess the 00:20:04.880 --> 00:20:06.200 listeners as well, since they're listening. 00:20:06.200 --> 00:20:08.100 Hopefully that's why we explain things. 00:20:08.100 --> 00:20:13.620 First of all you just mentioned log files. So a log file 00:20:13.620 --> 00:20:19.360 basically keeps track of every action your Bitcoin Core nodes does, right? 00:20:19.620 --> 00:20:22.720 Depending on how you configure it, you can tell it to keep track of quite a lot 00:20:22.720 --> 00:20:27.440 of detail, yes. But it's just a long text file and each line starts with the 00:20:27.440 --> 00:20:32.340 timestamp and then it says, okay, this happened, okay, this happened. And then if 00:20:32.340 --> 00:20:35.960 you want to process that data, it can be quite tedious. And not everything goes 00:20:35.960 --> 00:20:36.900 into the log file either. 00:20:37.280 --> 00:20:39.400 Okay, but this was already possible. 00:20:39.740 --> 00:20:39.940 Yes. 00:20:40.150 --> 00:20:45.430 And so now we're talking about user space statistically defined tracing, 00:20:45.430 --> 00:20:51.390 and if I saw if I'm trying to understand you, it's like a more 00:20:52.300 --> 00:20:56.920 specific type of log file? It tracks more specific things or… 00:20:56.920 --> 00:21:00.720 Yeah that's that's what I understand too, but I don't completely understand it 00:21:00.720 --> 00:21:04.720 either, but I guess it it really ties better into the operating system, and it's 00:21:04.720 --> 00:21:08.160 a way to to communicate this information in a more structured way than just a 00:21:08.160 --> 00:21:08.640 text file. 00:21:08.640 --> 00:21:13.440 Right, so the example you gave was something related to the peer-to-peer network 00:21:13.440 --> 00:21:17.040 you give it a very specific instruction. You don't have to log everything. You 00:21:17.040 --> 00:21:22.370 just log whatever other nodes are communicating with you or whatever data other 00:21:22.370 --> 00:21:28.260 nodes are sending to you. And that's sort of... Bitcoin 00:21:28.260 --> 00:21:32.920 Core now has the option to keep track of that in a way that's easy to understand 00:21:32.920 --> 00:21:34.920 by other types of software, perhaps. 00:21:35.200 --> 00:21:35.680 Yeah, exactly. 00:21:36.060 --> 00:21:41.460 Right. So, yeah. As you mentioned, useful for developers, useful for researchers. 00:21:42.280 --> 00:21:44.780 Not something a regular user will use in general. 00:21:44.980 --> 00:21:45.860 No, I don't think so. 00:21:46.020 --> 00:21:46.200 Okay. 00:21:47.430 --> 00:21:49.050 That's pretty clear to me. 00:21:50.710 --> 00:21:56.570 I completely lost access to our show notes. There we go. I'm back. You're 00:21:56.570 --> 00:21:57.230 back? I'm back. 00:21:58.950 --> 00:22:00.010 Next point is yours. 00:22:02.480 --> 00:22:03.220 Are you ready? 00:22:03.520 --> 00:22:04.100 Yeah, I'm ready. 00:22:05.860 --> 00:22:10.560 “Back” 32. How do I pronounce “back”? Is that how I pronounce it? That's probably 00:22:10.560 --> 00:22:11.920 a very Dutch way of pronouncing it. 00:22:11.940 --> 00:22:15.120 Yeah, I would say “back” 32, but others say “batch” 32. 00:22:15.640 --> 00:22:21.180 “Batch”, yeah. B-E-C-H 32. “batch” 32 um 00:22:21.180 --> 00:22:22.540 I 00:22:24.080 --> 00:22:25.600 forgot why this is in the show notes. 00:22:25.600 --> 00:22:30.260 Well, I'm sure you remember. As you may remember the Bech32 checksum has some 00:22:30.260 --> 00:22:33.840 nice properties. One of them is that it allows you locate where your typos are. 00:22:33.840 --> 00:22:39.050 Yeah oh yeah so Bech32 is a type of address. 00:22:39.050 --> 00:22:39.950 Yep 00:22:39.950 --> 00:22:45.730 And this type of address has nice… we did a previous episode on addresses 00:22:45.730 --> 00:22:46.790 Sjors, which episode is that? 00:22:46.790 --> 00:22:47.990 Yes we addressed this. 00:22:47.990 --> 00:22:49.070 Oh great. 00:22:49.070 --> 00:22:51.790 I think it was probably episode 2 or something. 00:22:51.950 --> 00:22:53.710 It was pretty early, I think, yeah. 00:22:53.910 --> 00:22:57.350 And one of the things we explained indeed is that this new address format that 00:22:57.350 --> 00:23:03.290 starts with BC1 will have the nice property that if you make a typo 00:23:03.290 --> 00:23:07.930 in it, you can actually find out where it was to do mathematical magic. And so 00:23:07.930 --> 00:23:12.470 that was already possible in theory, but it wasn't supported in practice. And now 00:23:12.470 --> 00:23:15.750 Bitcoin Core will let you do it, at least if you use the command line in this 00:23:15.750 --> 00:23:18.830 release, and then maybe in a future release, there's already some work for that. 00:23:19.650 --> 00:23:20.850 You can do it in the GUI. 00:23:21.030 --> 00:23:26.950 Right. So if someone for some reason would type out an address instead of 00:23:26.950 --> 00:23:32.010 just copy and paste and they make a typo, then your Bitcoin Core client will tell 00:23:32.010 --> 00:23:36.050 you there's a typo in it and it's there, right? 00:23:36.310 --> 00:23:36.510 Yeah. 00:23:36.730 --> 00:23:37.890 That's basically what will happen. 00:23:38.130 --> 00:23:43.610 And there's some discussion about up to what point that's safe because it could 00:23:43.610 --> 00:23:49.400 be situations where you make too many typos. And then... it might 00:23:49.400 --> 00:23:52.260 think you actually meant another address and it might actually help you 00:23:52.260 --> 00:23:57.020 accidentally change the address into a different address, which is even worse 00:23:57.020 --> 00:23:58.480 than the address not working. 00:23:58.600 --> 00:24:00.580 Sure. It's kind of like autocorrect in that sense. 00:24:00.980 --> 00:24:05.880 Yeah. But if you're using the command line, then you should know what you're 00:24:05.880 --> 00:24:08.940 doing. So it's easier to introduce these features there. 00:24:13.980 --> 00:24:15.300 Nice. All right. Next point. 00:24:17.360 --> 00:24:18.260 We're getting there? 00:24:18.840 --> 00:24:18.920 Yeah. 00:24:19.300 --> 00:24:21.320 Two or three more to go, right? All right. 00:24:23.840 --> 00:24:25.720 Wallet support for Taproot. 00:24:26.320 --> 00:24:31.940 That's right. I think more precisely, new wallets will support 00:24:31.940 --> 00:24:32.700 Taproot. 00:24:33.980 --> 00:24:39.000 So if you create a new wallet, it will have Taproot support. It won't use it by default. 00:24:40.240 --> 00:24:44.420 So the other change there is that there's a little drop-down menu where the 00:24:44.420 --> 00:24:48.640 checkbox used to be for Bech32. Now there's going to be a dropdown menu where you 00:24:48.640 --> 00:24:52.960 can choose, where it still uses SegWit by default, but you can actually select 00:24:52.960 --> 00:24:53.780