Episode 87: The Block 1,983,702 Problem

Aaron van Wirdum Live from Utrecht, this is Bitcoin.

Sjors Provoost Explained.

Aaron van Wirdum Hey, Sjors.

Sjors Provoost Hey, so last time I read the sponsor and it was a complete disaster. So this time you're going to do it. As the song goes, Aaron reads ads, Aaron reads ads, Aaron reads ads.

Aaron van Wirdum Nice. I forgot all about the jingle. You haven't read any... Toots. What's it called?

Sjors Provoost Boosts.

Aaron van Wirdum Boosts. You haven't read any Boosts for a while. What's going on with that?

Sjors Provoost No, we might do it later again. Because we've got this hyper-commercialized entity now with sponsors and stuff.

Aaron van Wirdum True, yeah. Sure. Do you know who our sponsor is? It's Coinkite. And they produce the COLDCARD. You know what I love about the COLDCARD, besides the fact that are— that they are our sponsor, Sjors? I love that they're Bitcoin only. I love that they're a hardware wallet. It's secure. It's for your Bitcoin. It's to store your Bitcoin on. How long is our read, Sjors? Did I get there yet?

Sjors Provoost I think you're good.

Aaron van Wirdum The COLDCARD is great. Get it. That's right. Sjors, today we're discussing a very niche bug that I had never heard of. But apparently there's a bug in the Bitcoin protocol.

Sjors Provoost Well, there was a bug in the Bitcoin protocol.

Aaron van Wirdum Right, but there's still a problem.

Sjors Provoost There was a bug, then there was no bug, then there was a bug, then there was no bug. There's still a problem, but not a bug.

Aaron van Wirdum Right, okay, I see. So there was a bug, now there's no bug, but there's still a problem, which is not a bug.

Sjors Provoost Well... It's kind of a bug, but it's not like a dangerous bug like the original thing.

Aaron van Wirdum Sounds pretty buggy. Anyway, so it's called the 1,983,702 problem. Did I say it right even? The block 1,983,702 problem.

Sjors Provoost Yeah, it sounds good. Or the block 1,983,702 problem.

Aaron van Wirdum Right. So this will be a problem in…

Sjors Provoost Yeah, there's another term you could use is the BIP… BIP 34 does not imply BIP 30 problem.

Aaron van Wirdum I don't know which one is worse. They're both pretty bad.

Sjors Provoost Okay, cool.

Aaron van Wirdum So this will be a problem in block. Well, again, 1,900,000 something.

Sjors Provoost Yeah, which is like a couple decades from now.

Aaron van Wirdum Yes, like 22 years from now, my sort of napkin math told me.

Sjors Provoost And to be clear, it's a problem. It's not like bad.

Aaron van Wirdum Right. Okay, but it is something that needs to be solved eventually in some way or another.

Sjors Provoost It's better if we solve it. But it's not like the 2106 problem, which in the year 2106, the whole blockchain simply stops. That's definitely a problem.

Aaron van Wirdum Right. This is not a problem that's going to require a consensus change.

Sjors Provoost No, ideally it would.

Aaron van Wirdum Oh, okay.

Sjors Provoost But not a hard fork.

Aaron van Wirdum Right, okay. How did you find about... Like I said, I'd never heard of this. Is this just something you... This is your hobby. You look for very niche things that no one else has heard about.

Sjors Provoost Well, we sometimes need to scrape the bottle of the barrel for episodes titles. But in this case, I was trying to understand a bug in Stratum V2, something I'm working on recently, and had something to do with the coinbase transactions and whether or not it has a witness. It turns out it does have a witness, or at least it can have a witness, which I didn't know, and that's why I kept banging my head against it. But as I was trying to understand how the code works, I was reading the code comments, and I came across this almost full-page story about this problem.

Aaron van Wirdum Okay. I'm going to just call it the 1,900,000 problem because I don't want to read it.

Sjors Provoost Sure.

Aaron van Wirdum And it's in full every time. So the 1,900,000 problem, we'll start at the beginning. So you mentioned there was a bug. It all started with a bug, right? And this has been a bug in Bitcoin since the beginning?

Sjors Provoost Yes.

Aaron van Wirdum Like it's an OG Satoshi bug?

Sjors Provoost Exactly, an OG Satoshi bug, which is that… it was possible for two identical transactions to exist, or more than one, basically, identical transactions to exist in sequence.

Aaron van Wirdum It was or wasn't?

Sjors Provoost It was possible.

Aaron van Wirdum It was possible.

Sjors Provoost And this was creating a problem because, well, when the transaction exists twice, then the original one essentially just disappears. This has to do with how transactions work.

Aaron van Wirdum Yeah, let's halt here for a second. So how do you get two identical transactions?

