 Well, hello, everyone, and welcome back to another edition of Bitcoin for Developers. This is a supplement to Sailor Academy's SC112. If you have not started the course yet, there's a link below. Go ahead and get the course started and catch up to where we are. You'll also find a link to previous videos we've done in the series. If you have any questions as we're going along, please feel free to leave them in the chat. And if you're watching later, you can leave a comment and we'll try and get to that too later. But without further ado, I'll just hand it over to Hannah and she can get started and I'll be back if anyone has any questions. All right. Thank you, Mike. Okay. Good morning. Good afternoon. Good evening. We are going to dive into Unit 4 today, which is all about hashing. So the topics that Unit 4 covers are what is the hash, hashing algorithms, hashing and Bitcoin mining, and Merkel trees. And what we'll be focusing on today is proof of work. So specifically going back through what we talked about in the presentation on Unit 1, where we talked about how the Bitcoin network makes decisions and how this whole proof of work mining system works. So we're going to come back over that today. Now going a bit more in depth on the proof of work mining process, and then of course we'll also talk about Merkel trees. So that's what we'll focus on. And if we have time, depending on how we go, we'll do a very short hashing exercise in Python, which would be a bit of fun if we get to that. And again, please do ask questions, you know, all throughout this process, right? You know, it's much more fun when we can sort of have a conversation with each other. So if a question comes to mind, if something's not clear to you, if you'd like a bit more of an explanation on something, please drop that in the chat and I'll pause periodically and Mike will let me know if there are any questions in the chat. And you know, this whole mining process generally can be quite confusing. So there, you know, I would expect there to be lots of questions. So if you're wondering something like please do ask about it now is the good opportunity to get clarification on whether it's confusing about the process. All right, so we'll go back to our handy graphic here demonstrating some of the features of hashing algorithms. Now, you know, in the course, we talk a bit about different types of hashing algorithms here we're going to think pretty much, you know, we're kind of not going to dive too much into that in this presentation. We're just most of the examples and what we're talking about here, we're just talking about, you know, Shah 256, right, which is the hashing algorithm, which is, you know, Bitcoin makes very, very heavy use of. So we won't get into the different types of hashing functions, but important to keep it in mind that there are many different types. But if you have a good hashing function, right, one of the some of the features of a good hashing functions are demonstrated in this graphic here, right. So we have inputs, we have our hashing functions, which we run our input through and then we have an output. So what we can see here is that all of these different inputs are slightly different and as we would expect all of these same outputs are different, right, because every the digest or output of a hashing algorithm on should be unique for each input, right, so it should be deterministic, meaning if I put this same input here Fox, if I just run that string through the hashing function, I should always get the same output. This is just dummy output here. This isn't actually the result of the hashing algorithm, but it just gives you an idea that if I input this string here, I should always get exactly this as the output, right, so it should be deterministic. Also, another feature of hashing functions that, you know, have a lot of utility is that the input can vary, right. So we can have a very short, simple input, just the word Fox or we can have this whole sentence or in theory, you know, the entirety of the works of Shakespeare, right, and we could run it through the same hashing hashing function and gets an output that is the same length as just putting one word like Fox through that function, right. So that's what we're demonstrating here, right. This input, the red Fox runs across the ice should produce the same length output as just the word Fox. Also important to note that any change in that input, even if very small, here we have the same sentence, but we change it slightly instead of the Fox running. The Fox is now walking, right, instead of runs, it walks. But that one small change, even if you had the entirety of the works of Shakespeare and you change one word, when you ran it through that hashing function, you should get a very different output, right. These two outputs are very different and there's, you know, they don't look to be related in any fashion, right. And these are features that we want of a hashing function. Also very important to note that hashing functions are one way. As in if I have this hashing function, if I have this digest or output of a hashing function, even if I know exactly what algorithm was used, there's no way I can take that output and reverse engineer it to get what the original input was, right. It's a one way function. And that's very important to how lots of systems, but certainly to how Bitcoin uses hashing functions. So that's just a brief overview on some of, you know, we talked about this bit, I think that unit two, I can't remember, went over, you know, what hashing functions do. So we're just refreshing here before we dive into exactly how they're or some specifics on how they're used in Bitcoin. OK, so let's talk about how hashing functions are used. This is a bit broader than Bitcoin. They'll give us a good idea here. All right. So hashes are used to verify message or software integrity, right. So this is commonly used, I think, in a unit six will be downloading Bitcoin Core, it's part of the exercise, and we'll set that up and use some, you know, walk through using Bitcoin Core and walk through some commands there. Often when you download software, there's different ways to do it, but you can download a binary and you might want to check that you downloaded the correct version of Bitcoin or what you're expecting, right, because potentially someone could create a version of Bitcoin that's got a bug in it that every time you send a transaction, it just swaps out the data and that transaction to send the money to a specific address, right, not the one you were intending, right. Theoretically, that's possible. So you want to make sure that when you download Bitcoin, you're downloading an unaltered version of it. And one way you can do that is with the hash. So the, you know, developers of Bitcoin, when they make a release, they might say, you know, and people do this a lot with different, various different types of software. They might hash, like run that entirety of that code for that specific release through a hashing algorithm, generate that unique identifier for it, and then maybe sign that bit of data, right, that hash there with their key. So then you can get a hash. You could even just run that software or that, you know, zip file or whatever it is, different ways to do it, right, run that file through a hashing algorithm, verify that you get, you know, the specific hash that's on that website, maybe even go as far to validate a signature that was used to sign that specific hash, and so you have a number of different ways to just sort of check that that software hasn't been messed with in any fashion, because of course, we know one of the features of hashing is that even if one character was off in that, you know, all that software that was typed up, you know, if one character was off, if you know one bit, and you know, the binary was off, you would get a completely different hash, right, it would be different. This is one very useful way that hashes are used. And of course, in version control software like Git, you know, hashes are used extensively there, too. All right, digital signatures. Again, information is often hashed before it's signed, and that's just to, you know, make, you know, often for additional verification, but also simplicity, so a signature can be on a smaller bit of information rather than a whole bunch of information if there's, if the message being signed is large. So often when we're doing digital signatures, we'll first take that message, run it through a hashing algorithm and then that hash digest that output of that hash will be what gets signed, right? So you need all of that information and you need to know what hashing algorithm was used to produce that hash to then validate that signature. So it's used there it's handy there password verification. What often happens is, of course, if you're running a website and you're allowing users to log into your website. If you, you know, have them set up username and password, you then have you have the responsibility of safeguarding everyone's passwords, right? So one thing that is, you know, pretty standard practice is if you have a database that has passwords and you don't store the actual passwords, you store hash of that password, right? And then when someone comes in to sign into your website, you take, you know, that password that they gave you hash it with the same algorithm used to store the password and then see if those hashes match, right? And you can do all kinds of other stuff, adding like assault to the hashes, et cetera, you get in depth with that, but that's where hashes are used to increase privacy, right? So you're not directly storing people's passwords in a database. All right, data identifier, again, it's can be used not just to ensure the integrity of a message, but also just as an ID for it, right? You have this file or that file, and we can just identify those via their hash using a specific algorithm. And of course, proof of work, which is what we're really going to dive into here. So in a second, we'll start that conversation. So if you have any questions on hashing in general, now's a great time to type those into the chat. But let's talk a bit about the history of proof of work. So this concept proof of work that Bitcoin uses was actually not created in the context of digital currency or crypto or all right before the crypto industry. And this was in the early 90s, that some cryptography researchers came up with this idea is actually as I think they thought of it as a method of spam prevention, right? So the idea being if I wanted to send an email to prevent someone from spamming somebody with email, right, that I say someone would only be willing to receive email if that email came with a hash that met a certain criteria. And this might not make that much sense right now, but really going to walk through it. This idea of proof of work is that you have to generate a hash that meets a certain criteria. And one of the interesting things about hashing algorithms is when you put data in, you don't have any way to really guess what the output what that hash is going to look like. So if you say, okay, here's your, your email, but you can only send it once you've generated a hash for this email that starts with a zero, right? So it's a number and it has to start with zero that number. And so you can change you add a bit of data to that email called like a nonce, which is essentially just like a random number, a random bit of data you add to it. Remember, every bit of data you add to something changes the hash, right? So let's say I have an email, it's just like, Hey, Mike, good morning, how it's going? How's it going? The sun is shining in San Juan today, right? Cheers, Hannah, that's my email, right? Now I have to then just add a random number to it will start with the number four and run it through that hashing algorithm. And I have to keep attempting to do this until I randomly happen upon a hash that starts with one zero, at least one zero. Once I've done that, then I can include that hash. And so I have my message, I have the nonce that I use, maybe it was the number 5,620, right? And then I take, you know, my email, my nonce in the hash, and then I can send it out to one of you all. And your email provider will only let's say, I don't think this idea ever gotten acted. But in theory, like, okay, your email provider is only going to accept incoming emails if they see a hash meeting that specific criteria. And the reason you would do this is that my computer is going to have to go do some work, right? It's going to it's providing this creates proof of work, right? My computer has to do some work, spend some computational energy to find just basically guessing over and over again, right, increasing that nonce, right, has to do work to find a hash that meets with that specific criteria. So if I were trying to spam people, if I were trying to send out millions of emails every day to spam people, my computer would just be like melting with heat, right? Because it would be doing so much work trying to find valid hashes. So it makes it computationally expensive to send out spam emails, right? This is where this whole idea of proof of work came from. And we're going to come back over that and talk through that whole proof of work process a couple of more times in this session here today. But this is where proof of work originated as the spam prevention mechanism. Now it was then taken so this is early 90s when this proof of work concept was created. It created is just, you know, theoretical method of spam prevention. Then later, I want to say later in the 90s can't quite remember when there was a project called hash cash, which used it again in the context of digital currencies and won't dive into any of that. But just saying it was, you know, proof of work was created kind of, you know, imagined is the spam prevention mechanism, then the project hash cash imagined it in the context of digital currencies before, you know, the crypto currency and crypto industry. And then then it was, you know, what's so interesting about Bitcoin is really all of the pieces, pretty much all of the pieces of Bitcoin existed, it was just, you know, Satoshi that pulled them together into what we now see as Bitcoin. But this proof of work using proof of work as a consensus algorithm, right, this is the magic ingredients that makes Bitcoin Bitcoin and it solved what we call the business team general problem, right, really made it possible for us to come up with a decentralized entirely decentralized mechanism for a, you know, global peer to peer network to come to agreement on who has what's when without central authority, right? So let's pause there for a moment now that we've gone through hashes and kind of an intro to the history of proof of work before we talk a little bit more about that and then dive into the specifics. Mike, do we have any questions? We don't have any questions quite yet. I will mention I don't know if Ron Burgundy is too old of a reference for people, but this is CS 102, not SC. So that's my mistake. But we don't have any questions right now. But I guess I'll pose you one. When you're talking about hashing with like email and stuff that is that I assume that's the reason that when you like try and like, get your email, they won't tell you what your email is, they'll just say, they'll just say, Oh, well, we need to know all your questions, because we don't have access to your emails that is that related to the same thing about when you try and reset the password? Yeah, is that is the reason is that the reason they can't just like be like, here it is. Yes, yes, that that is quite likely what's going on. There's different setup, but that's standard practice now to like store things as a hash, right? So when you go to reset your password, like they don't have it. But yes, you notice that they'll notice when you use reused an old password, right? Because it might hash to a previous hash, they'll be like, Oh, you already used that one, you got to set a different one. So that would be how they would know if you've already used that password, but also not be able to give you your current password. Yeah, I did not know that. Well, well, thank you for that answer. We're not having any questions. I'm not seeing any more questions right now. But if you have them, you could get an answer to your question, too. But we'll, but I'll let we can keep going and I'll let you know if we have any other questions. Okay, cool. Alright, so a couple more and just I think in this slide, I just have some background information on proof of work in Bitcoin mining. We're going to talk about the mining difficulty target, right? So in a minute, we're going to walk back through the slides of where we have Charlie trying to double spend to Alice and Bob. And we'll go through that whole process. But what's also really fascinating about this, and again, we'll come back through it a few times because of lots of different pieces here. But there's this idea of a difficulty targets in Bitcoin mining, right? How difficult it is to find an appropriate hash on a block of data, right? And this is a question that people commonly have like how is like so we can say, you know, right now the difficulty is such and such and that means you have to find a hash that starts with four zeros, but then the difficulty goes up. Now you have to find a hash that starts with five zeros, etc. And that's what we call the difficulty targets in people often have questions on how that's like how does this decentralized network know? How does it have any idea what the difficulty target is supposed to be? And the answer to that one is that the difficulty targets is recalculated independently by every note on the network every 2016 blocks, which should be roughly every two weeks. So every note on the network takes all the data from the past 2016 blocks takes the time stamps on those blocks, you know, takes how much, you know, where we want were the Bitcoin software is trying to even things out such that a block is found roughly every 10 minutes. So if a whole bunch of computers with a whole bunch of computing power join the network, blocks will be found a lot more fast, right? And then the difficulty level will go up. In contrast, if a bunch of miners turn their machines off, it'll take longer and longer for the miners on the network to find a hash, which so then the difficulty will go down to try and keep that even, you know, roughly every 10 minutes. And you could write an entire course on just, you know, how to manage, you know, these consensus algorithms and how to even this out and should the difficulty adjustment be every block? How about every, you know, sort of two weeks? How about every two months, right? You could spend an entire course just talking about that. That's kind of its own separate science. But just bring this up here to answer those common questions as we dive into this. And then we need to note here that the mining process, all right, mining is the process of hashing the block header repeatedly, changing one parameter, which is generally this nonce until the resulting hash matches a specific target. Okay. Now with all that in mind, you know, that's kind of some different facts about this. Let's try and put it all together by walking back through this example, right? So here in the middle, we have Charlie. And if you'll recall from our store, our story from unit one, Charlie legitimately owns one Bitcoin, right? He, that's his legitimately, he's the owner of that Bitcoin. Now he owes Alice one Bitcoin and he also owes Bob one Bitcoin. And what Charlie wants to do is what we call a double spend. He wants to attempt to send Alice and Bob the exact same Bitcoin, right? Now the cryptography, all of this signing and all of this sort of stuff, this can validate that indeed Charlie owns that Bitcoin and that he has indeed signed a transaction going to sending that Bitcoin to Alice and he has indeed signed a transaction sending that Bitcoin to Bob, right? So he has legitimate ownership of that Bitcoin and signed two entirely valid transactions. But the network has to prevent his him double spending, right? Charlie can't send the same Bitcoin to both Alice and Bob, right? So the network has to come up with a way of deciding which one of these transactions is valid, even though cryptographically, both of them are entirely valid. So one of them has to be accepted and the other one has to be rejected in order to prevent a double spend, right? And this is the magic sauce that is Bitcoin, this proof of work mining process, this proof of work consensus algorithm is what solves this problem makes this work. So let's walk through it. So Charlie signs these two transactions, they're both entirely cryptographically valid, he broadcast them to the network. These, you know, red computers, which we can see on the screen now, this is just a representation of a mining computer. Because when someone sets up a mining rig or wants to be a miner, generally, they'll buy a specialized computer, which is really good at, you know, running hash functions, right? I believe it's, you know, shot 256 hash functions, right? But get computers that have chips in them, they can just do hash functions really, really fast, right? So you're two people in the world, you know, maybe this one that's got Alice's transaction, maybe that's in Santiago, Chile, and then this one that's got Bob's transaction, maybe that's in Oh, China's not so friendly anymore, let's say Tokyo, right? That's that one's in Tokyo, right? So Charlie broadcasts these two transactions out to the network, these miners are sitting on the network, gathering up all this transaction data, putting it into a block, and then hashing it, right? So they take all these transactions, they shove it into a block or test to meet, you know, certain criteria, and then they try to hash it to come up with a hash that meets the current difficulty requirements on the network. And for Bitcoin, that is the difficulty requirement is how many zeros does that hash start with, right? And I can't even remember how many zeros it is currently, but like, it's a lot, like it's the difficulty target is high. So it takes a really, really specialized computer, you know, 10 minutes, right? On average, of course, you know, let's say one specialized computer, it's going to take at least 10 minutes to come up with a hash just hashing over and over and over again trying different, different nonces, like different random bits of information on there to change the output to just guests at what the right hashes. So how Bitcoin solves this issue is that this miner that has Alice's transaction and that miner that has Bob's transaction or the out the transaction going to Alice and going to Bob, they have different information, right? Because it just happened that, you know, they saw that transaction first, they took the first valid transaction, they rejected the second one, right? Because that's what the software is programmed so you can only send the same UTXO once, right? So they have competing information and which one is valid and which one rejected is rejected as a double spend depends on who wins this race, right? So here are these two miners that are just hashing, hashing, hashing, hashing, trying to come up with a valid hash. If this miner that has that transaction going to Alice, they come up with the winning hash before the miner that has a transaction going with to Bob. Well, they broadcast, they say, hi, yay, we found a block excellence, we found the appropriate hash, we're going to make money, we're going to get the block reward, we're going to get all the transaction fees that were in that block, all the transactions that were in that block. We're going to get the fees from all of those, yay, we win, they immediately broadcast out to the network the solution, right, that they want, here's my block of data, here's the knocks I used, here's my hash. And how hashes work is that you can't reverse engineer them, right? But you can very, very quickly validate that data, right? So all the other nodes and miners on the network can very quickly see that block of data that that miner sense, including the transaction going to Alice, check the non sonnet, run it through the hashing algorithm and see that indeed that hash matches that data and is meets with the current network standard, right? So if that were to happen, then the entire network at that point, once that block is propagated out, if you get a bit more complicated, if there's forks, all kinds of weird stuff, we'll talk about that in unit eight, but generally the vast majority of the time, vast, vast majority of the time, what's going to happen is this block then gets broadcast out, everyone can validate it and see that yep, this transaction going to Alice is considered to be the valid transaction, the one going to Bob is rejected as the double spend. And of course, if that had happened in the opposite way, if the miner that happened to have that transaction going to Bob had won that round the race of the race, if it had found an appropriate hash prior to the other miners, then that trend, that Bitcoin would go to Bob and the transaction going to Alice would be rejected as a double spent. So here is the block header, which is the bit of data that gets hashed over and over again, we'll come back to this slide in a minute is we talk a bit more about Merkel roots, and we're going to talk about Merkel trees. But first, I'd like to first of all pause for questions. And then we're going to go to this link here, which is a mining simulator. So, you know, we've talked all about this, but then we'll get to do it ourselves, which will help us get a bit more of a feel for it. You can also just type this URL into your browser on your computer and give it a try. So first of all, Mike, do we have any questions? Oh, yeah, we do have a couple questions here that we can get through. So let's start here with the first one. It seems like the Bitcoin blockchain exists independently of the Bitcoin core software. I someone could write their own code to interact with the blockchain. Is this true? And then a follow up. If this is true, how are the rules enforced? Okay, so this is a really fascinating topic, right? And and we dive into it a bit in Unit 8 when we talk about like how the software is updated, right? So kind of the Bitcoin software and the Bitcoin blockchain are separate things like it is the blockchain is essentially just a data structure, right? But it's a data structure that's created by the network that is created by the Bitcoin software, right? So these things are kind of all dependent on each other, but they are different components. What? Let me think. So yeah, they're different. It is that software that sets the rules for how that peer to peer network is kind of out of your network is formed, but certainly how blocks are formed, what transactions can get included in those blocks and that software kind of governs, you know, the difficulty level on the network, what sort of algorithms are being used, what qualifies as valid or qualifies as invalid or gets rejected as invalid. So it's that software that creates that structure that is the Bitcoin blockchain, that data structure. So these things are dependent upon each other. But they are sort of different components of the same system. So I hope that answers the question, but also in Unit 8, we dive into the really fascinating topic of how do you update something on the Bitcoin network, right? How do you enact a change to the software without the central authority, right, to push through that change? And how do you do that without fracturing the network? That's an interesting conversation. So we can come back to that in Unit 8. Excellent. And always a great time to remind people that this is a supplement to the Sailor Academy's course. So if your questions aren't answered in this unit, they might be in another unit that's coming up soon. But we do have another question here we can get to here for a minute about the Byzantine general problem and how Bitcoin solves that problem. Okay. So the Byzantines general problem is like, how do you coordinate how it can be a bit complicated? It's computer pure networking problem that existed, you know, long before Bitcoin and kind of the magic of Bitcoin is that essentially solve the Byzantines general problem. So the Byzantines general problem is like a very old school example for a very modern technological problem. And so when you have this peer to peer network without a coordinator, how do you trust the data that you're getting? And it kind of uses this old school analogy of like all these generals lining up trying to attack a city, but they have to coordinate like they're only going to successfully attack the city if they all attack at the same time. So they have to coordinate between them, but how do you know if one of them is a defector and trying to throw off the whole system? Right. It's just this this and it's a very specific technical problem, but it's this term for how can you trust the data coming from other people? How can you know that it's valid? How can you all come to an agreement when, you know, there's no central authority, there's no way to centralize that information. And so it is this whole mining process called, you know, this Nakamoto consensus, right? This proof of work consensus algorithm that solves that problem just by doing the work, right? So the computer that did the most work fastest to find that winning hash can broadcast that out and everyone can see that that's valid data, right? Using hashing and in cryptography and etc. Everyone can be like, aha, that's valid. They won that race, right? So it's just the Byzantines general problem is referencing, you know, this computer networking issue of how how to come to an agreement between these groups of people, like all these nodes, all these computers on this network, when you can't necessarily trust any particular one of them, right? You might know that your buddy is running a node and she's going to be honest with you, right? But there might be all these other kinds, all these other nodes on the network that you have no way of trusting. They could be very well be sending you bad data. So you can't just like all kind of vote on what's the, you know, best block or, you know, like just doing other sort of mechanisms of coming to consensus doesn't quite work in this scenario. And so this consensus algorithm solved that problem came up for a way for us to mathematically validate who had won that round and essentially what is the correct data. I hope that answers that question. Do you have any others, Mike? I'm not seeing any other questions in the chat right now. I do. I hope that answered people's questions. If you have any other questions, feel free to leave them in the chat. But I think we can move on. I think we're moving on. We're moving on to the yep, I can see it. All right. Okay, I'll change that shot up. All right. Excellent. So this is just a website. Actually, don't even know what this this business is, but shout out to them because they create this really cool mining simulator here, which is handy for us to demonstrate this. All right. So we are essentially going to attempt to mine a block, right? So let's say that I'm a Bitcoin miner and I here I have lots of data. This is specifically a block header. Okay, now I am going to add a nonce to this data, right? And that nonce is zero. Boom. And this particular website, I was playing with this the other day to refresh my memory. And I think it considers that we found like a valid block or a valid hash when we have a hash down here when the output of this hashing algorithm gives us four zeros, right? So we can see right now what it's doing is it's taking this data that I typed in. It's concatenating that, I believe, with this nonce, which is zero, but anyhow, it puts that data together. And then it runs it through a hashing algorithm and this is the output of that hash. It does not start with four zeros. So we did not find a winning block here, right? The network is not going to accept this as valid. So let's try again. Then we'll try a nonce of one. Oh, we changed that one bit of data. The entire hash changed. You see that, but it's still not valid. It still doesn't start with four zeros. So let's try it again. Two, well, the hash changed again, but still not valid. Now watch the hash change as I type in three. Oh, cool. There's a zero, but not four at the beginning. So that doesn't work. All right. Well, that one starts with the C. So that's not valid. Let's try five. Well, that starts with an F. That doesn't work. You see, we can sit here, right, and do this all day. So they also gave a cool button for us here, right? I'm going to push mine. And when I mine, it's just going to go through and it's going to increment the nonce by one and hash, hash, hash, hash and keep trying it again until it happens upon a hash with four. I think it's four zeros at the beginning. So we'll try it and we'll see how many zeros. And then also we'll be able to look at the nonce and get an idea for how many attempts were made to find that hash. So I'll try it now. Boom. OK. So basically just over twenty three thousand attempts were made and then it found a hash that starts with is that four zeros? Yeah, I think that's four zeros, right? And now it's green so we can see that that's accurate. Right. So imagine if we had to sit here and just go up by one twenty three thousand times that we'd be here for days, right? So thankfully, you know, the server of this website's running on did that for us and just try it again and again and again and again twenty three thousand times until it found the specific nonce which added to this data produces this hash which meets the requirements, right? So that gives you an idea of this is essentially what a blockchain Bitcoin miner is doing, right? When they're attempting to find a block and we'll try one more here. So we'll change the data. Say Buendia, just how people like to greet each other here in Puerto Rico and we'll start with the nonce of zero. Well, it starts with an A but not four zeros. Let's try it again. One, no, two, no, three, no, four, no, five. No, we could keep doing this, right? All day, but probably it would take a very long time and be very boring. So instead, we're going to push this mind button and let a computer guess what the appropriate nonces to satisfy that hash output requirement. Well, it's taken a while. See how many attempts it's made. Well, there we go. See, this one took a lot longer. It took a hundred and seventy thousand attempts, right? To find a nonce that when added to this data produces a hash. This one has five zeros. Small print. It's hard for me to read. But that is the first hash you could find that satisfied that that criteria, right? So I hope visualizing it a bit like this helps with understanding what's happening. Mike, let me know if we have any questions, but otherwise I think we're going to dive back into Merkel trees. We'll cover Merkel trees a bit. We do have one question here from the chat. Can you hear me? Sorry, I don't know. I can hear you. I switched that up so I didn't know if it came and switched back for me. We do have a question here about how long how long would it take for a losing minor to know that they lost? OK, great question. So let's go back to this here. They're in competition with each other. They were going to know pretty quickly. Like if, you know, the minor holding Alice's transaction, the transaction sending funds to Alice, right? If they find, you know, a winning hash, right? They're going to know the second, you know, like that mining simulator, it turns green. They're like, aha, and instantly their software is just going to be like broadcast. Tell everyone we've won, right? So probably within seconds of that minor finding the winning hash, they're just going to immediately broadcast it out to the network and then it depends on network latency issues, right? But probably within seconds, the minor holding the transaction to Bob is going to see that come through, right? It's going to message show up. Hey, we found the next block has been found, right? And it'll go, ah, darn, you know, I didn't win, but let me just validate that. And it, you know, take essentially takes that information and runs it through the same thing, takes that block header, takes, you know, concatenates it with the nonce, runs it through the hashing algorithm and boom, if it gets the hash that is valid with network standards and is the hash, you know, that it's of that specific data from that minor, then it goes, ah, it's, you know, validated that they've lost that particular round of the race and they'll just instantly get started on trying to win the next round of that race. So the answer, the short answer there is within seconds, really, it would be very, very fast. Um, that's great. Thanks. And I have just a follow up question of my own, which might be done. Could you could someone I know would be like impossible, but could you like guess it? Like, is the right answer already exists in the computer is trying to find it, right? So like, there are a way to think of it. Sorry, right answer, right? Like, like, so the whole idea that you can't reverse engineer, right, you can't select the data that's going to produce a certain output. And that's, you know, very, you know, that's the way the math works and the way the math needs to work for this whole setup to continue the way it is. So there isn't necessarily one right answer. There could be a number of different nonces that would produce a valid hash, right, a hash that the network would accept. There's no particular, there's no mathematical way to determine what that the appropriate nonce will be to deliver a certain hash. So the only way you could do that, I guess, if you're psychic, right, you can try just psychically coming up with a number and entering it in and hoping it works. But no, the minors of the world have not found any way because mathematically, like, you can't do that, you have no way of knowing what the outputs of the hash function will be. All right, well, great. Well, thanks. And again, anyone, if you have any more questions, please leave them in the chat and I'll pop back in if I'm needed. Cool. Thank you. All right, hashing block headers. So here we have a nice little visualization of the block chain every 10 minutes, you know, another block gets added to it and stacks on top of the last one. Again, this is the block header that's what gets hashed. And then we have to just talking here briefly about the whole chain aspect of this is each block references the header of the last, right? And that data is gets included in, you know, the data that makes up the new hash. So in this way, because we look here, the previous block hash is included in every new block. So in this way, all of the blocks in the blockchain are cryptographically tied to each other, you couldn't move them around and order them, because of course changing any tiny little bit of data in this block header would produce a completely different hash. So just referencing that here, that all of these blocks are tied together because each new block references the hash of the previous block. All right, now take a sip of water and then we'll drive drive into Merkel trees. And while the you know proof of work consensus algorithm is the magic sauce that makes Bitcoin. Merkel trees are used in so many things in Bitcoin, I joke that like I had a penny for every time I said Merkel tree, I have a lot more Bitcoin, because I just reference Merkel trees constantly. And, you know, a lot of times as you're working with Bitcoin based applications, all this stuff is sort of abstracted away. But if you ever get into the woods with it, ever get into the weeds, like, if you go in depth, you're gonna have to, you know, have some understanding of Merkel trees. So let's talk about it here, the data structure, but also remember that in this block header, right, all of the transactions that are in that block aren't included in the header. But what is included is the Merkel root which is a hash of the root of the Merkel tree of this block's transactions. So we'll talk through what that means, but essentially, all of the transactions that are included in the block are hashed in this particular fashion to come up with one hash at the end, which then gets included in that block header. So a block header references a very specific set of data or a very specific set of transactions. So even though just like the hash or the header is getting hashed, there's no way to swap out any of the transaction data that's in that block, because again, changing even one tiny thing would change the entire hash of this data. So how these things are summed up is we want to take, let's say we have 200 transactions that are in this particular block, right? It could be a lot more than that, but let's just say 200, right? And we want to find a way to hash all 200 of those transactions down to just one short hash, right? We want that hash to somehow summarize all of those 200 transactions. So what we do is create a Merkle tree. This gets its name because I believe there was some computer scientists and it was last thing was Merkel who invented this. So good job, Merkel, I say your name like 15 times a day. You would take all these transactions, right? And you would line them all up like this, right? And this is called a tree because this data structure winds up looking like, you know, upside down tree can see. And this is why this is called the root of it because imagine if we flipped it up like a tree, that would be the roots that were then going into the ground, right? So the idea is we take all these transactions, right? Here we have transaction A, transaction B, C, D, etc. And we line them all up. And this isn't exactly how the computer would do it, but this is how we can think about it, right? Line them all up along the bottom of that first layer along the bottom. It's important that you have an even amount. So if for some reason, I think I have that reference there now, okay? So for some reason you have an odd amount, it's just that last transaction gets duplicated. So it shows up twice, you have to have an even amount. So what we do is we take these first two transactions, right? And we'll settle on our hashing algorithm we're going to use all throughout this, right? And we take this transaction A, we hash it, we get a hash, we take this transaction B, we hash it, we get a hash. So the first thing we do is hash all of those transactions on the first level. Then we take the first two transactions A and B and we put them together those two hashes and hash it again. So now we have another unique hash for this layer of the tree, right? The sort of second layer we can think of it. And then we go to the next two transactions, transaction C and transaction D. Those are both hash. We take those two hashes, we put them together, we hash those hashes to produce that one hash, right? And so then we have this hash here on this layer of the tree, right? And of course, this is a very simplified Merkel tree showing just four transactions, but then we would have these hashes of these two layers. So we have this hash that we produce, which is hash A, B and we have this hash, which is hash C, D. Then we would take those two, put it together, run it through another, the same hashing algorithm, right? Run it through again, then we get hash A, B, C, D, right? And in this very simplified example, if we just have these four transactions, then this hash here, A, B, C, D is the Merkel root. And it is that bit of data that would then get included here in this part of the block headers. And this matters because then if someone comes along and tries to just change one little thing about transaction B, well, that's going to produce a different hash here, which will produce a different hash here, which will produce a different hash here. So with that, but the way this is structured, if I change just one tiny thing and any of the transactions included in this tree, this root hash will be completely different. Right? So this is how we can know that here's all this transaction data. Here's the Merkel root for that all that transaction data. And therefore, I know that if anyone changes any of this data, even slightly, this Merkel root is going to be completely different. So let's because we're running, we've got 10 more minutes, let's run right into a couple more things about Merkel trees, and then we'll pause for questions. So here is just another slightly more accurate representation of this, because of course in a real block, you might have, you know, a thousand transactions, right? And so that gets would be graphically pretty difficult to display on screen with, you know, a thousand transactions, then you would have to have more and more sort of layers reaching up to that root, that final hash. But this is, you know, a bit more realistic here, we can see we have a b, which goes into hash a b, which then gets combined with this one, this is a b c d, which then gets combined with this one, which a b c d f g h, which then goes into here, and you see this on and on, you get this root hash. So I hope this is fairly clear. I'll mention one more interesting thing about this, which we know is kind of like another level course, we won't really get into that here. But there's this cool thing to know about that gets used in many different Bitcoin features now. But this idea of doing a Merkel free inclusion proof, right? And you can also use this just to validate that a specific trend transaction is included in a specific block, right? So you can provide a proof, right? Without having it was cool about this, you can provide an inclusion proof without having to have knowledge of all of the transactions that were similar summarize in a particular Merkel tree, right? So it doesn't look like a huge improvement on data just from this picture here, because there's only how many is that 1215 or so transactions in this example. But remember that in actual Merkel tree represented in this way would be like so big, we couldn't the font would be so small on the screen wouldn't be able to see it, right? Could be thousands of transactions. So in this way, what we can do is let's say we are interested in this transaction here HL, right? The hash of transaction L. So it's transaction L that we care about. And we want to make sure is included in a specific block. And so is summarized in a specific Merkel tree root, right? So we have this hash, which we know is in a specific block header. So it means that this transaction should be in that specific block. But we want to validate it cryptographically, right? We're a mathematical proof that that transaction is in that block. So someone could provide us with some information, which is this Merkel tree inclusion proof, right? And say, okay, so I need to tell you about this transaction. I need to tell you about its pair on the Merkel tree, which is, you know, this K transaction K. So I need to give you, you know, transaction L you already have, I need to give you transaction K. I need to give you the next level up the, you know, hash that was paired with on the next level up, which is this hash of i j, you can then calculate this cool, then I need to give you just the hash of this level on the Merkel tree, which is hash of MNOP. You can calculate this cool, then I'm going to provide you with the hash of this level over here on the Merkel tree, which is ABCDFGH, right? And then you can recreate this hash, right? So I'm going if I want to provide a Merkel inclusion proof, I'm going to provide you would already have transaction L I would provide transaction K. I would provide this hash, this hash and this hash. And of course, you would already have, if you just had transaction L and the Merkel root, if I provided you with these three hashes also along the way, you would be able to take this data, plug it in and recreate this hash. And if you successfully recreated that hash, that's pretty darn good mathematical proof that that transaction is really included in that block, right? So this is used in all kinds of different applications because you can store a ton of data in these Merkel trees, but you just want to provide the, you know, inclusion of proof, you don't want to have to be sending around all of that data all the time, right? So this is a very efficient way to prove that this data is valid about having send around a ton of information. So let's pause there. And Mike, we'll see if we have any questions. Certainly, we have a question that's came in a little bit ago. But we have a question here. So if you want to change data, you sorry about that. If you have to change data, you have to do a lot of work and spend a lot of energy. Is that correct? Yes. So now we can talk about, you know, 51% attacks or how someone could try to change some sort of data. So the idea is that the longest chain work is the winner, right? Or the chain with the most accumulated proof of work. And again, I think we get into this a bit more in unit eight. So I won't dive into that a lot now. But the idea being if I wanted to go back in time, let's just say even two blocks, right? This is the latest block here. Don't worry about reading all the fine prints. I know that's a bit hard to read. That's just summarizing, you know, the block headers, right? And how they all reference each other, right? So if I wanted to go back and change one transaction that was three blocks ago, right? Back in this block here. All right. So I would have to gather up all the transaction data that was in that specific block, right? So on the blockchain, I'd have that. I would have to change one specific transaction. Of course, there would be the difficulty of providing a valid signature or unlocking script for the inputs to that transaction, right? Let's assume we could get past that. I just wanted to, you know, you know, Charlie regrets sending that transaction to Alice. He wants to send it to Bob instead, right? So I go and recreate that entire block. I create a valid Merkle root. But of course, now that I've changed that transaction, the Merkle root included in this block is different, right? So I then in order to get the network to accept this change that I've made, I have to create a longer blockchain, right? I have to recreate the hash valid hash on this block. I have to recreate a valid hash on this block. And I have to win like the next block, right? You know, so I would have to be able to find a hash, right? I would have to have mining computers that are like three, four times faster, you know, than anyone else's computers on the network to recreate all of that work, right? To recreate these valid structures, data structures that the network will accept. So if you're just like trying to change something that's right here, right at the tip of the blockchain, then it's possible that I could just, you know, change this, find a valid block and then perhaps find the next one. Highly unlikely, but okay, maybe, right? I could if I had really, if I had a whole bunch of mining computers working for me, right? And I wanted to change that one thing right at the tip of a blockchain. Maybe I could, right? And this is why sometimes if we're doing really high value transactions, we'll say that we want, say, like six confirmations. And what we mean by that is we want this our transaction to be buried in the blockchain, like six blocks down, right? Because once you get to that layer deep, like there is not enough computing power on the planet to recreate those six blocks or to create new, a new six blocks reorganizing all of that data, you'd have to find a winning hash for different data because the Merkel roots would then be the Merkel roots and the block headers would then be different all the way up. So we'd have to recreate all of that data. So the amount of computing power that would be necessary to recreate all of that in the next 10 minutes, just like doesn't really until we come up with really good quantum computers, right? Just doesn't really exist. So it's pretty darn good security. So we can be pretty darn sure that no one's going to be able to rewrite the blockchain. So I hope that answers the question. Awesome. Yeah. If that didn't answer the question, let's know I'm refreshing the chat here now. Let's know if you have any other questions. I think we have we're running a little short time. I think we do have a couple more slides to get through. So I was probably no, I think we have any because we did have this exercise, but that was just bonus. If we got to it, I think we spent too much time talking about Merkel trees. We won't do the exercise. So maybe we have time for one more question if there is one. Um, yeah, let's see if anyone here has any final questions here about we didn't really have anyone's curious here about the Merkel trees that we didn't really get any questions about that. If anyone needs any clarification. And of course we'll just remind you that will be do my vamp thing while this is going on just reminding you guys that will be here again next week, going over unit five. You know, if you found us just now, you can go back and check out the other videos. And of course, check out the course itself because these videos are a supplement to the course. Um, and of course, just while we're waiting, I want to thank everyone for, you know, the conversation that it happened. Thank you, Hannah, for taking us through it. Um, why don't while we just have like one more minute here, why don't you just tell people what the next unit's about just in case in case that's what they had the question, what we're doing for you. I honestly can't remember what unit five is because I've been so worried about the exercise for unit six, where I have to go through and make sure that like all of the commands for setting up a node and running through like unit six, we're going to like, um, construct some transactions using Bitcoin core, which will be really cool. So that's like, that's what's been on my head is like, I unit five, I got that unit six, I got to make sure all these commands are up to date, you know, because things do change slightly. I'm not, I'm not worried about because I'm excited for unit five Bitcoin data next week. Bitcoin data. That's it. That's why that's why we pay up so we have enough time. All right. All right, well, I'm not seeing any new questions come through here. So I just want to again thank you, Hannah, for taking us through this and thank everyone for joining us. And we will see you here same time next week for unit five Bitcoin data. See you there.