WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode.

00:00:09.710 --> 00:00:14.570
<v Aaron van Wirdum>Welcome to Bitcoin Explained, the podcast with the most boring name in Bitcoin.

00:00:15.290 --> 00:00:15.990
<v Aaron van Wirdum>Hey, Sjors.

00:00:16.190 --> 00:00:18.140
<v Sjors Provoost>What's up? What's the new name?

00:00:18.360 --> 00:00:20.680
<v Aaron van Wirdum>We've rebranded our podcast. What do you think?

00:00:21.320 --> 00:00:24.850
<v Sjors Provoost>Well, I think, you know, especially if you read it correctly, Bitcoin, comma,

00:00:24.860 --> 00:00:30.140
<v Sjors Provoost>Explained, I think it's an amazing name. I think the problem was that a lot of

00:00:30.140 --> 00:00:33.200
<v Sjors Provoost>people have no idea what the hell a Van Wirdum Sjorsnado is.

00:00:33.980 --> 00:00:38.420
<v Aaron van Wirdum>Apparently, no one had any idea what Van Wirdum Sjorsnado means or even how to

00:00:38.420 --> 00:00:41.400
<v Aaron van Wirdum>pronounce it. So we decided to go for a new name.

00:00:41.820 --> 00:00:44.640
<v Sjors Provoost>Though I think if people listen to it long enough, they'll know how to pronounce

00:00:44.640 --> 00:00:48.300
<v Sjors Provoost>it. But I think the problem is people who are not listening don't know how to

00:00:48.300 --> 00:00:48.760
<v Sjors Provoost>pronounce it.

00:00:49.080 --> 00:00:53.680
<v Aaron van Wirdum>So from now on, we're Bitcoin Explained. Why is the comma so important for you?

00:00:54.070 --> 00:00:57.530
<v Sjors Provoost>It makes it sound more profound. So if you just say, oh, I'm going to explain

00:00:57.530 --> 00:01:02.070
<v Sjors Provoost>Bitcoin, whereas Bitcoin Explained, you know, really says, okay, now you truly

00:01:02.070 --> 00:01:02.870
<v Sjors Provoost>understand it.

00:01:03.150 --> 00:01:07.310
<v Aaron van Wirdum>Very profound. So the first episode, we're just going to keep counting. So this

00:01:07.310 --> 00:01:11.710
<v Aaron van Wirdum>is episode 45 of Bitcoin Explained, previously known as The Van Wirdum Sjorsnado.

00:01:12.470 --> 00:01:18.210
<v Aaron van Wirdum>And we're going to start off with the new Bitcoin Core release, Bitcoin Core

00:01:18.210 --> 00:01:18.930
<v Aaron van Wirdum>22.

00:01:19.510 --> 00:01:20.150
<v Sjors Provoost>That's right.

00:01:20.310 --> 00:01:25.430
<v Aaron van Wirdum>From now on, it's not 0.22 anymore. It's just Bitcoin Core 22, right?

00:01:25.850 --> 00:01:30.250
<v Sjors Provoost>Yeah. Highly undemocratically decided at some point to just change the numbering

00:01:30.250 --> 00:01:33.290
<v Sjors Provoost>because people were asking, when is version one coming of Bitcoin? They were

00:01:33.290 --> 00:01:37.100
<v Sjors Provoost>like, yeah, we're just going to skip it. Because it's always bad luck when you do that.

00:01:37.460 --> 00:01:41.940
<v Aaron van Wirdum>Right. So from now on, does this mean we're not in beta anymore, Sjors, is that

00:01:41.940 --> 00:01:42.860
<v Aaron van Wirdum>the big announcement?

00:01:43.200 --> 00:01:46.320
<v Sjors Provoost>No, I think it means nothing. I think it just means that we stopped having this

00:01:46.320 --> 00:01:47.140
<v Sjors Provoost>zero prefix.

00:01:47.560 --> 00:01:51.760
<v Aaron van Wirdum>Basically, Bitcoin Core changed the name for the same reasons that we did. Just

00:01:51.760 --> 00:01:55.880
<v Aaron van Wirdum>to avoid annoying questions and make it more clear. Is that it?

00:01:56.140 --> 00:02:00.000
<v Sjors Provoost>I guess. I wasn't really there at the decision. It just happened and nobody

00:02:00.000 --> 00:02:00.900
<v Sjors Provoost>wanted to undo it.

00:02:01.240 --> 00:02:06.640
<v Aaron van Wirdum>Got it. Well, at the point that we're recording this, the new Bitcoin Core

00:02:06.640 --> 00:02:10.240
<v Aaron van Wirdum>release has not actually been released yet. Bitcoin Core 22 has not actually been

00:02:10.240 --> 00:02:15.820
<v Aaron van Wirdum>released yet. But by the time this episode is released, then maybe Bitcoin Core

00:02:15.820 --> 00:02:19.880
<v Aaron van Wirdum>22 is released as well. And otherwise, it will be released very soon, right?

00:02:20.220 --> 00:02:24.480
<v Sjors Provoost>That's right. There's now a third release candidate out. So that means basically

00:02:24.480 --> 00:02:25.240
<v Sjors Provoost>any day now.

00:02:25.610 --> 00:02:29.670
<v Aaron van Wirdum>At the point of recording, at least. And maybe, like I said, maybe it's out by

00:02:29.670 --> 00:02:34.650
<v Aaron van Wirdum>the time this episode is released. So anyways, we're going to highlight some of

00:02:34.650 --> 00:02:40.070
<v Aaron van Wirdum>the improvements compared to Bitcoin Core 21, essentially, and Bitcoin Core

00:02:40.070 --> 00:02:45.890
<v Aaron van Wirdum>21.1. Was there a Bitcoin Core 21.2 as well? I don't think so.

00:02:46.170 --> 00:02:47.630
<v Sjors Provoost>I think there's one in progress.

00:02:47.910 --> 00:02:52.710
<v Aaron van Wirdum>Right, exactly. Yeah, there's one coming as well. We're going to give a short

00:02:52.710 --> 00:02:55.570
<v Aaron van Wirdum>overview of the most notable changes.

00:02:56.090 --> 00:03:01.010
<v Sjors Provoost>Yeah, exactly. So usually the last version digit, those changes are very small.

00:03:01.190 --> 00:03:04.830
<v Sjors Provoost>They're usually bug fixes and those kind of things. So the release we're talking