Sjors Provoost Same hash. So the same hash means it's the same content. So it's the same inputs, the same outputs. And so typically you would expect this in a coinbase transaction in the early days because a coinbase transaction doesn't have any inputs or maybe it is the name of your pool, which would be the same if you were mining multiple blocks. And then the outputs might be the address that you're paying yourself to, which might also be the same if you were pool. So if you mined in the early days two blocks to the same address and with the same pool name and you weren't like, I guess, yeah.

Aaron van Wirdum Yeah, that makes sense. So you're a pool in the early days. You have your Bitcoin address, one blah, blah, blah, blah, blah, because that was the early addresses. And you're mining new coins, so there's no inputs. And you just did these new 50 coins are sent to this one blah, blah, blah, blah address. And if that happens twice, if you say you mine two blocks in a row, it's going to be the exact same transaction.

Sjors Provoost Yeah, however, it also would have to be the same amount, right? So this would be either a block with no transactions in it, so no fees. So the coinbase amount would be exactly 50 Bitcoin back in the day, or it would be coincidentally the exact same total fees.

Aaron van Wirdum Right.

Sjors Provoost I mean, the thing is, it only happened twice.

Aaron van Wirdum Well, especially in the early days, there was still a lot of transactions that didn't pay any fee, I guess. Or there was a fixed fee for a while.

Sjors Provoost Probably a fixed fee. So then maybe if you had, I don't know, I didn't look at those specific blocks.

Aaron van Wirdum Right. Anyways, that is the most… likely reason why that would happen. Is it plausible that it could happen in any other circumstance to identical transactions?

Sjors Provoost Well, it could happen as a child of the coinbase. So if the coinbase transactions are identical, then you could make another transaction. Basically, you could just replay another transaction from the past that spends that coinbase transaction. So the whole history of that coinbase could be repeated. So if somebody mines a block and then they send it to the Pirate Bay and they download a movie, you could redo all that history.

Aaron van Wirdum Yeah, it would just have to start from the same coinbase transaction. That's the only way you can get more identical transactions.

Sjors Provoost Exactly.

Aaron van Wirdum If you start from there, yeah.

Sjors Provoost Or if you break SHA-256.

Aaron van Wirdum Which is also an episode we recorded at some point, I think.

Sjors Provoost I don't think anybody broke SHA-256, but we did talk about hashes in general.

Aaron van Wirdum We talked about what it means to break it, I think. Anyways, I'm going on a tangent here. Okay, so that's how you can get identical transaction IDs.

Sjors Provoost Yeah.

Aaron van Wirdum And so you said it's possible. So why is it a bug if it's possible? Because I thought you were going to say it's impossible, but you said it's possible. Why is it a bug then?

Sjors Provoost It was possible, to be exact. But the bug is that it creates problems for you, especially for you as the recipient of that transaction.

Aaron van Wirdum Right, so the miner in this case?

Sjors Provoost Yeah, so the miner mined, say, 50 Bitcoin and doesn't spend it. And then a week later, he mines 50 Bitcoin and also doesn't spend it. Now he's like, oh, I've got 100 Bitcoins. How am I going to spend this? Oh, I'm going to make a transaction. And this transaction points to a previous transaction. That's what transactions do. So you would point to the original coinbase transaction by its hash and then also by the position of the output in the coinbase transaction. But then the question is, which one do you mean? And the Bitcoin Core software would simply look at the most recent one and would spend that. And there's only one entry, so it would just be overwritten. So the original coins would be gone.

Aaron van Wirdum Okay, you have to explain this, I think. Why would the original... So you say Bitcoin Core would just take the most recent one. So why wouldn't the older one just also still exist for next time you want to spend?

Sjors Provoost Well, so Bitcoin Core keeps track of a list of outputs that exist. Basically, the transaction hash and the identifier. So if you add another one that is the same, it would just overwrite it.

Aaron van Wirdum Oh, sorry. Do you just mean the UTXO set here?

Sjors Provoost Yeah, although I think at the time the UTXO set worked a little different than it does now. But I think essentially it was the same thing. It's just a list of coins that exist. So it's a transaction hash and an identifier and whatever script you need to spend it. And so if you were to create the transaction again, that would just be the same entry in the database. So the database would think there's only one.

Aaron van Wirdum Okay, so not both transactions would be included in this database. It would just be considered as the same transaction, so there's only one.

Sjors Provoost So then if you spend it,

Aaron van Wirdum both are gone because they overlap.

Sjors Provoost Because you deleted one entry. So this can lead to quite strange situations. For example, let's say you mine a transaction. You mine a transaction once, and then a couple blocks later, you mine it again. And then you spend it. And so then it disappeared, right? That's one way. But let's say you mine one transaction. Sorry, yeah, let's do it again. You mine one transaction, you mine a couple other blocks, and then you mine the transaction again. Now, if there's a reorg... The blockchain undoes your most recent block and then creates some other blocks. That means that your transaction has now disappeared from your point of view.

