WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:19.410 --> 00:00:21.430 Live from Utrecht, this is Bitcoin. 00:00:22.030 --> 00:00:22.670 Explained. 00:00:23.030 --> 00:00:23.370 Hey, Sjors. 00:00:23.930 --> 00:00:29.210 Hey, so last time I read the sponsor and it was a complete disaster. So this time 00:00:29.210 --> 00:00:34.710 you're going to do it. As the song goes, Aaron reads ads, Aaron reads ads, Aaron 00:00:34.710 --> 00:00:36.210 reads ads. 00:00:36.550 --> 00:00:42.170 Nice. I forgot all about the jingle. You haven't read any... Toots. 00:00:43.010 --> 00:00:43.750 What's it called? 00:00:44.070 --> 00:00:44.510 Boosts. 00:00:44.550 --> 00:00:47.030 Boosts. You haven't read any Boosts for a while. What's going on with that? 00:00:47.030 --> 00:00:49.870 No, we might do it later again. Because we've got this hyper-commercialized 00:00:49.870 --> 00:00:51.910 entity now with sponsors and stuff. 00:00:52.190 --> 00:00:57.890 True, yeah. Sure. Do you know who our sponsor is? It's Coinkite. 00:00:58.990 --> 00:01:03.250 And they produce the COLDCARD. You know what I love about the COLDCARD, besides 00:01:03.250 --> 00:01:07.370 the fact that are— that they are our sponsor, Sjors? I love that they're Bitcoin 00:01:07.370 --> 00:01:11.230 only. I love that they're a hardware wallet. It's secure. It's for your Bitcoin. 00:01:11.230 --> 00:01:16.430 It's to store your Bitcoin on. How long is our read, Sjors? Did I get there yet? 00:01:16.430 --> 00:01:17.190 I think you're good. 00:01:17.190 --> 00:01:23.070 The COLDCARD is great. Get it. That's right. Sjors, today we're discussing 00:01:24.190 --> 00:01:29.770 a very niche bug that I had never heard of. But apparently there's a bug in the 00:01:29.770 --> 00:01:30.410 Bitcoin protocol. 00:01:31.750 --> 00:01:33.950 Well, there was a bug in the Bitcoin protocol. 00:01:35.560 --> 00:01:38.660 Right, but there's still a problem. 00:01:38.960 --> 00:01:42.580 There was a bug, then there was no bug, then there was a bug, then there was no 00:01:42.580 --> 00:01:44.700 bug. There's still a problem, but not a bug. 00:01:45.200 --> 00:01:49.300 Right, okay, I see. So there was a bug, now there's no bug, but there's still a 00:01:49.300 --> 00:01:50.700 problem, which is not a bug. 00:01:51.280 --> 00:01:55.300 Well... It's kind of a bug, but it's not like a dangerous bug like the original thing. 00:01:55.300 --> 00:01:58.240 Sounds pretty buggy. Anyway, so it's called the 00:01:58.240 --> 00:02:04.220 1,983,702 problem. 00:02:04.650 --> 00:02:10.530 Did I say it right even? The block 1,983,702 problem. 00:02:10.990 --> 00:02:14.250 Yeah, it sounds good. Or the block 1,983,702 problem. 00:02:14.490 --> 00:02:17.790 Right. So this will be a problem in… 00:02:18.330 --> 00:02:24.130 Yeah, there's another term you could use is the BIP… BIP 34 does not 00:02:24.130 --> 00:02:25.810 imply BIP 30 problem. 00:02:27.350 --> 00:02:30.070 I don't know which one is worse. They're both pretty bad. 00:02:30.370 --> 00:02:30.830 Okay, cool. 00:02:31.130 --> 00:02:35.330 So this will be a problem in block. Well, again, 00:02:35.490 --> 00:02:37.630 1,900,000 something. 00:02:38.270 --> 00:02:40.410 Yeah, which is like a couple decades from now. 00:02:40.770 --> 00:02:44.110 Yes, like 22 years from now, my sort of napkin math told me. 00:02:44.350 --> 00:02:47.870 And to be clear, it's a problem. It's not like bad. 00:02:48.710 --> 00:02:54.650 Right. Okay, but it is something that needs to be solved eventually in some 00:02:54.650 --> 00:02:55.110 way or another. 00:02:55.450 --> 00:03:00.930 It's better if we solve it. But it's not like the 2106 problem, which in the year 00:03:00.930 --> 00:03:04.550 2106, the whole blockchain simply stops. That's definitely a problem. 00:03:05.110 --> 00:03:08.290 Right. This is not a problem that's going to require a consensus change. 00:03:09.350 --> 00:03:10.570 No, ideally it would. 00:03:10.850 --> 00:03:11.630 Oh, okay. 00:03:11.630 --> 00:03:12.330 But not a hard fork. 00:03:12.630 --> 00:03:18.490 Right, okay. How did you find about... Like I said, I'd never heard of this. Is 00:03:18.490 --> 00:03:21.970 this just something you... This is your hobby. You look for very niche things 00:03:21.970 --> 00:03:23.210 that no one else has heard about. 00:03:23.430 --> 00:03:26.950 Well, we sometimes need to scrape the bottle of the barrel for episodes titles. 00:03:27.090 --> 00:03:32.730 But in this case, I was trying to understand a bug in Stratum V2, 00:03:32.950 --> 00:03:37.420 something I'm working on recently, and had something to do with the coinbase 00:03:37.420 --> 00:03:41.800 transactions and whether or not it has a witness. It turns out it does have a 00:03:41.800 --> 00:03:45.880 witness, or at least it can have a witness, which I didn't know, and that's why I 00:03:45.880 --> 00:03:49.500 kept banging my head against it. But as I was trying to understand how the code 00:03:49.500 --> 00:03:53.620 works, I was reading the code comments, and I came across this almost full-page 00:03:53.620 --> 00:03:56.420 story about this problem. 00:03:56.800 --> 00:04:01.940 Okay. I'm going to just call it the 1,900,000 problem because I don't want to 00:04:01.940 --> 00:04:02.560 read it. 00:04:03.660 --> 00:04:04.100 Sure. 00:04:04.280 --> 00:04:09.860 And it's in full every time. So the 1,900,000 problem, we'll start at the 00:04:09.860 --> 00:04:14.840 beginning. So you mentioned there was a bug. It all started with a bug, right? 00:04:15.200 --> 00:04:18.120 And this has been a bug in Bitcoin since the beginning? 00:04:18.780 --> 00:04:19.220 Yes. 00:04:19.300 --> 00:04:21.160 Like it's an OG Satoshi bug? 00:04:21.340 --> 00:04:26.910 Exactly, an OG Satoshi bug, which is that… it was possible for two 00:04:26.910 --> 00:04:31.310 identical transactions to exist, or more than one, basically, identical 00:04:31.310 --> 00:04:33.450 transactions to exist in sequence. 00:04:33.650 --> 00:04:35.010 It was or wasn't? 00:04:35.010 --> 00:04:35.790 It was possible. 00:04:35.930 --> 00:04:36.710 It was possible. 00:04:36.970 --> 00:04:42.890 And this was creating a problem because, well, when the transaction exists 00:04:42.890 --> 00:04:47.610 twice, then the original one essentially just disappears. 00:04:48.750 --> 00:04:50.530 This has to do with how transactions work. 00:04:50.770 --> 00:04:56.670 Yeah, let's halt here for a second. So how do you get two identical transactions? 00:04:56.790 --> 00:05:02.230 Same hash. So the same hash means it's the same content. So it's the same inputs, 00:05:02.410 --> 00:05:05.950 the same outputs. And so typically you would expect this in a coinbase 00:05:05.950 --> 00:05:09.450 transaction in the early days because a coinbase transaction doesn't have any 00:05:09.450 --> 00:05:12.830 inputs or maybe it is the name of your pool, which would be the same if you were 00:05:12.830 --> 00:05:16.420 mining multiple blocks. And then the outputs might be the address that you're 00:05:16.420 --> 00:05:20.360 paying yourself to, which might also be the same if you were pool. So if you 00:05:20.360 --> 00:05:25.140 mined in the early days two blocks to the same address and with the same pool 00:05:25.140 --> 00:05:29.470 name and you weren't like, I guess, yeah. 00:05:31.140 --> 00:05:35.840 Yeah, that makes sense. So you're a pool in the early days. You have your Bitcoin 00:05:35.840 --> 00:05:39.700 address, one blah, blah, blah, blah, blah, because that was the early addresses. 00:05:40.120 --> 00:05:45.000 And you're mining new coins, so there's no inputs. And you just did these new 50 00:05:45.000 --> 00:05:48.520 coins are sent to this one blah, blah, blah, blah address. And if that happens 00:05:48.520 --> 00:05:52.820 twice, if you say you mine two blocks in a row, it's going to be the exact same 00:05:52.820 --> 00:05:53.420 transaction. 00:05:53.870 --> 00:05:58.050 Yeah, however, it also would have to be the same amount, right? So this would be 00:05:58.050 --> 00:06:01.830 either a block with no transactions in it, so no fees. So the coinbase amount 00:06:01.830 --> 00:06:07.690 would be exactly 50 Bitcoin back in the day, or it would be coincidentally the 00:06:07.690 --> 00:06:09.130 exact same total fees. 00:06:09.570 --> 00:06:10.010 Right. 00:06:10.270 --> 00:06:12.590 I mean, the thing is, it only happened twice. 00:06:14.050 --> 00:06:17.370 Well, especially in the early days, there was still a lot of transactions that 00:06:17.370 --> 00:06:20.290 didn't pay any fee, I guess. Or there was a fixed fee for a while. 00:06:20.410 --> 00:06:23.530 Probably a fixed fee. So then maybe if you had, I don't know, I didn't look at 00:06:23.530 --> 00:06:24.290 those specific blocks. 00:06:24.750 --> 00:06:30.500 Right. Anyways, that is the most… likely reason why that would happen. 00:06:30.740 --> 00:06:34.620 Is it plausible that it could happen in any other circumstance to identical 00:06:34.620 --> 00:06:35.140 transactions? 00:06:36.640 --> 00:06:40.980 Well, it could happen as a child of the coinbase. So if the coinbase transactions 00:06:40.980 --> 00:06:46.180 are identical, then you could make another transaction. Basically, you could just 00:06:46.180 --> 00:06:50.220 replay another transaction from the past that spends that coinbase transaction. 00:06:50.360 --> 00:06:54.640 So the whole history of that coinbase could be repeated. So if somebody mines a 00:06:54.640 --> 00:06:58.700 block and then they send it to the Pirate Bay and they download a movie, you 00:06:58.700 --> 00:07:00.460 could redo all that history. 00:07:00.860 --> 00:07:05.020 Yeah, it would just have to start from the same coinbase transaction. That's the 00:07:05.020 --> 00:07:07.760 only way you can get more identical transactions. 00:07:07.880 --> 00:07:08.160 Exactly. 00:07:08.300 --> 00:07:09.100 If you start from there, yeah. 00:07:09.300 --> 00:07:10.780 Or if you break SHA-256. 00:07:12.040 --> 00:07:16.060 Which is also an episode we recorded at some point, I think. 00:07:17.100 --> 00:07:21.280 I don't think anybody broke SHA-256, but we did talk about hashes in general. 00:07:21.340 --> 00:07:26.060 We talked about what it means to break it, I think. Anyways, I'm going on a 00:07:26.060 --> 00:07:31.980 tangent here. Okay, so that's how you can get identical transaction IDs. 00:07:32.360 --> 00:07:32.540 Yeah. 00:07:33.000 --> 00:07:37.460 And so you said it's possible. So why is it a bug if it's possible? Because I 00:07:37.460 --> 00:07:42.220 thought you were going to say it's impossible, but you said it's possible. Why is 00:07:42.220 --> 00:07:42.740 it a bug then? 00:07:42.920 --> 00:07:48.280 It was possible, to be exact. But the bug is that it creates problems for you, 00:07:48.400 --> 00:07:51.160 especially for you as the recipient of that transaction. 00:07:51.900 --> 00:07:53.500 Right, so the miner in this case? 00:07:53.740 --> 00:07:58.980 Yeah, so the miner mined, say, 50 Bitcoin and doesn't spend it. And then a week 00:07:58.980 --> 00:08:04.640 later, he mines 50 Bitcoin and also doesn't spend it. Now he's like, oh, I've got 00:08:04.640 --> 00:08:08.640 100 Bitcoins. How am I going to spend this? Oh, I'm going to make a transaction. 00:08:09.020 --> 00:08:14.100 And this transaction points to a previous transaction. That's what transactions 00:08:14.100 --> 00:08:19.720 do. So you would point to the original coinbase transaction by its hash and then 00:08:19.720 --> 00:08:24.780 also by the position of the output in the coinbase transaction. But then the 00:08:24.780 --> 00:08:28.520 question is, which one do you mean? And the Bitcoin Core software would simply 00:08:28.520 --> 00:08:34.520 look at the most recent one and would spend that. And there's only one 00:08:34.520 --> 00:08:36.040 entry, so it would just be overwritten. 00:08:37.290 --> 00:08:39.930 So the original coins would be gone. 00:08:42.310 --> 00:08:45.950 Okay, you have to explain this, I think. Why would the original... So you say 00:08:45.950 --> 00:08:50.650 Bitcoin Core would just take the most recent one. So why wouldn't the older one 00:08:50.650 --> 00:08:53.150 just also still exist for next time you want to spend? 00:08:53.350 --> 00:08:58.550 Well, so Bitcoin Core keeps track of a list of outputs that exist. Basically, the 00:08:58.550 --> 00:09:03.780 transaction hash and the identifier. So if you add another one that is the same, 00:09:04.020 --> 00:09:05.120 it would just overwrite it. 00:09:05.540 --> 00:09:08.240 Oh, sorry. Do you just mean the UTXO set here? 00:09:08.820 --> 00:09:12.400 Yeah, although I think at the time the UTXO set worked a little different than it 00:09:12.400 --> 00:09:16.140 does now. But I think essentially it was the same thing. It's just a list of 00:09:16.140 --> 00:09:19.360 coins that exist. So it's a transaction hash and an identifier and whatever 00:09:19.360 --> 00:09:23.810 script you need to spend it. And so if you were to create the transaction again, 00:09:23.990 --> 00:09:28.250 that would just be the same entry in the database. So the database would think 00:09:28.250 --> 00:09:28.870 there's only one. 00:09:29.090 --> 00:09:33.830 Okay, so not both transactions would be included in this database. It would just 00:09:33.830 --> 00:09:37.690 be considered as the same transaction, so there's only one. 00:09:38.010 --> 00:09:39.570 So then if you spend it, 00:09:39.710 --> 00:09:41.490 both are gone because they overlap. 00:09:41.490 --> 00:09:45.910 Because you deleted one entry. So this can lead to quite strange situations. For 00:09:45.910 --> 00:09:51.490 example, let's say you mine a transaction. You mine a transaction once, and then 00:09:51.490 --> 00:09:56.990 a couple blocks later, you mine it again. And then you spend it. 00:09:57.450 --> 00:10:00.010 And so then it disappeared, right? 00:10:01.490 --> 00:10:05.670 That's one way. But let's say you mine one transaction. Sorry, yeah, let's do it 00:10:05.670 --> 00:10:08.690 again. You mine one transaction, you mine a couple other blocks, and then you 00:10:08.690 --> 00:10:10.470 mine the transaction again. 00:10:11.680 --> 00:10:17.220 Now, if there's a reorg... The blockchain 00:10:17.220 --> 00:10:22.760 undoes your most recent block and then creates some other blocks. 00:10:23.240 --> 00:10:29.420 That means that your transaction has now disappeared from your point of view. 00:10:29.680 --> 00:10:35.430 Yeah, yeah, yeah. Okay, I get it. So, oh yeah. So, yeah. Let me try to re-explain 00:10:35.430 --> 00:10:38.630 that, even though it was kind of clear to me, but maybe if I re-explain, that 00:10:38.630 --> 00:10:43.030 might help one other person out there. So yeah, you're creating a blockchain, 00:10:43.430 --> 00:10:47.450 obviously, and then the first coinbase transaction is included in block three, 00:10:47.610 --> 00:10:52.490 and then the next one is included in block seven. But then there's another block 00:10:52.490 --> 00:10:56.990 seven, and that's the blockchain that the network goes with. That becomes the 00:10:56.990 --> 00:10:58.990 longest chain. So now... 00:11:00.550 --> 00:11:05.430 your second coinbase transaction is deleted from your UTXO set, basically, or 00:11:05.430 --> 00:11:09.730 this database. And it's not like the one before that is not automatically 00:11:09.730 --> 00:11:11.770 restored either. So now you lost both. 00:11:12.050 --> 00:11:16.830 Yeah, you lost both. However, somebody else who just starts up a new blockchain, 00:11:17.050 --> 00:11:20.690 a Bitcoin blockchain, will never see the original second block. So they will only 00:11:20.690 --> 00:11:24.510 see the first block in which you do get the coinbase. And as far as they're 00:11:24.510 --> 00:11:27.750 concerned, it's still there. So now you have a consensus failure. 00:11:28.010 --> 00:11:28.130 Right. 00:11:28.390 --> 00:11:30.870 Because part of the network believes that a coin exists and the other does not, 00:11:30.910 --> 00:11:33.390 and that will explode as soon as somebody tries to spend it. 00:11:33.630 --> 00:11:37.950 Yeah, or to put it a little bit more accurately, maybe. I mean, I think you're 00:11:37.950 --> 00:11:41.850 saying it technically accurately, but the more normie way of saying it is there's 00:11:41.850 --> 00:11:43.790 no consensus on who owns which coins. 00:11:44.310 --> 00:11:47.950 Well, yeah, there's no consensus on who owns that, on whether that specific coin 00:11:47.950 --> 00:11:48.510 exists. 00:11:48.770 --> 00:11:51.710 Well, that's a technical way of saying it, right? 00:11:51.890 --> 00:11:55.580 Well, it's not about who owns it. It's that it exists or not. So you can't spend 00:11:55.580 --> 00:11:59.850 a coin that doesn't exist. It's not about not satisfying the script, but it's 00:11:59.850 --> 00:12:01.470 just about the coin not existing. 00:12:01.570 --> 00:12:05.370 Yeah, you're right, actually. In the reorg case, some nodes would actually think 00:12:05.370 --> 00:12:08.870 the coins don't exist at all anymore because, yes, I see what you're saying. 00:12:09.210 --> 00:12:14.170 Yeah, you're right. Anyways, the important part is that the UTXO set... 00:12:14.170 --> 00:12:19.110 Sorry, why do you not call it the UTXO set? Did you say you back in the day... 00:12:19.110 --> 00:12:24.390 This is the part I'm a little vague on, but initially the concept that we call 00:12:24.390 --> 00:12:29.810 the UTXO set... So a list of coins that exist is not something that Satoshi 00:12:29.810 --> 00:12:34.530 invented as such. I think we'll cover that again maybe in a future episode. But 00:12:34.530 --> 00:12:40.320 this idea of having a database of which coin exists and you just add and remove 00:12:40.320 --> 00:12:45.180 coins from it, I think at the time it was not like that. It was just a list of 00:12:45.180 --> 00:12:49.660 all transactions that were still relevant or something like that. It was less 00:12:49.660 --> 00:12:53.200 efficient. So I think in 2018 or 2017 it was... 00:12:54.710 --> 00:13:00.610 refactored into what we would now consider the UTXO set. But this less efficient 00:13:00.610 --> 00:13:04.530 implementation had the same problem. The modern UTXO set would definitely have 00:13:04.530 --> 00:13:09.010 this problem. My understanding is the original one had too, even though it stored 00:13:09.010 --> 00:13:10.210 more data than we do now. 00:13:10.470 --> 00:13:15.770 Anyways, the key point here being that the ownership records that every node 00:13:15.770 --> 00:13:20.890 holds would start to diverge. And if that starts to happen, that is a consensus 00:13:20.890 --> 00:13:24.790 failure, that you could get to a place where you try spending coins and it 00:13:24.790 --> 00:13:28.050 confirms on your end and it doesn't confirm on the other end and networks start 00:13:28.050 --> 00:13:34.030 to... It's chaos. So that was a potential actual risk 00:13:34.030 --> 00:13:35.730 with this OG Satoshi bug. 00:13:35.970 --> 00:13:40.530 Yeah, and as far as I know, what did happen was there were two instances of these 00:13:40.530 --> 00:13:41.690 duplicate coinbases. 00:13:43.690 --> 00:13:49.130 Basically, miners losing 50 BTC, but I don't think there were cases of also 00:13:49.130 --> 00:13:53.110 reorgs on top of that that would have created this mess. But maybe there was and 00:13:53.110 --> 00:13:57.190 nobody noticed it. Because the mess would not have been... Well, I think we would 00:13:57.190 --> 00:13:58.110 have noticed it now, yeah. 00:13:58.310 --> 00:14:01.790 Probably, right? That would have been very unlucky as well. You've got to have an 00:14:01.790 --> 00:14:06.290 exact reorg exactly on that block where this exact block happened. 00:14:06.490 --> 00:14:09.870 Yeah, and because this... Well, as far as we can tell, it only happened twice. It 00:14:09.870 --> 00:14:12.890 might have happened more often in chains that never survived. 00:14:14.230 --> 00:14:16.170 Well, then we would have the problem, right? 00:14:17.310 --> 00:14:21.090 Well, maybe we are the surviving chain where that didn't happen, but there may 00:14:21.090 --> 00:14:23.670 have been other chains where it did happen and it didn't survive. 00:14:23.830 --> 00:14:27.030 Well, we would have probably heard it then at some point, don't you think? I 00:14:27.030 --> 00:14:29.870 would say so. Because then there would have been nodes with these different 00:14:29.870 --> 00:14:32.550 transaction records, UTXO set, whatever you want to call it. 00:14:32.570 --> 00:14:35.750 Yeah, but I mean, if this was long enough ago, maybe they just restarted the 00:14:35.750 --> 00:14:38.850 computer and just didn't care, but probably didn't happen. 00:14:38.990 --> 00:14:44.830 Fair. Alright, so this was the OG Satoshi bug. And 00:14:44.830 --> 00:14:46.550 this bug was fixed. 00:14:47.030 --> 00:14:50.530 Exactly. And this is where BIP 30 comes in. This was introduced in 2012. 00:14:52.690 --> 00:14:58.250 What BIP 30 does is very simple. It says there shall never be two transactions 00:14:58.250 --> 00:15:00.290 with the same hash at the same time. 00:15:01.260 --> 00:15:02.220 At the same time? 00:15:02.340 --> 00:15:06.740 At the same, as in, if you create a transaction right now, it's not allowed to 00:15:06.740 --> 00:15:08.520 already exist in the UTXO set. 00:15:08.760 --> 00:15:13.640 Okay, so it's just an invalid transaction. So if the same thing would happen, if 00:15:13.640 --> 00:15:17.800 the miner would create this coinbase transaction where he pays himself to the 00:15:17.800 --> 00:15:22.220 same address, the Bitcoin network nodes, my node, your node, would just say, this 00:15:22.220 --> 00:15:26.340 is not valid, you just wasted your energy, we're going to wait for a valid block. 00:15:26.460 --> 00:15:26.840 Exactly. 00:15:27.060 --> 00:15:27.260 Right. 00:15:28.880 --> 00:15:34.820 Let's say they do that, they make a coinbase, then they spend it, then they can 00:15:34.820 --> 00:15:37.960 make the same coinbase again. That's no problem. So BIP 30 does allow that. 00:15:38.240 --> 00:15:38.780 Right, okay. 00:15:40.760 --> 00:15:45.860 So that was great, and that worked. The only problem is that this 00:15:45.860 --> 00:15:50.540 rule is a bit difficult to check, because it means that whenever you get a new 00:15:50.540 --> 00:15:55.480 block, for every transaction in that block, you have to make sure that it doesn't 00:15:55.480 --> 00:15:59.950 already exist, the transaction itself. So right now, whenever you check a block, 00:16:00.190 --> 00:16:04.670 you go through every transaction and you check that all its inputs exist. So it's 00:16:04.670 --> 00:16:08.850 spending from something that exists. But you do not check if the transaction 00:16:08.850 --> 00:16:12.930 itself exists. Or at least, you know, you don't now because of what we'll 00:16:12.930 --> 00:16:16.790 discuss. But with BIP 30, you would have to do that. You'd have to do an extra 00:16:16.790 --> 00:16:20.610 check for every transaction. Like, hey, now that I've checked that all the inputs 00:16:20.610 --> 00:16:24.240 are valid, whatever, or whichever sequence we're going to do, does this 00:16:24.240 --> 00:16:25.060 transaction exist? 00:16:25.320 --> 00:16:30.960 Right. So that was the case in 2012 for a brief while, at least after BIP 30 00:16:30.960 --> 00:16:36.940 was deployed. And this sounds like it's an especially annoying or burdensome 00:16:36.520 --> 00:16:41.660 check because it's so unlikely that it's necessary, especially for all 00:16:41.660 --> 00:16:44.180 non-coinbase transactions. but just technically… 00:16:43.240 --> 00:16:47.740 Yeah, it's completely unnecessary in the sense that no miner would be this 00:16:47.740 --> 00:16:50.520 stupid. But of course, if you don't check, then they would be. 00:16:50.580 --> 00:16:52.860 You have to check. But it's burdensome. 00:16:52.580 --> 00:16:57.660 But it weighs some resources. I don't know how much, if it's like 1% or 10%, but 00:16:57.660 --> 00:16:58.740 it's annoying. 00:16:59.950 --> 00:17:05.120 Yeah, and also just in general, you want miners to be able to check validity of 00:17:05.120 --> 00:17:10.020 new blocks or all nodes. You want them to be able to check validity as soon as possible. 00:17:10.300 --> 00:17:14.400 Yeah, so every second you can shave off the checking time is better. So BIP 34 00:17:14.400 --> 00:17:17.660 was introduced, which made this process more efficient. 00:17:17.900 --> 00:17:18.580 When was this? 00:17:18.740 --> 00:17:20.540 Same year, but just a half a year later. 00:17:21.240 --> 00:17:23.840 And was this introduced especially because... 00:17:25.090 --> 00:17:26.630 For the reason we just mentioned? 00:17:26.910 --> 00:17:27.270 Yes. 00:17:27.510 --> 00:17:29.630 Okay, so it was like a performance improvement. 00:17:29.810 --> 00:17:35.170 I think so. So the little background is that BIP 30 was a relatively simple 00:17:35.170 --> 00:17:38.350 soft fork that could be deployed very quickly because they realized the problem 00:17:38.350 --> 00:17:42.110 and they wanted to fix it as quickly as possible so nobody would deliberately 00:17:42.110 --> 00:17:42.810 exploit it. 00:17:44.910 --> 00:17:48.970 BIP 34 was something that was deployed a bit more carefully, very much like the 00:17:48.970 --> 00:17:53.830 BIP 9 style soft fork. So there was some signaling involved. Block version number 00:17:53.830 --> 00:17:57.110 went up and you had like so many percent of the miners had to signal it, et 00:17:57.110 --> 00:18:00.630 cetera, et cetera. So BIP 34 was a more thorough solution, but it was also 00:18:00.630 --> 00:18:06.590 deployed more carefully. So what does BIP 34 do? Well, it makes sure that, 00:18:06.770 --> 00:18:10.650 well, that was the idea, that the coinbase transaction is unique by definition. 00:18:12.990 --> 00:18:17.630 by adding the block height to it. So every coinbase transaction must start with 00:18:17.630 --> 00:18:22.250 the block height. And because it must start with the block height, it's going to 00:18:22.250 --> 00:18:26.670 be different than previous transactions, which had a different block height, or 00:18:26.670 --> 00:18:29.610 previous coinbase transactions had a different block height, so you won't have 00:18:29.610 --> 00:18:33.230 the duplicates. That is to say, moving forward, you don't have the duplicates. 00:18:33.490 --> 00:18:38.590 Yeah. Okay. Yeah. This makes sense. This way, every coinbase necessarily is 00:18:38.590 --> 00:18:43.330 unique. Like every coinbase transaction necessarily is unique because it's in a 00:18:43.330 --> 00:18:47.330 new block that has new block height. And therefore, every transaction that comes 00:18:47.330 --> 00:18:51.230 from, that's spent from that coinbase is also unique. So now every transaction 00:18:51.230 --> 00:18:51.990 has to be unique. 00:18:52.190 --> 00:18:52.550 Yes. 00:18:52.670 --> 00:18:54.030 Right? Okay. Yeah. Makes sense. 00:18:54.510 --> 00:18:54.670 Yeah. 00:18:54.770 --> 00:18:56.990 Good solution. Sjors, I like it. Who came up with this? 00:18:58.220 --> 00:19:00.640 I think it was... I'm not sure. 00:19:02.040 --> 00:19:06.900 Well, whoever came up with it, congratulations. Thank you. However, I guess 00:19:06.900 --> 00:19:10.380 there's another problem you're going to mention about this solution or not. 00:19:10.480 --> 00:19:13.920 I think the original one was Pieter Wuille and the second one was Russell 00:19:13.920 --> 00:19:14.360 O’Connor. 00:19:15.220 --> 00:19:18.320 Right, okay. However, so I guess this is why we're making this episode. 00:19:18.340 --> 00:19:18.980 No, Gavin Andresen. 00:19:19.560 --> 00:19:20.460 Gavin Andresen. 00:19:21.890 --> 00:19:24.470 I could have guessed. Gavin, you messed up. 00:19:26.020 --> 00:19:29.880 Well, I don't know. I mean, it's just he's the author, so it doesn't mean that he came up with it. 00:19:29.880 --> 00:19:35.180 It was a joke, but maybe it's kind of a sensitive joke at this point in time. 00:19:35.920 --> 00:19:40.500 Sure, go on. Because there is a problem. It introduced a problem. 00:19:42.010 --> 00:19:47.290 Yes. Well, actually, it did not introduce a problem. So just having this rule... 00:19:47.720 --> 00:19:48.420 It's fine. 00:19:48.740 --> 00:19:49.140 Okay. 00:19:49.640 --> 00:19:49.980 However... 00:19:49.980 --> 00:19:50.940 Good job, Gavin. 00:19:52.120 --> 00:19:55.320 Exactly. So Gavin, whatever it was, he didn't do anything wrong. 00:19:55.540 --> 00:19:55.800 Okay. 00:19:56.020 --> 00:20:01.040 However, then in 2015, somebody tried to be smart and said, hey, we have this 00:20:01.040 --> 00:20:07.010 BIP 34, which means that we don't need to check for BIP 30 anymore. 00:20:07.010 --> 00:20:11.910 We can make it faster. So perhaps I said before in the episode, oh, this was the 00:20:11.910 --> 00:20:15.410 reason, the performance thing was the reason to introduce it. Maybe not. Maybe 00:20:15.410 --> 00:20:19.550 they did it because it was just a more elegant solution and it would prevent 00:20:19.550 --> 00:20:24.050 mistakes. But then a couple of years later, somebody realized, hey, we can 00:20:24.050 --> 00:20:29.780 actually make this faster by not checking BIP 30 anymore. Because we know 00:20:29.780 --> 00:20:31.540 that the blocks must be unique, right? 00:20:31.760 --> 00:20:35.680 Yeah, like I explained just now. I immediately got it. Why did it take these 00:20:35.680 --> 00:20:37.080 Bitcoin Core developers so long, Sjors? 00:20:37.280 --> 00:20:42.320 I don't know. So in 2015, that optimization was merged. 00:20:43.730 --> 00:20:49.650 And, well, then in 2018, so three years later, somebody 00:20:49.650 --> 00:20:54.260 realized, oh, oops, that doesn't actually work. 00:20:53.550 --> 00:20:57.110 Wait, wait, wait. Sorry, I lost the plot. Where are we now? What's the year? 00:20:57.330 --> 00:21:01.090 Well, the year of the fix is 2018, but I guess the year of the realization was 00:21:01.090 --> 00:21:01.930 late 2017. 00:21:03.070 --> 00:21:03.250 Okay. 00:21:03.670 --> 00:21:09.290 So somewhere, I think it was October 2017, but this wasn't documented, but 00:21:09.290 --> 00:21:15.210 it kind of follows. Somebody realized, oh, wait a minute. There are exceptions 00:21:15.210 --> 00:21:16.750 to this convenient rule. 00:21:18.380 --> 00:21:24.200 Remember that the rule of BIP 34 is that you put the height of the block at the 00:21:24.200 --> 00:21:28.540 beginning of the coinbase. So block number one would have height number one, et 00:21:28.540 --> 00:21:29.040 cetera, et cetera. 00:21:30.320 --> 00:21:35.720 But that rule only applies starting with block, I don't know, 200,000 something. 00:21:36.160 --> 00:21:38.360 It started being applied in 2012. 00:21:39.460 --> 00:21:44.240 Yeah, and it started being applied from height number 220,000 or something like that. 00:21:45.450 --> 00:21:48.750 And so from there on, this rule is correct. But the problem is, and that's what 00:21:48.750 --> 00:21:52.890 people realize, is that it doesn't apply earlier. The rule wasn't active earlier. 00:21:53.290 --> 00:21:57.490 So what is actually in those earlier coinbase transactions? Might there be 00:21:57.490 --> 00:22:01.390 numbers in those earlier coinbase transactions, numbers that could represent a 00:22:01.390 --> 00:22:07.210 block height? The answer is yes. There were numbers in there. All the coinbase 00:22:07.210 --> 00:22:10.270 transactions that had numbers in there that represented blocks that might occur 00:22:10.270 --> 00:22:10.710 in the future. 00:22:12.390 --> 00:22:17.310 Okay, I know what you're saying, but the word represent is confusing here. There 00:22:17.310 --> 00:22:21.270 were just numbers in there and they could be interpreted as blocks from the future. 00:22:21.610 --> 00:22:25.250 Yeah, either it was a very smart miner that saw that this problem was going to happen. 00:22:25.470 --> 00:22:31.130 Like let's say there could have been an early miner that for whatever reason put 00:22:31.130 --> 00:22:34.090 the number a million in the coinbase. 00:22:34.270 --> 00:22:40.010 Yeah, so as the episode suggests, some miner put the number 1,983,702 in the 00:22:40.010 --> 00:22:40.470 coinbase. 00:22:40.990 --> 00:22:41.390 Right. 00:22:41.750 --> 00:22:44.470 They didn't actually put that number in there. They were probably just writing 00:22:44.470 --> 00:22:48.670 their name, and the name, if you map it into how a computer reads it, might have 00:22:48.670 --> 00:22:49.590 looked like a big number. 00:22:50.740 --> 00:22:55.560 Right. Okay, so there was a block in, say, 2009 00:22:55.560 --> 00:22:59.740 that… start with the number 00:22:59.740 --> 00:23:05.460 1,900,000 something. So by the time we actually 00:23:05.460 --> 00:23:11.220 get to block number 1,900,000 and that number has to be put in the coinbase, 00:23:11.380 --> 00:23:15.840 there's a risk that it, well, it's a pretty, that's not gonna happen, right? 00:23:15.840 --> 00:23:20.620 Normally this would not happen, but in theory somebody could… put, would have to 00:23:20.620 --> 00:23:21.540 put the same number in it. 00:23:21.740 --> 00:23:22.180 Yes. 00:23:22.380 --> 00:23:26.860 And then could, if they wanted to, wouldn't happen accidentally, make the rest of 00:23:26.860 --> 00:23:29.440 the coinbase identical to that original transaction. 00:23:29.760 --> 00:23:34.760 Right. So, yeah. So it would just have to spend the same amount of, well, no, 00:23:34.900 --> 00:23:37.060 because there's 50 coins in the original coinbase. 00:23:37.080 --> 00:23:42.240 Much more. So Murch looked at this specific transaction and it turns out that 00:23:42.240 --> 00:23:46.520 that was a very lucky block. So not only did it get a 50 Bitcoin coinbase 00:23:47.320 --> 00:23:52.960 subsidy, which, you know, modern blocks don't get. It also got, I think, 50 or so 00:23:52.960 --> 00:23:55.060 BTC in fees. 00:23:55.420 --> 00:23:56.040 That's good. 00:23:56.280 --> 00:23:59.860 Yeah, so that's a very nice little block in the past. So if you wanted to 00:23:59.860 --> 00:24:05.780 reproduce this, your coinbase transaction would have to create about 107 Bitcoin. 00:24:06.120 --> 00:24:10.100 It would have to spend 107 Bitcoin. That is only allowed if there is 107 Bitcoin 00:24:10.100 --> 00:24:12.000 worth of fees in that block. 00:24:12.160 --> 00:24:12.400 Right. 00:24:12.600 --> 00:24:16.680 So that's never going to happen. Accidentally. The other thing that has to happen 00:24:16.680 --> 00:24:17.260 is... 00:24:17.260 --> 00:24:21.400 An attacker would have to actually probably pay these fees himself and then burn 00:24:21.400 --> 00:24:22.640 it in this block. 00:24:22.860 --> 00:24:26.520 Yes, because he cannot send it to some arbitrary destination. He has to reproduce 00:24:26.520 --> 00:24:31.180 the original coinbase transaction, which means that his 107 Bitcoin has to go to 00:24:31.180 --> 00:24:34.440 the original owner of that coinbase transaction. 00:24:34.660 --> 00:24:34.940 Right. 00:24:35.160 --> 00:24:40.720 And so maybe this miner, you know, was frozen and wakes up and decides that this 00:24:40.720 --> 00:24:44.280 is a fun joke because you can just get the 107 Bitcoin back after doing this. 00:24:46.540 --> 00:24:51.160 But the other problem is it would have to be a non-SegWit block because there was 00:24:51.160 --> 00:24:55.340 no SegWit back then and SegWit adds something to the coinbase. Well, you can't 00:24:55.340 --> 00:24:58.480 add that to the coinbase because then it would be a different block. So that 00:24:58.480 --> 00:25:02.420 means all the fees would have to be in non-SegWit transactions. There's all sorts 00:25:02.420 --> 00:25:03.520