00:03:04.830 --> 00:03:05.710
<v Sjors Provoost>about now is a big one.

00:03:06.010 --> 00:03:11.730
<v Aaron van Wirdum>Well, they're either very small or they're a protocol upgrade.

00:03:12.300 --> 00:03:16.440
<v Sjors Provoost>Right. So in this case, it's a bit more complicated because it's small fixes and

00:03:16.440 --> 00:03:22.350
<v Sjors Provoost>Taproot that go into 0.21.1 and also in 0.22.2, uh, 21.2.

00:03:23.000 --> 00:03:28.740
<v Aaron van Wirdum>So let's get to Bitcoin Core 22. That's what the episode is about. I think the

00:03:28.740 --> 00:03:32.420
<v Aaron van Wirdum>most notable change, the biggest change, I think you'll agree with that because

00:03:32.420 --> 00:03:37.930
<v Aaron van Wirdum>you worked on it. So you're biased, is hardware wallet support, the

00:03:37.930 --> 00:03:39.050
<v Aaron van Wirdum>GUI, right?

00:03:39.310 --> 00:03:42.050
<v Sjors Provoost>I think that's a pretty cool change. I don't know if it's the biggest change. I'm

00:03:42.050 --> 00:03:47.740
<v Sjors Provoost>definitely very happy with it. Yeah, so basically if you download Bitcoin Core 22

00:03:47.740 --> 00:03:53.120
<v Sjors Provoost>and then also download HWI, which we talked about in episode

00:03:53.120 --> 00:03:57.220
<v Sjors Provoost>30, which is just a Python script that connects to all sorts of different

00:03:57.220 --> 00:04:02.420
<v Sjors Provoost>hardware wallets essentially using their drivers. Then I think you just have to

00:04:02.420 --> 00:04:07.320
<v Sjors Provoost>change one setting, which is to tell it where you put the HWI script. And then

00:04:07.320 --> 00:04:11.200
<v Sjors Provoost>once you've done that, you just insert your hardware wallet. You say to Bitcoin

00:04:11.200 --> 00:04:14.500
<v Sjors Provoost>Core, give me a new wallet. And it'll say, oh, do you want to use a Trezor,

00:04:14.580 --> 00:04:19.710
<v Sjors Provoost>Ledger, whatever you just inserted? And it'll just work to you like any other

00:04:19.710 --> 00:04:23.130
<v Sjors Provoost>wallet, except that your hardware device will now show on screen, hey, do you

00:04:23.130 --> 00:04:25.800
<v Sjors Provoost>want to approve this transaction? So that's pretty cool, I think.

00:04:25.940 --> 00:04:30.440
<v Aaron van Wirdum>Right. But am I understanding you correctly that it does not work out of the box?

00:04:30.540 --> 00:04:35.640
<v Aaron van Wirdum>You can't only download Bitcoin Core 22. You also need to download the HWI.

00:04:35.800 --> 00:04:36.260
<v Sjors Provoost>Correct.

00:04:36.560 --> 00:04:38.100
<v Aaron van Wirdum>Which is a separate software package.

00:04:38.580 --> 00:04:42.880
<v Sjors Provoost>Yeah, it's a Python library. And because it contains all the stuff from the

00:04:42.880 --> 00:04:47.440
<v Sjors Provoost>hardware manufacturers and it communicates with USB. So it is potentially a can

00:04:47.440 --> 00:04:52.500
<v Sjors Provoost>of worms. And so we don't want to put it in Bitcoin Core for everybody. Maybe one

00:04:52.500 --> 00:04:56.580
<v Sjors Provoost>day will be, but I think it'll be a while because just including USB drivers into

00:04:56.580 --> 00:04:58.140
<v Sjors Provoost>Bitcoin Core sounds a bit scary.

00:04:58.720 --> 00:05:00.400
<v Aaron van Wirdum>Right. So for now, it's like an add-on.

00:05:00.760 --> 00:05:04.280
<v Sjors Provoost>Yes. But like I said, pretty easy to install. You download it, put it somewhere,

00:05:04.480 --> 00:05:05.440
<v Sjors Provoost>point to it, and that's it.

00:05:05.960 --> 00:05:09.920
<v Aaron van Wirdum>Hardware wallets were already supported by Bitcoin Core though, right?

00:05:10.380 --> 00:05:15.050
<v Sjors Provoost>Indirectly, yes. You could use HWI already. but you had to use it from the

00:05:15.050 --> 00:05:19.750
<v Sjors Provoost>command line yourself. And actually, HWI also came with a graphical tool, so you

00:05:19.750 --> 00:05:23.670
<v Sjors Provoost>could actually use it somewhat reasonably, but I think this is much easier now.

00:05:24.050 --> 00:05:27.170
<v Sjors Provoost>It's just right into the Bitcoin Core interface.

00:05:27.450 --> 00:05:31.490
<v Aaron van Wirdum>Yeah, no one uses the command line, sure, so only a couple of Bitcoin Core

00:05:31.490 --> 00:05:33.410
<v Aaron van Wirdum>developers themselves use that stuff.

00:05:33.650 --> 00:05:37.610
<v Sjors Provoost>A surprising number of Bitcoin Core developers use the graphical interface too,

00:05:37.850 --> 00:05:41.950
<v Sjors Provoost>and it's especially because of coin selection. It's just a lot easier to do. If

00:05:41.950 --> 00:05:45.470
<v Sjors Provoost>you want to decide which coins you want to spend using a graphical interface, you

00:05:45.470 --> 00:05:48.690
<v Sjors Provoost>just click on them. Whereas with the command line, it's horrible. You have to

00:05:48.690 --> 00:05:51.910
<v Sjors Provoost>copy-paste the transaction hash and the identifier.

00:05:52.310 --> 00:05:55.310
<v Aaron van Wirdum>Right. So which hardware wallets are supported?

00:05:55.670 --> 00:06:01.570
<v Sjors Provoost>Off the top of my head, whatever HWI supports. So that is the Trezor, the

00:06:01.570 --> 00:06:07.030
<v Sjors Provoost>Ledger, the KeepKey, COLDCARD. Maybe some more. Yeah, I was just opening the

00:06:07.030 --> 00:06:10.530
<v Sjors Provoost>support matrix. There's a whole list of it. BitBox.

00:06:10.530 --> 00:06:15.450
<v Aaron van Wirdum>Okay, is that the only hardware wallet related change in the Bitcoin Core 22?