Aaron van Wirdum Yeah, yeah, yeah. Okay, I get it. So, oh yeah. So, yeah. Let me try to re-explain that, even though it was kind of clear to me, but maybe if I re-explain, that might help one other person out there. So yeah, you're creating a blockchain, obviously, and then the first coinbase transaction is included in block three, and then the next one is included in block seven. But then there's another block seven, and that's the blockchain that the network goes with. That becomes the longest chain. So now... your second coinbase transaction is deleted from your UTXO set, basically, or this database. And it's not like the one before that is not automatically restored either. So now you lost both.

Sjors Provoost Yeah, you lost both. However, somebody else who just starts up a new blockchain, a Bitcoin blockchain, will never see the original second block. So they will only see the first block in which you do get the coinbase. And as far as they're concerned, it's still there. So now you have a consensus failure.

Aaron van Wirdum Right.

Sjors Provoost Because part of the network believes that a coin exists and the other does not, and that will explode as soon as somebody tries to spend it.

Aaron van Wirdum Yeah, or to put it a little bit more accurately, maybe. I mean, I think you're saying it technically accurately, but the more normie way of saying it is there's no consensus on who owns which coins.

Sjors Provoost Well, yeah, there's no consensus on who owns that, on whether that specific coin exists.

Aaron van Wirdum Well, that's a technical way of saying it, right?

Sjors Provoost Well, it's not about who owns it. It's that it exists or not. So you can't spend a coin that doesn't exist. It's not about not satisfying the script, but it's just about the coin not existing.

Aaron van Wirdum Yeah, you're right, actually. In the reorg case, some nodes would actually think the coins don't exist at all anymore because, yes, I see what you're saying. Yeah, you're right. Anyways, the important part is that the UTXO set... Sorry, why do you not call it the UTXO set? Did you say you back in the day...

Sjors Provoost This is the part I'm a little vague on, but initially the concept that we call the UTXO set... So a list of coins that exist is not something that Satoshi invented as such. I think we'll cover that again maybe in a future episode. But this idea of having a database of which coin exists and you just add and remove coins from it, I think at the time it was not like that. It was just a list of all transactions that were still relevant or something like that. It was less efficient. So I think in 2018 or 2017 it was... refactored into what we would now consider the UTXO set. But this less efficient implementation had the same problem. The modern UTXO set would definitely have this problem. My understanding is the original one had too, even though it stored more data than we do now.

Aaron van Wirdum Anyways, the key point here being that the ownership records that every node holds would start to diverge. And if that starts to happen, that is a consensus failure, that you could get to a place where you try spending coins and it confirms on your end and it doesn't confirm on the other end and networks start to... It's chaos. So that was a potential actual risk with this OG Satoshi bug.

Sjors Provoost Yeah, and as far as I know, what did happen was there were two instances of these duplicate coinbases. Basically, miners losing 50 BTC, but I don't think there were cases of also reorgs on top of that that would have created this mess. But maybe there was and nobody noticed it. Because the mess would not have been... Well, I think we would have noticed it now, yeah.

Aaron van Wirdum Probably, right? That would have been very unlucky as well. You've got to have an exact reorg exactly on that block where this exact block happened.

Sjors Provoost Yeah, and because this... Well, as far as we can tell, it only happened twice. It might have happened more often in chains that never survived.

Aaron van Wirdum Well, then we would have the problem, right?

Sjors Provoost Well, maybe we are the surviving chain where that didn't happen, but there may have been other chains where it did happen and it didn't survive.

Aaron van Wirdum Well, we would have probably heard it then at some point, don't you think? I would say so. Because then there would have been nodes with these different transaction records, UTXO set, whatever you want to call it.

Sjors Provoost Yeah, but I mean, if this was long enough ago, maybe they just restarted the computer and just didn't care, but probably didn't happen.

Aaron van Wirdum Fair. Alright, so this was the OG Satoshi bug. And this bug was fixed.

Sjors Provoost Exactly. And this is where BIP 30 comes in. This was introduced in 2012. What BIP 30 does is very simple. It says there shall never be two transactions with the same hash at the same time.

Aaron van Wirdum At the same time?

Sjors Provoost At the same, as in, if you create a transaction right now, it's not allowed to already exist in the UTXO set.

Aaron van Wirdum Okay, so it's just an invalid transaction. So if the same thing would happen, if the miner would create this coinbase transaction where he pays himself to the same address, the Bitcoin network nodes, my node, your node, would just say, this is not valid, you just wasted your energy, we're going to wait for a valid block.

Sjors Provoost Exactly.

