WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:07.340 --> 00:00:10.040 Live from Utrecht, this is the van Wirdum Sjorsnado. 00:00:10.180 --> 00:00:10.340 Hello. 00:00:11.400 --> 00:00:17.160 Sjors, you pointed out to me that Bitcoin Core has an amazing new feature 00:00:17.160 --> 00:00:19.360 merged into its repository. 00:00:19.740 --> 00:00:21.740 Absolutely. We have bigger onions now. 00:00:22.220 --> 00:00:22.880 Bigger onions. 00:00:23.160 --> 00:00:23.700 Bigger onions. 00:00:23.960 --> 00:00:28.340 Right. So I had basically no idea what it meant. You figured it out. 00:00:28.840 --> 00:00:29.440 I did. 00:00:29.600 --> 00:00:30.600 You know everything about this. 00:00:30.720 --> 00:00:34.320 Well, I wouldn't say that. But I know a thing or two. So basically... 00:00:34.320 --> 00:00:37.020 Yeah, so let's start at the beginning. It's about Tor. 00:00:37.720 --> 00:00:39.120 Well, it's also about Tor. 00:00:39.260 --> 00:00:39.460 Okay. 00:00:39.920 --> 00:00:43.980 But Tor was kind of the big, I guess, the big motivator to get everything in 00:00:43.980 --> 00:00:49.000 there. So if you're familiar with... Have you ever used Tor? Or do you know what 00:00:49.000 --> 00:00:50.780 Tor is? I shouldn't ask those kind of questions. 00:00:50.920 --> 00:00:53.200 I have a basic understanding of what Tor is, yes. 00:00:53.360 --> 00:00:57.630 Exactly. And when you see a Tor address, it's this weird little... It looks quite 00:00:57.630 --> 00:01:03.270 weird. Right. That's a nice way to say it. And so the idea is that 00:01:03.270 --> 00:01:06.870 it's actually a public key, essentially, a Tor address. 00:01:07.070 --> 00:01:07.350 Mm-hmm. 00:01:08.650 --> 00:01:13.690 And that refers to a hidden service somewhere on the internet. 00:01:14.070 --> 00:01:14.210 Right. 00:01:14.530 --> 00:01:18.850 And the way you communicate to that hidden service is not directly, because you 00:01:18.850 --> 00:01:23.030 don't know its IP address, but indirectly through the Tor network. And you use 00:01:23.030 --> 00:01:24.390 Onion packages for that. 00:01:24.850 --> 00:01:25.050 Yeah. 00:01:25.410 --> 00:01:29.850 So the idea is that you start from the inside, like the last hop before the 00:01:29.850 --> 00:01:34.090 hidden service, and you give that hop instructions how to reach the hidden 00:01:34.090 --> 00:01:39.080 service, and then you... write instructions for the second last hop, and you give 00:01:39.080 --> 00:01:41.480 it instructions how to reach the first hop. 00:01:42.110 --> 00:01:48.090 Sure, everyone is still using IP addresses, it's just you don't know 00:01:48.090 --> 00:01:53.840 the IP address of the Tor node you're communicating with. Instead, you're 00:01:53.840 --> 00:01:58.660 communicating with other Tor nodes, and every Tor node communicates with a direct 00:01:58.660 --> 00:02:03.640 peer, so everyone only knows the IP address of their direct peer, but they don't 00:02:03.640 --> 00:02:08.500 know where the message... originated or where it ends up, plus they can't read 00:02:08.500 --> 00:02:09.760 the message because it's encrypted. 00:02:10.260 --> 00:02:10.880 That's right. 00:02:10.980 --> 00:02:15.360 And in order to support this, all of these Tor nodes have their own sort of IP 00:02:15.360 --> 00:02:19.940 address, which is their Onion address, and that's what they use to, that's what 00:02:19.940 --> 00:02:23.200 you're communicating with directly, so to say. 00:02:23.580 --> 00:02:28.300 Yeah, and Bitcoin Core nodes can run behind such a hidden service. So everybody 00:02:28.300 --> 00:02:34.660 can have their Bitcoin node run at a secret location, so your IP address remains secret. 00:02:35.220 --> 00:02:37.260 Right. What's the practical benefit of that? 00:02:37.760 --> 00:02:43.620 Well, your IP address remains secret. So if you don't want the rest of the 00:02:43.620 --> 00:02:48.480 world to know that your IP address is running a Bitcoin node, maybe that's useful. 00:02:48.780 --> 00:02:54.160 Yeah. And I think it's also because if you're sending transactions... 00:02:54.350 --> 00:02:58.570 from an IP address, then network analysis can reveal where transactions 00:02:58.570 --> 00:03:02.690 originated. Although I guess that's also being solved, right? There's other 00:03:02.690 --> 00:03:03.670 solutions for that as well. 00:03:03.810 --> 00:03:07.830 Well, that's defense in depth, right? So ideally your node behaves in a way that 00:03:07.830 --> 00:03:11.610 it looks indistinguishable from all other nodes. So your node downloads all the 00:03:11.610 --> 00:03:16.150 blocks and it downloads all the mempool transactions and you can't tell which 00:03:16.150 --> 00:03:20.490 wallet is running inside which node, but there's all these sneaky companies that 00:03:20.490 --> 00:03:21.170 try anyway. 00:03:22.640 --> 00:03:26.580 And then they might know that you sent a specific transaction. Well, then they 00:03:26.580 --> 00:03:30.000 might know which Bitcoins belong to you. And since your IP address is, you know, 00:03:30.680 --> 00:03:34.720 quite easy to figure out who you are, it could be nice to have Tor. 00:03:35.710 --> 00:03:36.050 Right. 00:03:36.270 --> 00:03:40.030 In theory. But regardless, I mean, that's just how it works. 00:03:40.390 --> 00:03:45.910 Okay, so you can use Bitcoin from behind Tor. And I think the thing was that 00:03:45.910 --> 00:03:51.390 there's a new type of onion addresses. There was an updating in the Tor protocol. 00:03:52.060 --> 00:03:52.660 That's right. 00:03:52.820 --> 00:03:54.600 And that uses new addresses. 00:03:55.300 --> 00:04:00.580 Yes. So the Tor addresses are now longer, essentially, which just makes them more 00:04:00.580 --> 00:04:04.100 secure. And I guess we don't need to go into why that is because I don't know why 00:04:04.100 --> 00:04:08.960 that is. All we know is that Onion addresses now, version 3, are a bit longer. 00:04:11.020 --> 00:04:15.400 That means that if you want to keep running a Bitcoin node on Tor, you'll have to 00:04:15.400 --> 00:04:20.400 use those longer addresses. Because Tor is centralized, and they have decided to 00:04:20.400 --> 00:04:22.740 eventually get rid of the version 2 addresses. 00:04:23.460 --> 00:04:27.180 Okay, but they didn't yet. So right now, version 2 addresses are still usable? 00:04:27.420 --> 00:04:31.280 Yes, I think they've been officially deprecated now. And I think in about a year 00:04:31.280 --> 00:04:33.300 or so, they won't work anymore. 00:04:33.640 --> 00:04:39.180 I see. So anyone who wants to continue using Tor needs to upgrade 00:04:39.180 --> 00:04:41.980 before... Next year, so to say. 00:04:42.100 --> 00:04:43.280 Something like that. Roughly. 00:04:43.440 --> 00:04:47.260 So that's why Bitcoin would need to be upgraded in order to support this new address. 00:04:47.500 --> 00:04:52.820 Yes. So then we get to the question of why would this make a difference? What's 00:04:52.820 --> 00:04:57.040 wrong with a longer address? And that has to do with how Bitcoin nodes spread the 00:04:57.040 --> 00:05:02.890 word about who they are. Because how do you know... which node to 00:05:02.890 --> 00:05:07.590 connect to. And the idea there is that nodes can communicate with each other. 00:05:07.970 --> 00:05:13.250 They send each other lists of known nodes. So they ask each other, hey, which 00:05:13.250 --> 00:05:17.390 Bitcoin nodes do you know? And then they get a list of IP addresses. And 00:05:17.390 --> 00:05:23.340 generally those are either IPv4 addresses or IPv6 addresses. IPv6 is the new kid 00:05:23.340 --> 00:05:26.300 in town since, I don't know, 1998 or something. 00:05:26.780 --> 00:05:29.440 Right. These are the regular IP addresses. 00:05:29.740 --> 00:05:30.100 Correct. 00:05:30.420 --> 00:05:35.880 Yeah, and the IP 6 ones are longer as well, and that's because IP 4 was running 00:05:35.880 --> 00:05:36.340 out, right? 00:05:36.720 --> 00:05:42.300 Right, there's only, I think, 4 billion potential IPv4 addresses, whereas there's 00:05:42.300 --> 00:05:46.160 just enough for every molecule in the universe of IPv6 addresses. 00:05:46.460 --> 00:05:52.100 Right, so there's a list, or Bitcoin nodes keep lists of 00:05:52.100 --> 00:05:54.780 other Bitcoin nodes and their IP addresses. 00:05:54.980 --> 00:05:59.000 Yes, and the way you would communicate a Tor address that way is you would kind 00:05:59.000 --> 00:06:03.380 of piggyback on IPv6. Because there is a convention, I think it's used outside of 00:06:03.380 --> 00:06:07.920 Bitcoin too, where if the IPv6 address starts with a certain prefix, certain 00:06:07.920 --> 00:06:12.750 numbers, then everything that follows is the Tor address. 00:06:13.570 --> 00:06:19.410 Because the Tor version 2 address, let me see if I got it right, an IPv6 address 00:06:19.410 --> 00:06:25.270 is 16 bytes and a Tor address is only 10 bytes. So you can 00:06:25.270 --> 00:06:26.050 hide inside of it. 00:06:26.250 --> 00:06:32.070 So Bitcoin nodes keep... The IP addresses of other Bitcoin nodes they 00:06:32.070 --> 00:06:36.950 know, and these are these IPv4 and IP6, and some of the IPv6 are also the Tor 00:06:36.950 --> 00:06:38.010 addresses. 00:06:38.290 --> 00:06:38.610 Exactly. 00:06:38.870 --> 00:06:44.510 And this is what, when nodes connect with each other, they share their lists, so 00:06:44.510 --> 00:06:48.690 everyone has an even more complete list of all of the Bitcoin nodes. Is this correct? 00:06:48.870 --> 00:06:53.620 That's right, yes. The problem with Tor version 3 addresses is that they are 32 00:06:53.620 --> 00:06:56.160 bytes, which is twice as long as an IPv6 address. 00:06:56.520 --> 00:06:59.180 Right, so now you can't hide it inside an IPv6 address. 00:06:59.380 --> 00:07:04.480 No, so just nodes have no way to communicate those addresses at the moment. 00:07:04.720 --> 00:07:07.550 Right. So that has been upgraded. 00:07:08.420 --> 00:07:13.560 Exactly. So this is not rocket science to solve, but somebody actually needs to 00:07:13.560 --> 00:07:19.260 do it. And somebody, Wladimir van der Laan, wrote a standard a while ago, I think 00:07:19.260 --> 00:07:24.980 in 2019, that has a new way of communicating, of gossiping addresses. 00:07:25.700 --> 00:07:31.000 And the major change is that you can, each message says, okay, this is the type 00:07:31.000 --> 00:07:34.300 of address I'm going to communicate. And there can be various types, including 00:07:34.300 --> 00:07:38.940 the new Tor one, but also future ones. and then it can have different lengths. 00:07:39.820 --> 00:07:39.980 Right. 00:07:40.360 --> 00:07:43.640 So in the future, if a new address format comes along that's too long, that's not 00:07:43.640 --> 00:07:44.160 going to be a problem. 00:07:44.540 --> 00:07:50.300 Right. So that sounds like a pretty straightforward upgrade from my 00:07:50.300 --> 00:07:52.480 layman's perspective as a non-programmer. 00:07:52.660 --> 00:07:53.000 It is. 00:07:53.000 --> 00:07:57.620 But a very important one because we do want to keep using Tor potentially. 00:07:58.020 --> 00:08:03.400 Yeah, and the nice thing is it's a completely new peer-to-peer message. So I 00:08:03.400 --> 00:08:08.220 guess old nodes just... ignore that message or if you know it's an old node that 00:08:08.220 --> 00:08:13.280 you're talking to you don't use that message so newer nodes will will know this 00:08:13.280 --> 00:08:16.920 new message and can communicate all these new address types and older nodes just 00:08:16.920 --> 00:08:18.340 carry on like nothing happened. 00:08:18.340 --> 00:08:23.960 Right. Okay, I have one one follow-up question about this sharing of 00:08:23.960 --> 00:08:29.590 lists and sharing of IP addresses which is not Tor specific I guess, 00:08:29.590 --> 00:08:35.090 but what, how does it actually, how do you actually connect to the first node? 00:08:35.090 --> 00:08:40.310 How do you bootstrap to the network? if you have no idea, if you have no list yet 00:08:40.310 --> 00:08:44.590 of other nodes, then how do you find the first node? How does this actually work in Bitcoin? 00:08:44.590 --> 00:08:48.230 Yeah, so the bootstrap problem, basically, you've just downloaded Bitcoin Core or 00:08:48.230 --> 00:08:52.250 some other client and you start it up, and now what? Is it just going to guess 00:08:52.250 --> 00:08:56.880 random IP addresses? No, right? So it needs to know another node to connect to, 00:08:57.020 --> 00:09:01.520 at least one, preferably a couple. The way it tries to do that is using something 00:09:01.520 --> 00:09:06.980 called DNS seeds. The internet DNS system is used for websites when you type an 00:09:06.980 --> 00:09:12.640 address, www.google.com. What your browser does is it asks a 00:09:12.640 --> 00:09:17.760 DNS server what IP addresses are from that Google domain. 00:09:18.360 --> 00:09:21.200 Do you know how many DNS servers there are? 00:09:21.740 --> 00:09:26.980 Lots of them because... Basically, if you run a website, your hosting provider 00:09:26.980 --> 00:09:32.060 will have a DNS server that points to your website, but then your country will 00:09:32.060 --> 00:09:36.580 have a DNS server that will point to your hosting provider, and your internet 00:09:36.580 --> 00:09:40.800 provider has a DNS server that points to all these different countries, et 00:09:40.800 --> 00:09:44.000 cetera, et cetera. So it's very redundant, basically. 00:09:44.000 --> 00:09:48.420 We're going very off the trail here, but I do find it interesting. How are these 00:09:48.420 --> 00:09:51.340 DNS servers, how do they remain in sync? 00:09:52.340 --> 00:09:57.960 So basically, when you have a DNS record, so if you are maintaining a website, 00:09:58.220 --> 00:10:01.580 you usually have to go into some control panel and type in the IP address of your 00:10:01.580 --> 00:10:05.920 server and then your domain name, and that's stored on the DNS server. One of the 00:10:05.920 --> 00:10:10.240 fields you have to fill out is the timeout. So what you're saying is after 24 00:10:10.240 --> 00:10:15.710 hours, for example, or after one hour, you should ask me again. So when you're... 00:10:16.640 --> 00:10:21.720 when you're visiting a website, you're going to ask maybe your ISP, hey, do you 00:10:21.720 --> 00:10:25.120 know the IP address for this website? And if it doesn't, it's going to ask the 00:10:25.120 --> 00:10:30.220 next DNS server up the street, basically. Say, do you know it? And then as soon 00:10:30.220 --> 00:10:33.780 as it finds a record, it's going to say, okay, is this record still valid or is 00:10:33.780 --> 00:10:37.820 this expired? And if it's still valid, it'll use it. And if it's expired, it'll 00:10:37.820 --> 00:10:42.000 go up closer and closer to the actual hosting provider. 00:10:43.690 --> 00:10:49.540 So it's basically cached. Does that make sense? So the easiest would be if 00:10:49.540 --> 00:10:55.480 you go to a domain, like, say, google.com. Okay, how do you 00:10:55.480 --> 00:10:59.800 find the IP address? Well, you ask Google what the IP address is. But how do you 00:10:59.800 --> 00:11:04.040 know what the IP address is for google.com? You don't know that because that's 00:11:04.040 --> 00:11:09.160 what you were trying to find out. So you have to ask somebody else. And so you 00:11:09.160 --> 00:11:12.540 ask your internet provider, do you know the way to google.com? Well, your 00:11:12.540 --> 00:11:15.780 internet provider might not know that, but it says, well, I know the way to .com. 00:11:16.650 --> 00:11:20.910 basically, and .com will know the way to .google.com. So that's kind of how it 00:11:20.910 --> 00:11:23.530 works. .nl, same, you go to, you ask .nl, 00:11:25.110 --> 00:11:26.890 you know, where is Google.nl? 00:11:27.730 --> 00:11:29.610 Okay, yeah, that makes total sense. 00:11:29.950 --> 00:11:33.090 Yeah, and ideally, they already have this cached because so many people go to 00:11:33.090 --> 00:11:37.590 Google.com that if you ask your ISP, where's Google.com, they'll know because 00:11:37.590 --> 00:11:40.270 somebody else asked. But if they don't know, they'll send you to .com. 00:11:40.930 --> 00:11:44.610 Right, okay, well, so this is where I'm really getting at. The DNS system is 00:11:44.610 --> 00:11:46.070 ultimately centralized, right? 00:11:47.730 --> 00:11:48.330 Yes. 00:11:48.330 --> 00:11:50.370 There's a centralization risk there. 00:11:50.630 --> 00:11:51.070 Absolutely. 00:11:51.130 --> 00:11:53.390 Where you're trusting the DNS server. 00:11:53.610 --> 00:11:55.470 And for Bitcoin, we're kind of abusing it. 00:11:55.690 --> 00:11:55.890 Right. 00:11:56.130 --> 00:12:01.450 Because Bitcoin nodes are not websites. But the idea is that there are a couple 00:12:01.450 --> 00:12:06.270 of core developers who run DNS seeds, which are essentially DNS servers. 00:12:07.110 --> 00:12:12.230 And we're just pretending that, for example, seed.bitcoin.sprovoost 00:12:12.230 --> 00:12:18.220 .nl, which is what I'm running, is a website, quote unquote. And when you 00:12:18.220 --> 00:12:22.500 ask that website, quote unquote, what its IP address is, you get a whole list of 00:12:22.500 --> 00:12:26.650 IP addresses. But those IP addresses are Bitcoin nodes. And every time you ask 00:12:26.650 --> 00:12:27.970 it, it's going to give you different IP addresses. 00:12:28.450 --> 00:12:30.530 Right. So what if someone corrupts you? 00:12:31.010 --> 00:12:34.710 Well, one step back. So this means that the standard infrastructure of the 00:12:34.710 --> 00:12:37.910 internet, all the internet service providers in the world and all these others 00:12:37.910 --> 00:12:41.670 are caching exactly where all the Bitcoin nodes are because they think it's just 00:12:41.670 --> 00:12:45.330 a website. So it's kind of nice that you keep all these lists of nodes 00:12:45.330 --> 00:12:50.040 redundantly stored on the internet. And there's quite a few protections on the 00:12:50.040 --> 00:12:55.000 internet against censorship of DNS. So you're leveraging all that. But at the 00:12:55.000 --> 00:13:00.200 same time, of course, if I and the other people were to lie and run a fake 00:13:00.200 --> 00:13:05.460 server, we could send you to any node we want. But that would be very visible. 00:13:05.980 --> 00:13:11.000 All right. And the reason it's visible is because anyone can request these IP 00:13:11.000 --> 00:13:15.800 addresses from you and then check if they're actually Bitcoin nodes or not, or if 00:13:15.800 --> 00:13:19.520 you're trying to cheat there. That's the reason they're visible. Yeah, exactly. 00:13:19.600 --> 00:13:20.680 It would be hard to cheat. 00:13:20.720 --> 00:13:25.300 If you were to cheat like that, like very non-randomly, like to add to the whole 00:13:25.300 --> 00:13:26.420 world, it'd be very obvious. 00:13:26.600 --> 00:13:30.360 Right. So, but what if it happens? Like, is there another way to connect to the 00:13:30.360 --> 00:13:31.460 Bitcoin network at that point? 00:13:31.720 --> 00:13:36.700 Well, if they're lying, it's tricky. But if they're just offline... So if all the 00:13:36.700 --> 00:13:41.320 Bitcoin DNS seeds are not reachable, then inside the Bitcoin core source code and 00:13:41.320 --> 00:13:46.580 also in the thing you download is a list of IP addresses and as well as a few 00:13:46.580 --> 00:13:47.320 hidden services. 00:13:47.780 --> 00:13:51.840 Right. So that's also Bitcoin nodes. They're embedded into the source code. 00:13:52.040 --> 00:13:53.420 Yeah. So every year or so. 00:13:53.580 --> 00:13:56.860 Which nodes are these or why are these embedded in the source code? 00:13:57.000 --> 00:14:00.730 Okay. So it happens every six months or so, is we 00:14:00.730 --> 00:14:05.990 ask all the DNS seed maintainers 00:14:05.990 --> 00:14:11.610 to provide a list of the most reliable nodes. Just all the nodes 00:14:11.610 --> 00:14:16.110 sorted by how frequently they're online. Because your DNS seed tends to track, 00:14:16.270 --> 00:14:21.430 I've polled this node once and it was online. So basically what a DNS seed does 00:14:21.430 --> 00:14:27.300 on its side is it is just a crawler. So the DNS seed goes to a 00:14:27.300 --> 00:14:31.180 couple of Bitcoin nodes, asks it for all the nodes it knows, keeps a list and 00:14:31.180 --> 00:14:35.320 just goes to the list, pings them all. And then once it's done pinging them all, 00:14:35.420 --> 00:14:38.960 it's just going to ping them all again. And it keeps track of how often they're 00:14:38.960 --> 00:14:43.480 online. And so you make a list of that sorted by reliability. You take that from 00:14:43.480 --> 00:14:48.220 all the contributors and that goes into the source code. So that's the fallback. 00:14:48.760 --> 00:14:49.160 Interesting. 00:14:49.320 --> 00:14:54.230 But it's only the first time you start your node, at least in theory. So only the 00:14:54.230 --> 00:14:58.590 very first time you start your node, you need this. After that, you keep track of 00:14:58.590 --> 00:15:03.150 the nodes you know about. You store all these gossip nodes in a file and you 00:15:03.150 --> 00:15:07.370 start opening the file and you just try the nodes you know about. And only if you 00:15:07.370 --> 00:15:10.070 run out, if it doesn't work, you ask the seed again. 00:15:10.430 --> 00:15:15.530 Yep. And then you keep syncing your list of IP addresses with the new nodes. 00:15:16.270 --> 00:15:20.050 Yeah, exactly. I think whenever a node connects to you for the first time, that's 00:15:20.050 --> 00:15:24.050 one of the first things they ask. Who else do you know? I think you can even send 00:15:24.050 --> 00:15:24.930 them unsolicited. 00:15:26.120 --> 00:15:26.520 Okay. 00:15:26.700 --> 00:15:29.520 Which is why, you know, if you start a new node, you get inbound connections 00:15:29.520 --> 00:15:33.760 pretty quickly because you've announced your IP address to other people and 00:15:33.760 --> 00:15:37.190 they're gossiping it around and these other nodes then start connecting. 00:15:38.260 --> 00:15:43.120 Interesting. Okay, so that makes it pretty clear to me. You bootstrap to the 00:15:43.120 --> 00:15:48.840 Bitcoin network by first querying DNS records to find other Bitcoin 00:15:48.840 --> 00:15:54.400 nodes. You get a list of IP addresses. You use these to connect to the actual 00:15:54.400 --> 00:15:59.940 Bitcoin nodes, which could also be Tor nodes at that point, right? These you can 00:15:59.940 --> 00:16:05.820 also query from the DNS records. At that point, you ask... about all 00:16:05.820 --> 00:16:09.760 of the nodes they know and you update your list and from that point on you're 00:16:09.760 --> 00:16:15.130 also sharing the IP addresses you have with other nodes. 00:16:15.790 --> 00:16:21.630 So far these were IPv4 and IPv6 and IPv6 had a subset of onion nodes and 00:16:21.630 --> 00:16:27.450 with this upgrade we'll be ready for a newer version of onion nodes. That's the story. 00:16:28.050 --> 00:16:28.810 That's about right. 00:16:29.010 --> 00:16:29.630 That's our podcast. 00:16:29.830 --> 00:16:33.770 Great. And one tiny little thing that was recently added is that the Bitcoin node 00:16:33.770 --> 00:16:38.530 actually can spin up the version three onion node, but that is actually like a 00:16:38.530 --> 00:16:44.470 five-line change. So that's quite nice. That'll just work, TM, when you start a, 00:16:44.530 --> 00:16:48.510 I don't know, I think it's version 0.21. If you start it up, if you were running 00:16:48.510 --> 00:16:54.180 a version two node before, it's going to run a version three Tor node after. If 00:16:54.180 --> 00:16:57.520 you weren't, then you need to read the documentation how to set it up if you want to use it. 00:16:57.900 --> 00:16:58.360 Good. 00:16:59.190 --> 00:17:00.960 So, yeah. That's all. 00:17:01.160 --> 00:17:04.660 I guess that's it. All right. Guys, I forgot to mention something. 00:17:04.900 --> 00:17:05.520 Oh, my God. 00:17:05.760 --> 00:17:07.420 I have amazing news. 00:17:07.620 --> 00:17:08.080 Tell me. 00:17:08.200 --> 00:17:09.700 Actually, Sjors, you already know the news. 00:17:09.860 --> 00:17:10.080 I know. 00:17:10.380 --> 00:17:10.820 Ruben. 00:17:10.920 --> 00:17:11.360 What's the news? 00:17:11.600 --> 00:17:14.980 The van Wirdum Sjorsnado has its own feed now. 00:17:15.220 --> 00:17:15.600 Wow. 00:17:15.960 --> 00:17:19.160 Its own RSS feed, and it showed up in my podcast app. 00:17:19.460 --> 00:17:19.820 Excellent. 00:17:20.120 --> 00:17:24.500 So, I'm now subscribed to the van Wirdum Sjorsnado. If you're listening and if 00:17:24.500 --> 00:17:28.200 you want to hear it for all our episodes, then you can subscribe to the van 00:17:28.200 --> 00:17:28.820 Wirdum Sjorsnado. 00:17:29.020 --> 00:17:32.080 I'll be subscribing for sure. It's actually exactly what I was asking you guys 00:17:32.080 --> 00:17:34.920 for, like what I was missing. I just wanted to be able to subscribe to your 00:17:34.920 --> 00:17:36.400 podcast specifically, so great. 00:17:37.620 --> 00:17:42.100 That's two subscribers already, Sjors, me and Ruben. That's excellent. We're on a roll. 00:17:42.300 --> 00:17:43.180 I was already subscribed. 00:17:44.080 --> 00:17:44.660 It's free. 00:17:45.320 --> 00:17:49.040 Another related news is that we have had our first swap cast. 00:17:49.400 --> 00:17:50.380 Oh yeah, that's true. 00:17:50.540 --> 00:17:53.880 Because we actually featured on the Unhashed podcast. 00:17:54.220 --> 00:17:58.080 That's right. Yeah. So sometimes we're getting technical issues or whatever and 00:17:58.080 --> 00:18:03.180 unable to record. And then what we do is we look at other... podcast or something 00:18:03.180 --> 00:18:07.420 where maybe I appear or one of the other guys and we broadcast that so in this 00:18:07.420 --> 00:18:11.540 case I came onto your show so I asked you guys maybe we can put that on the 00:18:11.540 --> 00:18:15.540 Unhashed podcast so our Unhashed podcast listeners were also able to listen to 00:18:15.540 --> 00:18:20.040 the last episode and probably you know if I don't know a couple weeks from now we 00:18:20.040 --> 00:18:24.060 run into issues again maybe I'll be asking you to air this episode so, maybe 00:18:24.060 --> 00:18:25.180 it'll be number two. 00:18:25.440 --> 00:18:28.780 Yeah, and if you need an extra motivation to check that out, we actually 00:18:28.780 --> 00:18:32.040 re-edited the audio, so it's going to be a little bit better than the original. 00:18:32.200 --> 00:18:32.620 Yeah, that's correct. 00:18:32.680 --> 00:18:32.940 Check it out. 00:18:33.280 --> 00:18:34.560 All right, I wanted to mention that. 00:18:34.720 --> 00:18:37.300 Thank you for listening to the Van Wirdum Sjorsnado. 00:18:37.600 --> 00:18:38.080 There you go.