00:06:15.450 --> 00:06:20.170
<v Sjors Provoost>I mean that's a big enough one right and I'm sure in in next versions there'll be

00:06:20.170 --> 00:06:24.250
<v Sjors Provoost>some more incremental improvements like being able to bump the fee for example

00:06:24.250 --> 00:06:28.910
<v Sjors Provoost>would be nice that sort of stuff. Multisig would be very nice if it was possible

00:06:28.910 --> 00:06:29.750
<v Sjors Provoost>to do that directly.

00:06:30.070 --> 00:06:35.230
<v Aaron van Wirdum>Yeah. And for now, I think it's just one hardware wallet per Bitcoin Core wallet,

00:06:35.350 --> 00:06:38.010
<v Aaron van Wirdum>right? You can't do two out of three or that kind of...

00:06:38.450 --> 00:06:42.850
<v Sjors Provoost>No, exactly. Multi-signature support is not there yet. And that just is a whole

00:06:42.850 --> 00:06:45.710
<v Sjors Provoost>can of worms in general, right? Multi-signature support with Bitcoin Core is

00:06:45.710 --> 00:06:50.610
<v Sjors Provoost>still not very easy. It's all possible, but it requires some manual work.

00:06:50.890 --> 00:06:55.970
<v Aaron van Wirdum>Right. So hardware wallet integration into Bitcoin Core has been a long process,

00:06:56.130 --> 00:07:00.130
<v Aaron van Wirdum>has been an incremental process. And now for the first time with Bitcoin Core 22,

00:07:00.710 --> 00:07:05.130
<v Aaron van Wirdum>we have hardware wallet support in the GUI, which basically means we for the

00:07:05.130 --> 00:07:08.030
<v Aaron van Wirdum>first time have hardware wallet support for regular users.

00:07:08.250 --> 00:07:10.510
<v Sjors Provoost>Yeah, exactly. I think it's still marked experimental.

00:07:11.090 --> 00:07:14.930
<v Aaron van Wirdum>Great. Next up, I2P. Sjors, what is I2P?

00:07:15.270 --> 00:07:19.010
<v Sjors Provoost>I don't know. There's a lot of articles on the internet that say, what is the

00:07:19.010 --> 00:07:23.870
<v Sjors Provoost>difference between I2P and Tor? And then those articles start by saying, many

00:07:23.870 --> 00:07:28.250
<v Sjors Provoost>people ask what the difference is between I2P and Tor? Then they proceed in some

00:07:28.250 --> 00:07:32.870
<v Sjors Provoost>really convoluted language. But basically, you know, it is a Tor-like system that

00:07:32.870 --> 00:07:36.970
<v Sjors Provoost>is somehow different. But the good news is that Bitcoin Core can now use it.

00:07:37.450 --> 00:07:43.410
<v Aaron van Wirdum>Exactly, yeah. It's a privacy layer on top of the internet, a lot like Tor. You

00:07:43.410 --> 00:07:48.250
<v Aaron van Wirdum>know, Tor uses onion routing. So messages are encrypted and routed across

00:07:48.250 --> 00:07:53.530
<v Aaron van Wirdum>different users that all have a sort of encryption step on the way. And

00:07:53.530 --> 00:07:59.220
<v Aaron van Wirdum>therefore, you gain privacy. I2P is similar and

00:07:59.220 --> 00:08:04.660
<v Aaron van Wirdum>the differences are pretty subtle. It seems that

00:08:04.660 --> 00:08:10.410
<v Aaron van Wirdum>I2P has a more distributed way of mapping the network. I don't think

00:08:10.410 --> 00:08:14.670
<v Aaron van Wirdum>either of us know the details of how that works exactly, but it's more

00:08:14.670 --> 00:08:20.050
<v Aaron van Wirdum>distributed than with Tor. And somehow I2P is more dedicated

00:08:20.050 --> 00:08:21.070
<v Aaron van Wirdum>to...

00:08:21.070 --> 00:08:26.430
<v Sjors Provoost>It's internal, so it's more difficult to get out of I2P, whereas in Tor it's very

00:08:26.430 --> 00:08:30.950
<v Sjors Provoost>easy to use the original internet in addition to dedicated darknet, or not

00:08:30.950 --> 00:08:32.330
<v Sjors Provoost>darknet, but onion sites.

00:08:32.570 --> 00:08:36.210
<v Aaron van Wirdum>Yeah, that's what I was going to say. I2P is more dedicated to hidden services.

00:08:36.210 --> 00:08:41.590
<v Aaron van Wirdum>So if you stay within the network... I2P is sort of specialized for that, I

00:08:41.590 --> 00:08:46.310
<v Aaron van Wirdum>guess, where Tor is more usable if you want to send stuff to the regular

00:08:46.310 --> 00:08:48.210
<v Aaron van Wirdum>internet, to the web, right?

00:08:48.430 --> 00:08:52.530
<v Sjors Provoost>That's what we've read in random Google searches. So we wouldn't know.

00:08:52.910 --> 00:08:55.650
<v Aaron van Wirdum>These appear to be the subtle differences. So what does this have to do with

00:08:55.650 --> 00:08:56.170
<v Aaron van Wirdum>Bitcoin Core?

00:08:56.570 --> 00:09:01.290
<v Sjors Provoost>Well, so this kind of ties back into an earlier episode. So first of all, Bitcoin

00:09:01.290 --> 00:09:05.510
<v Sjors Provoost>Core 22 supports that network. So if you are interested in using it, you can.

00:09:05.990 --> 00:09:10.030
<v Aaron van Wirdum>Yeah, so you can now connect to the Bitcoin network through I2P.

00:09:10.270 --> 00:09:14.250
<v Sjors Provoost>Yeah, and so what we talked about in episode 13, back when it was still called

00:09:14.250 --> 00:09:18.890
<v Sjors Provoost>the Van Wirdum Sjorsnado, what we talked about then is that Bitcoin Core added

00:09:18.890 --> 00:09:23.450
<v Sjors Provoost>support for Tor version 3. And the other aspect we talked about then was more

00:09:23.450 --> 00:09:28.430
<v Sjors Provoost>generally, how does Bitcoin Core tell other nodes that which nodes to consider?

00:09:28.750 --> 00:09:32.390
<v Sjors Provoost>So there's basically a message where you can say, hey, here's a bunch of

00:09:32.390 --> 00:09:36.660
<v Sjors Provoost>addresses for other nodes. And what we explained in an episode is that there's