Aaron van Wirdum Right.

Sjors Provoost Let's say they do that, they make a coinbase, then they spend it, then they can make the same coinbase again. That's no problem. So BIP 30 does allow that.

Aaron van Wirdum Right, okay.

Sjors Provoost So that was great, and that worked. The only problem is that this rule is a bit difficult to check, because it means that whenever you get a new block, for every transaction in that block, you have to make sure that it doesn't already exist, the transaction itself. So right now, whenever you check a block, you go through every transaction and you check that all its inputs exist. So it's spending from something that exists. But you do not check if the transaction itself exists. Or at least, you know, you don't now because of what we'll discuss. But with BIP 30, you would have to do that. You'd have to do an extra check for every transaction. Like, hey, now that I've checked that all the inputs are valid, whatever, or whichever sequence we're going to do, does this transaction exist?

Aaron van Wirdum Right. So that was the case in 2012 for a brief while, at least after BIP 30 was deployed. And this sounds like it's an especially annoying or burdensome check because it's so unlikely that it's necessary, especially for all non-coinbase transactions. but just technically…

Sjors Provoost Yeah, it's completely unnecessary in the sense that no miner would be this stupid. But of course, if you don't check, then they would be.

Aaron van Wirdum You have to check. But it's burdensome.

Sjors Provoost But it weighs some resources. I don't know how much, if it's like 1% or 10%, but it's annoying.

Aaron van Wirdum Yeah, and also just in general, you want miners to be able to check validity of new blocks or all nodes. You want them to be able to check validity as soon as possible.

Sjors Provoost Yeah, so every second you can shave off the checking time is better. So BIP 34 was introduced, which made this process more efficient.

Aaron van Wirdum When was this?

Sjors Provoost Same year, but just a half a year later.

Aaron van Wirdum And was this introduced especially because... For the reason we just mentioned?

Sjors Provoost Yes.

Aaron van Wirdum Okay, so it was like a performance improvement.

Sjors Provoost I think so. So the little background is that BIP 30 was a relatively simple soft fork that could be deployed very quickly because they realized the problem and they wanted to fix it as quickly as possible so nobody would deliberately exploit it. BIP 34 was something that was deployed a bit more carefully, very much like the BIP 9 style soft fork. So there was some signaling involved. Block version number went up and you had like so many percent of the miners had to signal it, et cetera, et cetera. So BIP 34 was a more thorough solution, but it was also deployed more carefully. So what does BIP 34 do? Well, it makes sure that, well, that was the idea, that the coinbase transaction is unique by definition. by adding the block height to it. So every coinbase transaction must start with the block height. And because it must start with the block height, it's going to be different than previous transactions, which had a different block height, or previous coinbase transactions had a different block height, so you won't have the duplicates. That is to say, moving forward, you don't have the duplicates.

Aaron van Wirdum Yeah. Okay. Yeah. This makes sense. This way, every coinbase necessarily is unique. Like every coinbase transaction necessarily is unique because it's in a new block that has new block height. And therefore, every transaction that comes from, that's spent from that coinbase is also unique. So now every transaction has to be unique.

Sjors Provoost Yes.

Aaron van Wirdum Right? Okay. Yeah. Makes sense.

Sjors Provoost Yeah.

Aaron van Wirdum Good solution. Sjors, I like it. Who came up with this?

Sjors Provoost I think it was... I'm not sure.

Aaron van Wirdum Well, whoever came up with it, congratulations. Thank you. However, I guess there's another problem you're going to mention about this solution or not.

Sjors Provoost I think the original one was Pieter Wuille and the second one was Russell O’Connor.

Aaron van Wirdum Right, okay. However, so I guess this is why we're making this episode.

Sjors Provoost No, Gavin Andresen.

Aaron van Wirdum Gavin Andresen. I could have guessed. Gavin, you messed up.

Sjors Provoost 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.

Aaron van Wirdum It was a joke, but maybe it's kind of a sensitive joke at this point in time. Sure, go on. Because there is a problem. It introduced a problem.

Sjors Provoost Yes. Well, actually, it did not introduce a problem. So just having this rule... It's fine.

Aaron van Wirdum Okay.

Sjors Provoost However...

Aaron van Wirdum Good job, Gavin.

Sjors Provoost Exactly. So Gavin, whatever it was, he didn't do anything wrong.

Aaron van Wirdum Okay.

Sjors Provoost However, then in 2015, somebody tried to be smart and said, hey, we have this BIP 34, which means that we don't need to check for BIP 30 anymore. We can make it faster. So perhaps I said before in the episode, oh, this was the reason, the performance thing was the reason to introduce it. Maybe not. Maybe they did it because it was just a more elegant solution and it would prevent mistakes. But then a couple of years later, somebody realized, hey, we can actually make this faster by not checking BIP 30 anymore. Because we know that the blocks must be unique, right?

