WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:06.990 --> 00:00:09.550 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:09.690 --> 00:00:09.870 Hello. 00:00:10.850 --> 00:00:11.730 Episode 24. 00:00:12.070 --> 00:00:12.510 That's right. 00:00:12.930 --> 00:00:17.810 And in episode 24, Sjors, we're going to discuss Bitcoin Core 21. 00:00:18.680 --> 00:00:23.360 Hooray! Well, 0.21. We're still in the age of the 0.0 releases. 00:00:23.620 --> 00:00:24.800 Yes, which is ending now. 00:00:25.020 --> 00:00:25.720 Probably, yes. 00:00:26.080 --> 00:00:31.420 That's what I understand. The next one, the 22 will actually be Bitcoin Core 22. 00:00:31.740 --> 00:00:35.360 That's what it says in the master branch right now. But until there's a release, 00:00:35.520 --> 00:00:37.940 somebody could come out and change it back. 00:00:38.280 --> 00:00:41.100 All right, well, anyways. I guess it's going to be, yeah, 22 will be the next 00:00:41.100 --> 00:00:47.090 version. Yeah, so this one is still called Bitcoin Core 0.21. And 00:00:47.090 --> 00:00:52.410 it was released... when was it exactly a week ago when we're recording no less 00:00:52.410 --> 00:00:57.830 than a week ago anyways last week and we're gonna discuss this new release and 00:00:57.830 --> 00:00:59.450 the new features in this new release 00:00:59.450 --> 00:01:01.010 yeah there's some very cool features in there 00:01:01.010 --> 00:01:03.830 it's a big release there's a lot of new stuff in here 00:01:03.830 --> 00:01:07.810 yeah and we're gonna refer back to some earlier episodes where we talk about 00:01:07.810 --> 00:01:11.790 either the specific feature or at least sort of the general area that this 00:01:11.790 --> 00:01:12.510 feature touches 00:01:12.510 --> 00:01:16.610 yeah we already discussed some of it So what we're going to do for this episode 00:01:16.610 --> 00:01:22.170 is we're just going to take the release notes and kind of discuss each new 00:01:22.170 --> 00:01:27.770 feature, each notable new feature point by point for the most interesting ones. 00:01:27.970 --> 00:01:32.170 That's right. And in the show notes, you can find the full release notes, which 00:01:32.170 --> 00:01:32.910 are very long. 00:01:33.210 --> 00:01:35.110 Let's start. Are you ready? 00:01:35.390 --> 00:01:35.970 I'm ready. 00:01:36.170 --> 00:01:38.080 Let's go. So first points. 00:01:38.480 --> 00:01:43.920 Yeah. So the first change, the mempool, right? It used to be that 00:01:43.920 --> 00:01:48.200 when you have a Bitcoin Core wallet, you would be broadcasting transactions from 00:01:48.200 --> 00:01:53.880 your wallet. And then after 15 seconds or so, you would be broadcasting 00:01:53.880 --> 00:01:57.340 transactions from the wallet. And you would just keep broadcasting it to your 00:01:57.340 --> 00:01:57.940 peers nearby. 00:01:58.260 --> 00:01:59.380 Isn't it 15 minutes? 00:01:59.740 --> 00:02:04.020 Yeah, 15 minutes. Yeah. So it would very frequently broadcast its own 00:02:04.020 --> 00:02:06.780 transactions because the wallet really wants to make sure that the rest of the 00:02:06.780 --> 00:02:09.840 world hears about its transactions. The problem with that... 00:02:09.840 --> 00:02:12.000 Until it's included in a block, of course. 00:02:12.260 --> 00:02:16.280 Exactly. The problem with that is it's not very good for privacy. Because if you 00:02:16.280 --> 00:02:21.300 can pinpoint which node is constantly repeating a transaction, then that suggests 00:02:21.300 --> 00:02:22.800 that that's the node that created it. 00:02:23.020 --> 00:02:28.950 Yeah, it makes it very obvious which addresses, which inputs... originate 00:02:28.950 --> 00:02:32.530 from which node which is bad for privacy because a node can be tied to an IP 00:02:32.530 --> 00:02:35.630 address and an IP address to an identity and so forth. 00:02:35.770 --> 00:02:40.250 Exactly. So the long-term goal here, which has not been achieved in this specific 00:02:40.250 --> 00:02:45.350 change, but we always do little micro steps, the long-term goal is to get to a 00:02:45.350 --> 00:02:49.330 place where the node will just treat its own transactions, its own wallet 00:02:49.330 --> 00:02:54.140 transactions, just like it would transactions from another peer. So it will not 00:02:54.140 --> 00:02:58.480 prioritize its own transactions. And there's some downside to that because you 00:02:58.480 --> 00:03:03.240 have to keep your wallet open probably a little bit longer. to make sure that it 00:03:03.240 --> 00:03:07.680 does get broadcast. But yeah, then it would be indistinguishable. So I think one 00:03:07.680 --> 00:03:11.220 of the long-term goals is to say, we're going to wait until the wallet 00:03:11.220 --> 00:03:16.160 transaction fee is close to what it would be for the next block, right? Because 00:03:16.160 --> 00:03:17.540 you can order transactions by fee. 00:03:17.740 --> 00:03:22.660 Yeah, I think what you're trying to say is that right now, this rebroadcasting is 00:03:22.660 --> 00:03:27.200 done blindly, while in the future, the plan is to actually see if the transaction 00:03:27.200 --> 00:03:31.620 should have been included in a block by now. based on the fees. And only if 00:03:31.620 --> 00:03:36.280 that's not the case, will it rebroadcast the transaction. And it will do so for 00:03:36.280 --> 00:03:40.240 any transaction the node has seen, not just for its own transactions. 00:03:40.640 --> 00:03:44.420 Exactly. And this also creates a better separation between, because the Bitcoin 00:03:44.420 --> 00:03:50.300 Core is a node, which has a mempool, and it's a wallet. And this 00:03:50.300 --> 00:03:54.250 dealing with mempools should be done by the node. and it shouldn't be done by the 00:03:54.250 --> 00:03:57.110 wallet. So there's a lot of process separation going on under the hood there. 00:03:57.370 --> 00:04:01.210 Yeah, but this, what we're describing right now, is actually not included in 00:04:01.210 --> 00:04:06.910 Bitcoin Core 21 right now. We've seen one microstep towards this in Bitcoin Core 21. 00:04:07.210 --> 00:04:07.410 Yeah. 00:04:07.630 --> 00:04:08.710 So what is this microstep? 00:04:08.890 --> 00:04:12.090 If I understand correctly, the microstep is that it's going to broadcast it once 00:04:12.090 --> 00:04:13.870 a day instead of every 15 minutes. 00:04:14.030 --> 00:04:16.870 I think that's right. It just does it less often. 00:04:18.210 --> 00:04:22.070 there's a bigger chance it will have been included in a block by then, which 00:04:22.070 --> 00:04:24.170 means it's never going to rebroadcast. 00:04:24.310 --> 00:04:26.510 And you need to spy on a node a lot longer. 00:04:26.650 --> 00:04:29.970 Yeah, exactly. So it's a benefit for privacy. 00:04:30.190 --> 00:04:31.290 Yeah, I would say so. 00:04:31.390 --> 00:04:36.830 And it's a small step towards a bigger plan. Yeah. Okay, next one. Tor version 3 00:04:36.830 --> 00:04:40.970 support. Oh, we should mention, as far as the mempool stuff, we've discussed this 00:04:40.970 --> 00:04:46.540 in episode 19 in more detail. For listeners who want to 00:04:46.540 --> 00:04:49.260 go back a couple of episodes and hear more about this. 00:04:49.580 --> 00:04:49.660 Yeah. 00:04:50.000 --> 00:04:52.320 Okay, next point is Tor version 3 support. 00:04:52.560 --> 00:04:54.700 Yeah, which we talked about in episode 13. 00:04:55.160 --> 00:04:55.340 Correct. 00:04:55.540 --> 00:04:56.260 In quite a bit of detail. 00:04:56.500 --> 00:04:56.580 Yeah. 00:04:56.720 --> 00:05:01.540 So the quick version is Tor, you know, has been improved as a version 3. Bitcoin 00:05:01.540 --> 00:05:02.480 Core now uses that. 00:05:02.880 --> 00:05:04.260 That's the very short version. 00:05:04.760 --> 00:05:05.120 Yes. 00:05:05.440 --> 00:05:09.780 And I think that's good enough for now. So yeah, episode 13 for anyone who wants 00:05:09.780 --> 00:05:10.280 to hear more. 00:05:10.480 --> 00:05:13.580 Right, because this also includes a new way to gossip addresses. So that's 00:05:13.580 --> 00:05:15.500 actually a bigger change. 00:05:15.740 --> 00:05:21.100 Yeah. I mean, the important thing is that I think a year from now, if I'm 00:05:21.100 --> 00:05:26.800 recalling correctly, if you want to use Tor... in a year from now, you actually 00:05:26.800 --> 00:05:29.220 do need to have this version 3 support, right? 00:05:29.360 --> 00:05:32.260 That's also my understanding, yeah. Because Tor is still centralized. So there's 00:05:32.260 --> 00:05:36.440 somebody in charge who can say, okay, next year you can no longer use version 2. 00:05:36.820 --> 00:05:41.880 Right. So now Bitcoin Core supports version 3, which means it's compatible with 00:05:41.880 --> 00:05:43.980 Tor even a year from now. 00:05:44.480 --> 00:05:44.900 That's right. 00:05:45.280 --> 00:05:46.140 Okay, point 3. 00:05:46.760 --> 00:05:51.670 Anchors. It's a new file, but more importantly, we talked in episodes 17 and 18 00:05:51.670 --> 00:05:57.090 about eclipse attacks, how a node can be sort of isolated from the rest of the 00:05:57.090 --> 00:06:02.430 network. And one of the countermeasures that we talked about back then is that 00:06:02.430 --> 00:06:07.210 when the node restarts, it should remember at least some of the nodes it was 00:06:07.210 --> 00:06:10.630 previously connected to. And that's what these anchor connections are. So before 00:06:10.630 --> 00:06:15.590 your node shuts down, it saves, or I guess it regularly saves, two of the nodes 00:06:15.590 --> 00:06:19.070 that it's connected to currently, namely nodes that it's only exchanging blocks 00:06:19.070 --> 00:06:22.410 with, so very low bandwidth. And then when it starts up, it's going to read that 00:06:22.410 --> 00:06:26.190 file and it's going to connect to them again. And we explain a lot more about 00:06:26.190 --> 00:06:26.990 that in those episodes. 00:06:27.390 --> 00:06:33.050 Yeah, I think especially episode 17. Yeah, but both 17 and 18, I think most of 00:06:33.050 --> 00:06:38.890 it, most of this specific change was in episode 17. So anyway, so 00:06:38.890 --> 00:06:44.590 this was included in Bitcoin Core 21 as well. So Eclipse attacks are now harder 00:06:44.590 --> 00:06:47.070 to pull off against Bitcoin Core 21 nodes. 00:06:47.410 --> 00:06:47.850 Yes. 00:06:48.290 --> 00:06:49.990 Nice. All right. Next point. 00:06:50.330 --> 00:06:56.010 The next point is BIP-157. also known as neutrino filters. We have not 00:06:56.010 --> 00:07:00.950 talked about that yet, so we can briefly explain it. There are lots of mobile 00:07:00.950 --> 00:07:05.310 wallets out there, especially for Lightning, that don't want to download the 00:07:05.310 --> 00:07:06.390 entire blockchain. 00:07:06.690 --> 00:07:10.090 Yeah, or just light wallets in general. They don't have to be mobile, just 00:07:10.090 --> 00:07:13.250 something that doesn't download and verify the entire blockchain. 00:07:13.430 --> 00:07:16.970 Yeah, though I think the number of excuses you have to run a light wallet outside 00:07:16.970 --> 00:07:19.030 of a mobile situation are... 00:07:20.380 --> 00:07:24.920 I mean, a lot of people don't feel like waiting for two days for the whole thing 00:07:24.920 --> 00:07:25.360 to sync. 00:07:25.720 --> 00:07:27.640 Yeah, that's true, for the initial experience. I mean, 00:07:27.720 --> 00:07:32.880 it's a bad idea or definitely not preferable, but that would be the reason. 00:07:33.260 --> 00:07:38.380 Yeah. So what these filters do is instead of downloading every block, you 00:07:38.380 --> 00:07:41.480 download these filters, which are much smaller than a block, and then you can 00:07:41.480 --> 00:07:45.680 take your own list of addresses and run your own list of addresses against that 00:07:45.680 --> 00:07:50.310 filter. and the filter will tell you whether or not there's something in the 00:07:50.310 --> 00:07:52.230 block. pertaining to your addresses. 00:07:52.810 --> 00:07:53.810 Yeah, or at least possibly. 00:07:54.190 --> 00:07:58.490 Yeah, there can be some false positives. So you might get a list of 1,000 blocks 00:07:58.490 --> 00:08:02.170 that you need to download, and maybe of those 1,000 blocks, only 100 actually 00:08:02.170 --> 00:08:07.850 contain your transactions. But that's better than downloading all 666,666 plus 00:08:07.850 --> 00:08:08.270 blocks. 00:08:08.550 --> 00:08:11.130 Yes. Yeah, we made that milestone this week. 00:08:11.490 --> 00:08:12.230 Yeah, exactly. 00:08:12.670 --> 00:08:14.390 That's why you remember the exact number. 00:08:14.630 --> 00:08:19.090 Precisely. It's very hard to remember. There are lots of trade-offs when it comes 00:08:19.090 --> 00:08:21.970 to these filters, so I think we should go into that for another episode. It's not 00:08:21.970 --> 00:08:26.130 enforced by consensus, so you're kind of trusting that the list is real. 00:08:27.370 --> 00:08:31.190 Although, you know, if you, let's say the list gives you a bunch of nonsense 00:08:31.190 --> 00:08:33.910 results and you start downloading those blocks and you don't see what you're 00:08:33.910 --> 00:08:37.290 expecting, well then you know that whoever gave you those filters was lying to 00:08:37.290 --> 00:08:41.110 you, but it gets a little complicated. So we'll talk about that some other time. 00:08:41.130 --> 00:08:44.550 But it's there, and it was already used in the wild a lot, especially by the 00:08:44.550 --> 00:08:48.170 mobile Lightning wallets. So, so far there was only specialized nodes that would 00:08:48.170 --> 00:08:53.820 serve that, usually running BTCD. And now every Bitcoin Core wallet can do it if 00:08:53.820 --> 00:08:54.660 you turn it on. 00:08:55.120 --> 00:08:58.820 Right, yeah. So just to be clear, the thing that's new in this Bitcoin Core 21 00:08:58.820 --> 00:09:03.840 release, I'm just going to call it Bitcoin Core 21, not Bitcoin Core 0.21. 00:09:04.080 --> 00:09:08.600 Anyways, what's new here is that I think previous Bitcoin Core release could 00:09:08.600 --> 00:09:13.720 already create the filter. And now in this Bitcoin Core release, it can share it 00:09:13.720 --> 00:09:16.020 over, I guess, the peer-to-peer network, right? 00:09:16.040 --> 00:09:17.060 That's correct, yes. 00:09:17.200 --> 00:09:17.900 That's what's new. 00:09:18.360 --> 00:09:22.280 Yeah, the filter has been... around there so as usual you know you have this 00:09:22.280 --> 00:09:25.360 filter but you can't really use it and now you can use it next one 00:09:25.360 --> 00:09:29.220 yeah so we'll we'll get back to this in another episode i think this is the short 00:09:29.220 --> 00:09:32.650 version of it next point Signet 00:09:32.650 --> 00:09:35.530 Signet which we discussed in episode 10 00:09:35.530 --> 00:09:36.210 correct 00:09:36.210 --> 00:09:41.250 in great detail but the very short version is it is like testnet but heavily 00:09:41.250 --> 00:09:46.990 centralized and everybody can make their own if you want to and it's awesome 00:09:47.630 --> 00:09:53.290 yeah what it does is it it creates a bitcoin blockchain in a way just like 00:09:53.290 --> 00:09:58.350 testnet is just sort of a copy of the bitcoin blockchain same rules and same 00:09:58.350 --> 00:10:03.470 things apply it's just it's just there for developers to test new stuff on to 00:10:03.470 --> 00:10:08.610 test new you know software on without the risk of losing coins if there are bugs 00:10:08.610 --> 00:10:13.490 and these kinds of things the problem with the testnet is that because it's so 00:10:13.490 --> 00:10:18.570 similar to the bitcoin blockchain it it depends on hash power but without any 00:10:18.570 --> 00:10:23.830 economic incentives to actually keep the [unclear] secure or stable in any way 00:10:23.830 --> 00:10:28.590 the testnet can be very insecure or no not insecure. Well, insecure and more 00:10:28.590 --> 00:10:29.450 importantly unstable 00:10:29.450 --> 00:10:34.200 yeah unstable especially because there might not be any blocks and then After 20 00:10:34.200 --> 00:10:35.800 minutes, there's like lots of blocks. 00:10:36.020 --> 00:10:36.380 Yeah. 00:10:36.520 --> 00:10:40.640 It's just a mess. You can have very large reorgs. It's not fun to develop against 00:10:40.640 --> 00:10:45.220 it. And although when you develop software, you should make it very robust, you 00:10:45.220 --> 00:10:49.200 have to deal with edge cases that really make no sense on the real Bitcoin 00:10:49.200 --> 00:10:51.020 network. So you're kind of wasting your time. 00:10:51.280 --> 00:10:57.210 Right. So yeah, Signet is like a testnet, except that... Bitcoin blocks 00:10:57.210 --> 00:11:03.210 need a valid signature from whoever is running the signet. And that 00:11:03.210 --> 00:11:08.230 person is making sure that the test network is somewhat stable. So it's 00:11:08.230 --> 00:11:12.510 completely insecure. This is not how you want to design actual Bitcoin because it 00:11:12.510 --> 00:11:16.610 depends on the trusted third party. But because it's just for testing anyways, 00:11:16.630 --> 00:11:17.230 it's fine. 00:11:17.490 --> 00:11:21.870 Yeah. And although there's just two people who can sign it. That doesn't really 00:11:21.870 --> 00:11:25.950 matter because everybody can make their own Signet with their own rules. And you 00:11:25.950 --> 00:11:31.050 can have a 15 out of 15 multisig or you can make it, everybody can sign it. It's 00:11:31.050 --> 00:11:34.110 probably a bad idea. But, you know, the centralization part is solved by just 00:11:34.110 --> 00:11:36.290 having as many as you want and it's worth nothing. 00:11:36.470 --> 00:11:41.630 So this was included in Bitcoin Core 21. What does that mean exactly to have it 00:11:41.630 --> 00:11:42.910 included in Bitcoin Core 21? 00:11:43.250 --> 00:11:47.160 Well, it means that you can start Bitcoin Core with the dash Signet. just like 00:11:47.160 --> 00:11:50.940 you can start it with dash testnet and your icon will have a nice different 00:11:50.940 --> 00:11:55.120 color. And there's a faucet out there that you can go to and you can get signet 00:11:55.120 --> 00:11:59.560 coins, which you get by the dozen, I think. So it's nice. Yeah, you can use it. 00:11:59.720 --> 00:12:04.700 And we'll go back to it again in the, well, I guess we can skip to that item now 00:12:04.700 --> 00:12:08.080 because it makes sense. Because the other thing that's included is taproot. 00:12:08.460 --> 00:12:09.900 Right. Yeah. Okay. 00:12:10.460 --> 00:12:12.800 And Taproot is active on Signet. 00:12:12.980 --> 00:12:15.160 Yeah. So we now have Taproot on Signet. 00:12:15.300 --> 00:12:15.840 That's right. 00:12:16.020 --> 00:12:20.680 Obviously, this is meaningless for regular users. This is just for developers, 00:12:20.880 --> 00:12:22.880 just for testing their software. 00:12:23.120 --> 00:12:27.380 Exactly. The main plan was to have the Taproot code inside of Bitcoin Core, 00:12:27.620 --> 00:12:31.380 unactivated, but just there so people can find bugs in it and can play with it. 00:12:31.500 --> 00:12:34.320 Which is also the case. It's in there now. 00:12:34.520 --> 00:12:38.480 Exactly. So it's nice because normally you would have the code of a software in 00:12:38.480 --> 00:12:42.040 there and you could theoretically play with it, but it's not very clear how you 00:12:42.040 --> 00:12:45.680 would do that. But now it's very clear because you can use it on Signet. And the 00:12:45.680 --> 00:12:50.320 nice thing about Signet is that the rules can be changed anytime because there's 00:12:50.320 --> 00:12:55.920 two miners that can centralize, decide to just enforce different taproot rules if 00:12:55.920 --> 00:12:57.640 the taproot spec is changed. 00:12:58.000 --> 00:12:58.440 Right. 00:12:58.740 --> 00:13:01.610 Because it's not final. until it's live. 00:13:02.110 --> 00:13:05.050 Yeah, well, it's kind of final, right? The idea is that from here on out, it 00:13:05.050 --> 00:13:09.270 shouldn't be changed anymore, I think. That's why it's included in the code in 00:13:09.270 --> 00:13:09.850 the first place. 00:13:10.050 --> 00:13:11.810 Yeah, I think you'd see it as a release candidate. 00:13:12.350 --> 00:13:12.570 Right. 00:13:13.010 --> 00:13:16.930 Because even if Taproot activates on mainnet in the future with a new version of 00:13:16.930 --> 00:13:21.010 Bitcoin Core, this old version of Bitcoin Core won't do anything with that. 00:13:21.130 --> 00:13:22.070 Right. Yeah. 00:13:22.490 --> 00:13:26.810 So even if the rules change now, there's no problem with your 0.21 node. It will 00:13:26.810 --> 00:13:30.480 not get confused if Taproot changes. Of course, hopefully it doesn't. 00:13:30.820 --> 00:13:35.000 Yeah. Sure. But about that, so yeah, the Taproot code is included in Bitcoin Core 00:13:35.000 --> 00:13:40.830 21. This also means that probably the 00:13:40.830 --> 00:13:46.410 next minor version of Bitcoin Core, which would be Bitcoin Core 21.1, 00:13:47.490 --> 00:13:52.850 well, Bitcoin Core 0.21.1, will have the actual activation logic for 00:13:52.850 --> 00:13:53.530 Taproot. 00:13:54.110 --> 00:13:55.430 Hopefully, yeah, if all goes well. 00:13:55.510 --> 00:13:56.450 That's kind of the plan, right? 00:13:56.750 --> 00:14:01.900 I mean... Yeah, I think that's the tradition. But, you know, there's no 00:14:01.900 --> 00:14:07.740 centralized management team that decides what the plan is. So it is what 00:14:07.740 --> 00:14:11.440 may happen. But yeah, let's just say that's the plan. That's the thing with an 00:14:11.440 --> 00:14:15.820 anarchistic system, right? It's what we did the last time, but nobody can force 00:14:15.820 --> 00:14:19.420 any of the volunteers and developers to do it again until it's been done. 00:14:19.820 --> 00:14:21.720 Is it time for you to take charge Sjors? 00:14:21.920 --> 00:14:22.260 No. 00:14:24.150 --> 00:14:28.830 I'm assuming that there will be a minor release, which has Taproot activation in 00:14:28.830 --> 00:14:30.610 it. It's just going to be my assumption. 00:14:30.830 --> 00:14:33.110 I'm optimistic, but I have not followed any of the... 00:14:33.110 --> 00:14:38.290 We discussed Taproot activation possibilities in Episode 3, I believe, and 00:14:38.290 --> 00:14:40.330 Taproot itself in Episode 2, or the other way around. 00:14:40.530 --> 00:14:45.330 Right, yep. and I have not followed the news since then when it comes to 00:14:45.330 --> 00:14:47.510 activation, so I guess I'll just see when it activates. 00:14:47.890 --> 00:14:52.410 Yeah, more on that discussion indeed in Episode 3 and Taproot itself in Episode 00:14:52.410 --> 00:14:54.450 2. All right, next point. 00:14:54.690 --> 00:15:00.470 Yeah, so we'll jump back in our little queue to BIP339 Witness Transaction ID 00:15:00.470 --> 00:15:06.410 Relay, or WTXID. So here's the thing. A long, long time 00:15:06.410 --> 00:15:12.150 ago, before there was SegWit, transactions had a hash. And this hash represented 00:15:12.150 --> 00:15:15.260 the entire transaction. But... 00:15:15.260 --> 00:15:16.540 It was a transaction ID. 00:15:17.230 --> 00:15:17.830 Exactly. 00:15:18.210 --> 00:15:18.330 Yeah. 00:15:18.810 --> 00:15:24.120 But then we created SegWit. And SegWit added data to the transaction. 00:15:24.440 --> 00:15:30.220 But the identifiers that we use for transactions are still based on what is in 00:15:30.220 --> 00:15:35.720 the transaction minus all the SegWit stuff. This is because old nodes don't see 00:15:35.720 --> 00:15:36.460 the SegWit stuff. 00:15:36.620 --> 00:15:42.410 Yeah, this was kind of why SegWit worked. to solve malleability. 00:15:42.850 --> 00:15:43.490 Exactly. 00:15:43.650 --> 00:15:48.030 Because previously, a transaction, before SegWit, a transaction had all the 00:15:48.030 --> 00:15:52.710 transaction details, how many bitcoins are involved, where are they going, plus 00:15:52.710 --> 00:15:56.730 the signature, and this was all hashed, and this hash was a transaction ID. 00:15:57.370 --> 00:16:03.260 However, it turned out that slightly different signatures could all be 00:16:03.260 --> 00:16:08.840 valid. And therefore, a signature could be changed in flight, for example. 00:16:09.100 --> 00:16:13.940 You send the transaction to the network. Someone on that network slightly changes 00:16:13.940 --> 00:16:17.460 the signature. The transaction is still valid. But all of a sudden, the 00:16:17.460 --> 00:16:21.640 transaction ID changed because the hash changed because the signature changed. So 00:16:21.640 --> 00:16:26.240 to solve that, this was a problem for things like lightning. So to solve this, 00:16:26.800 --> 00:16:32.130 SegWit separated the transaction details from the signature. the transaction 00:16:32.130 --> 00:16:36.950 details were still hashed to create the transaction ID, and the signature was put 00:16:36.950 --> 00:16:42.570 in a separate part of a block, segwit part of the block, and therefore 00:16:42.570 --> 00:16:44.050 malleability was solved. 00:16:44.270 --> 00:16:44.790 That's right. 00:16:44.990 --> 00:16:48.790 But this meant that the signature was not part of the transaction ID at all. 00:16:49.190 --> 00:16:52.470 That's right, and that makes a lot of sense when you, for example, have something 00:16:52.470 --> 00:16:57.630 like Lightning or any sort of escrow system where you pre-sign a transaction to 00:16:57.630 --> 00:17:01.590 release coins. You want to make sure that the transactions go in. And so the 00:17:01.590 --> 00:17:05.430 transaction that releases the coins refers to the transaction that puts the coins 00:17:05.430 --> 00:17:08.910 in there. So you don't want somebody to be able to change that transaction that 00:17:08.910 --> 00:17:13.290 goes in. Because then you suddenly don't have a release transaction anymore and 00:17:13.290 --> 00:17:14.290 your coins are held hostage. 00:17:14.610 --> 00:17:16.370 So what's this change now? 00:17:16.610 --> 00:17:20.470 So what this change is not about how the consensus works, but it's how 00:17:20.470 --> 00:17:26.340 transactions are relayed between nodes. So when a node... talks to another node 00:17:26.340 --> 00:17:29.380 that says, hey, here's a bunch of transaction IDs. Would you like the whole 00:17:29.380 --> 00:17:33.860 transaction for this thing? And that's still referring to this pre-SegWit 00:17:33.860 --> 00:17:39.320 transaction hash, also the on-chain transaction hash. But this new change lets 00:17:39.320 --> 00:17:44.600 you gossip these transactions using the witness transaction ID, which does 00:17:44.600 --> 00:17:48.700 include the signature, I believe. Now, I don't know why that's useful, to be 00:17:48.700 --> 00:17:52.340 honest, but because I haven't read up on what exactly the BIP is saying. I'm just 00:17:52.340 --> 00:17:56.400 saying that... you can now gossip transactions based on including the witness, 00:17:56.660 --> 00:17:59.400 which I guess could have some benefit. 00:17:59.660 --> 00:18:03.780 Does this have something to do with potentially sharing a transaction with an 00:18:03.780 --> 00:18:06.460 invalid signature and therefore... 00:18:06.460 --> 00:18:10.960 That's my theory because I should have read it, but my guess is that indeed you 00:18:10.960 --> 00:18:15.680 would send another node a transaction hash and they would ask for the transaction 00:18:15.680 --> 00:18:18.260 and you would give it a fake transaction because you would just add your own 00:18:18.260 --> 00:18:22.190 signature to it and it would just be nonsense. And then the other node would say, 00:18:22.270 --> 00:18:25.570 okay, this transaction is dumb. I'm just going to ignore that moving forward. And 00:18:25.570 --> 00:18:30.450 then another node would give the real one, but this node is now rejecting it 00:18:30.450 --> 00:18:34.110 because it's already seen it and it thought it was fake. So you want to prevent that. 00:18:34.350 --> 00:18:39.630 Right. And that's what this new change might solve is your speculation, but 00:18:39.630 --> 00:18:42.430 neither of us is actually sure because we didn't read the BIP. 00:18:42.630 --> 00:18:43.090 That's right. 00:18:43.810 --> 00:18:45.290 Read the BIP fellows. 00:18:45.590 --> 00:18:46.810 I also know this was done. 00:18:46.810 --> 00:18:48.730 And it's BIP, which one is it? 00:18:49.030 --> 00:18:53.620 339. Yes. I also know this was done before Taproot because it has some sort of 00:18:53.620 --> 00:18:54.460 utility there too. 00:18:54.940 --> 00:18:55.140 Right. 00:18:55.560 --> 00:18:56.800 All right, next item. 00:18:57.440 --> 00:19:02.860 Next item is Taproot, which we've already covered. So then the next item is a 00:19:02.860 --> 00:19:04.480 bunch of RPC changes. 00:19:04.900 --> 00:19:08.040 That's right. If you look at the release notes, a lot of changes are about the 00:19:08.040 --> 00:19:11.140 RPC, and we're not going to mention them because they're not that interesting. 00:19:11.660 --> 00:19:14.200 RPC stands for Remote Procedure Call. 00:19:14.460 --> 00:19:14.900 Yes. 00:19:15.000 --> 00:19:16.220 What does that mean actually, Sjors? 00:19:16.280 --> 00:19:20.720 It basically means if you're running a Bitcoin node, then you can issue commands 00:19:20.720 --> 00:19:24.760 to it. And if you're a desktop user, you would just click on buttons. But if 00:19:24.760 --> 00:19:27.940 you're in the command line, well, you would type Bitcoin client, then some 00:19:27.940 --> 00:19:30.680 command. But if you are on the network, 00:19:32.050 --> 00:19:36.770 you probably want to send some JSON to it and get some JSON back from it over the 00:19:36.770 --> 00:19:42.070 network. And that's what these RPC calls are for. So you can send the commands 00:19:42.070 --> 00:19:44.310 over the network and get a response back. 00:19:44.830 --> 00:19:45.290 Right. 00:19:45.650 --> 00:19:49.990 And if you've built some sort of complicated server, you want to make sure 00:19:49.990 --> 00:19:54.330 nothing breaks. And Bitcoin Core is always very careful. It tries not to make 00:19:54.330 --> 00:20:00.170 breaking changes in that RPC. So, for example, a situation you might be in 00:20:00.170 --> 00:20:06.110 is you run a block explorer of some sort and you have one little server 00:20:06.110 --> 00:20:11.930 machine that has a Bitcoin full node on it. And we'll get to that actually with 00:20:11.930 --> 00:20:15.600 the ZMQ explanation, but I guess we'll transition to that. So you'll have one 00:20:15.600 --> 00:20:20.700 node that runs Bitcoin Core on it and another that runs a database and another 00:20:20.700 --> 00:20:24.000 that runs the website because usually, you know, they try to split all these 00:20:24.000 --> 00:20:29.180 things up. So the web server might ask the node questions like, what is the 00:20:29.180 --> 00:20:34.020 current block height? Or, you know, what's in your mempool? That's done via RPC. 00:20:34.980 --> 00:20:40.270 Or it might say, send a transaction to this person. That's also done via RPC. So 00:20:40.270 --> 00:20:43.050 that's all scripts and code. So you want to make sure that your code is still 00:20:43.050 --> 00:20:46.650 doing what you think it's doing when you upgrade the node. But which brings us to 00:20:46.650 --> 00:20:52.550 the next point, ZeroMQ feature improvement. So you can read in, if you find 00:20:52.550 --> 00:20:54.370 this interesting, you can read in the release notes exactly what. 00:20:54.570 --> 00:20:56.070 Is that one of the RPC changes? 00:20:56.860 --> 00:21:02.700 Well, ZeroMQ is not actually RPC, but it's also a way to communicate. 00:21:03.040 --> 00:21:03.260 Okay. 00:21:03.680 --> 00:21:09.680 So with RPC, you have the Bitcoin node is listening. and you send a command 00:21:09.680 --> 00:21:14.320 to it and you get a response back. That's how RPC works. But ZeroMQ is push 00:21:14.320 --> 00:21:19.300 -based. So what you're doing is the Bitcoin node is constantly broadcasting and 00:21:19.300 --> 00:21:22.720 you can listen to that broadcast through a channel. And so the broadcast could be 00:21:22.720 --> 00:21:27.390 every new block. So then you're listening to a certain channel and you get the 00:21:27.390 --> 00:21:32.750 block as soon as the node sees it. Or you can listen to transactions. Or I 00:21:32.750 --> 00:21:36.550 believe you can even listen to transactions at a certain address. This might be 00:21:36.550 --> 00:21:41.130 useful if you have a block explorer with a live page where you're looking at an 00:21:41.130 --> 00:21:45.830 address and then the node sees a new transaction on that address. It sends a 00:21:45.830 --> 00:21:50.970 message to your ZMQ. to the web server, and the web server sends a WebSocket 00:21:50.970 --> 00:21:54.610 message to the browser so your browser updates without having to hit the refresh 00:21:54.610 --> 00:21:56.050 button. Something like that. 00:21:56.330 --> 00:21:56.470 Okay. 00:21:56.910 --> 00:21:59.110 So that's nice for people who care about that. Next item. 00:21:59.370 --> 00:22:00.230 Okay. Yep. 00:22:00.830 --> 00:22:05.410 There is a new SendRPC by yours truly, which is cool. 00:22:06.640 --> 00:22:10.140 Basically, if you want to send coins through the command line, you can do it with 00:22:10.140 --> 00:22:13.240 the graphical interface, but if the cool kids want to do it with the command 00:22:13.240 --> 00:22:18.160 line, it's very tedious. When the first version of Bitcoin Core came out, when it 00:22:18.160 --> 00:22:21.420 wasn't even Bitcoin Core, I think you just had a command called send to address, 00:22:21.620 --> 00:22:25.080 and you gave it an address and an amount, and that was it. And that's still out 00:22:25.080 --> 00:22:29.940 there. But the problem is that command got expanded, but it doesn't have all the 00:22:29.940 --> 00:22:34.400 features you may want. And at the same time, there were commands to create PSBTs 00:22:34.400 --> 00:22:35.960 that we talked about in an earlier episode. 00:22:36.760 --> 00:22:38.560 Partially signed Bitcoin transactions. 00:22:38.760 --> 00:22:41.320 Exactly. And those were very powerful. You could do all sorts of cool things to 00:22:41.320 --> 00:22:45.320 your transaction, including coin selection, for example, through the command 00:22:45.320 --> 00:22:49.800 line. But it was very tedious because if you want to make a PSBT, then you have 00:22:49.800 --> 00:22:54.960 to... make it and then sign it and then finalize it and do a bunch of things. So 00:22:54.960 --> 00:22:59.740 the problem was you had a very simple way to send coins with the very old Satoshi 00:22:59.740 --> 00:23:04.900 Time RPC methods, just sent to an address, but you couldn't configure it. Or 00:23:04.900 --> 00:23:09.280 you had a super powerful method that was extremely hard to use. And so the new 00:23:09.280 --> 00:23:13.070 SendRPC is... easier to use, and powerful. 00:23:13.370 --> 00:23:14.190 And you made this? 00:23:14.410 --> 00:23:16.030 Yes, and it's been improved since. 00:23:16.230 --> 00:23:16.750 Thank you, Sjors. 00:23:16.950 --> 00:23:19.890 Hopefully you're welcome. It's marked experimental, so if you... 00:23:19.890 --> 00:23:22.710 I'm not one of the cool kids anyways, I just used GUI. 00:23:23.050 --> 00:23:27.010 Well, it's especially useful if you're experimenting with newer features like 00:23:27.010 --> 00:23:31.090 hardware wallet integration and stuff. Then you want to experiment on the command 00:23:31.090 --> 00:23:33.210 line and then hopefully later do it in the GUI. 00:23:33.390 --> 00:23:38.250 How is that going to take a side path? What's going on with hardware integration, 00:23:38.490 --> 00:23:39.390 hardware wallet integration? 00:23:39.670 --> 00:23:43.890 It's very slow. Yeah. So I think I gave a presentation in 00:23:43.890 --> 00:23:46.330 2019 or something. 00:23:46.410 --> 00:23:46.710 In London. 00:23:47.100 --> 00:23:51.080 Yeah, and Andrew Chow has done it as well. Yeah. And I mean, the final picture we 00:23:51.080 --> 00:23:55.400