00:09:36.660 --> 00:09:42.420
<v Sjors Provoost>now a new message that makes it easier to announce nodes of various kinds

00:09:42.420 --> 00:09:48.080
<v Sjors Provoost>to other nodes, including to say, okay, here's a list of Tor version 3 nodes,

00:09:48.100 --> 00:09:53.440
<v Sjors Provoost>or here's a list of IPv6 nodes, or here's a list of I2P nodes.

00:09:54.340 --> 00:09:58.500
<v Sjors Provoost>And this mechanism is now more generic, which means that in the future, if other

00:09:58.500 --> 00:10:02.760
<v Sjors Provoost>networks like this come about, some other anonymity network, you know, maybe

00:10:02.760 --> 00:10:06.650
<v Sjors Provoost>internet over the Lightning network, who knows? It'll be much easier to add

00:10:06.650 --> 00:10:10.050
<v Sjors Provoost>support for that because we'll have a way to gossip those nodes around.

00:10:10.650 --> 00:10:10.810
<v Aaron van Wirdum>Right.

00:10:16.870 --> 00:10:21.790
<v Aaron van Wirdum>Speaking of these kinds of topics, you already mentioned Tor version 3. Tor

00:10:21.790 --> 00:10:24.990
<v Aaron van Wirdum>version 2 has now been fully deprecated, right?

00:10:25.470 --> 00:10:29.590
<v Sjors Provoost>Yeah, it was essentially already the case because in the previous version of

00:10:29.590 --> 00:10:34.670
<v Sjors Provoost>Bitcoin Core, if it started up, it would immediately switch to Tor version 3 and

00:10:34.670 --> 00:10:39.520
<v Sjors Provoost>would just not use your Tor version 2 settings. But you could still go back if

00:10:39.520 --> 00:10:42.300
<v Sjors Provoost>you did something manually. And now I think all that code has been stripped out

00:10:42.300 --> 00:10:47.660
<v Sjors Provoost>because I think Tor version 2 is more or less shut down. Because remember, Tor is

00:10:47.660 --> 00:10:51.200
<v Sjors Provoost>centralized in that way. Like there's somebody out there that can say, okay, this

00:10:51.200 --> 00:10:52.180
<v Sjors Provoost>thing no longer works.

00:10:52.580 --> 00:10:57.000
<v Aaron van Wirdum>Right. Yeah. We've discussed this in one of the previous Bitcoin Core release

00:10:57.000 --> 00:11:02.300
<v Aaron van Wirdum>episodes, I think, where the switch from Tor version 2 to version 3 was happening.

00:11:02.560 --> 00:11:04.820
<v Sjors Provoost>Yeah, we did that in the same episode, episode 13.

00:11:05.240 --> 00:11:10.330
<v Aaron van Wirdum>Right. Got it. These are two changes we've mentioned, hardware wallets and I2P

00:11:10.330 --> 00:11:15.550
<v Aaron van Wirdum>support. You've also mentioned at the start of this episode, this difference

00:11:15.550 --> 00:11:19.970
<v Aaron van Wirdum>between major releases and minor releases, where minor releases are usually

00:11:19.970 --> 00:11:25.270
<v Aaron van Wirdum>either bug fixes or they include protocol upgrades. Now, the last minor release

00:11:25.270 --> 00:11:29.990
<v Aaron van Wirdum>did include protocol upgrades, namely Taproot, which also means that this is the

00:11:29.990 --> 00:11:35.230
<v Aaron van Wirdum>first major Bitcoin Core release that has Taproot support. And we can find this

00:11:35.230 --> 00:11:38.750
<v Aaron van Wirdum>Taproot support in a couple of places in this upgrade, right?

00:11:38.990 --> 00:11:42.030
<v Sjors Provoost>Yeah, of course, the most important part is that all the Taproot consensus stuff

00:11:42.030 --> 00:11:46.740
<v Sjors Provoost>is in here. obviously, the activation code, the speedy trial, all that sort of stuff.

00:11:46.960 --> 00:11:50.680
<v Aaron van Wirdum>If you haven't upgraded to the minor release yet, Taproot is going to activate in

00:11:50.680 --> 00:11:54.400
<v Aaron van Wirdum>November. So this would be a good opportunity to actually upgrade if you want to

00:11:54.400 --> 00:11:59.680
<v Aaron van Wirdum>enforce the new Taproot rules, which you should do if you want to get the maximum

00:11:59.680 --> 00:12:02.320
<v Aaron van Wirdum>security that a full node promises to offer.

00:12:02.560 --> 00:12:08.040
<v Sjors Provoost>Yeah, but the good news is that if you really, really liked version, say, 0.21.0,

00:12:08.650 --> 00:12:14.270
<v Sjors Provoost>and you don't want to change too much then you could just go to 0.21.1 and you'll

00:12:14.270 --> 00:12:20.090
<v Sjors Provoost>enforce Taproot but as we'll talk about now I think version 22 has a few more

00:12:20.090 --> 00:12:22.170
<v Sjors Provoost>things on top of this, the consensus enforcement.

00:12:22.170 --> 00:12:27.040
<v Aaron van Wirdum>Yes. So what does Bitcoin Core 22 include Taproot wise?

00:12:27.040 --> 00:12:32.420
<v Sjors Provoost>Well, it includes some very rudimentary support for wallet Taproot wallets.

00:12:32.420 --> 00:12:38.220
<v Sjors Provoost>Basically, you're just a single public key type of wallet you know which doesn't

00:12:38.220 --> 00:12:44.040
<v Sjors Provoost>make Taproot that interesting and slightly more generic things where you can have

00:12:44.040 --> 00:12:50.000
<v Sjors Provoost>one private, one, yeah one key per Taproot branch so remember in Taproot

00:12:50.000 --> 00:12:55.160
<v Sjors Provoost>you have a main key and you also have scripts that are sitting in a tree And so

00:12:55.160 --> 00:12:58.480
<v Sjors Provoost>there's now support for those scripts in a tree. However, as far as I understand

00:12:58.480 --> 00:13:03.540
<v Sjors Provoost>it, those scripts can only be of the super simple type, namely a public key.

00:13:03.940 --> 00:13:04.420
<v Aaron van Wirdum>Right.

00:13:04.700 --> 00:13:07.740
<v Sjors Provoost>So they're not very interesting yet, but this is how it goes with Bitcoin Core.

00:13:07.860 --> 00:13:09.740
<v Sjors Provoost>We add little increments at a time.