Aaron van Wirdum Yeah, like I explained just now. I immediately got it. Why did it take these Bitcoin Core developers so long, Sjors?

Sjors Provoost I don't know. So in 2015, that optimization was merged. And, well, then in 2018, so three years later, somebody realized, oh, oops, that doesn't actually work.

Aaron van Wirdum Wait, wait, wait. Sorry, I lost the plot. Where are we now? What's the year?

Sjors Provoost Well, the year of the fix is 2018, but I guess the year of the realization was late 2017.

Aaron van Wirdum Okay.

Sjors Provoost So somewhere, I think it was October 2017, but this wasn't documented, but it kind of follows. Somebody realized, oh, wait a minute. There are exceptions to this convenient rule. Remember that the rule of BIP 34 is that you put the height of the block at the beginning of the coinbase. So block number one would have height number one, et cetera, et cetera. But that rule only applies starting with block, I don't know, 200,000 something.

Aaron van Wirdum It started being applied in 2012.

Sjors Provoost Yeah, and it started being applied from height number 220,000 or something like that. And so from there on, this rule is correct. But the problem is, and that's what people realize, is that it doesn't apply earlier. The rule wasn't active earlier. So what is actually in those earlier coinbase transactions? Might there be numbers in those earlier coinbase transactions, numbers that could represent a block height? The answer is yes. There were numbers in there. All the coinbase transactions that had numbers in there that represented blocks that might occur in the future.

Aaron van Wirdum Okay, I know what you're saying, but the word represent is confusing here. There were just numbers in there and they could be interpreted as blocks from the future.

Sjors Provoost Yeah, either it was a very smart miner that saw that this problem was going to happen.

Aaron van Wirdum Like let's say there could have been an early miner that for whatever reason put the number a million in the coinbase.

Sjors Provoost Yeah, so as the episode suggests, some miner put the number 1,983,702 in the coinbase.

Aaron van Wirdum Right.

Sjors Provoost They didn't actually put that number in there. They were probably just writing their name, and the name, if you map it into how a computer reads it, might have looked like a big number.

Aaron van Wirdum Right. Okay, so there was a block in, say, 2009 that… start with the number 1,900,000 something. So by the time we actually get to block number 1,900,000 and that number has to be put in the coinbase, there's a risk that it, well, it's a pretty, that's not gonna happen, right?

Sjors Provoost Normally this would not happen, but in theory somebody could… put, would have to put the same number in it.

Aaron van Wirdum Yes.

Sjors Provoost And then could, if they wanted to, wouldn't happen accidentally, make the rest of the coinbase identical to that original transaction.

Aaron van Wirdum Right. So, yeah. So it would just have to spend the same amount of, well, no, because there's 50 coins in the original coinbase.

Sjors Provoost Much more. So Murch looked at this specific transaction and it turns out that that was a very lucky block. So not only did it get a 50 Bitcoin coinbase subsidy, which, you know, modern blocks don't get. It also got, I think, 50 or so BTC in fees.

Aaron van Wirdum That's good.

Sjors Provoost Yeah, so that's a very nice little block in the past. So if you wanted to reproduce this, your coinbase transaction would have to create about 107 Bitcoin. It would have to spend 107 Bitcoin. That is only allowed if there is 107 Bitcoin worth of fees in that block.

Aaron van Wirdum Right.

Sjors Provoost So that's never going to happen. Accidentally. The other thing that has to happen is...

Aaron van Wirdum An attacker would have to actually probably pay these fees himself and then burn it in this block.

Sjors Provoost Yes, because he cannot send it to some arbitrary destination. He has to reproduce the original coinbase transaction, which means that his 107 Bitcoin has to go to the original owner of that coinbase transaction.

Aaron van Wirdum Right.

Sjors Provoost And so maybe this miner, you know, was frozen and wakes up and decides that this is a fun joke because you can just get the 107 Bitcoin back after doing this. But the other problem is it would have to be a non-SegWit block because there was no SegWit back then and SegWit adds something to the coinbase. Well, you can't add that to the coinbase because then it would be a different block. So that means all the fees would have to be in non-SegWit transactions. There's all sorts of problems with this attack. One problem I can think about is that the next miner might be like, hey, there's a lot of fees in that original block. Let me reorg it and mine it myself. But anyway, this could be done. And then you would have an identical transaction.

Aaron van Wirdum Hang on, hang on. Maybe first finish your sentence.

Sjors Provoost So if the attacker did that, they would have an identical transaction. And this is what people realized back in 2017, 2018. That's bad because that is a BIP 30 violation. But we are not checking BIP 30 anymore. So we should check BIP 30 again. That's the solution, basically. But it was a realization, like, oh, if we don't fix this, let me, you know, they would have to look at all the other numbers that were in all the transactions and see if this could happen earlier.

