WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:08.210 --> 00:00:10.890 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:11.090 --> 00:00:11.290 Hello. 00:00:11.750 --> 00:00:12.150 Hey, Sjors. 00:00:12.330 --> 00:00:12.650 What's up? 00:00:13.380 --> 00:00:16.140 I forgot to mention something very important last week. 00:00:16.340 --> 00:00:16.580 Okay. 00:00:17.580 --> 00:00:20.420 We, Sjors, have our own RSS feed. 00:00:20.620 --> 00:00:21.180 We do. 00:00:21.460 --> 00:00:22.720 For the Van Wirdum Sjorsnado. 00:00:23.000 --> 00:00:25.980 But you didn't really forget to say it because it was spliced in and then Ruben 00:00:25.980 --> 00:00:26.680 appeared out of nowhere. 00:00:26.920 --> 00:00:28.200 No, that was the week before. 00:00:28.660 --> 00:00:30.280 It was spliced in last week, too. 00:00:30.800 --> 00:00:31.340 Oh, was it? 00:00:31.480 --> 00:00:31.660 Yes. 00:00:31.820 --> 00:00:32.020 Nice. 00:00:32.200 --> 00:00:34.480 So it was really strange because Ruben suddenly appeared in the podcast. 00:00:34.800 --> 00:00:36.440 Oh, that's weird. I didn't know that. 00:00:36.560 --> 00:00:37.340 He's not here now. 00:00:37.520 --> 00:00:40.960 Clearly, I didn't listen to our own podcast last week. 00:00:41.180 --> 00:00:42.540 I always like to listen to it. 00:00:43.000 --> 00:00:45.640 Okay, well, that's good. So our editor saved us there. 00:00:46.100 --> 00:00:46.440 Yes. 00:00:46.660 --> 00:00:48.000 And this week, I'm saving us. 00:00:48.420 --> 00:00:48.560 Okay. 00:00:48.780 --> 00:00:53.000 Dear listeners, we have our own RSS feed. Make sure to tune in to the Van Wirdum 00:00:53.000 --> 00:00:54.700 Sjorsnado each week. 00:00:54.880 --> 00:00:58.440 If you don't know what an RSS feed is, yet you are listening to this rather 00:00:58.440 --> 00:01:02.840 technical podcast, just you know you can subscribe in Apple, in iTunes podcast or 00:01:02.840 --> 00:01:04.280 Spotify podcast etc. 00:01:04.280 --> 00:01:09.780 So, Sjors, this week we are going to create a carbon copy of the Chaincode 00:01:10.100 --> 00:01:10.560 Podcast. 00:01:10.560 --> 00:01:11.820 That's correct. 00:01:11.820 --> 00:01:17.800 The the Chaincode guys, they have their own podcast which is called, let's see, 00:01:17.800 --> 00:01:19.640 is it just called the Chaincode Podcast? 00:01:19.640 --> 00:01:19.980 Yep, 00:01:19.980 --> 00:01:22.480 it's just called the Chaincode Podcast. It's a great podcast. 00:01:22.480 --> 00:01:23.980 It is a good podcast. 00:01:24.720 --> 00:01:29.940 They had an episode with James O'Beirne on Assume UTXO. 00:01:30.220 --> 00:01:34.100 And we are going to make an episode on Assume UTXO. 00:01:34.240 --> 00:01:37.020 And we're going to follow roughly the same structure. 00:01:37.240 --> 00:01:41.880 We're just going to create the same podcast just with our voices this time. 00:01:42.320 --> 00:01:42.440 Yep. 00:01:42.820 --> 00:01:47.950 We're going to do it step by step. First step is headers first. 00:01:48.690 --> 00:01:50.910 That's how they did it, so that's how we're going to do it. 00:01:51.290 --> 00:01:53.830 Right, and by first step, you mean we're going to go back in time and look at 00:01:53.830 --> 00:01:57.570 some improvements on how to download the blockchain quickly and safely. 00:01:57.810 --> 00:02:01.690 Yeah, that's basically the problem that we're solving here. Well, not you or me. 00:02:01.810 --> 00:02:06.430 Well, maybe you a bit, but definitely not me. But it's the problem of syncing. So 00:02:06.430 --> 00:02:11.310 when you turn on your Bitcoin Core node, then the first thing your node's got to 00:02:11.310 --> 00:02:15.850 do is... well, other than connect to the network, which we discussed last week, 00:02:16.030 --> 00:02:20.130 then the next thing is it needs to be able to 00:02:21.090 --> 00:02:26.410 communicate with the network. It needs to download the blockchain. It needs to be 00:02:26.410 --> 00:02:29.430 aware of the state of the network, basically. 00:02:29.830 --> 00:02:33.210 So the most naive way to do that would be to say to other peers, just give me 00:02:33.210 --> 00:02:37.610 everything you've got. And then you get gigabytes and gigabytes and gigabytes and 00:02:37.610 --> 00:02:41.810 terabytes of blocks and headers and random stuff, and your hard disk is full and 00:02:41.810 --> 00:02:46.380 you crash. So that's not the right way to do it. So I think the initial version 00:02:46.380 --> 00:02:52.200 of Bitcoin, before it was even called Bitcoin Core, it would just ask nodes 00:02:52.200 --> 00:02:56.560 for a header and then it got a header and it would ask nodes for a block and it 00:02:56.560 --> 00:03:01.050 would get that block. And it would ask for the next header, and it would just 00:03:01.050 --> 00:03:04.050 sequentially get all the headers, sequentially get all the blocks. 00:03:04.450 --> 00:03:08.090 One header at a time followed by the same block, one at a time. 00:03:08.310 --> 00:03:11.270 Yeah, I think so. I might be wrong on this, but it doesn't really matter for what 00:03:11.270 --> 00:03:12.070 we're about to explain. 00:03:12.510 --> 00:03:14.110 So what's the problem with that? 00:03:14.250 --> 00:03:18.150 Well, the problem with that is you don't know if you're following a dead end. So 00:03:18.150 --> 00:03:23.190 I might be, you know, we all know, you know, there's a lot of blocks out there. 00:03:24.760 --> 00:03:28.560 But when you start syncing, I could give you the first block and then I could 00:03:28.560 --> 00:03:33.060 just mine the second block and the third block myself at a very low difficulty. 00:03:33.700 --> 00:03:37.940 So I could just keep the Bitcoin difficulty at one and just mine a chain with 00:03:37.940 --> 00:03:41.580 like a million blocks in it. And I would give them to you one by one by one by 00:03:41.580 --> 00:03:43.780 one, and you would check it, and you'd be happy, and you would check it, and 00:03:43.780 --> 00:03:47.880 you'd be happy. And I would send you megabyte-sized blocks or even bigger with 00:03:47.880 --> 00:03:48.820 all the SegWit stuff in it. 00:03:48.960 --> 00:03:51.960 Sure, yeah, just to be clear, even though the difficulty is low, that doesn't 00:03:51.960 --> 00:03:56.600 make it any easier for my nodes to verify the transactions. It's still going to 00:03:56.600 --> 00:03:58.320 cost a lot of computational power. 00:03:58.480 --> 00:04:01.700 So it's very cheap for me to generate a fake chain with very low difficulty, and 00:04:01.700 --> 00:04:06.360 I can just keep you busy for a long time. So one way to get rid of that 00:04:06.360 --> 00:04:10.470 problem... is to first ask for headers, not the entire block, but just headers. 00:04:10.970 --> 00:04:15.370 Just to be clear, this isn't really a problem in itself, because in the end, I 00:04:15.370 --> 00:04:21.010 would still, as a new node, compare chains, compare blockchains, and then pick 00:04:21.010 --> 00:04:26.720 the one with the most difficulty. It's just you need to... You need to verify all 00:04:26.720 --> 00:04:30.480 of the chains first before you would make the pick. That's the problem here. 00:04:30.620 --> 00:04:35.080 But I could, you know, turn on Amazon and give you a million chains like that. 00:04:35.400 --> 00:04:35.480 Right. 00:04:35.660 --> 00:04:37.560 So it would be very hard for you to find the real one. 00:04:37.720 --> 00:04:38.020 Right. 00:04:38.400 --> 00:04:43.400 Right. So the idea then is you download the headers instead. So headers are a lot 00:04:43.400 --> 00:04:48.140 smaller. So I can give you a bunch of nonsense there, but you can quickly shop 00:04:48.140 --> 00:04:51.840 between headers and see the total difficulty in it. 00:04:52.200 --> 00:04:56.720 Right. So instead of downloading and verifying all the chains and then picking 00:04:56.720 --> 00:05:02.240 the one with the most proof of work, I'm first checking out which chain has got 00:05:02.240 --> 00:05:05.280 the most proof of work. So I'm basically inverting it, right? 00:05:05.400 --> 00:05:05.800 Yes, exactly. 00:05:05.880 --> 00:05:09.380 And then the one with the most proof of work, that's the one I'm actually gonna 00:05:09.900 --> 00:05:10.500 validate. 00:05:10.550 --> 00:05:14.890 Right, because so far you just have SPV security, so you just know which one has 00:05:14.890 --> 00:05:17.710 the most proof of work, but it could be invalid. So in that case, you start 00:05:17.710 --> 00:05:21.510 downloading one block at a time, or in fact, because you already have all the 00:05:21.510 --> 00:05:25.190 headers, you can download lots of blocks at the same time from different nodes in 00:05:25.190 --> 00:05:30.380 parallel, but you have to verify them in sequence. And then if you run into an 00:05:30.380 --> 00:05:33.860 invalid block, okay, then you say this header chain might have the most proof of 00:05:33.860 --> 00:05:36.920 work, but it's not valid. So I'm going to go to this second most proof of work 00:05:36.920 --> 00:05:41.120 header chain and ask for the blocks. It's mostly going to be the same, maybe 00:05:41.120 --> 00:05:42.020 except the last few. 00:05:42.680 --> 00:05:47.220 Yeah, you mentioned SPV security very briefly. Technically, that would be 00:05:47.220 --> 00:05:50.620 possible, right? Even though Bitcoin Core doesn't do that right now, it would be 00:05:50.620 --> 00:05:56.460 possible to bootstrap your nodes, get started with SPV security at first, and 00:05:56.460 --> 00:06:00.490 then only... after you're done validating all of the blocks, you got full 00:06:00.490 --> 00:06:00.970 security. 00:06:01.590 --> 00:06:04.890 Yeah, no, you could. But I don't think you would know your transaction history 00:06:04.890 --> 00:06:07.050 because you do need the blocks for that. 00:06:07.490 --> 00:06:11.590 Sure, but you would still have SPV security. And there was a proposal to 00:06:11.590 --> 00:06:14.110 implement something like this in Bitcoin Core a while ago. 00:06:14.410 --> 00:06:18.350 Yeah, I think so. This was by Jonas Schnelli, I think four or five years ago, an 00:06:18.350 --> 00:06:23.110 attempt to at least start up in SPV mode. And then I guess if you create a new 00:06:23.110 --> 00:06:28.210 address from scratch... then you know its history. So then when the next block 00:06:28.210 --> 00:06:33.230 comes in and you see a transaction to that address, then you know that you have a 00:06:33.230 --> 00:06:37.670 balance. You can't rescan any old addresses, but I guess you can see anything new 00:06:37.670 --> 00:06:40.610 that comes in because you're going to download all the real blocks after, 00:06:41.010 --> 00:06:43.330 starting at the present, basically. 00:06:43.550 --> 00:06:48.030 Yeah, you're at least sure that miners think it's a valid transaction or at least 00:06:48.030 --> 00:06:53.230 they're spending hash power telling you it's a valid transaction. So even though 00:06:53.230 --> 00:06:56.690 you don't have full security, it's a little bit better than nothing. 00:06:57.190 --> 00:07:00.770 Right, and of course, it's definitely enough to receive it and then just to 00:07:00.770 --> 00:07:05.190 assume that it's fake. you know, you can just sit on it for a while. But in the 00:07:05.190 --> 00:07:07.230 meantime, you would be validating all the older blocks. 00:07:07.490 --> 00:07:10.430 Yeah. But just to be clear, Bitcoin Core doesn't do this right now. 00:07:10.650 --> 00:07:10.950 No, it doesn't. 00:07:11.010 --> 00:07:15.690 Right now, it's just a trick to avoid having to download all of these fake 00:07:15.690 --> 00:07:20.710 chains, potentially. Instead, you only download the chain that has the most proof of work. 00:07:21.030 --> 00:07:21.470 Yes. 00:07:21.630 --> 00:07:23.030 That's what Headers First is. 00:07:23.230 --> 00:07:23.390 Yeah. 00:07:23.750 --> 00:07:27.510 Okay. Now, next step. So there's a thing called assume valid. 00:07:27.870 --> 00:07:28.430 That's right. 00:07:28.630 --> 00:07:29.490 What is assume valid? 00:07:29.810 --> 00:07:35.480 So assume valid... is a block hash that is encoded in the software. 00:07:35.720 --> 00:07:38.120 Just to be clear, this is actually in Bitcoin Core today. 00:07:38.320 --> 00:07:43.160 Yes, it's been there for a few years. So it is a hash of a recent block, as in 00:07:43.160 --> 00:07:49.100 recent before the release. And a lot of the different Bitcoin Core developers and 00:07:49.100 --> 00:07:53.430 anybody else who is on GitHub... can see what that hash is, and they can check 00:07:53.430 --> 00:07:58.730 for themselves whether that hash is real. And if you're a new user and you start 00:07:58.730 --> 00:08:02.830 a Bitcoin Core, it's going to sync all the headers, it's going to get all the 00:08:02.830 --> 00:08:08.760 blocks. And if that particular hash is in the chain, then 00:08:08.760 --> 00:08:13.790 it will not verify the signatures. So it's not a checkpoint. The hash does not 00:08:13.790 --> 00:08:18.950 have to be out there. But if it's out there... You don't verify any of the 00:08:18.950 --> 00:08:23.050 signatures up to that point. So it's a lot faster to sync that way. Or a lot less 00:08:23.050 --> 00:08:23.810 slow, I would say. 00:08:24.090 --> 00:08:25.370 Do you still download the signatures? 00:08:25.970 --> 00:08:28.270 Yeah, you download everything. You download the whole blockchain. 00:08:28.550 --> 00:08:34.070 Right. So just a shortcut for syncing is that you do not verify the signatures up 00:08:34.070 --> 00:08:34.830 until that point. 00:08:35.110 --> 00:08:35.350 Exactly. 00:08:35.610 --> 00:08:39.510 So what you are doing is you're still checking the proof of work. You're still 00:08:39.510 --> 00:08:44.910 checking that miners actually produce the blocks by expending energy. 00:08:45.090 --> 00:08:45.570 Yeah. 00:08:45.790 --> 00:08:49.690 And you're checking that it is the longest chain. And you're also checking all of 00:08:49.690 --> 00:08:55.180 the transactions in order to... construct the UTXO set, which is the current 00:08:55.180 --> 00:08:56.040 state of balances. 00:08:56.440 --> 00:08:59.260 Right. Money cannot come out of nowhere, basically. 00:08:59.620 --> 00:08:59.800 Right. 00:09:00.000 --> 00:09:02.220 So you check all that stuff, but you do not check the signatures. 00:09:02.400 --> 00:09:07.920 Right. So you're not checking that the valid owner of each coin in any part of 00:09:07.920 --> 00:09:13.840 history was actually the correct owner. For that, you're trusting essentially on 00:09:13.840 --> 00:09:17.200 the miners as well as on the developers, I guess. 00:09:17.340 --> 00:09:20.750 You're fully trusting the developers. Well, you're trusting that... The 00:09:20.750 --> 00:09:25.870 developers, if they were to put in something that's not real, somebody would 00:09:25.870 --> 00:09:29.370 notice that. Because you can see the source code and it's just one line and if 00:09:29.370 --> 00:09:33.830 that has a hash in it that doesn't exist, well, then you should be worried. And 00:09:33.830 --> 00:09:37.530 it would be quite weird even then because it would have to be a chain with more 00:09:37.530 --> 00:09:42.370 proof of work. Otherwise, you would never see it. So some evil developer would 00:09:42.370 --> 00:09:47.230 have to produce a chain with more proof of work than the real thing in order to 00:09:47.230 --> 00:09:51.180 trick some future user. but risk everybody noticing it. 00:09:51.540 --> 00:09:55.440 Yes. Well, that's why I mentioned also the miners. Like you still got to produce 00:09:55.440 --> 00:09:56.340 the proof of work, right? 00:09:56.560 --> 00:09:56.760 Yeah. 00:09:57.120 --> 00:10:01.080 So why, Sjors, would we trust guys like you? 00:10:01.240 --> 00:10:07.190 You don't. I mean, the saying is don't trust verify. But you're kind of relying 00:10:07.190 --> 00:10:12.330 on that somebody's done that. Because don't forget that you're still downloading 00:10:12.330 --> 00:10:16.450 a piece of software from the internet, which could have a line of code in there 00:10:16.450 --> 00:10:18.530 that says just send all the bitcoins to me. 00:10:19.370 --> 00:10:19.850 Right. 00:10:20.050 --> 00:10:24.630 So you have to check for sneaky things by the developers in general. But that 00:10:24.630 --> 00:10:28.150 particular sneaky thing would be extremely easy to see because it's one place in 00:10:28.150 --> 00:10:31.830 the code base that has a hash in it and everybody can reproduce it. And if you 00:10:31.830 --> 00:10:35.910 don't like this and you don't have to like this, you start Bitcoin from scratch 00:10:35.910 --> 00:10:41.740 with dash assume valid is zero. And then it will validate 00:10:41.740 --> 00:10:42.380 all the signatures. 00:10:42.800 --> 00:10:47.200 Exactly. That's just what I was about to ask. If you don't want to put this trust 00:10:47.200 --> 00:10:49.040 in developers, you can still do it yourself. 00:10:49.340 --> 00:10:52.760 Yeah, but keep in mind, you're not putting that particular piece of trust in the 00:10:52.760 --> 00:10:56.420 developers, but you still downloaded a binary file from the internet. So you are 00:10:56.420 --> 00:10:57.940 putting trust in the developers. 00:10:58.980 --> 00:11:04.560 I mean, that depends, right? You could check the source code if you really wanted to. 00:11:05.300 --> 00:11:06.500 Yes, you should. 00:11:07.140 --> 00:11:09.460 Compile it into binaries if you want to. 00:11:10.440 --> 00:11:14.660 Yeah, you can do that. And then you'll see this hash, and you trust that part of 00:11:14.660 --> 00:11:18.020 the source code isn't sneaky. Because you can look at the source code, but there 00:11:18.020 --> 00:11:21.880 could be some really sneaky obscure C++ code in there that you have no idea what 00:11:21.880 --> 00:11:24.020 it's doing, and it's stealing your coins. 00:11:24.400 --> 00:11:30.010 You're underestimating my ability to check for... very sneaky C++ 00:11:30.010 --> 00:11:30.970 source code. 00:11:31.190 --> 00:11:34.550 Well, that's great. We need more people like you to make sure that doesn't happen. 00:11:34.810 --> 00:11:38.430 I wish that was true. Okay, so this is actually in Bitcoin Core, and it's been in 00:11:38.430 --> 00:11:39.610 Bitcoin Core for a while. 00:11:40.030 --> 00:11:41.230 Yeah, I think a couple of years. 00:11:41.630 --> 00:11:44.910 Yeah, and apparently everyone's comfortable enough with this. 00:11:45.190 --> 00:11:45.770 I don't know. 00:11:45.930 --> 00:11:46.610 Looks like it. 00:11:46.930 --> 00:11:49.270 I don't know if people use the feature, right? They might turn it off. 00:11:49.470 --> 00:11:54.390 So now a newer idea, which is sort of based on AssumeValid, 00:11:54.590 --> 00:11:58.060 is... James O'Beirne's assume UTXO. 00:11:58.240 --> 00:11:58.620 Yes. 00:11:58.880 --> 00:12:02.540 Right? So what is the difference? What is assume UTXO then? 00:12:02.800 --> 00:12:07.340 Well, here the UTXO set, as we've said a couple of times, is the collection of 00:12:07.340 --> 00:12:11.680 coins that exist right now. So every time you send somebody money, that creates a 00:12:11.680 --> 00:12:14.260 UTXO and it destroys the UTXO that you sent from. 00:12:14.480 --> 00:12:18.160 Yeah, it's the current state of balances is how I generally call it. 00:12:18.860 --> 00:12:20.360 Yeah. Although, yeah. 00:12:20.600 --> 00:12:24.440 Yeah, yeah. I know technically, I guess you object to the term balances. 00:12:25.110 --> 00:12:29.190 Well, because balance is something you can add and subtract to, but these UTXOs 00:12:29.190 --> 00:12:31.630 are destroyed all the time. So it's like you have a bank account and the bank 00:12:31.630 --> 00:12:32.950 account is destroyed when you use it. 00:12:33.150 --> 00:12:33.290 Sure. 00:12:33.530 --> 00:12:39.380 But in general, the idea is that every time... The only way you can reconstruct 00:12:39.380 --> 00:12:43.500 the UTXO set, so the only way you can find out which coins exist right now, is to 00:12:43.500 --> 00:12:48.440 replay... everything from scratch. So you have to take the first block, see which 00:12:48.440 --> 00:12:52.280 coins it creates, which coins it destroys, then the second block, see which coins 00:12:52.280 --> 00:12:54.980 it destroys, which coins it creates, et cetera, et cetera, et cetera, et cetera. 00:12:55.040 --> 00:12:59.830 And that takes a long time and you can only do it sequentially. You have to start 00:12:59.830 --> 00:13:02.030 at the beginning, you have to go to the end. You cannot do it in parallel. 00:13:02.920 --> 00:13:06.680 Because you don't know if block 100,000, you don't know if it's valid because you 00:13:06.680 --> 00:13:11.320 need to know what coins existed at one block before it. So this is annoying 00:13:11.320 --> 00:13:15.180 because it takes a long ass time to sync the whole blockchain. So what Assume 00:13:15.180 --> 00:13:21.060 UTXO does is it takes a snapshot of this UTXO set at a certain height, maybe just 00:13:21.060 --> 00:13:26.920 before the release or a bit older. And then when your node starts, it 00:13:26.920 --> 00:13:31.760 starts from that point. So it skips, initially skips the whole history. It starts 00:13:31.760 --> 00:13:35.240 from this snapshot and then it just checks the next block and the next block and 00:13:35.240 --> 00:13:38.260 the next block and the next block until it reaches the tip, the most recent 00:13:38.260 --> 00:13:43.900 block. So then you know exactly your balances and you can start using it. But in 00:13:43.900 --> 00:13:48.240 the meantime, in the background, it starts at the Genesis block, goes all the way 00:13:48.240 --> 00:13:51.870 to the snapshot. and make sure that the snapshot is correct. And if the snapshot 00:13:51.870 --> 00:13:53.190 is not correct, it starts screaming. 00:13:53.610 --> 00:13:58.270 Right. I'm assuming it still does the header first syncing, right? Like first it 00:13:58.270 --> 00:14:00.410 checks out which chain is the longest one. 00:14:00.830 --> 00:14:04.770 In fact, it has to, because in order to load the snapshot, it must already have 00:14:04.770 --> 00:14:08.950 the headers at that point. So it has to have the headers up into the snapshot 00:14:08.950 --> 00:14:10.970 before it can even load the snapshot. 00:14:11.270 --> 00:14:16.760 Right. And then with assume valid, it still did all of the... UTXO set 00:14:16.760 --> 00:14:21.760 constructing. It still replayed all of the transactions. It just didn't check for 00:14:21.760 --> 00:14:26.420 the signatures. It just skipped the signature validation. And now with assume 00:14:26.420 --> 00:14:30.920 UTXO, at least initially, it skips all of it. It skips 00:14:32.070 --> 00:14:36.830 the transaction replaying as well as obviously then also the signature checking. 00:14:37.230 --> 00:14:37.310 Yeah. 00:14:37.470 --> 00:14:41.450 So it just takes the UTXO set and from there on out constructs the blockchain 00:14:41.450 --> 00:14:44.070 based on the newer blocks that have been found since then. 00:14:44.250 --> 00:14:49.610 Exactly. And so you're back to where everything started as soon as that backlog 00:14:49.610 --> 00:14:52.910 checking has been done. Then you're basically the same trust as you are now. 00:14:53.250 --> 00:14:56.550 However, you know, you could argue and, you know, this gets into trade-offs. 00:14:56.710 --> 00:15:00.390 Like, do you really want to check all the history? Because there are a lot of 00:15:00.390 --> 00:15:03.890 things you can know without checking history. So there's no plan right now to not 00:15:03.890 --> 00:15:06.070 check history because that's still a bit controversial. 00:15:06.430 --> 00:15:09.230 Yeah, you mean check history after... 00:15:09.230 --> 00:15:10.010 Before the snapshot. 00:15:10.390 --> 00:15:15.130 Yes, you basically check the snapshot. Then you check what has happened since the 00:15:15.130 --> 00:15:20.310 snapshot. And once you've constructed the current version of the UTXO set and the 00:15:20.310 --> 00:15:25.270 current version of the blockchain, then you go back to block number one. and 00:15:25.270 --> 00:15:29.650 start to check if your assumption of the UTXO set was actually correct. 00:15:29.890 --> 00:15:33.810 That's right. And so the question is, could you eventually in the future opt out 00:15:33.810 --> 00:15:39.250 of doing that? And what are you sacrificing when you do that? Right. Well, some 00:15:39.250 --> 00:15:44.660 things you're not sacrificing. So the nice thing is, if you start at the 00:15:44.660 --> 00:15:50.250 snapshot, and you create a new address, and you receive coins on it, and they get 00:15:50.250 --> 00:15:55.310 into a block, then you kind of know that block is valid, at least unless there's 00:15:55.310 --> 00:15:59.750 another chain out there. Because otherwise, like a lot of miners are wasting a 00:15:59.750 --> 00:16:01.890 lot of proof of work on a chain that's not valid. 00:16:02.330 --> 00:16:02.810 Sure. 00:16:03.130 --> 00:16:03.310 Which could be true. 00:16:03.510 --> 00:16:07.810 Which could be true, yes. Which is a trade-off. You're trusting that miners are 00:16:07.810 --> 00:16:12.110 being honest there. You're trusting that they're not burning resources just to 00:16:12.110 --> 00:16:12.650 screw with you. 00:16:13.330 --> 00:16:18.410 Not screw with you, screw with everyone. But there could be some conspiracy where 00:16:18.410 --> 00:16:24.030 the snapshot is fake. and the core developers and the miners 00:16:24.030 --> 00:16:28.350 collude and create a fake snapshot that has a couple of extra coins in it, that 00:16:28.350 --> 00:16:32.030 all the miners agree that they will approve blocks with that coin in it. So you 00:16:32.030 --> 00:16:36.110 could sneak in a hard fork. That's kind of the scary thing about it. Which is 00:16:36.110 --> 00:16:39.590 why, again, you need people to check whether the snapshot is real. You can either 00:16:39.590 --> 00:16:44.630 do it yourself with this back validation, or you can go in, 00:16:44.920 --> 00:16:50.340 or you can rely... on the fact that other people are looking at the source code 00:16:50.340 --> 00:16:53.900 and see this one particular line, which if it contains something ridiculous, 00:16:54.220 --> 00:16:59.900 there's a problem. And again, the same story with the headers that still need to 00:16:59.900 --> 00:17:04.190 match. So somebody would have to spend a whole lot of proof of work. and sneak 00:17:04.190 --> 00:17:05.330 that fake snapshot in. 00:17:05.730 --> 00:17:08.610 Right, so this is not included in Bitcoin Core right now. 00:17:08.790 --> 00:17:12.990 No, in fact, all of this is quite new. So I think the current version of Bitcoin 00:17:12.990 --> 00:17:16.210 Core has a way to create a snapshot, but there's nothing you can do with that 00:17:16.210 --> 00:17:19.850 snapshot. And then not the version that's coming out now, but the version that 00:17:19.850 --> 00:17:25.310 might come out early next year should have a way to, probably will have a way to 00:17:25.310 --> 00:17:25.990 load a snapshot. 00:17:26.250 --> 00:17:27.810 What does load a snapshot mean? 00:17:28.010 --> 00:17:33.230 So this UTXO snapshot, the set of coins is a couple gigabytes. And the only way 00:17:33.230 --> 00:17:35.010 you can get it is to download it from someone. 00:17:35.210 --> 00:17:35.530 Right. 00:17:36.110 --> 00:17:39.750 It's not included in the source code and there's no way to serve it over the peer 00:17:39.750 --> 00:17:40.530 -to-peer network yet. 00:17:40.950 --> 00:17:45.150 Right. The only thing that's included in the source code would be the hash of the 00:17:45.150 --> 00:17:48.170 UTXO set, not the UTXO set itself because it's too big. 00:17:48.330 --> 00:17:51.850 Right. And so initially, maybe that UTXO set is just a torrent that people can 00:17:51.850 --> 00:17:56.030 host. It's very easy to check a torrent because it also has a hash. Or one use 00:17:56.030 --> 00:17:59.650 case for that could be, say, if you're running a BTCPay Server, if you're 00:17:59.650 --> 00:18:04.220 spinning that up for the first time, it's really, really time consuming to have 00:18:04.220 --> 00:18:05.720 to download the entire blockchain. 00:18:06.960 --> 00:18:11.150 But then you probably want to skip validation of the older stuff. Because if 00:18:11.150 --> 00:18:13.830 you're running that server, you know, you're probably also running a node 00:18:13.830 --> 00:18:17.190 somewhere else. So you can still compare that you're actually looking at the same 00:18:17.190 --> 00:18:21.810 chain. So that could be a good use case for it. And then it's nice that the 00:18:21.810 --> 00:18:25.790 BTCPay Server thing just downloads a three gigabyte file and then starts syncing 00:18:25.790 --> 00:18:29.310 from there. Saves you like two weeks. Because all these web servers, they're 00:18:29.310 --> 00:18:30.430 incredibly slow. 00:18:31.120 --> 00:18:35.660 Right. So right now, Bitcoin Core can make a snapshot of a UTXO set, but it 00:18:35.660 --> 00:18:40.020 doesn't actually do anything with it. Then in an upcoming release, it's going to 00:18:40.020 --> 00:18:43.790 be able to download a UTXO set? 00:18:43.930 --> 00:18:47.250 No, it's going to be able to load a UTXO set that you downloaded. 00:18:47.730 --> 00:18:48.170 Right. 00:18:48.860 --> 00:18:49.460 Somewhere. 00:18:49.800 --> 00:18:55.140 Okay. And then maybe in the future version after that, then it's going to sort of 00:18:55.140 --> 00:19:00.500 complete the package and you might have something called assume UTXO in Bitcoin Core. 00:19:00.720 --> 00:19:06.680 One way such a future could look is the nodes. Every node that wants to 00:19:06.680 --> 00:19:11.560 would serve this snapshot. Probably not automatically because it's pretty big. 00:19:11.720 --> 00:19:15.420 It's like a couple gigabytes. But any node that wants to can serve the snapshot, 00:19:15.700 --> 00:19:19.140 and then there's a peer-to-peer protocol to download the snapshot automatically. 00:19:19.200 --> 00:19:23.340 And so when you start a new node, it would automatically find the snapshot, use 00:19:23.340 --> 00:19:28.060 the snapshot, sync to the tip, show you some orange blinking thing, probably, and 00:19:28.060 --> 00:19:32.220 then sync from the start to the snapshot, and then show you a nice green blinking thing. 00:19:35.690 --> 00:19:41.090 Is this controversial at all? The fact that there are some trade-offs there, some 00:19:41.090 --> 00:19:45.510 security trade-offs, even though they're small and temporary, they're there. Do 00:19:45.510 --> 00:19:47.190 you think this is controversial at all? 00:19:47.350 --> 00:19:50.970 I don't know. I mean, usually with these kind of features, first of all, it's 00:19:50.970 --> 00:19:55.990 experimental. So that means you probably need to do something to turn it on. My 00:19:55.990 --> 00:20:01.810 guess is once it's done to the point that I just described, it's probably still 00:20:01.810 --> 00:20:07.180 going to be off the first time. And then if people start objecting to it or not, 00:20:07.360 --> 00:20:10.760 that's sort of the thing you need to see. I mean, something is controversial when 00:20:10.760 --> 00:20:12.140 people decide it's controversial. 00:20:13.220 --> 00:20:15.620 Yeah, but that hasn't been decided yet then. 00:20:16.080 --> 00:20:20.480 Not that I know, but there's only a handful of people who actually grasp this 00:20:20.480 --> 00:20:25.810 feature. So it might be a bit early. In the longer run, something that's been an 00:20:25.810 --> 00:20:30.270 ongoing discussion for ages is the idea of committing to the UTXO set inside the 00:20:30.270 --> 00:20:30.970 blockchain itself. 00:20:32.600 --> 00:20:33.560 UTXO commitments. 00:20:33.820 --> 00:20:34.640 I've heard of that. 00:20:34.940 --> 00:20:39.280 That certainly is controversial. I don't know if anybody is opposed to it in 00:20:39.280 --> 00:20:43.550 principle, but it's certainly controversial depending on how you do it. Because 00:20:43.550 --> 00:20:47.050 what you want to prevent is sort of the scenarios we discussed before, right? The 00:20:47.050 --> 00:20:52.230 scenario where the blockchain is too big to check for everybody and then a bunch 00:20:52.230 --> 00:20:56.670 of miners and developers decide to give themselves some coins and they get away 00:20:56.670 --> 00:21:01.830 with it because not enough people... verify the entire history. So that's a risky 00:21:01.830 --> 00:21:03.070 part of it. 00:21:03.650 --> 00:21:09.220 How would that work with embedding? Sorry, it's embedding the UTXO set into the blocks? 00:21:09.420 --> 00:21:11.480 You're not embedding it, you're embedding a hash into the block. 00:21:11.520 --> 00:21:11.700 Sure, 00:21:11.600 --> 00:21:11.780 So 00:21:11.700 --> 00:21:11.900 yeah. 00:21:11.780 --> 00:21:15.780 every block would contain, I guess in the Coinbase transaction, a hash of the 00:21:15.780 --> 00:21:18.760 UTXO set or some other derived thing of the UTXO set. 00:21:20.380 --> 00:21:21.640 What's the benefit of that? 00:21:22.460 --> 00:21:27.000 Well then... Instead of relying on what's in the source code, this hash, you 00:21:27.000 --> 00:21:28.900 would rely on what's in the blockchain, this hash. 00:21:30.300 --> 00:21:34.840 I guess you make it part of consensus and a block is not valid if the hash is not 00:21:34.840 --> 00:21:39.580 valid. So you would reject blocks that have an invalid hash rather than reject 00:21:39.580 --> 00:21:40.900 code that looks fishy. 00:21:42.160 --> 00:21:46.820 I think it's a different thing. But there are very different ways that you can 00:21:46.820 --> 00:21:51.300 put stuff in a block. It could be as straightforward as a hash. but it could also 00:21:51.300 --> 00:21:56.800 be something a little bit more indirect. Something that if you look at the block 00:21:56.800 --> 00:22:02.640 and you see this number, you do not know the UTXO set and you can't 00:22:02.640 --> 00:22:07.510 download the UTXO set using that information. But instead, you have to 00:22:07.510 --> 00:22:13.060 process the whole blockchain from the Genesis block to make sure that that thing 00:22:13.060 --> 00:22:16.140 in the blockchain is valid. But then the question is what its use is going to be. 00:22:16.380 --> 00:22:19.860 There's some tricky trade-offs there. You should ask Peter Todd at some point. 00:22:20.760 --> 00:22:22.460 because he's thought about that stuff a bit more 00:22:22.460 --> 00:22:24.500 At some point I will. 00:22:24.500 --> 00:22:25.440 Yeah. 00:22:25.440 --> 00:22:27.840 All right, we've gone off the rails. 00:22:27.840 --> 00:22:28.620 Well, no, we... 00:22:28.620 --> 00:22:30.440 But I think we covered everything. Yeah, 00:22:30.440 --> 00:22:34.440 I mean in general it's you know one thing that people complain about when they 00:22:34.440 --> 00:22:37.060 hear about Bitcoin Core it's like, oh my god I need to download the whole 00:22:37.060 --> 00:22:42.350 blockchain. And then you know you get this trade-off: do you want people to just 00:22:42.350 --> 00:22:45.290 put up with that? Do you want to make it slightly less annoying? 00:22:45.290 --> 00:22:47.470 Yes, at a trade-off. 00:22:47.470 --> 00:22:50.550 Yeah. And then the smallest possible trade-off. 00:22:52.110 --> 00:22:57.240 So I think this is a very interesting project, so I'm happy to test it. That's 00:22:57.240 --> 00:22:57.860 usually what I do. 00:22:58.360 --> 00:22:58.720 Good. 00:22:58.880 --> 00:23:01.720 Test it, try to break something, and then complain on GitHub. 00:23:03.030 --> 00:23:05.830 All right. Well, I have nothing else to ask. 00:23:06.010 --> 00:23:09.090 All righty. In that case, thank you for listening to the Van Wirdum Sjorsnado. 00:23:09.590 --> 00:23:10.070 There you go.