00:13:10.120 --> 00:13:15.060
<v Aaron van Wirdum>Yes, we've mentioned that a couple of times. Bitcoin Core is improved slowly but

00:13:15.060 --> 00:13:20.760
<v Aaron van Wirdum>surely. Every half year there's a new release, so it's not necessarily that

00:13:21.000 --> 00:13:25.180
<v Aaron van Wirdum>all the Taproot stuff comes at the same time. It's just step by step. And now the

00:13:25.180 --> 00:13:30.860
<v Aaron van Wirdum>first step is to have very basic Taproot support, which essentially comes down to

00:13:30.860 --> 00:13:35.600
<v Aaron van Wirdum>Taproot support for regular transactions. So none of the fancy smart contract

00:13:35.600 --> 00:13:41.240
<v Aaron van Wirdum>stuff, but you can use a Taproot type of address and transaction to receive funds.

00:13:41.440 --> 00:13:46.740
<v Sjors Provoost>Yeah, in principle. But again, it's not even on by default. You actually have to

00:13:46.740 --> 00:13:51.260
<v Sjors Provoost>manually make it happen. So probably for version 23, you know, it'll

00:13:51.260 --> 00:13:52.980
<v Sjors Provoost>automatically do the Taproot things.

00:13:53.660 --> 00:13:57.500
<v Aaron van Wirdum>Yeah, I think another way to put it short, if you agree with me, is that there's

00:13:57.500 --> 00:14:02.020
<v Aaron van Wirdum>no actual benefit yet in using Taproot in this Bitcoin Core release. But it's

00:14:02.020 --> 00:14:05.000
<v Aaron van Wirdum>possible to use it for sort of regular transactions, right?

00:14:05.560 --> 00:14:08.580
<v Sjors Provoost>Yeah, exactly. So you can if you really know what you're doing. And other than

00:14:08.580 --> 00:14:11.880
<v Sjors Provoost>that, it's probably useful to have it in there anyway for people who want to test

00:14:11.880 --> 00:14:15.520
<v Sjors Provoost>things on Signet or Testnet or that sort of stuff. Because we want other

00:14:15.520 --> 00:14:17.060
<v Sjors Provoost>developers to keep working on Taproot.

00:14:17.280 --> 00:14:22.150
<v Aaron van Wirdum>Yeah, so this was basically Taproot addresses we were discussing. A little bit

00:14:22.150 --> 00:14:25.130
<v Aaron van Wirdum>deeper under the hood, you have the Taproot descriptors.

00:14:25.410 --> 00:14:30.390
<v Sjors Provoost>Yes. So a descriptor is a way to say, I want to generate a series of addresses,

00:14:31.210 --> 00:14:34.950
<v Sjors Provoost>basically. So instead of saying, okay, our wallet is one address, you say, okay,

00:14:35.350 --> 00:14:40.910
<v Sjors Provoost>our wallet starts with the root private key, and then it does a bunch of BIP32

00:14:40.910 --> 00:14:46.790
<v Sjors Provoost>style derivations. And then it says, okay, give me the address number 15 or

00:14:46.790 --> 00:14:51.890
<v Sjors Provoost>16 or 17. And descriptors allow you to describe that. And now they also let you

00:14:51.890 --> 00:14:52.670
<v Sjors Provoost>do that for Taproot.

00:14:52.870 --> 00:14:58.870
<v Aaron van Wirdum>I think descriptors also allow you to sort of categorize your funds into specific

00:14:58.870 --> 00:15:03.940
<v Aaron van Wirdum>types of... funds right so you can have you can say these are all my Taproot

00:15:03.940 --> 00:15:07.800
<v Aaron van Wirdum>funds locked in Taproot stuff and these are all my multisig funds like the

00:15:07.800 --> 00:15:12.920
<v Aaron van Wirdum>multisig addresses and the descriptors sort of let you label these right?

00:15:12.920 --> 00:15:18.120
<v Sjors Provoost>Yeah, because they describe in a sort of a human readable form what your

00:15:18.120 --> 00:15:21.860
<v Sjors Provoost>addresses are how to get to your addresses yeah you can say I have one descriptor

00:15:21.860 --> 00:15:26.140
<v Sjors Provoost>for my SegWit addresses. I have one descriptor for my Taproot addresses. Yeah.

00:15:26.480 --> 00:15:30.600
<v Aaron van Wirdum>Yeah. So now there's a Taproot descriptor. So that's another sort of small step

00:15:30.600 --> 00:15:33.180
<v Aaron van Wirdum>in the Taproot process for Bitcoin Core.

00:15:33.420 --> 00:15:37.440
<v Sjors Provoost>That is what the wallet has support for. So you can add Taproot descriptors to

00:15:37.440 --> 00:15:39.480
<v Sjors Provoost>the wallet now, but you have to do it yourself.

00:15:39.800 --> 00:15:40.200
<v Aaron van Wirdum>Right.

00:15:49.240 --> 00:15:55.140
<v Aaron van Wirdum>So, hardware wallet support in the GUI, I2P support, Taproot, first major release

00:15:55.140 --> 00:15:56.780
<v Aaron van Wirdum>with Taproot. Oh, are we done with Taproot?

00:15:57.120 --> 00:16:01.260
<v Sjors Provoost>Almost. The other thing is there's a little safety measure there. Well, two

00:16:01.260 --> 00:16:05.740
<v Sjors Provoost>things. So there's a little safety measure there that you cannot add Taproot to a

00:16:05.740 --> 00:16:11.280
<v Sjors Provoost>wallet on mainnet before it activates. Just to make sure you don't have people

00:16:11.280 --> 00:16:13.920
<v Sjors Provoost>send to your Taproot address before it activates because then you lose all the

00:16:13.920 --> 00:16:16.690
<v Sjors Provoost>coins. And the other thing is that...

00:16:16.690 --> 00:16:20.110
<v Aaron van Wirdum>Wait, wait, wait. Why would you lose the coins? It just means you can't spend the

00:16:20.110 --> 00:16:20.690
<v Aaron van Wirdum>coins, right?

00:16:21.390 --> 00:16:26.290
<v Sjors Provoost>No, if you're receiving money on a Taproot address before Taproot activates, then

00:16:26.290 --> 00:16:27.450
<v Sjors Provoost>that's anyone can spend.

00:16:27.710 --> 00:16:28.750
<v Aaron van Wirdum>Yeah, right, right.