Aaron van Wirdum Okay, also, there could still be nodes that are checking BIP 30, right, in theory?

Sjors Provoost Yeah, that could be very old nodes.

Aaron van Wirdum Which could be sort of its own problem.

Sjors Provoost Exactly, all the nodes from before 2015 would check BIP 30, and they would not approve this block if this attacker did that.

Aaron van Wirdum Let me sort of cut down, shortcut to... Okay, so let's say an actual... Let's say just the classical example, like a state-level attacker that does want to burn 100 Bitcoin just to fuck with Bitcoin.

Sjors Provoost It doesn't have to be a state-level attacker, like 100 Bitcoin. It's a lot of money, but it's not state-level money.

Aaron van Wirdum Well, hang on. We're talking in 20 years from now, Sjors. That's enough to buy North America.

Sjors Provoost Sure. Okay.

Aaron van Wirdum So a state level, my attacker wants to do this. What's the actual specific consequence [unclear], like, he wouldn't also have to do the reorg thing and then the UTXO sets get…

Sjors Provoost Well, okay, so the question is, first of all, you want to...

Aaron van Wirdum What's the actual risk?

Sjors Provoost Well, the first risk, and again, this has been fixed, but if it had not been fixed... The first risk is that they could violate BIP 30. And that means that if you had a node from before 2015, it would not accept the block. New nodes would accept the block. So you get a chain split. And of course, you know, the majority of people would probably be on the modern nodes because you wouldn't be running 25-year-old software, but it's still not healthy.

Aaron van Wirdum I mean, I'm pretty lazy with upgrading, to be honest.

Sjors Provoost Yeah. Well, your computer will force you to, probably. But the other thing is... Yeah, then you could have shenanigans, right? So, yeah, you could be talking about this reorg scenario. I don't know if that's useful for the attacker or just shoots himself in the foot. But there may be other weird things that you can do. It shouldn't happen, basically. So you can try and reason about it, but you just want to prevent that from happening.

Aaron van Wirdum Okay, so we've got 22 years, more or less, to do something about this problem.

Sjors Provoost Yeah, we didn't wait that long.

Aaron van Wirdum What are we going to do? Oh, it's solved already?

Sjors Provoost Yes, in 2018, once they realized this problem, it was solved. And the solution is very simple. As of block 1,983,702, we just check BIP 30 again.

Aaron van Wirdum Oh, we're back to checking BIP 30 with all these inefficiencies?

Sjors Provoost Yes. Now we will check it from that block onward.

Aaron van Wirdum Oh, okay, yeah, that makes sense.

Sjors Provoost Which means we have 30 years to actually solve the problem, but if we don't solve the problem, we'll just check BIP 30.

Aaron van Wirdum Right, okay, so in 20 years... My Bitcoin Core node, well, I haven't upgraded my... Your Bitcoin Core node today, if you don't upgrade it, will still start checking for BIP 30 in 20 years from now.

Sjors Provoost That's right.

Aaron van Wirdum Oh, okay. Interesting.

Sjors Provoost So will your node probably, unless you didn't upgrade before 2018.

Aaron van Wirdum I'm not sure. No, probably I did. No, I did upgrade since 2018.

Sjors Provoost There are so many security vulnerabilities in old Bitcoin nodes that this is the last of your problems.

Aaron van Wirdum I might be like three versions behind, but not that many.

Sjors Provoost That's probably not too bad. But it gets more exciting than that because 1,983,702 is not the only block where this happens. It was an earlier block where it didn't happen, but it could have. Or it could not have.

Aaron van Wirdum Wait, sorry, there was?

Sjors Provoost There is block 490,897.

Aaron van Wirdum Are we talking about the future or the past?

Sjors Provoost The past.

Aaron van Wirdum Okay, what about it?

Sjors Provoost So this block was another one of those numbers that if you look at the older coinbase transactions and you just find what number is in there, there was a couple of numbers in there. I think one number was so low, like 200,000, it was before BIP 34 was activated. So it wasn't a problem because it was referring to something in the same era. But the next number was 490,897, which was in October 2017. And that block, if it wasn't for some lucky circumstances, could have already exposed this bug that we just talked about. So we wouldn't have had 30 years. No, we had two weeks, basically. At least the people who discovered this issue discovered it about two weeks before that block.

Aaron van Wirdum Interesting.

Sjors Provoost So this is like the asteroid coming towards the Earth, and NASA says, oh, we found an asteroid coming towards the Earth, but don't worry, it's going to miss us by at least the distance between here and the Moon. It's fine. The only thing is we found out like two hours ago, so if it had not missed us, we would be dead and we would not have noticed it.

