 All right, welcome everyone. Good morning, Buendia. We are at the final unit, Unit 8. We made it all the way here. So today, as Mike said, please drop, you know, as always, drop lots of questions into the chat. We'll pause regularly to answer questions. I'm excited to do this particular session today because what we're covering a lot of today is, you know, how changes to Bitcoin happen, right? The question is like, well, this is a completely decentralized thing that no one controls. How do you change it, right? And it was one of the more difficult concepts in Bitcoin for me to grasp, you know, personally, I struggled with trying to figure out how the heck this works. And it's complicated. So it's a fun one for me to go over. So please do ask many, many questions. It is sort of a difficult concept. So please ask all the questions as we go through this session. I'll pause regularly to check with Mike to see what questions are being asked. All right, so again, this is a supplement to Unit 8 of the Bitcoin for Developers course. These are some of the topics that are covered in Unit 8. We have elements of valid transactions, right? The mining process, right? We've covered mining many times, but we're going to go back over it a little bit more today. A bit more detail. There is an excellent video in the course that really walks through that mining process. So we'll just touch on a couple of things from that today. And we're going to talk about consensus, right? The all-important consensus and then updating consensus, which is indeed a very, very tricky thing to do. And today, what we're focusing on is exactly that. How the heck can you update this open thing that no one particular person or entity controls? Like how do you make that happen? So we'll dive into that today. So first up is we want to talk a bit about mining. So I hope y'all have gotten the chance to watch that video in the course. It's not a highly recommended, really. I think it's about an hour long where Andreas really walks through in depth, the mining process, different scenarios, you know, what that might look like for a miner sitting on the network, seeing this information or that information, how things can diverge and come back together. It's really very in-depth, excellent video. But one of the scenarios I want to talk about briefly here, which is a really, really important one to get. And it's also just an opportunity for any of you to ask questions about it if you were confused about any of that. If there's something there that just isn't quite clicking for you or isn't quite clear, now's a great time to ask questions about it. And it's this idea I want to talk about is that sometimes you can have, we're going to talk about forks a lot in this session. But, you know, a fork we can think of sometimes is like, maybe not in this scenario right here, but you can kind of have some natural divergence which happen on the network. So maybe two blocks are found at roughly the same time. There's some sort of confusion on the network about what's happening, which block is the next block we're supposed to build on, which, you know, there's a couple of different versions, maybe of this blockchain going around and which one's the real blockchain, which one's valid, right? And so this can happen just because this, you know, open decentralized network that's not being directly coordinated by any one entity. So you can have this momentary, like this temporary confusion on the network or even say confusion, but it's, you know, duplicated information or slightly differing information. So one of the most important concepts to get about mining and coming to consensus is that you may have two different miners which find a perfectly valid block, right? So they went through the whole proof-of-work process. They found a hash which matches with the current network standards. And, you know, on different sides of the world, two different miners both find a valid block, an entirely valid block at roughly the same time. So there might be some confusion in the network as to which block another miner should build on top of or you can have these situations where there's just slightly differing information. So this is a question that happens a lot. Which block will a miner build on top of? Which, you know, version of this blockchain will it build on top of? Or which one's the accurate one? And so it's not just, it's a little bit more complicated than just whatever is the longest chain, right? So you might have, you know, this version of the blockchain with one more block than this version of the blockchain here. It's a bit more complex and it's the most cumulative proof-of-work. So the main chain at any time is whichever valid chain of blocks has the most cumulative proof-of-work associated with it. Under most circumstances, this is also the chain with the most blocks in it, unless there are two equal length chains and one has more proof-of-work. So I think this is one of the most challenging concepts to grasp in mining. So now is a great time to ask any questions you may have on this topic and then I'll just kind of dive through it one more time as I'm waiting for any questions to come in. Mike, do let me know if we get any. But this is kind of how, you know, I like to visualize a blockchain in many different ways to do it, right? But you have these blocks of all this transaction data. And if we remember from the earlier sessions on mining, right, each block, the miner has to go through a process of taking all that data in the block, hashing it and producing a hash that meets with the current network difficulty standards, right? And because it takes such computing work to sort of guess, right, to just try over and over again to find a hash that meets with the current network standard, then that hash is deemed to be proof of all of the work that your computer has done, right? All of the work that the computing power, the computing work that you have put into it. So, you know, not depicted here, but you can imagine that this block hash, right? There's a hash that's, you know, the ID for this particular block, right? It has a certain amount of zeros that it starts with and those zeros represent the amount of work that went in there. So we could just imagine that there's some sort of, you know, we could just think of as a number of zeros at the beginning of that block hash, but there's some sort of number we can slap on this that is the amount of work that we have proved that we have done to produce this block. And that would be the same here. There would also be some number we could slap on that that is the amount of work that we can prove with this hash that we have done to find this block and this one, the exact same, some measure of that work we can slap on top of this block, right? And so when a minor, a mining computer is looking at, okay, there's slightly different versions of the blockchain out on the network right now, which can happen just, you know, not centrally controlled, you get these sort of times you can have this momentary duplication of data or slightly different versions happening out, you know, on the network. And so that minor will look at this, you know, perhaps two different versions of this, right? Two different versions of this blockchain and calculate not only how many blocks there are, but how much proof of work is in each one of these blocks and sort of add that all up and come up with the total. So if you have two different versions, this one has more proof of work, right? Higher score for that proof of work than this is, this one over here is the valid blockchain. It's the accurate one, the correct one. So I just wanted to go over that particular concept because it's important in understanding how you can have what you might call like, I refer to sort of like a natural temporary fork in the blockchain, right? Two slightly different versions and then how the software will bring us back to convergence back to consensus onto what is the accurate blockchain, right? So this is kind of how that happens, right? And so you just as this race to find the next block continues and continues, this is what we think of as the valid blockchain. So that's a lot of information. Mike, do we have any questions on that point? Yes, we do here. We actually have a question about you moving this thing otherwise so I could read it. How do you measure the amount of proof of work in a chain? How do you measure the proof of work in a chain? I'm sorry. How do you measure the amount of proof of work in a chain? Cool. Yeah, that's kind of just what I was going through here where you would look at sort of the hash for a particular block and it has to start with, you know, a certain amount of zeros, right? To meet with the current network standard and that sort of amount of zeros is kind of a measure of how difficult it was to find that block, which is a measure of how much proof of work went into it. So, well, maybe not exactly correct. You could think of, you know, I'm just going to calculate how many zeros the hash for this block has and I'm going to calculate how many zeros at the beginning the hash for this block has, same here. And then you can kind of use that as a measure of the proof of work that went into this, creating this block and this particular version of the blockchain. So I hope that answers that question there. Do we have any others? We don't have any other questions right yet, but of course, as always, if anyone has any questions, you can leave them in the chat and we'll get to them. So no more questions right now, but if you have questions, put them in the chat and I'll let you know. Awesome. All right. So now we're going to talk a little bit. So we're going to talk about consensus attacks briefly and then we're going to really dive into how you update the Bitcoin software and update what happens on the network. So if you have any questions on that topic, do get them prepped, we'll dive into that soon and get an ask them at any time. Okay. So consensus attacks in this unit eight, we also talk about how this consensus process can be attacked or manipulated or different, you know, potential vulnerabilities or areas of concern in consensus. All right. So it's important to understand what we mean by a consensus attack. And so here we note that a consensus attack is not an attack on cryptography, right? So in every, you know, Bitcoin transaction, there is some sort of cryptography involved generally, like, you know, hashing and signing that goes into proving that a transaction is valid. So one, you know, when people think of attacking Bitcoin, they always think of breaking the cryptography, right? And it's pretty darn good, you know, cryptographic algorithms used in Bitcoin that have yet not been broken. And we don't see that happening anytime, you know, out on the horizon. Although theoretically, you know, maybe with quantum computing at some point in the future, this could happen at the moment. Not something I lose my sleep over. I don't worry about that, at least not anytime soon. But it's very important to note that when we talk about these attacks, we're not talking about someone attempting to attack cryptography. We're talking about someone attempting to attack the mechanism that Bitcoin uses to reach consensus, sort of, or the mining process, something like that, right? All right. So a consensus attack cannot steal Bitcoin, right? Because in order to steal Bitcoin, you would have to alter, like, let's say, the signatures on a transaction, which would mean breaking cryptography, which currently we don't know how to do, right? So a consensus attack does not steal Bitcoin. You cannot fake signatures or break cryptography. You cannot change past transactions, but you can't change, you know, a signature on a transaction from way back when, right? A consensus attack can double-spend, potentially, right? This is complex, right? All right. So let's think of what we give a solid example for what we mean by double-spend, right? And we went through this in Unit 1, the presentation there, where we talked about, you know, Charlie trying to take the same Bitcoin that he legitimately owes, but send it to both Alice and to Bob, right? So he's trying to, like, copy, paste his Bitcoin and send it twice, right? Double-spend it. And of course we know the Bitcoin consensus algorithm, the mining process prevents Charlie from being able to do that. But let's walk through another scenario in which someone could attempt to sort of double-spend. And one classic example is that I walk into a big, you know, shop, right, an electronic store. I say, hey, I love that really awesome, super huge, you know, flat screen TV that costs thousands of dollars because it's got all the latest and greatest widgets. I don't even know if they are, but I want that. Super great flat screen TV. It costs a couple thousand dollars. I'm going to send you a Bitcoin transaction, right? So I legitimately own some Bitcoin. I have a UTXO. I'm going to take it, sign it over to you, right, and make great, perfectly valid transaction and broadcast it to the store, right? So let's say the store accepts Bitcoin. I'm checking out. I send this transaction to them. It pops up on their screen. They, you know, that cashier can see that, I have, there's a pending Bitcoin transaction for the amounts of this awesome flat screen, you know, big, giant TV coming to the store, right? But in actuality, what you want to do with a, you know, expensive item of that sort is, you know, if you're going to do an on-chain transaction, if you wouldn't just let them walk straight out of the store, you know, with the item because while highly, highly unlikely, what could potentially happen is I send that transaction to the store, but I take, I make another transaction, right? Using that same UTXO, right? Unspent transaction output that I'm trying to send to the store. I take that same UTXO and I create another transaction, sending it back to myself, right? And then maybe I can do something tricky, like trying to include a much higher fee on this transaction that I included on this one, thinking that I can, a miner will choose to include this one rather than this one. And so this one that I sent to the store is just kind of going to disappear out of the mem pool and then this one will get confirmed, right? Making the other one invalid. So that's how in practice someone could attempt to double-spend and they can get really in the weeds with this, but general rule of thumb for this type of thing is if you're selling, you know, your car for Bitcoin, you want to wait until you get a couple of confirmations before you just hand someone the keys and let them drive off, right? And this, you know, in e-commerce scenarios for on-chain transaction, right? This is a consideration. All right, so a consensus attack, someone trying to mess with this process can, this is one example, but can affect the most recent blocks, right? So like the last one, two or three blocks potentially, right? If you have a really sophisticated attacker who has a whole bunch of computing power behind them, they can potentially reorg or change a couple of things in the past few blocks, but it's pretty much infeasible. Like let's just go ahead and say impossible to change transactions that happened years ago in Bitcoin, right? Because someone would have to recreate the entire blockchain from that point all the way up to the present. They would have to recreate that entire thing, essentially in the next 10 minutes. So with the computing power that humans currently have, like that's just not really possible. So I guess if aliens showed up to the planet with super sophisticated computing power, they could potentially mess with a transaction in the blockchain from a year ago. But humans at the moment that we know of do not have the technology to do that, right? So when we think of consensus attacks, it's generally going to affect the most recent blocks where potentially there could be someone that has enough computing power to kind of reorganize or mess with that. All right. You can have denial of service sort of disruptions, potentially that can be a consensus attack. And you could even potentially try to cause a fork as a consensus attack. And we will talk in depth about forks in just a minute. Here we go forks, forks and more forks. And again, apologies, I ran out of fancy graphics. So once again, we're going to get to the rescue. A, you know, open source image of some forks. So I'm going to pause there. Mike, do we have any questions on the consensus attacks? I'm not seeing any questions right now down in the chat. But of course, if anyone has any questions, they can, they can always put them down in the chat. I'll just say, I don't think I have any of those forks. I had all the plays we had last time. Oh, there we go. We got a question in here. Oh, okay. This means that a 51% attack can only affect the most recent blocks. Therefore, it is not a real threat to Bitcoin, right? Okay. A 51% attack is the idea that someone could have enough hashing power, enough computing power. That they could control, like, have 51% of the hashing power on the network, right? With this, they could potentially do some, perhaps a double spend, right? Where they could send out a transaction, but then mine another one, like send out another one and include it in a block so quickly before anyone else can, because they have such a tremendous hashing power that they could maybe potentially do a double spend, right? And 51% attacks, people worry about them a lot. You can see sometimes on, you know, other chains that are similar to Bitcoin, but have a much, much smaller network so that people can take really, really powerful mining computers and then focus those on a much, much smaller network and then successfully do these sorts of consensus attacks, including a double spend because they have, you know, over 51% of the hashing power on that particular chain. In general, I would say, yes, that's correct that that 51% attack could only really affect the most recent blocks because, again, you just don't, humans don't have enough hashing power to recreate, you know, like 10 blocks deep in the next 10 minutes, right? We just, I'm not aware of, you know, any particular entity on planet Earth that would have that kind of computing power, even large governments. So I don't, so yes, you're correct in that statement and I don't worry a whole bunch about 51% attacks. And again, I think Bitcoin has done so well for itself because it gets the incentives consistently so right. So if someone had enough hashing power to pull off a 51% attack, they could quite quickly there would be countermeasures in the network, people would disconnect from those nodes, like there'd be various things that would happen, defensive measures if someone really did attack Bitcoin with the 51% attack. And, you know, in the meantime, if you have all that hashing power, hey, you can make some money mining Bitcoin legitimately without messing with the system. So, you know, the odds of, you know, you profiting from the 51% attack on Bitcoin are so low. Like monetarily, it just makes so much more sense that if you happen to have that much hashing power, you're much better off just mining honestly. So this is why I think we don't really see this sort of issue in that I don't really worry about it a lot. But I hope that answers the question. Any others on that one, Mike? I'm not seeing any other questions right now, but of course, as always, I'll let you know if we get them. Okay, cool. And yes, Mike, this fork right here in the middle is like my childhood fork that I had all over the house. Yeah, I mean, I have the hot dog one on the right, I think. Oh, nice. Excellent. All right. So hopefully, yeah. So we're going to talk about forks, forks and more forks. And here's this very amusing image for that. So let's go ahead and dive in and discuss what on earth can you buy a fork? All right. So if you're a software developer, you might have heard the term fork as it relates to software. Right? So if you go to GitHub, you can clone someone's repo, make your own copy of it and change it. And that is like a software fork, right? I took this, you know, this whole line of history, which was going along here and, you know, stored in Git, right? This whole, whole line of history. And then I duplicate it and I change it. And I start at forks off, right? It's now a different version of history is going to be developed on this side than is developed on this side, right? So if you're a software developer, you're already familiar with this variety of fork. I'm going to talk about many other varieties of forks, but it is kind of analogous, right? It is just you duplicate it, but then it veers off into different directions. Okay. Then we're also going to talk about a natural or spontaneous fork, right? And this is what we discussed a bit earlier. We're talking about this consensus process. It's the idea that as, you know, you have this open decentralized networking of these, you know, thousands of miners mining computers all around the globe competing to find the next block. And there's no coordination, right? Just people competing with each other, you know, racing to, you know, win the next, you know, block reward. And so you can have sort of just on accidents, you know, just spontaneously naturally you can have two different versions of the next block that are found, right? And what happens then, let's say you have a miner in Australia and a miner in Scotland, right? And they both find two slightly different versions of the same block, like whatever is the next block, right? They both find that. So now the network's kind of, you know, they've got conflicting information, which one's the correct blockchain? Of course, any mining computer run that calculation. You know, how much proof of work is there? Is this a valid block, et cetera? But also, even if there are some confusions to which one to build on top of the next round, right? Of this race. So if these two different versions of the same block, I got the same block height, we have two different versions. Well, that next round, roughly 10 minutes, you know, the next block is found. If it's found on top of this block, well, that becomes the longest group of work chain, right? If it's found on top of this block, this becomes the longest group of work chain, right? So generally, these type of forks will resolve themselves pretty quickly, right? I'd say that probably happens. I don't follow with that closely, but that happens pretty regularly on the Bitcoin network where maybe there'll be two blocks, two, you know, nearly identical blocks, right? If the same block height's found at roughly the same time, but generally within 10 minutes, like that's going to resolve itself. Rarely it might get up to like two or three blocks. We've got like three blocks, like that might be newsworthy, you know? So you can have these sort of natural and spontaneous forks where you have the same history, but then there's two slightly different versions at the tip of that history, right? Generally, this natural and spontaneous fork resolves itself probably within the next 10 minutes. It's not like a big issue, right? Bitcoin does this sporadically all the time, right? It's not a big issue in the Bitcoin ecosystem. Because it's temporary, sometimes it's referred to as a reorg. Again, on some smaller chains or sometimes with your, you know, news stories, you know, if you're, you know, following some particular ecosystem, you know, different blockchain, talk about, oh, there was a massive reorg on this without the other chain. And that means that there was differing histories that built up for a number of different blocks before, you know, one or the other was determined to be the winner, right? What was accurate on the network. All right. So now we've gotten through software fork we've gotten through the natural or spontaneous fork and now on to the impenis and dreaded hard fork. So a hard fork is something that is avoided intensely, right? Because this is sort of a permanent split in the network or can lead to a permanent split in the network. In Bitcoin's history, there was, you know, one particularly difficult, contentious, right? Big hard fork, right? And this is kind of when, well, this is when Bitcoin or Bitcoin cash went and split off from Bitcoin. So this was, I want to say, August 1st, 2017 when this fork happened in the Bitcoin network. And this all, you know, the history of that is fascinating if you really wanted to dig into how this all happens. And, you know, if you want to geek out on how changes are made to the blockchain, how contentious that could be and hard forks and soft forks, then definitely go read all about that. It was fascinating to watch it play out in real time. But what happened is that there was this really serious disagreement in the Bitcoin community as to started with how to scale Bitcoin, you know, where you try and increase, you know, how many transactions you put into a block or whether you create a second layer was kind of the big disagreement. And then there were different technical suggestions on how to implement these different changes or are we going to make the block size bigger? Are we going to enable SegWit, which eliminates transaction malleability, which enabled the Lightning Network, which is the second layer on top of Bitcoin. All kinds of intense technical debate happened that were about the consensus rules, right? We have to change, you know, to handle the scaling problem. There may be some sort of change to the consensus rules. But when you do that, when you change what, you know, counts as a valid block on the network, you run the risk if you can't get everyone to agree of working the network where you have two different versions. And that's, it's really complicated, but that's essentially what wound up happening to Bitcoin is the Bitcoin cash people, they wanted to scale Bitcoin in a different way than, you know, Bitcoin Core wanted to. And so you had disagreement on consensus rules, which led to a complete split in the network, right? So prior to August 1st, 2017, these were what these chains were one in the same, exactly the same history, right? And then after this, they split off. And now we are years later, they're completely different histories, right? I mean, you know, from 2017 on, the history of these chains are totally different. They've completely diverged, right? And this is a hard fork. Sometimes when we talk about a hard fork, though we don't necessarily just mean a split in the network, we mean a change that could potentially cause a split in the network. Say, hey, there's this change to the consensus rules, right, which is going to go through, and it's, you know, a hard fork, like it requires everyone updating their software, otherwise the network could split off, right? So this is really contentious. This is the type of thing that will keep me up at night, you know, when there's big concerns about this and a big change is coming through. Thankfully, we haven't done anything nearly as dramatic as, you know, the scaling wars back in 2016, 2017. You haven't had anything nearly that dramatic since, but this is the type of thing that is a serious concern, like how do you update Bitcoin? How do you make consensus changes without fracturing the network? This is like when you have to make a hard fork, right? A change that requires everyone to update. This is the type of thing that keeps Bitcoiners up at night, right? All right. So this can switch the network permanently, right? All right. Now, again, if you go back and read the history of that particular moment in time in Bitcoin, there was trying to figure out how to do this without requiring, right, the hard fork, right? How do you make these changes? In this case, it was specifically about an upgrade called SegWit, which eliminated transaction malability, but like, how do you make this change without requiring everyone to have to update their software? Because if you do that, you say, hey, this version of Bitcoin, this change goes into effect, and anyone who doesn't have this is gonna be validating blocks differently, such that people over here will think, hey, this is a valid block, and people over here will think, that's not a valid block. We reject that, and so the network will completely fracture in two, right? How do you make those changes without potentially causing that split in the network? And that is something that we call a soft fork. So, yeah, we'll come back to that. So it's a way of making an upgrade to the consensus rules, to the network, but in a way that's sort of backwards compatible. So even if we have, you know, Alice and Bob, and Bob's really keen on this change, and he goes and updates the software, but Alice doesn't like this change or maybe just isn't paying attention to what's going on right now, doesn't update her software, right? The blocks that Bob now says this is a valid block, Alice, her software is still going to see that as a valid block, and so the network does not partition it stays together, right? And so a soft fork kinda actually not a fork, right? It sort of prevents a network fork. All right, so this is a lot of different information on forks, right? We'll go talk through it here in a second, but could I just add a lot of information out at you, Mike? Are there any questions? I am not seeing any questions right now in the chat, but of course, as always, I'm down here in the chat if anyone has any questions and I'll talk for a little bit in case anyone has any, but I'm not seeing any right now, so I will pop back in if I get any. Okay, cool. Well, I'm glad no one has any questions, but I kind of don't believe you, but maybe that's just because this was a very typical topic for me. So when I was learning this and when I was, you know, relearning this during all this saga of 2017, like I had so many questions. So I'll go over this a little bit again here and please ask any questions, anything that might be on your mind. Okay. So here is just a little visualization of a fork, right? So we can look at maybe there's some change that needs to happen, right? Or that some developers or some members of the Bitcoin community have decided that needs to happen, right? Here's this upgrade that we need to make, right? And all this time we're debating about it, blah, blah, blah. Finally, let's say this block here. This change goes into effect, but this is what we call a hard fork, right? Meaning that if someone has not upgraded their software, someone's still running an old version, then what happens over here with for the people that have the upgraded software is going to look invalid for, you know, someone over here or kind of vice versa, right? There's going to be disagreements about what is a valid block, right? What transactions are indeed valid because we've changed those consensus rules. And so what can happen there is if this change is enacted here, then this next block produced follows these new rules. And any, you know, minor or node running on the network is going to see this block and say, nah, those aren't the rules I'm familiar with. I reject that. And then some minor over here will create a block that still follows the old rules, right? And in this way, then these minors over here are creating blocks that follow the old rules. And these minors on this side of the chain are creating blocks that follow the new rules. And we're kind of no longer talking to each other. So we've diverged. So this is kind of a visualization of what a hard fork looks like. And also in, you know, the master in Bitcoin book, there is some, you know, technical specifics on what's playing out here. But this is a nice visual for you. This is a fancy graphic as opposed to our previous photo of kitchen works. So any more questions now, Mike, or should we move along? Right now we have not seen any, any new questions, but I will let you know if they come through. Like, like, like, like I speak into a phantom. We have a question. Here's your question. Do both minors who create a natural fork receive newly minted Bitcoin? I'm guessing no. Is this the reason for the 100 block spend rule? Yes. This person is spot on. Okay. So that's exactly the reason for the, you have to wait till it's, you know, that block, the Bitcoin you received as a reward for finding that block is, you have to wait till that's 100 confirmations deep in order to be able to spend it. And this is exactly why. Because if you have two minors that find, you know, similar blocks at the same block height, they both in theory got a transaction going to them to give them that mining reward, right? And both of them have that, that coin based transaction, we call it going to them in each of their versions of the block, but we can't have both of them, right? Otherwise we have a fork and we want to avoid a hard fork. So under normal times, you know, we would find there, one of these is going to wind up becoming invalid and sort of forgotten about, and one of these will wind up being valid and sort of the truth on the network. So this unlucky soul here who had, they thought they had a mining reward going to them, but it turns out minors build on top of this chain. So this becomes invalid and that money they thought they had goes away, big bummer. But we all know this, you know, in the Bitcoin world, you know that, you know, that money, like you have to be compromised, especially that coin based transaction, have to be 100 confirmations deep before it's, it's yours and you can spend it. And this is very much a reason for why that is the case. So yeah. Any other questions? Yeah, we have another question here about notifications and updates and stuff. The question is, how does new software get broadcast to the network so that minors know to update? Okay. Excellent. All right. I will hold off on asking, answering that because that we're going to dive into that in this next section. So please hold on to that question. If I don't answer it in the next five or 10 minutes, then ask it again and we'll come back to it. Sounds good. Cool. All right. What else did I say about hard forks? All right. Conceptually, we can think of a hard fork as developing in four stages. Okay. Cool. All right. So let's go with. So we've talked about the different type of forks. Then we were talking about how a hard fork requires everyone to update can potentially lead to this split in the network. Divergence in the network. This is the type of stuff that definitely does keep Bitcoiners up at night. So let's walk through if that were to happen. There's an update coming to the network. And that is going to result in a hard fork, right? A partition of the network. What's that process like? Okay. So first it's, we can think of it as a software fork. And that's not entirely correct because, you know, thinking of a software fork is like a repo and then a different version of a repo. And that absolutely can happen. But also it could just be an update that happens to the one version of the repo. But there's a change in software, right? So we can think of it kind of like, first, there's a software fork. There we go. Then there's a network fork in the sense that sometimes we're using this word network a little bit differently. So this is confusing. But here what we mean is. First we change the software, right? And we'll get a little bit more in depth into how this happens. But, you know, the Bitcoin developers, they reach agreements and they decide to push into the repo, a change, right? Then all of the nodes and mining nodes out on the network need to update their software. And maybe this is contentious. And so half of them update in the other half say, nope, we don't like that. We're not updating. And again, if we think this was unit one where we talked about the balance of power in the Bitcoin ecosystem, developers, the core developers of Bitcoin have a lot of influence, right? They have power, but they can't make anyone run their software, right? Can't do that. So they could put it, put out a change, but there would be a whole bunch of people on the network would just go, nope, not downloading that version, not running it, not doing it, right? So first we had a change in the, the software. Then we had sort of a splits in the network on who's deciding to run what version of this, of this software. Then we have a mining fork is, and then we have this chain hits the miners. So now if we go back to this image, we can see that this miner here is running a different version of the software and is mining with different rules than this one is, right? So these miners are operating with different rules. So first the change hits the software, then it hits the nodes where they update or not. Then it hits the actual mining process. And then that results finally in the chain fork, right? That results in this image where blocks are being mined then with different rules and the chain starts to look like this where it separates into distinct change, chains. So just walking through that to get to sort of the step-by-step process of what happens if you actually have a, a breaking change, right? A hard fork that actually leads to a network, mining and chain fork. So sorry, that's a lot of sort of confusing vocabulary, but I hope that separates out a little bit. Okay. Talk briefly about soft forks before we dive into the update process. So a soft fork, kind of not actually a fork. Only consensus changes that are forward incompatible cause network forks, right? And there we need actual split in the chain. All right. A change implemented in such a way that non-upgraded clients can still use, can still see the transaction or block is valid under the previous rules. So just once again reiterating what we said previously that a soft fork doesn't actually cause a chain fork, like a split in the block chains because even on updated nodes can still, can still see everything that's happening as valid. All right. Soft fork upgrades can only be used to constrain the consensus rules, not to expand them, right? Otherwise you get that breaking feature. Okay. So now let's get to the part where you're saying, all right. So how does it happen that you can go through the process of making an update to Bitcoin that doesn't cause all this chaos and split the network, et cetera? How can we do this? And the answer is it's complicated. Very complicated. But again, I always keep this picture in my head, right? And because, you know, Bitcoin isn't centrally controlled, you know, if you just have to remember that what's happening in Bitcoin is just different people in different parts of the world just choosing to download and run software, right? So I always just keep this picture in my head. It's just somewhere, somewhere, someone, somewhere in the world with an internet connected computer that is there making the decisions on which version of that software to download and run on their machine, right? This is what's happening out on the Bitcoin network. So I always keep this picture in my head. All right. So what happens when you're trying to make an update as that first, the first step is the software developers, right? So recently we had a change to Bitcoin that was taproot. So it involved some change to signatures. We got snore signatures. We got different ways of doing sort of different types of transactions. But anyhow, let's call this upgrade taproot, right? And so what happened first is there was a process whereby for years, developers, Bitcoin Core developers and associated people who were involved with Bitcoin at that depth went back and forth for years debating, testing, theorizing, trying to come up with exactly how this change in Bitcoin transactions would function, you know, worrying about weird edge cases, running things on test nets to try and attack it and like just spending years researching and implementing this particular change, the taproot changes to Bitcoin. And then we're going to talk about a couple of different, so then we have that, we got all the way up to there. So we got to the point where here is a change to Bitcoin. Now in this particular case with taproot, it's sort of, it's a soft work, right? Like it's not going, it wasn't potential to split the blockchain into two different versions, right? So it's sort of backwards compatible. You don't have to do taproot transactions if you don't want to, et cetera, et cetera. But you have this particular change happening to the network. And we have to then decide that we're all going to agree or in certain cases, especially there's a hard for it, you have to find some sort of way to make sure you know that everyone on the network has upgraded and we're now ready for this change before we sort of turn it on, right? And then you have different signaling mechanisms. So here are two ones versus BIP34, which is signaling and activation. And this uses the integer value of the block version. So we're going to go look at this in just a second, look at block versions. But then we also have BIP9, which is signaling and activation again, but interprets the block version as a BIP field instead of an integer. Okay, so what this means is that if you, basically this isn't sort of minor signaling, right? So you have this version of Bitcoin that gets released that includes these new changes, right? But you don't quite activate them on the network yet. What you do is you say, okay, everyone's going to download this and then minors are going to signal to the network that they are ready for this upgrade by changing something in the block version. And there's different ways to do this, but we're going to look at sort of BIP9 here in a minute. So they can say, okay, this will take this block version value and there's like different, we'll take it as a BIP field and this BIP here, we're going to change to signal that we're ready for these tap routes changes to the network. And I'm kind of mixing up different examples. I just want to get you an idea of how this flow would go, right? So the first the software engineers spend years working on some particular change, then people on the network can download the new version of that. But before it gets activated, they're all, they're going to signal that they're ready for it. And then in some situations, again, there's lots of different versions of this process have been tried, but one example is that you can say, okay, after 90% of, you know, the minors are signaling that they're ready for this. And how you might calculate that is say out of the past 2016 blocks, because that's two weeks worth, right? So in the past 2016 blocks, if 90% of those block headers signal that they're ready for this change, this update, then we're going to say that change is now locked in, right? And then that means that in another two weeks, other 2016 blocks, that change will get activated. So first it gets, you get this minor signaling, right, that they're ready for it, then that gets locked in, then in two weeks it gets activated. All of this is built into the software, right? So this new version of the software says, hey, I'm going to look at what's going on in the past 2016 blocks. Once we get, you know, a segment of 2016 blocks where 90% of those blocks include the activation or signaling the activation of this change, then in the next 2000, next two weeks from now, we're going to activate this change and actually start using these rules. So this whole process is baked into the software that someone chose to download and run on their computer. So that's kind of a, you know, obviously you can get really in depth with this stuff, it's been tried a number of different ways, but this roughly is the process that happens now or slight versions of this process, is how you go from, you know, someone on some forum somewhere proposing a change all the way to get to the point where that's actually the new consensus rules on the network. And by going through this process. So here we go. First we define it, we test it, all right, then, you know, we start signaling for it, then it gets locked in, then it gets activated, right? So here's kind of, you know, this VIP nine process for how a change can get signaled, locked in, and then activated. And hopefully the idea is you go through this whole process and, you know, there's different thresholds that you can do, you know, it has to be all, you know, maybe only 60% of the people on the network or maybe that's to be 98% because this is some sort of breaking change, right? There's all sorts of different debates and ways in which you can do this, but you go through this process where it's locked in, then it's activated. So everyone knows this is once it's locked in, it's like, you know this is coming and you've got those two weeks to update or you might get kicked off or accidentally wind up on a little fork of the network over here, right? If this is a breaking change, if it's a hard fork, so to speak. All right. So all of this is complicated and it's incredibly difficult to make these sort of consensus changes to the network. It takes years, right? All right, so it's important, this is a quote from Mastering Bitcoin, right? It's important to recognize that there is no perfect solution for consensus development. Both hard forks and soft forks involve trade-offs. For some types of changes, soft forks may be a better choice. For other hard forks may be a better choice. Keep in mind that soft fork is the one that's kind of backwards compatible and hard fork is the one that could potentially split the network and the chain in two because it's not great two versions of the hardware or software which are not compatible with each other. All right. There is no perfect choice. Both carry risks. One constant characteristic of consensus software development is that change is difficult and consensus forces compromise. Some see this as a weakness of consensus systems in time. You may come to see it as I do as the system's greatest strength. So it's kind of a good thing and a bad thing that it is incredibly difficult to update Bitcoin, right? It means that you can't really mess with it because it's going through the process of changing Bitcoin takes years and you have to have incredible consensus and momentum in agreement on doing that. And then how to do it is, you know, it depends, right? Pluses and minuses for, you know, making breaking changes or making non-breaking changes. So that's a lot. We've got about eight more minutes left. Mike, are there any questions before we just go in and look at some block headers? Yeah, we have one question here. Is it possible to merge a hard fork? To merge a hard fork. Okay, so after the network has split to somehow bring it back together. So if we go, I'm assuming that's what the question is. So if we have this scenario, is it possible to bring it back together? The answer essentially is no. So if we look at, you know, Bitcoin cash split off from Bitcoin back in 2017, these histories are now so different from each other. We're coming up on like six years of differences. There's, there's no feasible way at this point to merge them back together. Because with the blockchain, every block has to reference the header of the previous block, right? So the only way to merge that back together would be like to completely redo one of those blockchains so that everything syncs up exactly, right? Keep this perfect chain of events. And so you would have to have enough computing power to completely redo six years of one of these blockchains. And currently on planet Earth, I do not think that kind of computing power exists. So essentially no, you cannot, unless you're only this fork is only in like the first two or three sort of blocks, right? Then you can kind of one gets dropped. Like you have these sort of natural or spontaneous forks and one kind of gets dropped and merged on the other, but you can't really like, is that really like merging like in like gets how you would merge? It doesn't work quite like that. It's just one gets disregarded and one gets carried on with. So short answer is no, you can't do that. Any other questions? Yeah, we got one more question here, but I'll save it for the end. It feels like a good ending question. Okay, cool. So we can get through the, we'll get through the work. We'll get back to you. Don't worry. Okay, awesome. Okay. So now we're just going to go quickly and look here. And do I have pulled up? Oh, okay. Hold on a second. I just got a reconnect to the node here. I've got my one of my nodes pulled up. Hold on. Make sure I'm on the right server. Indeed I am. Excellent. Okay. This is one of my nodes. It's running on main net. So we're just going to do a couple of commands so we can go look at what's currently being signaled on the network. All right. There aren't any big major changes coming up. So nothing here is going to be terribly content. We'll just have a quick look at it for fun. All right. So this is how many blocks are currently on the Bitcoin main net blockchain. Then we're going to go look at Bitcoin version on this node. I'm running an outdated version of Bitcoin 22. I think we're now at the 24. So I need to upgrade. But we're going to do gets blockchain info. All right. Okay, cool. So we have all kinds of information about we're on the main chain. This is how many blocks there are. This is how many headers I have downloaded on this computer. Best block hash. This is the hash of the latest blockchain that my node is aware of. I shouldn't copy that because it's not going to matter here. Okay. So now we're going to get the header for that block. So we're going to come here. Now I'm going to copy this there. Boom. Okay. So this is the latest block on the Bitcoin blockchain. This is the header. So here we have the hash. Oh, one confirmation. Okay. Did we just find another block? Here is the version. So I don't think I'll copy that. But all right. So we look at this. But then we say, okay. So this is going to be like that bit field, right? Where because this is a five or this is an eight, right? This means something. But what does it mean? Right. This is not very human friendly. So. Twitter. Twitter is both awful and beautiful all at the same time. And I was having this discussion on Twitter the other day asking people like, what is the best way to read this? Right. How do I re make this human readable? So I know what's being signaled here. And long story short, someone sent me this. And so we can kind of, I won't read through it now, but you can find it here, Bitcoin stack exchange, what restrictions is the version field and the block header have, right? So someone wrote this nice response. And it kind of breaks down for you how you can go through and read what's being signaled in that, that version field in the block header. So because this is highly technical and we only have two minutes left, I will just show you what this looks a little bit like. So signaling for taproot on bit two, right? Like what this, what this looks like. This is how this taproot change may have been implemented here with this type of signaling on bit two. Cool. So you can also go into a block explorer. Yep. Okay. Cool. So I have, this is the link that I was just talking about that we were just looking at here, but you can go on something like block stream.info or any other blockchain, blockchain explorer, you generally need to find like the advanced button. So it'll show you the actual version number included in that particular block. But if you're curious, you can go, you know, stroll through, you know, scroll through the different blocks, find a version in one of these blocks and maybe go to this link and try and decipher what exactly is being signaled there. Okay. So I think we've got that. Oops. Why is my phone going out? There we go. Okay. So Mike, I think we are now ready for that last question just about on time here. Okay. Well, it sounds good. We have a couple of questions I can just answer is a lot of this stuff is again, this is a supplement to our course, which Sailors course, which you can find link below in the description. I believe I'll double check when I get done. If not, you can find in the link below in the description, like five minutes after we're done, but it should be down there. And a lot of thank yous to you and stuff. So I just also, you know, want to want to share that with you. And the question I thought might be good to end this is people asked if you had what made recommendations you might have, you know, books other courses for people who want to continue learning about Bitcoin technology. Excellent question. So there are a number of, you know, this course references heavily the mastering Bitcoin second edition. And I think that's an excellent resource to dive into. I have, you know, a copy of it sitting right over there on my bookshelf. I come back to it regularly. So that's a great resource. Also Andreas Antonopoulos who wrote that book has a website that has a ton of different resources there. There are other really good books on Bitcoin, specifically this one called Programming Bitcoin, which I haven't made it all the way through, but it's another really good one. And then if you're interested in Bitcoin's second layer, the Lightning Network, there's another great book called Mastering the Lightning Network. I always try to post educational content and useful resources on, on Twitter, right? Twitter and LinkedIn. So I try to provide good resources there. And then, you know, their academy is a great resource too. So I hope that answers the question. Oh, real quick question. What is your Twitter handle? H. Michelle Rose. All right. Well, well, thank you everyone for joining us on for these eight units. Thank you again, Hannah, for taking us through it. And I will see you here next time for some other course, maybe. We'll see you guys. Have a good one. Keep learning everybody. Thanks for joining us.