00:16:29.050 --> 00:16:34.930
<v Sjors Provoost>So yeah, that's a bad idea. So this is a little basically anti-footgun measure.

00:16:35.350 --> 00:16:35.810
<v Aaron van Wirdum>Got it.

00:16:35.870 --> 00:16:41.500
<v Sjors Provoost>The other upgrade is that there's now some support for Bech32m. We talked about,

00:16:41.780 --> 00:16:45.520
<v Sjors Provoost>I think, Bech32 addresses in general, and that for Taproot, there's a small

00:16:45.520 --> 00:16:48.940
<v Sjors Provoost>change to it. The episode 28, we talked about addresses.

00:16:49.340 --> 00:16:50.240
<v Aaron van Wirdum>I remember that.

00:16:50.620 --> 00:16:55.790
<v Sjors Provoost>Yeah, and so to the human eye, they'll look identical. They start with bc1, but

00:16:55.790 --> 00:16:59.790
<v Sjors Provoost>there's some subtle changes in the checksum that you can safely ignore, but it

00:16:59.790 --> 00:17:00.570
<v Sjors Provoost>does have to be built.

00:17:00.830 --> 00:17:05.110
<v Aaron van Wirdum>Right. That's also included in this release and also related to Taproot.

00:17:05.510 --> 00:17:06.010
<v Sjors Provoost>Exactly.

00:17:06.610 --> 00:17:08.270
<v Aaron van Wirdum>All right. Was that all Taproot?

00:17:08.490 --> 00:17:09.350
<v Sjors Provoost>I think so.

00:17:09.830 --> 00:17:15.660
<v Aaron van Wirdum>Okay, great. So yeah, hardware wallet support, I2P, taproot. And then the fourth

00:17:15.660 --> 00:17:20.620
<v Aaron van Wirdum>notable change that we're going to discuss is there's an update to

00:17:20.620 --> 00:17:23.140
<v Aaron van Wirdum>testmempoolaccepts. Am I saying that right?

00:17:23.700 --> 00:17:24.180
<v Sjors Provoost>That's right.

00:17:24.600 --> 00:17:26.580
<v Aaron van Wirdum>Or is testmempoolaccept newly included?

00:17:26.900 --> 00:17:31.320
<v Sjors Provoost>No, testmempoolaccept has been around. So testmempoolaccept is an RPC method,

00:17:31.760 --> 00:17:35.860
<v Sjors Provoost>right? So the RPC is a way to programmatically talk to a node from maybe from a

00:17:35.860 --> 00:17:40.850
<v Sjors Provoost>Python script or just manually. And what testmempoolaccept does is it it takes a

00:17:40.850 --> 00:17:45.270
<v Sjors Provoost>transaction and it says yeah if you were to broadcast this transaction it would

00:17:45.270 --> 00:17:48.870
<v Sjors Provoost>be valid or it would say no this transaction is invalid because the signature is

00:17:48.870 --> 00:17:52.710
<v Sjors Provoost>wrong so it's just a way to check if a transaction is correct before actually

00:17:52.710 --> 00:17:57.470
<v Sjors Provoost>sending it and one of the things I believe it checks against is whether the fee

00:17:57.470 --> 00:18:01.090
<v Sjors Provoost>is high enough to even make it into your mempool Because your mempool might be

00:18:01.090 --> 00:18:05.990
<v Sjors Provoost>very full and if it's too low, it'll say, no, fee is not high enough. But one of

00:18:05.990 --> 00:18:10.490
<v Sjors Provoost>the restrictions that comes with that, and we talked about this in episode

00:18:10.490 --> 00:18:16.190
<v Sjors Provoost>19, package relay and other things. One of the restrictions is that

00:18:16.190 --> 00:18:20.150
<v Sjors Provoost>it evaluates these transactions one at a time. So you might have one transaction

00:18:20.150 --> 00:18:23.910
<v Sjors Provoost>that pays a very low fee and then the next transaction actually spends that first

00:18:23.910 --> 00:18:25.290
<v Sjors Provoost>transaction and pays a huge fee.

00:18:26.520 --> 00:18:29.680
<v Sjors Provoost>you won't get through because the first transaction is immediately tossed away.

00:18:30.470 --> 00:18:35.130
<v Sjors Provoost>And so the longer term goal that we talked about in this episode is that these

00:18:35.130 --> 00:18:40.330
<v Sjors Provoost>transactions can be analyzed as a package in various places. So by the mempool

00:18:40.330 --> 00:18:46.210
<v Sjors Provoost>itself and in the peer-to-peer messaging protocol. And so this adds a tiny,

00:18:46.310 --> 00:18:50.110
<v Sjors Provoost>tiny, tiny step, which is that now you can give this command multiple

00:18:50.110 --> 00:18:54.510
<v Sjors Provoost>transactions. It's still going to evaluate them one by one. But again, this is

00:18:54.510 --> 00:18:55.190
<v Sjors Provoost>baby steps.

00:18:55.770 --> 00:19:01.610
<v Aaron van Wirdum>Yeah, if I have to jog my memory, the point here was that for some protocols like

00:19:01.610 --> 00:19:06.810
<v Aaron van Wirdum>the Lightning Network, you might need to use a trick called child pays for

00:19:06.810 --> 00:19:12.450
<v Aaron van Wirdum>parent, which means that you create a new transaction that has a high enough

00:19:12.450 --> 00:19:15.310
<v Aaron van Wirdum>fee to essentially pay for a previous transaction.

00:19:15.590 --> 00:19:15.870
<v Sjors Provoost>Yep.

00:19:16.170 --> 00:19:19.830
<v Aaron van Wirdum>That a transaction is sort of stuck in the mempool or whatever. Well, that's

00:19:19.830 --> 00:19:23.890
<v Aaron van Wirdum>where it will be stuck. And to speed it up, you create a new transaction that

00:19:23.890 --> 00:19:28.470
<v Aaron van Wirdum>spends the same funds, include an extra high transaction there. And that's how

00:19:28.470 --> 00:19:31.450
<v Aaron van Wirdum>you sort of get them both unstuck. That's how you get the first transaction

00:19:31.450 --> 00:19:36.330
<v Aaron van Wirdum>unstuck, which you sometimes actually really need to do with some. You might be

00:19:36.330 --> 00:19:39.910
<v Aaron van Wirdum>in a rush, in a hurry to actually do that in context of protocols of the

00:19:39.910 --> 00:19:43.490
<v Aaron van Wirdum>Lightning network, because sometimes you actually need transactions to confirm