Aaron van Wirdum Right, right, right.

Sjors Provoost So this is one of those cases where, yes, the bug isn't actually harmful, but if it had been harmful, it would have been only two weeks to deal with it.

Aaron van Wirdum I mean, the bug could have been harmful if someone wanted to exploit it.

Sjors Provoost No. So basically, by looking at the original transaction, they could see that it was not possible to exploit this. And the reason is because that coinbase, yes, you could duplicate it, but it was already spent. And so you then need to reproduce the transactions that spent the coinbase. And that is impossible because one of those transactions was spending another coinbase. And that other coinbase had a number in it. It's like 5 billion or some insane number. And we can never get to block 5 billion, at least not in the current code, right? Because it stops in 2106.

Aaron van Wirdum I see.

Sjors Provoost And then you have a hard fork. So with a hard fork, you can fix everything basically though. Anything after blocks 6 million or so, you don't have to worry about it. So that was good, but it was a close call.

Aaron van Wirdum With a hard fork, you can fix anything. You can quote Sjors on that.

Sjors Provoost I'm not saying you're not introducing any new problems.

Aaron van Wirdum Are you pushing for a hard fork?

Sjors Provoost No, you can just wait until 2006, 2106.

Aaron van Wirdum Anyways, okay, we had a near miss in 2017. That turned out to not be a real problem. Now we got 20 years to either fix this problem or just ignore it because it's kind of already fixed. Anything else?

Sjors Provoost Yeah, so the fix was shipped in 2018. It just basically says, okay, from this block, I'm going to check BIP 30. So anybody running a modern node doesn't have to worry too much. Except on testnet, I think. On testnet, I think on testnet, it's already checking BIP 30 now. But who cares about testnet? Because testnet has the same kind of problem.

Aaron van Wirdum Yeah.

Sjors Provoost And it was fixed in the same way.

Aaron van Wirdum Okay.

Sjors Provoost And I think in testnet, there was another block like that in block 2,200,000 or something like that.

Aaron van Wirdum I don't care about testnet.

Sjors Provoost But testnet has already had block 2,500,000. So I think it's already checking BIP 30.

Aaron van Wirdum Okay.

Sjors Provoost And there's a little code comment saying like, oh, I'm sure somebody will fix it before then.

Aaron van Wirdum Oh, I was going to ask, so we got 20 years, are there other solutions? Is this just it, or do we have other ways out of this conundrum that we find ourselves in?

Sjors Provoost So ideally, you want to have something in every block that we know was not in those blocks before BIP 34 activated. And there's a bunch of candidates that were mentioned back in the day. But one candidate that I saw on Twitter, I think it was Calvin Kim that said it, but I don't know if he came up with it or heard it from somebody else. And that is to basically make SegWit mandatory. And why? Right now...

Aaron van Wirdum Wait, wait.

Sjors Provoost SegWit commitments.

Aaron van Wirdum SegWit for every transaction mandatory?

Sjors Provoost No, just Seg… for every block.

Aaron van Wirdum For every coinbase transaction?

Sjors Provoost Yes.

Aaron van Wirdum Yeah, okay, that makes sense.

Sjors Provoost So every block has to commit to SegWit, has to include the SegWit commitment. The SegWit commitment is an OP_RETURN that refers to the tree of SegWit transactions.

Aaron van Wirdum Oh, wait, so are you just, oh.

Sjors Provoost So the transactions in the block don't have to be SegWit.

Aaron van Wirdum Oh, so what you're saying is that could still be a block mined that has zero SegWit transactions. But as soon as there's one SegWit transaction in a block, you need the SegWit thing in the coinbase and therefore the transaction ID is different.

Sjors Provoost Yeah, and so right now, every time there is a SegWit block, yes, that's happened automatically. But empty blocks or blocks with no SegWit transactions do not commit to SegWit. But definitely empty blocks don't. However, they can, they just don't. Because they don't have to. So the change would be to say, okay, you have to.

Aaron van Wirdum Let me ask this question real quick. So because I was going to ask, has there been any block mined that doesn't include any SegWit transactions since SegWit [unclear]?

Sjors Provoost Yes.

Aaron van Wirdum And that would be empty blocks.

Sjors Provoost Yes.

Aaron van Wirdum Right. Yeah. Makes sense. Okay. Go on.

Sjors Provoost So basically, you know, the difficulty then would just be, okay, when you propose an empty block, which you have to do as a miner sometimes, very briefly. Just make sure that it's a SegWit block. So that would be a fairly simple soft fork. But there are other ideas out there.

Aaron van Wirdum It's probably still like, you know, in the sort of Puritan Bitcoin conservative, you know, which is a good philosophy. It's still... it's still kind of a cost to miners, which you're opposing on miners. Like now they have to do something extra. Like it might still be controversial. I don't know. What do you think?

