WEBVTT 00:00:13.140 --> 00:00:15.840 So with that, I think we should say... 00:00:16.000 --> 00:00:18.440 Live from Amsterdam, this is Bitcoin. 00:00:17.890 --> 00:00:19.730 Explained. 00:00:18.440 --> 00:00:20.240 Hey, Sjors. 00:00:20.240 --> 00:00:20.680 Hello. 00:00:20.680 --> 00:00:24.380 This is the first time I can say that without lying. 00:00:24.980 --> 00:00:25.720 Hey, Sjors? 00:00:25.720 --> 00:00:27.640 No, yeah well, no, that we're live. 00:00:27.960 --> 00:00:29.280 That's that. 00:00:28.060 --> 00:00:28.760 Oh, okay. 00:00:28.940 --> 00:00:29.160 Yes. 00:00:29.280 --> 00:00:33.320 So I don't know if you even remember why I started saying that. 00:00:33.680 --> 00:00:35.100 Why, you said live from Utrecht? 00:00:34.980 --> 00:00:38.180 Yeah, I mean, we never actually record live, right? 00:00:35.300 --> 00:00:35.640 Yes. 00:00:38.280 --> 00:00:41.200 It's always recorded and even edited and... 00:00:41.480 --> 00:00:47.020 But yeah, CK at the time, our manager at Bitcoin Magazine, he said we needed a... 00:00:47.020 --> 00:00:50.120 That was the only pointer we got from him when we made our podcast. 00:00:50.320 --> 00:00:55.120 He said you need a way, like a standard way to open the podcast and a standard way 00:00:55.120 --> 00:00:56.060 to close the podcast. 00:00:56.280 --> 00:00:59.100 And otherwise, you know, you have free reign. 00:00:59.320 --> 00:01:00.660 And we didn't prepare anything. 00:01:00.800 --> 00:01:03.440 And I think at the time was just the first thing that came to mind. 00:01:03.580 --> 00:01:04.300 So we stuck with it. 00:01:03.840 --> 00:01:08.320 Well, the first episode we ever recorded was a complete flop because we didn't 00:01:08.320 --> 00:01:08.780 prepare it. 00:01:09.060 --> 00:01:12.920 Because we thought like, ah, PSBT bugs in hardware wallets, that's not too 00:01:12.920 --> 00:01:13.380 complicated. 00:01:13.380 --> 00:01:14.660 We can explain it off the cuff. 00:01:14.900 --> 00:01:18.140 And like within two sentences, it was like, I have no idea how this works. 00:01:18.440 --> 00:01:19.280 Oh, that's right. 00:01:19.420 --> 00:01:20.280 And also... 00:01:20.800 --> 00:01:26.420 I think the original concept for our podcast, we wanted to do two 00:01:26.420 --> 00:01:27.780 topics per episode. 00:01:28.860 --> 00:01:34.780 We want to do two topics per episode and because I at that time I was still kind 00:01:34.780 --> 00:01:38.640 of working as technical editor I was still on my late sort of stage of being the 00:01:38.640 --> 00:01:43.620 technical editor before writing a book and becoming editor-in-chief and and so I 00:01:43.620 --> 00:01:48.100 was still covering technical stuff like very regularly and I think the original 00:01:48.100 --> 00:01:50.740 idea was I will explain a topic you will explain a 00:01:50.740 --> 00:01:55.020 topic to me and I'll explain a topic to you because sometimes maybe I had something 00:01:55.020 --> 00:01:56.140 that you didn't know 00:01:55.780 --> 00:01:58.200 You had an idea of explaining a topic to me? 00:01:58.000 --> 00:02:00.300 Yeah, you don't even remember. 00:02:01.360 --> 00:02:03.200 That's how far we drifted from that. 00:02:03.360 --> 00:02:06.620 We completely abandoned that concept and now it's just me. 00:02:07.380 --> 00:02:09.560 Sjors knows everything and I know nothing basically. 00:02:09.840 --> 00:02:15.540 Well, you do know a lot, but the recipe is usually we have like a call before and 00:02:15.540 --> 00:02:16.500 we did that today as well. 00:02:17.090 --> 00:02:21.470 to kind of go through it a bit and then hopefully the real thing will be better, 00:02:21.610 --> 00:02:22.850 but we'll see how it goes. 00:02:22.770 --> 00:02:24.510 Yeah, and just out of interest. 00:02:24.830 --> 00:02:30.520 So I assume most people have at least listened to it. 00:02:30.560 --> 00:02:33.060 Is there anyone in the room that has never listened to our podcast? 00:02:33.280 --> 00:02:34.520 That doesn't know our podcast? 00:02:34.920 --> 00:02:39.160 Okay, that's actually unsurprisingly, but it's still a big number. 00:02:38.010 --> 00:02:41.630 It also doesn't add up because I asked the opposite question and we got like 10 00:02:41.630 --> 00:02:41.990 hands. 00:02:42.850 --> 00:02:48.770 so a lot of neutrals is there anyone who knew that we do 00:02:43.150 --> 00:02:44.690 So a lot of people have good OPSEC. 00:02:48.770 --> 00:02:53.670 still make a podcast sometimes because we used to make it like weekly at one point 00:02:53.670 --> 00:02:58.350 and now it's three or four a year maybe anyway okay so 00:02:57.260 --> 00:03:00.600 Yeah, I mean, part of the problem was just it became exponentially... 00:03:00.600 --> 00:03:04.340 In the beginning, we did episodes about topics that I already knew something about, 00:03:04.210 --> 00:03:06.370 yeah yeah 00:03:04.380 --> 00:03:08.480 but at some point you run out, and then I had to spend like a day preparing the 00:03:08.480 --> 00:03:12.320 podcast, which makes no sense unless you're like Peter McCormack famous. 00:03:13.060 --> 00:03:18.140 yeah yeah and and also we want to make it in person and I haven't been living in 00:03:16.760 --> 00:03:17.200 Yes, 00:03:18.140 --> 00:03:23.330 the netherlands for the last year and a half two years so that doesn't help So 00:03:23.330 --> 00:03:25.030 anyways, we'll make a new episode. 00:03:25.190 --> 00:03:30.330 So yeah, the general concept for those to know basically every episode we pick a 00:03:30.330 --> 00:03:34.610 topic about Bitcoin, a technical topic that we then explain. 00:03:36.360 --> 00:03:40.980 And or we've also made, so now actually most of our podcasts are if there's a new 00:03:40.980 --> 00:03:45.340 Bitcoin Core release and then we kind of go over what's new in the new Bitcoin Core 00:03:45.340 --> 00:03:45.680 release. 00:03:46.000 --> 00:03:47.740 That's what we'll be doing today, right? 00:03:47.610 --> 00:03:47.990 exactly. 00:03:48.200 --> 00:03:50.300 So we're going to talk about Bitcoin Core 32. 00:03:50.680 --> 00:03:54.000 I don't even, is it even, is it released? 00:03:50.690 --> 00:03:51.490 Point one, 00:03:53.710 --> 00:03:54.690 yes. 00:03:54.200 --> 00:03:55.140 I don't even know that. 00:03:55.260 --> 00:03:55.980 When was it released? 00:03:55.810 --> 00:03:59.090 So v32.0 was never released. 00:03:59.990 --> 00:04:03.310 V32.1 was released, I don't know, two weeks ago, one week ago. 00:04:03.570 --> 00:04:07.650 Okay, so we actually, I didn't even know this, but it's a good timing to make this 00:04:07.650 --> 00:04:08.070 podcast. 00:04:07.770 --> 00:04:08.310 Yes. 00:04:08.290 --> 00:04:10.130 That's right, because we planned it a while ago. 00:04:09.940 --> 00:04:10.680 Yes. 00:04:10.890 --> 00:04:16.150 But we, Bitcoin Core comes out every like six months is, so we could at least make 00:04:16.150 --> 00:04:17.530 a good estimate. 00:04:18.010 --> 00:04:22.610 Yeah, so the way we make these episodes is we go through the release notes of 00:04:22.610 --> 00:04:26.450 Bitcoin Core, we write down the... 00:04:26.600 --> 00:04:31.120 four or five maybe six topics that sort of are more interesting because there's 00:04:31.120 --> 00:04:34.740 always a bunch of bug fixes and there's always a bunch of stuff that you can't 00:04:34.740 --> 00:04:39.600 really talk much about although in this episode we will talk about some bug fixes 00:04:36.470 --> 00:04:37.210 Yes. 00:04:39.600 --> 00:04:45.420 because they're particularly relevant but we'll start out So we, again, we picked 00:04:41.250 --> 00:04:41.990 Yes. 00:04:45.420 --> 00:04:48.500 out like a handful of topics that are interesting 00:04:48.500 --> 00:04:53.420 enough, at least for those that are interested in this kind of stuff, to talk about 00:04:53.420 --> 00:04:53.700 a bit. 00:04:53.940 --> 00:04:57.280 And then mostly Sjors will do the explaining and I'll do the asking questions. 00:04:58.110 --> 00:04:59.050 Sounds good. 00:04:58.140 --> 00:04:58.380 Good? 00:04:58.820 --> 00:04:59.420 You're ready? 00:04:59.110 --> 00:05:00.070 Go for it. 00:04:59.920 --> 00:05:00.360 Okay. 00:05:00.920 --> 00:05:03.880 So the first one we wrote down is proof of work. 00:05:04.420 --> 00:05:06.600 I can't even read my own handwriting. 00:05:07.200 --> 00:05:08.320 Proof work with Tor. 00:05:07.580 --> 00:05:08.660 Proof of work defenses. 00:05:09.530 --> 00:05:11.210 Yeah, so there's, okay, go on. 00:05:09.830 --> 00:05:10.190 Yeah. 00:05:11.340 --> 00:05:12.080 So. 00:05:11.370 --> 00:05:12.970 I'll hand you the floor. 00:05:13.020 --> 00:05:15.560 So everybody presumably knows the Tor network. 00:05:16.640 --> 00:05:22.370 They've been under attack quite a lot in recent years by, well, they have some 00:05:22.370 --> 00:05:25.430 suspicions of who these people are, but it doesn't really matter. 00:05:25.790 --> 00:05:27.470 Their network is constantly under attack. 00:05:27.620 --> 00:05:28.700 What is the attack? 00:05:29.230 --> 00:05:33.890 Basically a DOS, denial of service, so your Tor node, especially your hidden 00:05:33.890 --> 00:05:37.930 service sites, becomes unreachable or you can't connect to something, and that's 00:05:37.930 --> 00:05:38.410 kind of annoying. 00:05:39.030 --> 00:05:39.930 And remember that... 00:05:39.220 --> 00:05:43.060 Yeah, so you're running a Tor node or a Bitcoin node, I guess, over Tor and you 00:05:43.060 --> 00:05:45.120 just get tons of connection requests. 00:05:44.690 --> 00:05:50.030 Yeah, so on Tor you are you know as a consumer you are browsing stuff on Tor 00:05:50.030 --> 00:05:55.030 network or outside and There are websites on Tor called the darknet But a Bitcoin 00:05:55.030 --> 00:05:59.530 node can actually be like a darknet website as in you can be reachable on Tor as a 00:05:59.530 --> 00:06:00.010 hidden service 00:06:01.310 --> 00:06:05.450 And yeah, so the Tor project itself came up with a solution, or at least a partial 00:06:05.450 --> 00:06:06.630 solution, called Proof of Work. 00:06:07.350 --> 00:06:08.710 We're familiar with this idea. 00:06:09.710 --> 00:06:14.190 It's not one difficulty, I believe. 00:06:14.410 --> 00:06:19.590 It's just every node for themselves decides how much they want the clients to work. 00:06:19.790 --> 00:06:22.310 And that's sort of a way for them to rate limit the attack. 00:06:22.430 --> 00:06:25.270 Makes the attack just more expensive, because the attacker has to do a bunch of 00:06:25.270 --> 00:06:25.530 work. 00:06:25.790 --> 00:06:27.950 Whereas the legitimate users can do it. 00:06:26.730 --> 00:06:30.770 And the work like in Bitcoin, it just means you have to make a bunch of hashes 00:06:30.770 --> 00:06:35.780 until you come up with like a valid hash as determined by your node, like how many 00:06:33.540 --> 00:06:34.800 Yeah, I don't know if it's a hash. 00:06:35.780 --> 00:06:36.580 zeros it needs. 00:06:36.620 --> 00:06:39.520 Yeah, I don't know what exactly the proof of work they use. 00:06:39.740 --> 00:06:41.580 Probably not SHA-256 or something else. 00:06:42.900 --> 00:06:44.120 But yeah, that's the idea. 00:06:45.260 --> 00:06:49.720 And now Bitcoin Core, because it can also be a listening Tor node, if you have that 00:06:49.720 --> 00:06:52.280 installed, it will turn that feature on. 00:06:52.860 --> 00:06:56.100 So there's nothing that Bitcoin Core is doing other than telling the Tor software, 00:06:56.220 --> 00:06:56.940 like, use this. 00:06:57.660 --> 00:07:01.960 Right, okay, so I'm using Bitcoin Core over Tor and you are using Bitcoin Core over 00:07:01.960 --> 00:07:07.380 Tor, let's say I want to connect to your node and now I have to do some, my node 00:07:07.380 --> 00:07:12.020 has to do some work in order for that connection to be accepted by you. 00:07:11.850 --> 00:07:16.990 Yeah, your Tor software has to do some work for my Tor software to 00:07:12.440 --> 00:07:16.320 Yeah, right. 00:07:16.990 --> 00:07:18.990 let the nodes talk to each other. 00:07:19.110 --> 00:07:21.590 So the nodes don't really bother with any of this. 00:07:21.730 --> 00:07:23.610 It's the underlying Tor software that's doing it. 00:07:26.550 --> 00:07:31.590 Why do you think because I wrote a book right on the prehistory of Bitcoin so also 00:07:31.590 --> 00:07:35.970 about the invention of proof-of-work which Adam Back at least a Bitcoin version of 00:07:35.970 --> 00:07:40.630 it was invented by Adam Back and for him at the time he saw proof-of-work kind of 00:07:40.630 --> 00:07:46.590 as a stopgap until digital cash was invented as a way to make a payment 00:07:46.590 --> 00:07:48.390 basically right but you have to 00:07:48.390 --> 00:07:53.630 prove work so wouldn't it be much cooler if Tor actually starts to use Bitcoin now 00:07:53.630 --> 00:07:58.590 that Bitcoin exists and then you send a couple of sats to a node in order to be 00:07:58.590 --> 00:08:01.510 connected so we can skip that proof of work aspect. 00:08:01.720 --> 00:08:03.240 If I take your question... 00:08:02.030 --> 00:08:05.350 Why don't you lobby the Tor project to implement that? 00:08:05.270 --> 00:08:08.310 Well, your question was, would it be cooler? 00:08:08.550 --> 00:08:10.590 Yes, agreed. 00:08:08.630 --> 00:08:09.570 And the answer is yes. 00:08:10.650 --> 00:08:14.190 The question is, would it be easier? 00:08:14.410 --> 00:08:15.870 And the answer is absolutely not. 00:08:16.610 --> 00:08:20.490 So the Bitcoin proof of work itself is ridiculously simple, right? 00:08:20.550 --> 00:08:24.350 You just count the number of zeros before the hash or some equivalent problem. 00:08:24.950 --> 00:08:29.690 And like I said in the introduction here, we don't need... 00:08:30.750 --> 00:08:32.270 global coordination of the proof of work. 00:08:32.410 --> 00:08:36.290 So in Bitcoin, the complexity is in coordinating all the nodes to agree on what the 00:08:36.290 --> 00:08:37.850 proof of work is, what the difficulty is. 00:08:38.470 --> 00:08:40.570 As far as I know, for Tor, it's a local thing. 00:08:40.690 --> 00:08:41.930 Your node is getting dosed. 00:08:42.230 --> 00:08:43.810 It just increases the proof of work. 00:08:44.230 --> 00:08:46.410 until the DOS becomes manageable. 00:08:47.150 --> 00:08:51.630 That's not a coordination problem, so it's just much easier to do that way. 00:08:52.270 --> 00:08:57.730 I could imagine one day perhaps them using something like ecash because, yes, they 00:08:57.730 --> 00:09:00.330 could use Lightning, but the problem with Lightning is now you need to have your 00:09:00.330 --> 00:09:04.010 Tor network, have the Lightning channels routing across the Tor network, but you 00:09:04.010 --> 00:09:04.890 have this chicken-egg problem. 00:09:04.930 --> 00:09:10.190 If your Tor network goes down, you can't pay somebody to bypass the DOS, but ecash 00:09:10.190 --> 00:09:12.950 would bypass it, but ecash, as in Cashu, is... 00:09:13.170 --> 00:09:13.710 custodial. 00:09:15.070 --> 00:09:16.470 But it could help here. 00:09:16.610 --> 00:09:19.610 And I think there's also a philosophical difference, which could be a legal 00:09:19.610 --> 00:09:19.970 difference. 00:09:20.430 --> 00:09:24.070 Right now, the Tor network is entirely volunteer run. 00:09:24.490 --> 00:09:28.610 As soon as you start paying people, governments have opinions about that that are 00:09:28.610 --> 00:09:30.190 different than when you're not paying people. 00:09:30.790 --> 00:09:33.130 Although, you know, we've seen that not always work out. 00:09:33.340 --> 00:09:34.140 Yeah, okay. 00:09:34.420 --> 00:09:37.380 TLDR, it's just much easier to use proof of work and that's new. 00:09:36.900 --> 00:09:41.140 In theory, your nodes on Tor should now be better reachable when there's a DOS 00:09:41.140 --> 00:09:41.400 attack. 00:09:41.600 --> 00:09:43.680 But I haven't looked at any measurements here. 00:09:43.640 --> 00:09:44.100 Right. 00:09:44.380 --> 00:09:46.360 Okay, next point then. 00:09:46.600 --> 00:09:51.240 I believe this isn't even a new thing, but we decided to include it anyways. 00:09:52.520 --> 00:09:56.400 So it has to do with CJDNS. 00:09:56.390 --> 00:09:56.970 That's right. 00:09:56.720 --> 00:09:58.360 Okay, explain. 00:09:58.360 --> 00:09:59.740 I have no idea what it is. 00:09:59.740 --> 00:10:00.420 Yeah. 00:10:00.380 --> 00:10:06.080 Apparently it's something like Tor and I2P, like a privacy network, using a 00:10:06.080 --> 00:10:06.820 different mechanism. 00:10:07.420 --> 00:10:12.320 The main issue, and Bitcoin Core added support for that years ago, and apparently 00:10:12.320 --> 00:10:16.260 very few people use it, and it does add complexity to the code base. 00:10:16.480 --> 00:10:21.240 So the call to action to Bitcoin Core users is, if you like this feature, 00:10:21.660 --> 00:10:24.980 speak out, because otherwise we might disappear it. 00:10:25.150 --> 00:10:25.930 Right, okay. 00:10:26.050 --> 00:10:30.890 So it's another potential privacy layer for Bitcoin Core that you can use. 00:10:31.110 --> 00:10:35.870 It is available now, but because it's so little use, there's now an open question 00:10:35.870 --> 00:10:37.310 like, should we even keep this? 00:10:37.280 --> 00:10:40.540 Yeah, so if you have like three peers on the network, it's not... 00:10:37.950 --> 00:10:42.210 And so what if one person says, I love cjdns. 00:10:42.530 --> 00:10:45.270 Is it then going to stay or what's the... 00:10:45.270 --> 00:10:47.130 How is this decision going to be made? 00:10:45.340 --> 00:10:49.380 My guess is then that person would have to fix all the bugs related to it. 00:10:49.720 --> 00:10:51.840 And if they do that, then it might stay. 00:10:52.110 --> 00:10:52.750 All right. 00:10:52.500 --> 00:10:55.080 I haven't looked into details, but that's typically how it goes. 00:10:53.610 --> 00:10:54.730 So it's part... 00:10:55.180 --> 00:10:58.660 If you want a feature to stay, then you should take some responsibility. 00:11:00.350 --> 00:11:03.170 If you want a feature to stay and you're not willing to do the work, then it will 00:11:03.170 --> 00:11:03.850 definitely go away. 00:11:04.390 --> 00:11:06.850 If you are willing to do the work, then it might not go away. 00:11:06.670 --> 00:11:07.370 Right. 00:11:07.950 --> 00:11:08.470 Yeah. 00:11:08.040 --> 00:11:11.980 This is also how Windows survives and the wallet survives and the GUI survives and 00:11:11.980 --> 00:11:14.920 all these things that there's always people that want to get rid of it because it's 00:11:14.920 --> 00:11:18.920 extra stuff But then there's people say no don't take it away from me and I'll 00:11:18.920 --> 00:11:22.020 maintain it and then that's how it stays in Then 00:11:21.640 --> 00:11:26.900 Yeah, I told you this in the preparation, but I think I randomly know this guy from 00:11:26.900 --> 00:11:28.340 years ago. 00:11:28.780 --> 00:11:31.620 I was at a conference and I just slept at his place. 00:11:31.820 --> 00:11:32.420 He offered me... 00:11:32.420 --> 00:11:34.240 I had no idea what CJDNS was. 00:11:34.360 --> 00:11:35.660 I had no idea who the guy was. 00:11:35.880 --> 00:11:38.300 But it's like now 10 years later, I come across this. 00:11:38.420 --> 00:11:39.280 I know that guy. 00:11:39.480 --> 00:11:40.440 I think his name is Caleb. 00:11:41.120 --> 00:11:43.240 Maybe I should reach out to him and ask about this. 00:11:41.380 --> 00:11:43.000 you should maybe talk to him. 00:11:43.120 --> 00:11:43.760 Yeah, exactly. 00:11:43.760 --> 00:11:44.300 Should I? 00:11:44.420 --> 00:11:46.080 Is that something you would want? 00:11:47.080 --> 00:11:48.300 It sounds like... 00:11:47.130 --> 00:11:48.330 I think I know the guy. 00:11:48.300 --> 00:11:51.300 He should pitch it. 00:11:48.470 --> 00:11:50.410 I think I have his number randomly again. 00:11:51.520 --> 00:11:51.620 Yeah. 00:11:52.680 --> 00:11:54.600 Okay, let's move on to the next topic. 00:11:52.780 --> 00:11:53.220 Okay. 00:11:53.620 --> 00:11:54.060 Oh, 00:11:56.670 --> 00:11:57.070 Increase... 00:11:57.070 --> 00:12:00.390 Jeez, my handwriting and the light also does help. 00:12:01.530 --> 00:12:04.860 Increase inbound activity. 00:12:05.480 --> 00:12:06.660 you're going slightly different. 00:12:06.100 --> 00:12:07.160 Is that the next one? 00:12:06.900 --> 00:12:09.200 You're not doing lib event or is that later on your list? 00:12:09.410 --> 00:12:09.930 What's that? 00:12:09.780 --> 00:12:12.460 There should be one about libevent still, HTTP. 00:12:12.520 --> 00:12:13.540 Am I skipping one? 00:12:13.450 --> 00:12:14.790 Yes, there's another. 00:12:14.620 --> 00:12:15.680 Sorry, what am I skipping? 00:12:16.540 --> 00:12:20.980 Removing libevent in favor of HTTP ourselves. 00:12:21.490 --> 00:12:22.770 That's the next one on my list. 00:12:22.970 --> 00:12:24.810 Well, it's in the theme of removing things. 00:12:26.000 --> 00:12:26.540 Okay. 00:12:26.040 --> 00:12:26.840 Okay, yeah, go. 00:12:27.060 --> 00:12:27.600 Okay, sure. 00:12:27.780 --> 00:12:28.160 We can skip. 00:12:28.850 --> 00:12:33.160 So we have a bunch of dependencies in Bitcoin Core. 00:12:33.460 --> 00:12:34.940 One of them is called libevent. 00:12:35.100 --> 00:12:36.040 It's a very old library. 00:12:36.440 --> 00:12:38.100 It helps us... 00:12:38.440 --> 00:12:40.000 to HTTP stuff. 00:12:40.240 --> 00:12:43.740 You might ask yourself, what is Bitcoin Core doing that has anything to do with 00:12:43.740 --> 00:12:44.000 HTTP? 00:12:44.180 --> 00:12:48.640 Well, we have something called the RPC, which is the way your node talks to any 00:12:48.640 --> 00:12:50.360 kind of other software, typically. 00:12:49.580 --> 00:12:49.880 Yeah. 00:12:51.540 --> 00:12:55.080 Which could be wallets, which could be applications, which could be... 00:12:52.820 --> 00:12:56.420 Which could be external wallets, can be your lightning node, probably. 00:12:56.400 --> 00:13:00.220 Yeah, just if you want your node to talk with anything else and that's what you 00:13:00.220 --> 00:13:00.640 would use 00:13:01.320 --> 00:13:02.680 Anything else on your computer? 00:13:02.630 --> 00:13:03.590 Yeah, 00:13:02.920 --> 00:13:03.200 Yes. 00:13:03.780 --> 00:13:07.840 So your computer, so your Bitcoin node spins up a little web server that speaks 00:13:07.840 --> 00:13:12.460 JSON and it gets a command like get blockchain info and it replies, you know, this 00:13:12.460 --> 00:13:13.500 is the height, this is etc. 00:13:14.260 --> 00:13:18.420 So it's a very simple web server and that web server is powered by LibEvent. 00:13:18.600 --> 00:13:20.280 I think LibEvent was also doing some other things. 00:13:20.920 --> 00:13:23.380 But now we've taken the essence. 00:13:24.020 --> 00:13:26.680 that we need, the HTTP part. 00:13:26.820 --> 00:13:29.220 We implemented that and threw away lib event. 00:13:29.440 --> 00:13:30.640 So fewer dependencies. 00:13:31.100 --> 00:13:33.840 Now we have to maintain some HTTP server code. 00:13:34.020 --> 00:13:36.320 But apparently, that trade-off is worth it. 00:13:36.100 --> 00:13:41.080 yeah, explain why is few I mean for those that don't know why is fewer dependencies 00:13:41.080 --> 00:13:41.500 better? 00:13:41.720 --> 00:13:43.000 Why are dependencies a problem? 00:13:43.060 --> 00:13:47.460 We did a whole episode about dependencies in general, with multiple reasons. 00:13:47.600 --> 00:13:52.380 Dependencies are software maintained by other people, and other people could put 00:13:52.380 --> 00:13:54.920 backdoors in them, so that's one reason. 00:13:55.260 --> 00:14:00.780 But also, our software, Bitcoin Core, keeps modernizing in terms of the code, 00:14:01.000 --> 00:14:03.260 so using newer versions of C++, etc. 00:14:04.250 --> 00:14:10.070 And if your dependencies are not also modernizing, then you kind of have a problem, 00:14:10.110 --> 00:14:13.790 because you have to maintain compatibility with some older ways of doing things. 00:14:14.250 --> 00:14:18.150 That can be a reason, or it can just cause all sorts of bugs that are difficult to 00:14:18.150 --> 00:14:18.710 debug. 00:14:19.770 --> 00:14:24.950 So a reason to get rid of dependencies can be security, can be easier maintenance, 00:14:25.590 --> 00:14:28.450 and just reducing complexity, those kind of arguments. 00:14:28.630 --> 00:14:32.270 I'm not sure about the exact argument here, but yeah. 00:14:28.680 --> 00:14:30.180 Yes Yeah, 00:14:33.020 --> 00:14:37.760 so as much as possible we would want Bitcoin Core to be standalone software that 00:14:37.760 --> 00:14:40.720 doesn't require Right, 00:14:38.990 --> 00:14:43.310 Yeah, but there is a trade-off because if you implement everything yourself, that 00:14:43.310 --> 00:14:47.010 is more work, first of all, but also you might not be the best at it, right? 00:14:47.090 --> 00:14:48.710 You have specialization of labor in the world. 00:14:48.850 --> 00:14:53.250 Some people are very good at writing HTTP servers and other people are not. 00:14:53.410 --> 00:14:58.550 And the HTTP server in Bitcoin Core that we have written now is not the best one in 00:14:58.550 --> 00:14:58.850 the world. 00:14:59.050 --> 00:15:03.710 In fact, it is the worst one in the world because it is trying to do only what it 00:15:03.710 --> 00:15:06.230 needs to talk to these other pieces of software. 00:15:06.730 --> 00:15:12.630 It is not trying to power, I don't know, NSA.gov or some super popular 00:15:12.630 --> 00:15:12.970 website. 00:15:13.290 --> 00:15:16.730 So it's not designed to be fast or amazing. 00:15:16.890 --> 00:15:18.630 It's just designed to be simple. 00:15:19.720 --> 00:15:21.600 okay in any case Right, 00:15:19.750 --> 00:15:24.530 And to run on a somewhat trusted environment because RPC is usually not something 00:15:24.530 --> 00:15:25.950 you expose to the internet. 00:15:25.950 --> 00:15:29.750 You just expose it on your own computer to your own software or your own Docker 00:15:29.750 --> 00:15:31.010 container or something like that. 00:15:31.880 --> 00:15:36.060 okay in any case so this this dependency is now removed in the new version of 00:15:35.590 --> 00:15:36.150 Gone. 00:15:36.060 --> 00:15:42.020 Bitcoin it's gone yes all right and so then let's so then I 00:15:37.610 --> 00:15:38.470 It's gone. 00:15:42.020 --> 00:15:45.340 have the increase inbound activity point 00:15:46.010 --> 00:15:46.570 Yes. 00:15:47.130 --> 00:15:51.410 Okay, so Bitcoin Core connects to nodes when you start it up. 00:15:51.470 --> 00:15:55.750 It tries to connect to about eight peers in general for everything, and then two 00:15:55.750 --> 00:15:58.790 peers just for blocks, not for mempool stuff. 00:15:56.700 --> 00:16:02.630 mm-hmm yeah so eight peers for 00:15:59.590 --> 00:16:00.110 And 00:16:02.630 --> 00:16:04.970 blocks and transactions and two for only blocks 00:16:03.980 --> 00:16:09.640 depending on if you're on a data center or at home and your router allows it, it 00:16:09.640 --> 00:16:11.340 also listens to peers. 00:16:11.340 --> 00:16:12.940 We've done some episodes about that. 00:16:13.520 --> 00:16:16.180 It will listen to at most 125. 00:16:17.180 --> 00:16:18.540 peers that can connect to you. 00:16:18.720 --> 00:16:23.680 Again, if they can get through your router and to you, it is up to 125. 00:16:24.700 --> 00:16:26.860 That number has now gone up to 200. 00:16:27.180 --> 00:16:29.880 So number go up, even if the market doesn't go up, number go up. 00:16:30.340 --> 00:16:31.360 There is a catch. 00:16:33.040 --> 00:16:38.760 These extra nodes are only used for block relay, not for mempool relay. 00:16:38.890 --> 00:16:44.750 the 75 extra block peers are only used for blocks that you will only share blocks 00:16:43.350 --> 00:16:45.900 Yeah, exactly. 00:16:44.750 --> 00:16:50.130 with them no transactions right and why was this change made or why wasn't it 00:16:50.130 --> 00:16:52.590 already the case or why now yeah 00:16:51.390 --> 00:16:55.230 So relaying blocks takes a lot less bandwidth, because most of the time nothing 00:16:55.230 --> 00:16:57.570 happens, and then suddenly something happens. 00:16:58.090 --> 00:17:00.730 And these block announcements are the most important things. 00:17:01.110 --> 00:17:02.850 You really need to know what the next block is. 00:17:02.870 --> 00:17:06.030 If you miss a few mempool transactions, this is not a big deal, or if you get them 00:17:06.030 --> 00:17:06.470 a bit later. 00:17:08.680 --> 00:17:13.520 But the reason why we're doing this now is because later on we want to start 00:17:13.520 --> 00:17:15.480 connecting to more of these nodes. 00:17:16.130 --> 00:17:20.030 So remember we have now eight, I believe it's eight regular outbounds and then two 00:17:20.030 --> 00:17:21.130 ones that are blocks only. 00:17:21.710 --> 00:17:27.150 We want to increase that to maybe 10 blocks only so we get a better view of the 00:17:27.150 --> 00:17:27.550 network. 00:17:28.290 --> 00:17:32.390 But you don't want to do that until the listening side is actually able to because 00:17:32.390 --> 00:17:34.550 right now a lot of nodes are just full. 00:17:34.650 --> 00:17:38.130 You connect to them and they just say like, sorry, or they hang up on somebody 00:17:38.130 --> 00:17:38.370 else. 00:17:39.410 --> 00:17:44.790 it still sounds very out of out of whack almost so you have 10 outgoing connections 00:17:44.790 --> 00:17:46.730 and 200 incoming now 00:17:46.030 --> 00:17:49.750 Yeah, but keep in mind that the number of nodes that are listening is much smaller 00:17:49.750 --> 00:17:52.630 than the number of nodes that are connecting outwards because a lot of nodes are 00:17:52.630 --> 00:17:55.710 running on home networks that are protected by a router. 00:17:56.150 --> 00:17:57.370 So there's an asymmetry there. 00:17:57.470 --> 00:17:59.390 That's why the number has to be asymmetric too. 00:17:59.270 --> 00:18:03.150 right okay and but as a [unclear: boiler] right 00:18:01.490 --> 00:18:03.290 And there's a big trust difference. 00:18:03.410 --> 00:18:06.330 So you might say, well, if you just have all these incoming nodes that give you 00:18:06.330 --> 00:18:07.070 blocks, you're happy. 00:18:07.730 --> 00:18:11.810 But in general, we trust nodes that we connect to more than nodes that connect to 00:18:11.810 --> 00:18:12.070 us. 00:18:12.270 --> 00:18:17.730