00:19:43.490 --> 00:19:49.390
<v Aaron van Wirdum>before some kind of time lock runs out. And then the problem is that while

00:19:49.390 --> 00:19:55.030
<v Aaron van Wirdum>this works for getting a transaction actually included in a block, it doesn't

00:19:55.030 --> 00:20:00.890
<v Aaron van Wirdum>necessarily work for getting a transaction into a mempool. So sometimes, am I

00:20:00.890 --> 00:20:05.990
<v Aaron van Wirdum>saying this right? Sometimes you need to get a transaction unstuck, but that

00:20:05.990 --> 00:20:10.310
<v Aaron van Wirdum>transaction doesn't even make it into the mempool, which means you also can't get

00:20:10.310 --> 00:20:15.070
<v Aaron van Wirdum>it unstuck with child pays for parent. And then the solution there would be to

00:20:15.070 --> 00:20:20.420
<v Aaron van Wirdum>have... the network to broadcast packages of transactions over a network. So in

00:20:20.420 --> 00:20:24.580
<v Aaron van Wirdum>the same way that a package of transactions can sort of be confirmed by a miner

00:20:24.580 --> 00:20:29.760
<v Aaron van Wirdum>all at once because the miner calculates the total fee, that sort of same

00:20:29.760 --> 00:20:34.400
<v Aaron van Wirdum>calculation, the total fee calculation would come to apply for what regular nodes

00:20:34.400 --> 00:20:40.140
<v Aaron van Wirdum>put in the mempool. That's sort of the long-term upgrade that's being worked on.

00:20:40.560 --> 00:20:43.680
<v Aaron van Wirdum>And this is a very small step in that process, right?

00:20:44.140 --> 00:20:48.560
<v Sjors Provoost>Yeah. And for Lightning, it's a way to reduce fees, right? Because right now when

00:20:48.560 --> 00:20:53.780
<v Sjors Provoost>you... Well, to reduce fees in some cases. So right now with Lightning, you have

00:20:53.780 --> 00:20:57.600
<v Sjors Provoost>to pre-sign a transaction, which means you have to decide in advance what the fee

00:20:57.600 --> 00:21:01.960
<v Sjors Provoost>is going to be for that transaction. And so these fees have to be taken some sort

00:21:01.960 --> 00:21:07.390
<v Sjors Provoost>of worst case scenario into account. Whereas with this change, eventually the

00:21:07.390 --> 00:21:13.160
<v Sjors Provoost>hope is that... you just set no fee on it on the backup transaction that you have

00:21:13.160 --> 00:21:18.080
<v Sjors Provoost>in Lightning and you just send it on the blockchain and then whoever really needs

00:21:18.080 --> 00:21:22.440
<v Sjors Provoost>this transaction will just pay the extra fee that is needed right then as a child

00:21:22.440 --> 00:21:25.360
<v Sjors Provoost>pays for parent, so it's a useful feature but yeah there's some problems with

00:21:25.360 --> 00:21:27.300
<v Sjors Provoost>relay when the mempool is very full so,

00:21:27.300 --> 00:21:31.860
<v Aaron van Wirdum>yeah, that makes sense. So this testmempoolaccept is a small step in improving

00:21:31.860 --> 00:21:32.700
<v Aaron van Wirdum>that process.

00:21:32.700 --> 00:21:33.760
<v Sjors Provoost>Yep.

00:21:33.760 --> 00:21:39.080
<v Aaron van Wirdum>Another, another incremental improvement. Exactly. All right, so one more to go, Sjors?

00:21:39.080 --> 00:21:43.600
<v Sjors Provoost>Oh, maybe two actually. I have some some other [unclear] but one small one is

00:21:43.600 --> 00:21:48.520
<v Sjors Provoost>addmultisigaddress I think we talked about that. Well, basically the

00:21:48.520 --> 00:21:53.340
<v Sjors Provoost>multi-signature support inside the RPC you can now use it for

00:21:54.480 --> 00:21:58.780
<v Sjors Provoost>20 public keys instead of 16, which is something that SegWit supports.

00:21:59.420 --> 00:22:04.660
<v Aaron van Wirdum>Right, this is for Bitcoin Core users that want to receive a transaction. Right

00:22:04.660 --> 00:22:10.260
<v Aaron van Wirdum>now, this is limited to, you can create a multisig, but it's limited to 16

00:22:10.260 --> 00:22:11.920
<v Aaron van Wirdum>public keys. Is that right?

00:22:12.100 --> 00:22:17.820
<v Sjors Provoost>Yeah, and I think the reason is that legacy addresses could only do 16 P2SH and

00:22:17.820 --> 00:22:22.410
<v Sjors Provoost>SegWit can do 20. Right. But the Bitcoin Core couldn't support it yet.

00:22:22.920 --> 00:22:28.820
<v Aaron van Wirdum>Right, so now Bitcoin Core users can receive transactions on 20

00:22:28.820 --> 00:22:29.720
<v Aaron van Wirdum>key multisigs.

00:22:30.180 --> 00:22:33.940
<v Sjors Provoost>Yeah, it's not a consensus change. None of the rules change. It's just that the

00:22:33.940 --> 00:22:35.860
<v Sjors Provoost>Bitcoin Core wallet can now do a little bit more.

00:22:36.530 --> 00:22:41.370
<v Aaron van Wirdum>Yeah, it was always possible according to the consensus rules, but not according

00:22:41.370 --> 00:22:43.030
<v Aaron van Wirdum>to Bitcoin Core yet, until now.

00:22:43.770 --> 00:22:47.830
<v Sjors Provoost>Yeah, so another thing we can mention that is, I think, fun is support for

00:22:47.830 --> 00:22:53.820
<v Sjors Provoost>NAT-PMP. Basically, when you have a router, like if you're running a node at home

00:22:53.820 --> 00:22:58.820
<v Sjors Provoost>and you usually have a router, that will cause your node to not listen to

00:22:58.820 --> 00:23:02.770
<v Sjors Provoost>anything else. You know, your node can connect outbound, but other nodes can't

00:23:02.770 --> 00:23:06.710
<v Sjors Provoost>connect to you because they can't see you. And the way you solve that is by

00:23:06.710 --> 00:23:10.790
<v Sjors Provoost>opening a port on the router, forwarding that port to your node, which you can do

00:23:10.790 --> 00:23:16.750
<v Sjors Provoost>manually. Like you go to, I don't know, 192.16802, and then you log in and