Sjors Provoost I don't know if it's a cost to miners because if they use Bitcoin Core to create the block templates, Bitcoin Core would just do it for them.

Aaron van Wirdum Well, the cost I'm referring to is you have to upgrade your Bitcoin Core node once in a while. It's not backwards compatible is what I'm basically saying, for miners.

Sjors Provoost Not for the miners, no, but that's always true for soft forks. Well, no, it's not always true for soft forks. Generally, soft forks are done in such a way that if you only mine standard transactions, then you're going to be fine. But for this case, yes, miners would have to do something, just like they had in the first time it was introduced. So, yeah, it's not entirely innocent.

Aaron van Wirdum It seems to me like a very plausible or reasonable solution. I'm just pointing out that even that might have some pushback.

Sjors Provoost Yeah, and the other solutions, I think, have the same property, is that every miner would have to do it, or they might lose a block if they mine an empty block.

Aaron van Wirdum Right.

Sjors Provoost So I think another one was, okay, we just add the block height again, but we add it to a different field, like the lock time of the coinbase transaction.

Aaron van Wirdum Because lock time wasn't activated back in?

Sjors Provoost Lock time wasn't used. As far as I know, again, you'd have to run a script and check.

Aaron van Wirdum Well, lock time was introduced in 2015, right?

Sjors Provoost It's possible, but the numbers were there. They didn't have any meaning. So you still have to check that they weren't used. But that's easy. I think this SegWit thing is the simplest one. The other option is we can buy ourselves another 20 years or so, to block 3,808,179.

Aaron van Wirdum How?

Sjors Provoost Well, we would have to very carefully study block 1,983,702. Well, not this block, but the original block that created it. And that coinbase has been spent, so it can already be recreated, but you have to look at all the descendants. So this thing was spent to like, I don't know, 10 different addresses and those could spend and those could spend. And if you can show that for every transaction descending from it, it was also using a coinbase transaction that cannot be duplicated. Maybe you can prove that it, you know, you could write a proof that it can never happen. Gives you another 20 years. I think that's a stupid exercise compared to the simple soft fork.

Aaron van Wirdum Well, you didn't figure it out for this podcast if that's the case or not?

Sjors Provoost I did ask it on Stack Overflow in a comment somewhere, but no, I did not.

Aaron van Wirdum What do you do for this podcast?

Sjors Provoost Nothing.

Aaron van Wirdum Moving on.

Sjors Provoost I did actually run a script to check that there are no OP_RETURN transactions before BIP 324 activated.

Aaron van Wirdum Wait, sorry. Can you repeat that just for me?

Sjors Provoost There were no OP_RETURN transactions in the coinbase, okay, before BIP 324 activated.

Aaron van Wirdum You did actually check that?

Sjors Provoost Yes.

Aaron van Wirdum Okay.

Sjors Provoost Which means that you don't even have to commit to SegWit. You just have to put OP_RETURN in a coinbase transaction. That will be the rule. But of course, it's easier to just say SegWit.

Aaron van Wirdum Okay, so far I think we agree SegWit is the most reasonable, low effort kind of way of doing this. I guess you could do Taproot as well maybe or no. Does it make sense?

Sjors Provoost Taproot is just a subset.

Aaron van Wirdum I'm just thinking out loud.

Sjors Provoost You want to keep it simple? So the funny thing is there was in 2019 a proposal.

Aaron van Wirdum I'm just thinking of soft forks that were introduced after 2015 to make me sound smart. But yeah, SegWit is the obvious thing here. Go on.

Sjors Provoost Yeah, so there was a great consensus cleanup proposal back in 2019 by Matt Corallo, Blue Matt, which contained a bunch of these very small fixes, kind of similar to this one, but not actually this one.

Aaron van Wirdum Sorry, a fix for this specific problem?

Sjors Provoost Yeah, it was not in there.

Aaron van Wirdum So why do you even bring it up?

Sjors Provoost Because I was curious whether the great consensus cleanup would clean this up.

Aaron van Wirdum And it doesn't.

Sjors Provoost But it would if you were to revive that proposal, you should clean this up too.

Aaron van Wirdum Okay.

Sjors Provoost Because it also fixes the time warp attack and other things that we've discussed in other episodes.

Aaron van Wirdum Sure. Yeah. Okay.

Sjors Provoost That's all I have.

Aaron van Wirdum Yeah. Well, I mean, it sounds to me like SegWit is the easy way to go. And also...

Sjors Provoost We have a few decades to figure this out.

Aaron van Wirdum We can think about it in a while. All right. Thanks, Sjors.

Sjors Provoost All right, and thank you for listening to Bitcoin.

Aaron van Wirdum Explained.