WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.530 --> 00:00:22.750 Live from Utrecht, this is Bitcoin 00:00:23.690 --> 00:00:24.210 Explained. 00:00:25.030 --> 00:00:29.130 Sjors, you were just telling me that one of the reasons you came up with the 00:00:29.130 --> 00:00:34.510 topic for this episode, which is BIP 324, peer-to-peer encryption, right? 00:00:35.030 --> 00:00:38.710 One of the reasons you came up with that is because you had a call with other 00:00:38.710 --> 00:00:40.010 Bitcoin developers about this. 00:00:40.510 --> 00:00:41.090 Yeah, that's right. 00:00:41.310 --> 00:00:44.810 Sjors, since when do Bitcoin Core developers call? What is this? 00:00:44.930 --> 00:00:45.570 Very rarely. 00:00:45.830 --> 00:00:51.310 What is happening? I know Bitcoin developers as... IRC wizards and they're on a 00:00:51.310 --> 00:00:55.190 call now that sounds like Ethereum Bitcoin Cash type of communication what's 00:00:55.190 --> 00:00:55.590 going on? 00:00:55.590 --> 00:01:01.530 No, so the idea would be to put these calls on some sort of podcast or feed if 00:01:01.530 --> 00:01:04.140 the Optech folks are organizing it So… 00:01:04.140 --> 00:01:06.300 So, okay so what is this tell me more? 00:01:06.300 --> 00:01:10.480 No, it's basically just a short lecture by the people who are working on a 00:01:10.480 --> 00:01:12.920 project so the people who work… 00:01:12.920 --> 00:01:14.840 So it's like an educational type of thing? 00:01:15.220 --> 00:01:18.520 Yeah, but then, of course, the idea is to get some feedback from people and to 00:01:18.520 --> 00:01:20.620 encourage them to start reviewing it. 00:01:20.860 --> 00:01:25.900 So is it like online bit devs? How am I supposed to think about this? 00:01:25.900 --> 00:01:30.860 Maybe you could see it as an online Socratic small seminar with fewer people talking. 00:01:31.460 --> 00:01:32.460 Okay. Is this new? 00:01:32.640 --> 00:01:36.900 I think it's very new. At least I was only invited very recently, so who knows? 00:01:37.100 --> 00:01:37.400 Okay. 00:01:37.580 --> 00:01:43.050 Maybe it's a third level, what is it called? oh yeah Illuminati. 00:01:43.050 --> 00:01:48.010 Yeah, it's like this invite only thing where you're you're you enter the the 00:01:48.010 --> 00:01:48.830 inner ring now. 00:01:48.830 --> 00:01:50.370 The Bilderberg exactly. 00:01:50.370 --> 00:01:56.060 Yeah, so we're gonna oh no before we get to peer-to-peer encryption 00:01:56.060 --> 00:02:01.660 of course first everyone's favorite part of the episode Sjors stacks 00:02:01.660 --> 00:02:04.180 sats where you read boostagrams 00:02:04.950 --> 00:02:05.510 That's right. 00:02:05.770 --> 00:02:10.250 Sjors stacks sats. Sjors stacks sats, Sjors stacks sats. 00:02:11.730 --> 00:02:17.370 This is a shame that we don't have video. Okay, we have one from AdFake for 3,000 00:02:17.370 --> 00:02:21.290 satoshis saying Mike in Space has finally done something noteworthy. 00:02:21.990 --> 00:02:27.670 Haha. Okay, I'm going to give you an outro tune as well because otherwise... it's 00:02:27.670 --> 00:02:30.150 a bit awkward to get back to the rest of the episode so 00:02:30.060 --> 00:02:30.940 No, I think it's fine. 00:02:30.940 --> 00:02:35.490 Sjors stacks sats. No, see this is better now we can go All right now everyone 00:02:35.490 --> 00:02:39.390 knows that the Sjors Stacks Sats part of the episode is over and we get to 00:02:39.390 --> 00:02:45.000 business so business today Sjors, is BIP 00:02:45.000 --> 00:02:49.680 324 324 peer-to-peer encryption 00:02:49.680 --> 00:02:50.680 That's right. 00:02:50.680 --> 00:02:55.910 a little bit of background on this… is this used to be called 00:02:55.910 --> 00:03:01.630 BIP 151, 151, right? And it used to be Jonas Schnelli's 00:03:01.630 --> 00:03:07.610 project. Jonas Schnelli retired as Bitcoin Core Developer. And the project 00:03:07.610 --> 00:03:13.110 is now led by Dhruv. Am I saying his name right? Yeah, so it's Dhruv, 00:03:13.250 --> 00:03:16.430 Pieter Wuille, aka sipa, and Tim Ruffing. 00:03:18.450 --> 00:03:21.710 And all three names are on the BIP. So it's the three of them are working on 00:03:21.710 --> 00:03:27.270 this. Okay, great. So yeah, so they picked up the project from Jonas when he left 00:03:27.270 --> 00:03:32.780 and they rebranded it or renamed it or they got a new BIP. So now it's 00:03:32.780 --> 00:03:34.760 BIP 324. Do you know why? 00:03:35.240 --> 00:03:38.500 Yeah, I think it's because enough of the things about the proposal have changed 00:03:38.500 --> 00:03:40.800 that it was worth just giving it a whole new BIP number. 00:03:42.080 --> 00:03:43.780 Also, do you know why 324? 00:03:44.730 --> 00:03:45.170 No. 00:03:46.260 --> 00:03:52.020 That would require you to get into Luke Dashjr's… mind. I think there's a 00:03:52.020 --> 00:03:56.100 logic to the numbers somewhere in his brain. Yeah, but I don't think anyone else 00:03:56.100 --> 00:03:56.960 in the world knows it. 00:03:56.960 --> 00:04:02.940 We did an episode about the coin improvement process basically but we did 00:04:02.940 --> 00:04:07.520 not go into numerology for the same reason we didn't go into numerology for 00:04:07.520 --> 00:04:08.060 Ordinals. 00:04:08.060 --> 00:04:11.700 Right, okay so let's get going then. 00:04:13.840 --> 00:04:19.460 Why, so we're talking about, I guess we always start with like a very short two 00:04:19.460 --> 00:04:22.680 sentence explanation of what we're even talking about. So what we're talking 00:04:22.680 --> 00:04:28.680 about is encrypting communication between Bitcoin nodes, right? So right now 00:04:28.680 --> 00:04:34.300 nodes don't encrypt. So nodes send, I think, three things between each other, 00:04:34.540 --> 00:04:38.580 which are blocks, transactions, and each other's IP addresses, right? IP 00:04:38.580 --> 00:04:39.620 addresses of other nodes. 00:04:39.760 --> 00:04:40.460 Pretty much. 00:04:41.050 --> 00:04:43.750 And right now they do all of this unencrypted. 00:04:44.070 --> 00:04:44.550 That's right. 00:04:44.870 --> 00:04:49.850 Now the idea is to encrypt this. So that's very short sort of bird's eye. 00:04:50.370 --> 00:04:53.830 Yeah, exactly. So the, you know, unencrypted traffic is, you know, remember the 00:04:53.830 --> 00:04:58.850 days when HTTPS was considered a feature, you know, when websites would say, oh 00:04:58.850 --> 00:05:02.610 my God, we have an HTTPS certificate. Well, before that time, you could just 00:05:02.610 --> 00:05:06.330 eavesdrop on anything you were doing at a web shop. But Bitcoin Core nodes still 00:05:06.330 --> 00:05:07.430 use that old method. 00:05:07.810 --> 00:05:08.010 Right. 00:05:08.030 --> 00:05:08.970 There's reasons for that. 00:05:10.130 --> 00:05:12.010 There's reasons for using the old methods? 00:05:12.490 --> 00:05:16.010 There's reasons. There's definitely reasons it's not using HTTPS. 00:05:17.770 --> 00:05:21.130 But it is nice to have some sort of encryption, and that's what I guess we'll get into. 00:05:21.410 --> 00:05:26.010 Okay, so why would that be nice? So what's the problem we're trying to solve, or 00:05:26.010 --> 00:05:28.570 what's the problem Bitcoin developers are trying to solve? 00:05:28.730 --> 00:05:30.210 They are spying on us. 00:05:30.390 --> 00:05:31.410 Who is spying on us? 00:05:31.550 --> 00:05:33.030 They, the government. 00:05:33.170 --> 00:05:33.450 Everyone? 00:05:33.790 --> 00:05:38.850 All of them. No, so basically the problem is that Bitcoin nodes are talking to 00:05:38.850 --> 00:05:43.450 each other in a way that anybody with access to the network can eavesdrop on it. 00:05:43.630 --> 00:05:47.590 And then I especially mean people with physical access to the network. So they 00:05:47.590 --> 00:05:52.050 could have a machine on the wire. This could be somebody monitoring your home. 00:05:52.250 --> 00:05:55.990 This could be your internet provider monitoring all their customers. This could 00:05:55.990 --> 00:05:59.870 be a spy agency monitoring all the internet companies, even without the internet 00:05:59.870 --> 00:06:01.290 companies knowing that this is happening. 00:06:03.240 --> 00:06:07.200 They can basically see exactly which node it's sending, which transaction to 00:06:07.200 --> 00:06:11.080 which other node, if they wanted to. Now, I don't know if they're doing that. 00:06:11.240 --> 00:06:15.100 Maybe they really don't care. I haven't seen any evidence that they're doing it. 00:06:15.900 --> 00:06:18.700 I know because they're already, you know, if you look at things like chain 00:06:18.700 --> 00:06:23.160 analysis, that they're already doing a lot of work, just the hard way. As far as 00:06:23.160 --> 00:06:26.140 I know, chain analysis is not getting data from the spy agencies. 00:06:27.360 --> 00:06:32.080 Yeah, well, that ties in with the question I was going to ask. The question I was 00:06:32.080 --> 00:06:37.180 going to ask is, so what if they do? All the data is public anyways, right? It's 00:06:37.180 --> 00:06:38.600 all going on the blockchain anyways. 00:06:38.940 --> 00:06:42.820 Well, what's on the blockchain is public, but the question which IP address 00:06:42.820 --> 00:06:46.780 created a transaction is definitely not public or not supposed to be public, but 00:06:46.780 --> 00:06:51.460 it is if you look at the transaction. So if I make a transaction on my node and I 00:06:51.460 --> 00:06:56.170 send it to the nodes around me, then a spy agency that can see all the internet 00:06:56.170 --> 00:07:00.190 traffic would be able to see basically this transaction exactly where it started. 00:07:00.670 --> 00:07:03.990 And that, of course, would be very interesting information for them. Right now, 00:07:04.250 --> 00:07:07.230 as far as I know, the only companies that do these are these chain analytics 00:07:07.230 --> 00:07:10.710 companies. And they have to do it the hard way. They have to make lots of 00:07:10.710 --> 00:07:14.200 connections to lots of different nodes and monitor it that way. None of what 00:07:14.200 --> 00:07:17.040 we're going to discuss is going to make that impossible. But the idea of just 00:07:17.040 --> 00:07:20.760 looking at the whole network and seeing what's going on, that's the thing we want to prevent. 00:07:20.980 --> 00:07:25.520 Okay. So I'm going to try a concrete example. So 00:07:25.940 --> 00:07:31.620 if I send a Bitcoin transaction, you know, I spend my own Bitcoin, 00:07:31.860 --> 00:07:37.540 then that transaction would have to originate from my node. And in that case, my 00:07:37.540 --> 00:07:41.600 internet service provider, for example, would see that, oh, look, that 00:07:41.600 --> 00:07:47.580 transaction came from Aaron's node. So these must be Aaron's bitcoins. And that's 00:07:47.580 --> 00:07:51.080 the type of spying we're talking about, right? 00:07:51.400 --> 00:07:51.520 Yeah. 00:07:51.740 --> 00:07:55.520 While if that connection from me to the network would be encrypted, then they 00:07:55.520 --> 00:08:00.510 wouldn't see that that specific transaction originated from me. And the same is 00:08:00.510 --> 00:08:05.270 true, of course, for miners, for example, who create blocks. We'd like miners to 00:08:05.270 --> 00:08:10.330 be anonymous on the network. And if an ISP knows where blocks originate, they 00:08:10.330 --> 00:08:11.530 know where a miner is, right? 00:08:11.830 --> 00:08:14.790 Yeah, and in a perfect world, they would not be able to do that. Now, this 00:08:14.790 --> 00:08:18.090 proposal will not get us to the perfect world, but it will get us to a slightly 00:08:18.090 --> 00:08:18.650 better world. 00:08:22.870 --> 00:08:27.090 And there's also the issue, that's privacy, I guess. The other issue is 00:08:27.090 --> 00:08:31.140 censorship, potentially. because this internet provider that saw that transaction 00:08:31.140 --> 00:08:34.920 coming from you might also think well you know what we don't like this guy we're 00:08:34.920 --> 00:08:39.060 gonna block just his transactions not everything else and they can do that too 00:08:39.060 --> 00:08:43.340 they can get in the middle of our basically of the communication between our 00:08:43.340 --> 00:08:47.520 nodes and they can selectively listen to it let everything through except one or 00:08:47.520 --> 00:08:48.900 two things that they don't like to let through 00:08:49.410 --> 00:08:54.930 Right yeah these are sort of two sides of the same coin right so 00:08:54.930 --> 00:09:00.450 it It is because if there's no privacy, then that would also allow 00:09:00.450 --> 00:09:06.410 specific censorship. Well, if all Bitcoin traffic data, if all the 00:09:06.410 --> 00:09:09.790 Bitcoin data looks the same, they can't single out transactions and therefore 00:09:09.790 --> 00:09:11.790 they also can't block certain transactions. 00:09:12.350 --> 00:09:12.470 Yeah. 00:09:12.810 --> 00:09:13.290 Right? Okay. 00:09:13.450 --> 00:09:17.390 And then I guess the third category would be things like miners when they are, 00:09:17.570 --> 00:09:21.770 you know, maybe you could eclipse attack them. So we had an episode about eclipse 00:09:21.770 --> 00:09:26.940 attacks very early on. which basically boils down to showing one thing to one 00:09:26.940 --> 00:09:30.760 node and showing other things to other nodes. And the companies that are 00:09:30.760 --> 00:09:32.780 operating the internet have some power to do that. 00:09:35.550 --> 00:09:40.550 Okay, so that's the problem. I think we've now covered in general 00:09:40.550 --> 00:09:45.850 lines what the problem is we're trying to solve with peer-to-peer encryption. Is that right? 00:09:46.190 --> 00:09:46.430 Yep. 00:09:46.650 --> 00:09:52.970 Okay, so what is the solution? The solution is to encrypt data. Is it that simple? 00:09:53.270 --> 00:09:57.110 Yeah, pretty much. Well, that's at least the beginning of the cat and mouse game. 00:09:57.810 --> 00:10:01.090 The beginning of the cat and mouse game is to say we're going to encrypt all the 00:10:01.090 --> 00:10:06.770 data so that when somebody is looking at our internet connection, all they see is noise. 00:10:08.000 --> 00:10:12.840 They cannot read the individual transactions. They don't even know. At first 00:10:12.840 --> 00:10:15.240 glance, they don't even know what is a transaction and what is not. 00:10:16.190 --> 00:10:19.150 Okay, so more concretely, how does it work? 00:10:20.170 --> 00:10:24.750 Okay, so the idea is that when you connect to another peer, 00:10:25.910 --> 00:10:30.950 You do a handshake with that peer, and that handshake basically creates an 00:10:30.950 --> 00:10:32.550 encrypted connection between the two of you. 00:10:32.690 --> 00:10:33.610 What is a handshake? 00:10:33.890 --> 00:10:37.930 A handshake is basically saying, here's my key, and then you say, here's my key. 00:10:38.570 --> 00:10:38.970 Okay. 00:10:40.390 --> 00:10:44.530 There's a little bit more to it, of course, but the general idea is they call it 00:10:44.530 --> 00:10:46.110 a Diffie-Hellman key exchange. 00:10:46.430 --> 00:10:46.630 Right. 00:10:46.690 --> 00:10:50.610 If you Google that, you'll find it. We've talked about it in other podcasts, too. 00:10:51.070 --> 00:10:55.980 It basically means I get your public key, you get my public key. And we can 00:10:55.980 --> 00:11:01.020 combine those keys into a shared key, basically a key that both of us know. 00:11:01.240 --> 00:11:03.100 Do you want to try to explain how this works? 00:11:03.280 --> 00:11:03.480 No. 00:11:03.980 --> 00:11:08.640 I can give it a try. Let's see if this works. Because I think I got a way of 00:11:08.640 --> 00:11:13.140 explaining it that might actually be sort of understandable over audio even. All 00:11:13.140 --> 00:11:15.220 right. I'm going to give it a try. Are you ready? 00:11:15.820 --> 00:11:16.040 Yep. 00:11:16.320 --> 00:11:21.780 Okay, so basically you got a mathematical one-way function, right? So you take a 00:11:21.780 --> 00:11:24.840 number, we've explained one-way functions. You take a number, you put it through 00:11:24.840 --> 00:11:26.800 a one-way function, you get a different number. 00:11:27.040 --> 00:11:32.400 Well, it's not really a one-way function because theoretically you can go both 00:11:32.400 --> 00:11:34.640 ways. In practice, you can't. 00:11:35.080 --> 00:11:38.100 No, no, I think you don't even know where I'm going with my explanation. 00:11:38.220 --> 00:11:41.140 Well, we talked about hash functions in another episode about hash functions. 00:11:41.300 --> 00:11:43.480 Those are actually one-way functions. There is no way back. 00:11:43.720 --> 00:11:48.940 Well, but I mean, that's how, so that's how you derive a public key from a 00:11:48.940 --> 00:11:49.600 private key, right? 00:11:50.180 --> 00:11:50.560 No. 00:11:51.600 --> 00:11:56.620 Well, it's definitely a one-way function from a private key to a public key. 00:11:56.680 --> 00:11:59.840 No, it's a two-way function. The thing is just that the way back is so difficult 00:11:59.840 --> 00:12:03.400 that in practice you can never go back. That's what we hope in theory. 00:12:03.320 --> 00:12:04.080 Well, that's… 00:12:04.100 --> 00:12:06.040 But a hash function is really one-way. 00:12:06.040 --> 00:12:07.880 [unclear] that's not a one-way function? 00:12:08.080 --> 00:12:13.140 Because you can go both ways in theory. Mathematically speaking, it just goes both ways. 00:12:13.300 --> 00:12:19.200 Is this what we discussed and I forgot about it? Did you explain what the 00:12:19.200 --> 00:12:19.780 difference is? 00:12:19.940 --> 00:12:21.000 I think I did, yeah. 00:12:21.360 --> 00:12:22.680 Because it sounds the same to me. 00:12:22.820 --> 00:12:24.680 So a hash function is really one way. 00:12:26.160 --> 00:12:26.600 Okay. 00:12:27.980 --> 00:12:32.480 From a private key to a public key is more is easier than from a public key to a 00:12:32.480 --> 00:12:37.300 private key so you know it's like it's it goes both ways but the toll on the way 00:12:37.300 --> 00:12:38.260 back is very high. 00:12:38.260 --> 00:12:42.220 Can you excuse me if I call it a one-way function for now? 00:12:42.220 --> 00:12:43.920 A one-way-ish function. 00:12:43.920 --> 00:12:49.820 Okay, I still think it's a one-way function but all right so you have a 00:12:49.820 --> 00:12:53.680 number you put it through a one-way-ish function you get a different number right? 00:12:53.680 --> 00:12:54.100 Yep. 00:12:54.100 --> 00:12:57.000 now if you do it twice you get a different number again. 00:12:57.550 --> 00:12:58.530 Yes, sure. 00:12:58.530 --> 00:13:04.140 Okay, so what is a public key it's basically a number put through 00:13:04.140 --> 00:13:05.800 one one-way function right? 00:13:05.800 --> 00:13:06.300 Yes. 00:13:06.300 --> 00:13:11.510 Okay, so now I take your public key so that's your secret number 00:13:11.510 --> 00:13:16.950 put through one one-way function and then I multiply it with my own secret number 00:13:16.950 --> 00:13:21.530 so now what we get is a mix of two secret numbers and one one-way function 00:13:22.940 --> 00:13:27.400 okay and you can do the same thing right you could take your private key and then 00:13:27.400 --> 00:13:32.020 you have your secret number and my public key so that's my public so that's my 00:13:32.020 --> 00:13:37.750 private number yeah so now you got a mix again of two private numbers 00:13:37.750 --> 00:13:42.430 plus one one-way function the reason no one else can do it is because then the 00:13:42.430 --> 00:13:46.490 only way they could do it is take two public keys so now they get two private now 00:13:46.490 --> 00:13:51.790 they get a mix of two private numbers plus two one-way functions so you get a 00:13:51.790 --> 00:13:52.350 different number 00:13:54.070 --> 00:13:55.250 That's basically it, right? 00:13:55.650 --> 00:13:57.210 Yeah, I'm not sure if that made a lot of sense. 00:13:57.830 --> 00:14:00.970 I mean, I'm not sure if people can follow it over audio, but I think it's 00:14:00.970 --> 00:14:03.430 correct. I think this is the simplest way of explaining it. 00:14:04.430 --> 00:14:07.730 It could be, but it basically boils down to, yeah, exactly. I know my private 00:14:07.730 --> 00:14:13.130 key, you know your private key. We don't want to share our own private keys. So I 00:14:13.130 --> 00:14:17.050 give you my public key, you give me. Your public key and we do the math and 00:14:17.050 --> 00:14:18.650 basically now we have a shared key. 00:14:18.810 --> 00:14:23.670 Okay, so that's Diffie-Hellman and that's what Bitcoin nodes would use. So 00:14:23.670 --> 00:14:28.590 practically speaking, does it mean that every Bitcoin node has a public key? 00:14:28.790 --> 00:14:34.740 No, so that's a big distinction. We are not doing identity here. because that 00:14:34.740 --> 00:14:38.500 would actually be kind of controversial. Every node should pretty much look like 00:14:38.500 --> 00:14:39.160 every other node. 00:14:39.260 --> 00:14:44.200 Is this one of the biggest differences or maybe the biggest difference compared 00:14:44.200 --> 00:14:49.900 to BIP-151? Because from what I recall... BIP-151 did 00:14:49.900 --> 00:14:51.780 use identity, or that was part of the plan? 00:14:52.060 --> 00:14:56.220 No, I think it also made a distinction between these two things, but maybe the 00:14:56.220 --> 00:14:59.540 distinction was done in a slightly different way. But the idea was always that 00:14:59.540 --> 00:15:00.920 these are separate things. 00:15:01.240 --> 00:15:06.780 Okay, so what then happens instead, I would assume, is every time a node tries to 00:15:06.780 --> 00:15:10.820 connect to another node, they go for this handshake, which means at that point 00:15:10.820 --> 00:15:12.810 they generate a new key pair. 00:15:12.810 --> 00:15:16.870 Yeah, they do it for every connection so if I connect to you and then somebody 00:15:16.870 --> 00:15:19.570 else connects to you they're all going to see a different key you're not going to 00:15:19.570 --> 00:15:21.130 present yourself as the same identity. 00:15:21.130 --> 00:15:24.010 Yeah, I'm going to generate keys for every new connection. 00:15:24.010 --> 00:15:24.610 Yes. 00:15:24.610 --> 00:15:30.400 Okay, so and then establish a new Diffie-Hellman secure connection 00:15:30.400 --> 00:15:33.800 based on every new key and every new… with every new… 00:15:33.800 --> 00:15:35.520 Exactly. Right, okay. 00:15:37.600 --> 00:15:43.600 so that's how it works does that solve the problem that we discussed 00:15:43.600 --> 00:15:46.680 in the first part of the episode? 00:15:46.680 --> 00:15:50.660 There's a little extra so I mean it's always a cat and mouse game right but so 00:15:50.660 --> 00:15:54.840 right now what happens if somebody is just passively listening to our traffic all 00:15:54.840 --> 00:15:59.400 they see in this example would be somebody sending a public key and somebody else 00:15:59.400 --> 00:16:03.400 sending a public key and after that they just see noise they have no idea what 00:16:03.400 --> 00:16:08.400 the rest of the traffic is because it's encrypted now you could say that that's a 00:16:08.400 --> 00:16:11.920 good start because now at least they won't be able to tell which transactions are 00:16:11.920 --> 00:16:16.430 which but they could still and sort of here's the trade-offs, they could still 00:16:16.430 --> 00:16:21.430 get in the middle. So because when I connected to you and you connect to me, how 00:16:21.430 --> 00:16:26.160 do I actually know that it was you? I don't because we don't have identity. So 00:16:26.160 --> 00:16:30.100 you don't have a public key. You don't have something on your website that says 00:16:30.100 --> 00:16:34.700 it's me. I just have your IP address. And besides, I'm connecting to random nodes 00:16:34.700 --> 00:16:39.370 in the internet anyway, right, as a Bitcoin node. So the man in the middle attack 00:16:39.370 --> 00:16:44.390 is still possible, but this is called an active attack. So if the government or 00:16:44.390 --> 00:16:48.750 whatever wants to see our traffic, they would have to do it in such a way that I 00:16:48.750 --> 00:16:51.430 think I'm connecting to you, but I'm really connecting to this government server. 00:16:51.730 --> 00:16:55.230 And then the government server connects to you and pretends it's coming from me. 00:16:56.510 --> 00:16:59.990 And that way I'm doing a Diffie-Hellman exchange with the government and you're 00:16:59.990 --> 00:17:03.910 doing a Diffie-Hellman exchange with the government. Now, this proposal contains 00:17:03.910 --> 00:17:09.440 a countermeasure to that risk. which is that we could get on a phone call and we 00:17:09.440 --> 00:17:13.680 could look up this thing called the session ID. And this session ID is just 00:17:13.680 --> 00:17:17.900 basically saying, well, okay, we have a connection session. And if that number is 00:17:17.900 --> 00:17:21.580 the same, then we know we are directly connected to each other. If the number is 00:17:21.580 --> 00:17:23.260 different, that means there's somebody in between us. 00:17:23.800 --> 00:17:29.040 Okay. So I got the first part. I don't think I need to repeat that, right? That 00:17:29.040 --> 00:17:32.360 was pretty straightforward. I think people probably know what a man in the middle 00:17:32.360 --> 00:17:35.550 attack is, even the name reveals it. 00:17:35.950 --> 00:17:38.170 Yeah. In this case, I was making a government in the middle attack. 00:17:38.430 --> 00:17:38.610 Right. 00:17:39.010 --> 00:17:39.650 But yes. 00:17:40.030 --> 00:17:44.230 And then you said one of the ways to solve it is... I don't know. 00:17:44.450 --> 00:17:46.170 So you're not preventing it. 00:17:46.250 --> 00:17:46.390 Yeah. 00:17:46.530 --> 00:17:49.630 But first of all, it's more expensive because the government can no longer or 00:17:49.630 --> 00:17:53.090 whoever's eavesdropping can no longer just listen. Like don't just put their ears 00:17:53.090 --> 00:17:56.190 on the cable. They have to actually install a computer that actually does all the 00:17:56.190 --> 00:18:01.170 handshaking. So it takes some CPU power, takes some much more work. And if they 00:18:01.170 --> 00:18:06.430 do it because of this session ID, if we communicate outside of the protocol, we 00:18:06.430 --> 00:18:09.410 can compare nodes and then we can see that there's somebody in between. 00:18:09.720 --> 00:18:11.420 Right. I guess this... 00:18:11.420 --> 00:18:15.520 It's very similar to how it works with Signal. For example, if you add somebody 00:18:15.520 --> 00:18:19.680 as a contact on Signal, you show each other a QR code and that is really a way to 00:18:19.680 --> 00:18:24.600 see that, okay, my Signal device app is actually connected directly to your 00:18:24.600 --> 00:18:26.160 Signal app and there's nobody in between. 00:18:26.760 --> 00:18:27.200 Yeah. 00:18:27.460 --> 00:18:29.020 You have to do in person or on the phone. 00:18:29.260 --> 00:18:30.460 Serial number kind of thing. 00:18:30.920 --> 00:18:31.520 Yeah, exactly. 00:18:31.920 --> 00:18:36.540 Okay. This sounds like a theoretical thing because no one's actually going to get 00:18:36.540 --> 00:18:40.780 on the phone to see if we have the same Bitcoin node. 00:18:40.210 --> 00:18:45.890 So the good thing here is that if the government wants to surveil everyone then 00:18:45.890 --> 00:18:49.830 there's going to be some people that will do this and then they can actually say 00:18:49.830 --> 00:18:53.650 hey this is happening and then they can make a bunch of noise so this is relying 00:18:53.650 --> 00:18:58.970 on an incentive for governments to not get caught doing this so it's a more work 00:18:58.970 --> 00:19:01.850 and b they would not be able to do it undetected right now they can do it 00:19:01.850 --> 00:19:03.480 undetected right 00:19:04.460 --> 00:19:09.960 Okay so it sounds so this is what it sounds like if a government really wants to 00:19:09.960 --> 00:19:15.860 spy on you on your node on your node traffic or an ISP or they they would 00:19:15.860 --> 00:19:20.700 still be able to do that however it would require more resources so right now 00:19:20.700 --> 00:19:24.800 they don't need to do anything extra they're just kind of spying on you by 00:19:24.800 --> 00:19:29.320 default just the only thing they got to do is you know point their eyeball 00:19:29.320 --> 00:19:34.650 towards the data and then they can see what's going on yeah And if this peer-to 00:19:34.650 --> 00:19:38.830 -peer encryption would be deployed, then they would actually have to install stuff 00:19:38.830 --> 00:19:42.010 and sync the blockchain. 00:19:42.790 --> 00:19:45.770 Maybe not sync the blockchain, but they definitely have to do some work there. 00:19:46.110 --> 00:19:47.870 And you would be able to see that it's happening. 00:19:47.990 --> 00:19:52.610 And then potentially, yeah, if people would actually get on the phone call, which 00:19:52.610 --> 00:19:53.950 is something that you might do. 00:19:55.110 --> 00:20:00.970 Again, only a small number of people have to do this to catch them. Now, of 00:20:00.970 --> 00:20:05.070 course, we're still not in paradise because we just said that the government, 00:20:05.350 --> 00:20:09.370 when they're looking at our channel, I don't want to make this sound like 00:20:09.370 --> 00:20:13.370 Lightning, but looking at our connection, all they're seeing is noise. But it 00:20:13.370 --> 00:20:17.210 does turn out the cat and mouse game doesn't end there. Noise still has patterns 00:20:17.210 --> 00:20:22.590 to it. So for example, if I'm sending you a transaction, that's a very small 00:20:22.590 --> 00:20:27.220 little thing. If I'm sending you a block, that tends to be a bigger thing. And 00:20:27.220 --> 00:20:32.760 those blocks also are all sent around the same time. So I could guess that I was 00:20:32.760 --> 00:20:37.460 sending you a block. Just by looking at, you know, I'm looking, you know, the 00:20:37.460 --> 00:20:39.540 government might be running their own node. They see, oh, there's a new block 00:20:39.540 --> 00:20:43.020 coming in. And right around that time, there's a lot of noise on all these 00:20:43.020 --> 00:20:46.960 different connections. Well, what would that be? So then at least they'll know 00:20:46.960 --> 00:20:50.520 that these people are running a Bitcoin node. Also because they're all running on 00:20:50.520 --> 00:20:52.520 port 8333, which is a bit obvious. 00:20:53.040 --> 00:20:55.540 Yeah, we also discussed that in another episode. 00:20:55.820 --> 00:20:59.540 But again, it's already an improvement, right? So port 8333 is something you can 00:20:59.540 --> 00:21:03.710 change. But right now, whatever port you're running on, the first thing you say 00:21:03.710 --> 00:21:07.840 when you connect to another node is, I think it's literally the word Bitcoin. So 00:21:07.840 --> 00:21:11.980 a ISP just has to listen for the word Bitcoin on any connection and then know 00:21:11.980 --> 00:21:16.930 that it's Bitcoin. And with this, they would not. Now, in order to make it 00:21:16.930 --> 00:21:19.110 impossible for a government to even look at these patterns. 00:21:19.190 --> 00:21:25.080 Wait, maybe there's something worth pointing out. Why? wouldn't that still be 00:21:25.080 --> 00:21:30.200 the first word? Why wouldn't you still, you first need to know that you're 00:21:30.200 --> 00:21:31.880 talking with another Bitcoin node, right? 00:21:32.040 --> 00:21:35.540 Yeah, so here is where the handshake, we should probably go into a little bit 00:21:35.540 --> 00:21:37.060 more detail about what that handshake looks like. 00:21:37.180 --> 00:21:37.560 Okay, yeah. 00:21:37.900 --> 00:21:41.380 So instead of saying, hello, I'm a Bitcoin node, would you like to talk to me? 00:21:41.840 --> 00:21:47.080 What I'm going to do is I'm going to send you somewhere between 64 bytes and I 00:21:47.080 --> 00:21:51.220 think two and a half kilobytes of what looks like completely random data. 00:21:53.170 --> 00:21:58.230 But again, what looks like completely random data. And then you will send me 00:21:58.230 --> 00:22:04.110 also completely random data between 64 bytes and two and a half kilobytes. 00:22:04.290 --> 00:22:04.410 Right. 00:22:05.050 --> 00:22:10.900 And part of this data that looks like noise is your public key. In 00:22:10.900 --> 00:22:14.360 fact, it's the start of the data. So the first 64 bytes are going to be your 00:22:14.360 --> 00:22:18.900 public key and the other way around. And then the rest is called garbage. And 00:22:18.900 --> 00:22:23.100 there's a little trick that, well, doesn't really matter, I guess. But basically 00:22:23.100 --> 00:22:28.370 I take the first 64 bytes and I know it's a public key and then I'm going to 00:22:28.370 --> 00:22:31.570 treat it as a public key. I'm going to treat it as a Diffie-Hellman exchange. And 00:22:31.570 --> 00:22:34.870 that actually allows me to also read the rest of the stuff that you're sending 00:22:34.870 --> 00:22:39.620 me, this garbage. And then I know, okay, we're done with a handshake and then we 00:22:39.620 --> 00:22:40.780 do our usual protocol. 00:22:41.360 --> 00:22:43.240 Right. So what's in the rest of the stuff? 00:22:43.420 --> 00:22:45.240 So an outside observer will just see randomness. 00:22:45.400 --> 00:22:45.720 Yeah. 00:22:46.210 --> 00:22:48.570 but you will actually know that it's a public key. 00:22:48.910 --> 00:22:50.650 And what's in the rest of the stuff? 00:22:51.810 --> 00:22:55.110 Garbage, literally, like random stuff or zeros. 00:22:55.700 --> 00:22:59.460 Oh, I thought you said that you can decrypt the rest. 00:22:59.920 --> 00:23:04.900 Yeah, so I think my understanding is that the garbage itself, you 00:23:04.900 --> 00:23:10.280 can still decrypt it and then you can check that it is nothing. 00:23:11.300 --> 00:23:15.160 basically, but there's a difference between something that's encrypted, but it's 00:23:15.160 --> 00:23:19.160 empty. Like basically you write a piece of empty text and you encrypt it. And if 00:23:19.160 --> 00:23:23.200 I decrypt it and I see an empty text, then I know you actually encrypted it. It 00:23:23.200 --> 00:23:29.030 wasn't real garbage. Now, the reason we don't do it 00:23:29.030 --> 00:23:33.530 more simply is because if I just sent you 64 bytes and you just sent me 64 bytes, 00:23:33.630 --> 00:23:37.470 then any government again can see, oh, well, a Bitcoin node is anything that 00:23:37.470 --> 00:23:41.830 sends 64 bytes and then replies with 64 bytes. So to make that more difficult, 00:23:42.030 --> 00:23:46.090 this garbage is added. So the packages can be larger, can be smaller. 00:23:47.390 --> 00:23:52.430 But there has to be a way for you to know when the garbage ends and when the real 00:23:52.430 --> 00:23:53.210 communication starts. 00:23:53.470 --> 00:23:58.250 Okay, what's the goal here? Because I thought the goal was not necessarily to 00:23:58.250 --> 00:24:03.990 hide that you are a Bitcoin node that is doing Bitcoin-y stuff. But I thought the 00:24:03.990 --> 00:24:06.870 goal was to hide what Bitcoin-y stuff exactly. 00:24:07.310 --> 00:24:11.950 The goal is to make it possible to completely hide in the long run. To completely 00:24:11.950 --> 00:24:13.570 hide that you're doing Bitcoin stuff. 00:24:13.730 --> 00:24:18.220 In the long run. So what else would be necessary for that? But that's not where 00:24:18.220 --> 00:24:19.480 we are now. 00:24:19.620 --> 00:24:22.240 No, the general thing that you're going to need for that is called traffic 00:24:22.240 --> 00:24:27.320 shaping. And traffic shaping means that instead of sending your data the most 00:24:27.320 --> 00:24:30.120 efficient way possible, so I need to send you a block, I'm just going to send you 00:24:30.120 --> 00:24:34.380 one megabyte as fast as I can. What you do instead is know you're going to make 00:24:34.380 --> 00:24:38.720 it look like something else. So instead of sending you the block very quickly, 00:24:38.840 --> 00:24:42.960 I'm going to send it very slowly. And instead of sending you individual 00:24:42.960 --> 00:24:47.020 transactions, maybe I'm always going to send you 10 bytes per minute. And 00:24:47.020 --> 00:24:50.220