00:23:16.750 --> 00:23:22.290
<v Sjors Provoost>you say port forwarding and you say send port 8333 to this device that runs my

00:23:22.290 --> 00:23:28.150
<v Sjors Provoost>node. But nobody wants to do that. So there are libraries that are

00:23:28.150 --> 00:23:32.130
<v Sjors Provoost>often used by games and by programs like BitTorrent and all these things that

00:23:32.130 --> 00:23:36.230
<v Sjors Provoost>will do it for you automatically. They will just, from your computer, ping your

00:23:36.230 --> 00:23:41.770
<v Sjors Provoost>router and say, please route this port to me. And that was done using UPnP,

00:23:41.950 --> 00:23:46.870
<v Sjors Provoost>but apparently that's very insecure and very bad. So it was turned off by default

00:23:46.870 --> 00:23:51.130
<v Sjors Provoost>in Bitcoin Core, so nobody was using it. And now there's another library called

00:23:51.130 --> 00:23:56.680
<v Sjors Provoost>NAT-PMP that apparently is a bit safer, a bit easier. And that's now added. So

00:23:56.680 --> 00:24:02.320
<v Sjors Provoost>if you open Bitcoin Core in the settings, in the GUI, there's a button that says

00:24:02.320 --> 00:24:08.040
<v Sjors Provoost>NAT-PMP. I think you can click on it and it'll try. And then it'll try to open

00:24:08.040 --> 00:24:11.660
<v Sjors Provoost>the other port on the router to listen. I don't know if it gives any useful

00:24:11.660 --> 00:24:15.770
<v Sjors Provoost>feedback. If it doesn't work I haven't tried it. It doesn't. I don't think it

00:24:15.770 --> 00:24:16.490
<v Sjors Provoost>works on my router.

00:24:16.490 --> 00:24:20.610
<v Aaron van Wirdum>Great. And then other than that what we haven't mentioned of course every Bitcoin

00:24:20.610 --> 00:24:26.550
<v Aaron van Wirdum>Core upgrade has a ton of smaller improvements bug fixes these kinds

00:24:26.550 --> 00:24:30.910
<v Aaron van Wirdum>of things but I think we agree that these were what we've mentioned now were the

00:24:30.910 --> 00:24:32.710
<v Aaron van Wirdum>six most notable changes.

00:24:32.710 --> 00:24:36.750
<v Sjors Provoost>Yeah, there's there's one meta change I think we should we forgot to mention

00:24:37.370 --> 00:24:41.870
<v Sjors Provoost>which is not inside the build itself, is that the deterministic builds for this

00:24:41.870 --> 00:24:44.610
<v Sjors Provoost>release are being made using Guix for the first time.

00:24:45.010 --> 00:24:48.390
<v Aaron van Wirdum>Right, yeah, I do think we've mentioned that, but maybe you can explain real

00:24:48.390 --> 00:24:49.230
<v Aaron van Wirdum>quick what that is.

00:24:49.350 --> 00:24:53.470
<v Sjors Provoost>I think we talked about reproducibility in an earlier episode, why open source

00:24:53.470 --> 00:24:59.400
<v Sjors Provoost>matters, episode 21. We talked about it's important for Bitcoin Core to be open

00:24:59.400 --> 00:25:04.090
<v Sjors Provoost>source, but also that the thing you're downloading from BitcoinCore.org is

00:25:04.090 --> 00:25:08.060
<v Sjors Provoost>actually related to that source that's out there. Because we could just say, hey,

00:25:08.180 --> 00:25:11.380
<v Sjors Provoost>look at this beautiful source code and then give you some binary that's just

00:25:11.380 --> 00:25:16.520
<v Sjors Provoost>ransomware. And we spent the whole episode 21 explaining how to prevent that. And

00:25:16.520 --> 00:25:21.720
<v Sjors Provoost>Guix, G-U-I-X, is a new project, relatively new, that

00:25:21.720 --> 00:25:27.800
<v Sjors Provoost>makes that process of verifiability better. And we're now using that for the release.

00:25:28.140 --> 00:25:28.340
<v Aaron van Wirdum>Great.

00:25:28.720 --> 00:25:30.560
<v Sjors Provoost>Yeah, I think that's basically it.

00:25:31.060 --> 00:25:36.840
<v Aaron van Wirdum>Yeah, so the main changes were hardware wallet support in GUI, I2P support, first

00:25:36.840 --> 00:25:40.700
<v Aaron van Wirdum>release to have Taproot, which includes receiving very basic Taproot

00:25:40.700 --> 00:25:46.180
<v Aaron van Wirdum>transactions. testmempoolaccept was updated as an incremental step towards

00:25:46.180 --> 00:25:47.420
<v Aaron van Wirdum>package relay.

00:25:47.680 --> 00:25:51.520
<v Sjors Provoost>I mean, I don't even know if you want to call it the main changes. It's the

00:25:51.520 --> 00:25:55.590
<v Sjors Provoost>changes we discussed and that are maybe the most visible and and makes sense. But

00:25:55.590 --> 00:26:00.110
<v Sjors Provoost>I can list a few other things. There's a coinstats index which has been on my

00:26:00.110 --> 00:26:05.690
<v Sjors Provoost>to-do list for a long time to see UTXO snapshots. We talked about UTXO snapshots

00:26:05.690 --> 00:26:10.990
<v Sjors Provoost>I think another episode and just another little piece of progress in there. Yeah,

00:26:10.990 --> 00:26:11.970
<v Sjors Provoost>hundreds of things.

00:26:11.970 --> 00:26:17.150
<v Aaron van Wirdum>Extended multisig support is what I forgot to mention. NAT-PMP. It's amazing.

00:26:17.150 --> 00:26:21.050
<v Sjors Provoost>It's awesome. It's going to be available in a store near you. Oh no it's free.

00:26:21.050 --> 00:26:22.350
<v Aaron van Wirdum>Oh, even better.

00:26:22.350 --> 00:26:24.830
<v Sjors Provoost>All right, I think that's all right.

00:26:24.830 --> 00:26:26.370
<v Aaron van Wirdum>Yeah, that's that's it for me.

00:26:26.370 --> 00:26:31.330
<v Sjors Provoost>Okay, then, thank you for listening to Bitcoin Explained, formerly known as the

00:26:31.330 --> 00:26:32.350
<v Sjors Provoost>Van Wirdum Sjorsnado.