 Hello, and welcome to the second lecture, which is going to be all about decentralization in Bitcoin. Now, in the first lecture, you saw a lot of the crypto basics that underlie Bitcoin, and we ended with a simple currency that we called Scroogecoin that seems to achieve a lot of what we want in a ledger-based cryptocurrency, except for one big glaring problem, which is that it relies upon the centralized authority called Scrooge, and we ended with the question of, how do we decrogeify this currency? How do we go to a decentralized version of this? That's what we're going to see today. What I find cool about this is that the way in which Bitcoin achieves decentralization is not purely technical, but it's a combination of technical and clever incentive engineering. And at the end of this lecture, you should have a really good appreciation for how this happens, and a lot of the magic or the mystery of Bitcoin should become clear to you in how it works and why it's secure and what makes it tick. So it turns out that decentralization is an important concept, not just for Bitcoin, but in fact, this notion of competing paradigms of centralization versus decentralization plays out in a variety of different digital technologies. To understand Bitcoin's decentralization, I want to start with the caveat that decentralization almost always is not all or nothing. Almost no system is purely decentralized or purely centralized. And a good example of this is email, which is a decentralized system, fundamentally I would say. It's based on a standard spaced protocol, SMTP, but what has happened, especially in the last decade or so, is that we see a dominance of a few different webmail providers which are sort of centralized service providers, and this might be a good model for understanding what might be happening to Bitcoin. So with that, let's delve into some of the technical aspects of Bitcoin's decentralization, and I would break this down into at least five different questions. Questions like who maintains this ledger of transactions? Who has authority over which transactions are valid? Who creates new Bitcoins? And in fact, other questions like who determines how the rules of the system change and how do Bitcoins acquire exchange value? So these are all components of decentralization of the Bitcoin protocol more or less, and the first three of these are going to be the questions that we will consider in this lecture. And when I say how is Bitcoin decentralized, what I mean encompasses the first three of these meanings. And I want to emphasize that there are aspects to decentralization beyond the protocol. That includes things like Bitcoin exchanges where you can convert Bitcoin into other currencies. It includes things like wallet software and a variety of other service providers. And so even though the underlying protocol is decentralized, these services that develop on top of it may be centralized or decentralized to varying degrees. And just to drive home this point, let me show you three different aspects of Bitcoin and where they fall on the centralization decentralization spectrum. First, there's the peer-to-peer network. And this aspect of Bitcoin, I would say, is the closest thing to purely decentralized. Why is that? Because anybody can run a Bitcoin node and there's a fairly low barrier to entry. You can go online, you can download a Bitcoin client yourself. It requires a lot of disconsumption on your computer, but basically you can run that on your laptop or your PC yourself. And currently there are several thousand Bitcoin nodes. And so this really resembles a peer-to-peer decentralized system. But that's not the only component of Bitcoin. There's also Bitcoin mining, which we'll study later in this lecture. And Bitcoin mining is technically also open to anyone. But it turns out that it requires a very high capital cost. It's a consequence of how the system happens to have evolved. And because of this, there has been a high centralization or a concentration of power in the Bitcoin mining ecosystem. And the community frequently sees this as quite undesirable. So this aspect of Bitcoin is not quite as decentralized as one might want it to be. And here's a third aspect, updates to the software. And this really gets to how and when the rules of the system change. And once again here, one can conceptually imagine that everybody running a Bitcoin node will look at the Bitcoin specification and maybe even create their own software. And again, you have a purely decentralized system. But of course, that's not how it works in practice. The core developers are really trusted by the community. And they have a lot of power when it comes to determining what Bitcoin software each of these nodes will run on their computer. So we've talked in a generic manner about centralization and decentralization. Let's now talk at a bit more technical level about Bitcoin and decentralization. And a key word that's going to come up again and again here is consensus, specifically distributed consensus. So what am I talking about here? At a technical level, the key challenge that you have to solve to build a distributed eCache system is called distributed consensus. And this is a class of protocols that's been studied for decades in the computer science literature. So, but intuitively, you can think of it as our goal being to decentralize Crugecoin, which is the hypothetical currency that we saw in the first lecture. So as I said, there's decades of research in computer science on these consensus protocols, and the traditional motivating application for this is reliability in distributed systems. What do I mean by that? Imagine you're in charge of the back end for a company like Google or Facebook. These companies typically have thousands or even millions of servers, which form a massive distributed database that records all of the actions that happen on the system, like users' comments and likes and posts and so on. So when a new comment, let's say, comes in, the way it'll be recorded is that there might be 10 or 15 different nodes in that massive back end that might contain copies of this action. Now, what the server needs to make sure is that that comment either gets recorded in all copies of that database or none of them. If, for some reason, because some of these nodes might be faulty, the action gets recorded in none of the databases, it's okay. You can go back to the user and say, there was a problem saving your post. Would you please try again? On the other hand, if some of the copies of the database saved it and others didn't, then you'd be in a lot of trouble because you'd have an inconsistent database. So this is the key problem that motivated the traditional research on distributed consensus. And you can sort of see the similarities to Bitcoin here, but we're going to talk in a bit more detail about the similarities and differences. So that was the traditional motivating application, but we can also imagine that if we achieved a distributed consensus protocol, and we were able to use that to build a massive global scale distributed key value store that maps arbitrary keys or names to arbitrary values, then that will enable a lot of applications. For example, a distributed domain name system, which is simply a mapping between human understandable domain names to IP addresses. Or a public key directory, which is a mapping between user email addresses, let's say, to their public keys. Or even things like stock trades, because this distributed database, instead of keeping track of who's paid whom, how much money, would keep track of who's transferred, what units of which stock to whom. And the cool thing about this is that now that Bitcoin has solved the distributed consensus problem in a certain sense that we'll try to understand in this lecture, we can also go ahead and try to think about solutions to all of these other related problems. And in fact, there are many altcoins. And altcoins, we'll have several more lectures about altcoins. But very briefly, altcoins are systems built on Bitcoin-like principles to achieve perhaps slightly different goals, sometimes currency systems, sometimes not currency systems such as one of these applications. So, given that we can solve distributed consensus now, and given that we can build a global distributed key value store, it enables a lot of these other cool applications. Okay, let's go to a technical definition now. The technical definition of distributed consensus is really quite simple. Imagine that there is a fixed number N of nodes or processes. And each of these nodes has some input value. And then a consensus protocol happens, and the two requirements on this consensus protocol are that the protocol should terminate and all correct nodes should decide on some value, the consensus value, right? And I say correct nodes because some of the nodes might be faulty or even outright malicious. And the second requirement is that this value that they agree upon cannot be an arbitrary value, but it should be a value that was proposed as input by at least one of these correct nodes. So, it's really that simple. But let's try to see what this might mean in the context of Bitcoin. So, to understand how distributed consensus could work in Bitcoin, let's start with the reminder that Bitcoin is a peer to peer system, right? So, what I mean when I say that Bitcoin is a peer to peer system is that when Alice wants to pay Bob, what she does is she's going to broadcast a transaction to all of the Bitcoin nodes that comprise the peer to peer network. And you can see here the structure of the transaction. This is similar to Goofy coin that we saw in the first lecture. And what a transaction is going to have is it's going to have Alice's signature, which the other nodes need in order to know that it really in fact came from Alice. It's going to have Bob's public key, which also acts as his address at which he wants to receive Bitcoins. And further, it contains a hash. What is this hash? Recall this notion of hash pointers that we saw in the first lecture. So this hash is a way for Alice to link together this transaction or this coin to her receipt of this coin from someone else previously, right? So those are the things that are contained in this data structure that we call a transaction and she's going to broadcast that to all of the Bitcoin peer to peer nodes. And notice something funny here, Bob's computer is nowhere in this picture. Now, Bob, if he wants to be notified that this transaction did in fact happen and that he got paid, he might want to run a Bitcoin node that's one of these peer to peer nodes in order to listen in on the network and be sure that he's received that transaction. But his listening is not in fact necessary for him to receive the funds. The Bitcoins will be his whether or not he's running a node on the network. So given this peer to peer system, what is it exactly that the nodes might want to reach consensus on? Well, given that a variety of users are broadcasting these transactions to the network, what everybody wants to reach consensus on is exactly which transactions were broadcasted and the order in which these transactions happened, right? So what does that mean specifically? How consensus could work in Bitcoin is that at any given time, all the nodes in the peer to peer network would have a sequence of blocks of transactions that they've reached consensus on. So recall that in Scroogecoin, for optimization purposes for efficiency, we put transactions into blocks and we link these blocks together on a blockchain. So we're utilizing a similar principle here. We could do consensus on transactions one by one, that would be okay, it would just be an efficient. So instead, we do consensus on a block by block basis. So at any given point, all these nodes in the peer to peer network would have the sequence of blocks that they've agreed upon already. And each node would then have a set of outstanding transactions that it has heard about. So recall that for these transactions, consensus has not yet happened. And so almost by definition, each node might have a slightly different version of the outstanding transactions that it's heard about. The peer to peer network is not perfect, so some node may have heard about a transaction, but not other nodes. So given that we have the setup, what could happen is that you have the sequence of blocks that everybody has agreed upon, a block is just a series of transactions. And now there are these, let's say, these three nodes in the system, each of whom proposes, each of whom has an input, the set of outstanding transactions that it's heard about. And they execute together some consensus protocol. And for the consensus protocol to succeed, you can select any valid block, even if it's a block that was proposed by only one node. And for a block to be valid, all of these transactions have to have the right crypto signatures and so on. So you could select any of these valid blocks and the consensus protocol would still be okay. If some transaction somehow didn't make it into this particular block that gets chosen as the result of a consensus protocol, it could just wait and get into the next block. So maybe this green block gets selected, it now gets added to the consensus blockchain, and then the protocol proceeds and rounds. So if you took the traditional theory of distributed consensus and applied that to Bitcoin, this is the sort of system that you might end up with. Now this has some similarities to how Bitcoin works, but it's not exactly how Bitcoin works. And why is that? And the reason for this is simple. Doing things this way is a really hard technical problem for a variety of reasons. There are some obvious ones. Nodes might crash and nodes might outright be malicious. But also because the network is highly imperfect. It's a peer-to-peer system. Not all pairs of nodes are connected to each other. There could be faults in the network because of poor internet connectivity and so on. And finally, there's gonna be a lot of latency in the system, because all of these things happen over the internet. They're not even within a single data center or something like that. And one particular consequence of this high latency is that there is no notion of global time. What does this mean and why is this important? It means that not all nodes can agree to a common ordering of events simply based on observing time stamps. It just doesn't work like that. So you can't possibly design your protocol by saying things like, take the node that sent the first message in step one and have that node do something in step two. You just can't work like that because not all nodes will agree on which message was sent first in the first step of the protocol. So this really puts serious constraints on what sorts of algorithms you can really put into your consensus protocols. And in fact, because of these constraints, a lot of the literature on distributed consensus is somewhat pessimistic and many impossibility results have been proved. I'm just gonna name a couple of these in case you wanna look them up, but I won't go into too much detail. One impossibility result that's very well known and pretty simple to understand is called the Byzantine Generals Problem. And a much more subtle one known for the names of the authors who first proved it is called the Fisher Lynch Patterson Impossibility Result. Under some conditions, which include the nodes acting in a deterministic manner, what they proved is that consensus is impossible even with a single faulty process. So despite these impossibility results, there are a few well known protocols and Paxos is probably one of the better known. And what Paxos does is it makes certain compromises. What it gives you is that it never produces an inconsistent result, which would be really bad. But it accepts the trade off that under certain conditions, albeit rare ones, the protocol can get stuck and fail to make any progress. But here's the interesting thing. These impossibility results were, they were proved in a different model. They were intended to study distributed databases. And this model doesn't carry over that well to this setting that Bitcoin operates under. So what these results really tell us more about the model than about the problem, in fact. And what Bitcoin does is that it violates a lot of the assumptions that go into these models. And because of that, consensus in Bitcoin ironically works better in practice than in theory. And what this really means is that the theory that was developed for a different set of problems needs to catch up in order to be able to say really interesting things about Bitcoin. But nevertheless, that theory is quite important because, for example, it can help us predict unforeseen attacks and really be able to come to strong guarantees on the nature of consensus and security in Bitcoin. So what are these different assumptions? What are some things that Bitcoin does differently? Well, first of all, it introduces the idea of incentives. And this is very different from any previous system for distributed consensus. And this is only possible in Bitcoin because it is a currency and you can use that currency to give incentives to the participants for acting honestly. And so Bitcoin doesn't quite solve the distributed consensus problem in a general sense, but it solves it in the context of the currency system. The other thing that it does differently is that it really embraces the notion of randomness. And what I mean by that is one of the things it does is it does away with the notion of a specific starting point and ending point for consensus. Instead, consensus happens over a long period of time, about an hour in the practical system. But even at the end of that time, you're not 100% sure that a transaction or a block that you're interested in has made it into the consensus blockchain. Instead, as time goes on, your probability goes up higher and higher, and the probability that you're wrong in making an assumption about a transaction goes down exponentially. So that's the kind of inherently probabilistic guarantee that Bitcoin gives you, and that's why it's able to completely get around these traditional impossibility results on distributed consensus protocols. So let's now dig into the technical details of Bitcoin's consensus algorithm. And while we're looking at that, we should keep in mind that Bitcoin does all of this without nodes having any persistent long-term identities. And this is yet again a difference from how traditional distributed consensus algorithms operate it. And if nodes did have identities, it would make things a lot easier for a couple of reasons. One is a pragmatic reason. It would allow you to put into your protocol things like now the node with the lowest numerical ID should take some step or something like that. So that's a simple pragmatic reason, which already, if nodes are completely anonymous, becomes harder to do. But a much more serious reason for nodes to have identities is for security, because if nodes were identified and it weren't trivial to create new node identities, then we could make assumptions like, let's say that less than 50% of the nodes are malicious. And we could derive security properties out of that. So for both of these reasons, the consensus protocol in Bitcoin is a bit harder. But why is it exactly that Bitcoin nodes don't have identities? Well, it's for a couple of reasons. One is that if you're in a decentralized model and a peer-to-peer system, there is no central authority to give identities to nodes and verify that they're not creating new nodes at will. And in fact, the technical term for this is a Sybil attack. Sybils are just copies of nodes that a malicious adversary can create to look like there are a lot of different participants when, in fact, all those pseudo participants are really controlled by the same adversary. The other reason is that pseudonymity is inherently a goal of Bitcoin. Even if it were possible or easy to establish identities for all nodes or all participants, we wouldn't necessarily want to do that. So Bitcoin doesn't give you strong anonymity guarantees out of the box, in that the different transactions that you make can probably be linked together. But at the same time, nobody is forcing you to put your real-life identity like your name or IP address or anything like that in order to participate in the peer-to-peer network and in the blockchain. And that's an important property. So what we can do instead is we can make a weaker assumption. And I kind of want you to take a leap of faith with me here, that this weaker assumption is something that is going to be feasible. And I'm going to make this assumption here and later show you how this is actually accomplished. And what this weaker assumption is, is that we're going to assume that there is some ability somehow to pick a random node in the system. And a good motivating analogy for this is a lottery or a raffle or any number of real-life systems where tracking and verifying people and giving them identities and verifying those identities is pretty hard. And so what we do in those contexts is we might give them tokens or tickets or something of that sort, and that then enables us to later pick a random token ID and call upon that person. So we're going to do something similar with respect to these Bitcoin nodes and further assume for the moment that this token generation and distribution algorithm has enough smarts so that if the adversary is going to try to create a lot of symbol nodes, together all of those symbols just get one token so the adversary is not able to multiply his power that way. So let's make this assumption for now and let's see what becomes possible if we make this assumption. Here's the key idea. What becomes possible under this assumption of random node selection is something called implicit consensus. So what is implicit consensus? In each round, and there are going to be multiple rounds each round corresponding to a different block in the blockchain, in each round a random node is somehow selected magically for the moment, and this node gets to propose the next block in the chain. There is no consensus algorithm. There is no voting. This node simply unilaterally proposes what the next block in the blockchain is going to be. But what if that node is malicious? Well, there is a process for this, but it is an implicit one. Other nodes will implicitly accept or reject that block. And how will they do that? If they accept that block, they will signal that acceptance by extending the blockchain starting from that block or if they reject that block, they will extend the chain by ignoring that block and starting from whatever was the previous latest block in the blockchain. And technically, how is that implemented? Recall that each block contains a hash of the block that it extends, and this is the technical mechanism that allows nodes to signal which block it is that they're extending. So given this, this is what the overall consensus algorithm in Bitcoin is going to look like. Now, this is a little bit simplified, and the reason it's simplified is, again, that I'm assuming sort of this magic random node selection process. But except for that simplification, this is pretty close to how Bitcoin actually works. So whenever Alice wants to pay Bob, she will create a transaction, and she will broadcast it to all of the nodes. And any one of these nodes is constantly listening to the network and collecting a list of outstanding transactions that have not yet made it into the blockchain. At some point, one of these nodes is going to be randomly called upon to propose the next block. It's going to round up all of the outstanding transactions that it's heard about and propose that block. Now, presumably that node was honest, but it could also be a malicious node or a faulty node and propose a block that contains some invalid transactions. Invalid transactions are those that don't have the right crypto signature or where the transaction is already spent. In other words, an attempt to double-spend. So if that happens, other nodes are going to signal their acceptance or rejection of the block, as we saw in the last slide, by either including the hash of this latest block in their next block or ignoring this block and including the hash of whatever was the previous block that they considered to be valid. So now let's try to understand why this consensus algorithm works. And the way I like to understand this is instead of asking why this works, let's try to ask, how can a malicious adversary try to subvert this process? So let's look at that for a second. So here, we have a couple of blocks in the blockchain. Assume that this extends to the left a long way back, all the way to what is called the genesis block. But here, I'm only showing you a couple of blocks in the blockchain. And that pointer that you see over there is a block referring to what is the previous block that it extends by including a hash of that previous block within its own contents. So a malicious attacker, let's call her Alice. What might she try to do? Can she simply steal bitcoins belonging to another user at a different address that she doesn't control? Now, even if it is now Alice's turn to propose the next block in this chain, she cannot steal other users' bitcoins. Why? Because she cannot forge their signature. So as long as the underlying crypto is solid, she's not able to simply steal bitcoins. Another thing she might try to do is if she really, really hates some other user bomb, then she can look at Bob's address and she can decide that any transactions originating from Bob's address, she will simply not include them in any block that she proposes to get onto the blockchain. In other words, she's denying service to Bob. So this is a valid attack that she can try to mount. But luckily, it's nothing more than a little annoyance because if Bob's block doesn't make it into the next block that Alice proposes, he will just wait another block until an honest node gets the chance to propose a block and then his transaction will get into that block. So that's not really a good attack either. So the only one that we're really left with for what a malicious node can try to do here is called a double-spending attack. So how might a double-spending attack work? To understand that, let's assume that Alice is a customer of some online merchant or a website run by Bob who provides some online service in exchange for payment and bitcoins. Let's say he allows the download of some software. So here's how a double-spending attack might work. Alice goes to Bob's website and decides to buy this item, pays for it with bitcoins. And what that means in technical terms is that she's going to create a bitcoin transaction from her address to Bob's address. She broadcasts it to the network and let's say that some honest node creates the next block, listens to this transaction and includes it in that block. So what is going on here? So there is this block that was created by an honest node that contains a transaction that represents a payment from Alice to the merchant Bob. By C subscript A, I mean a coin belonging to Alice and that is now being sent to Bob's address. Let's zoom into this in a little bit more technical detail. A transaction, as we saw earlier, is a data structure that contains Alice's signature here and an instruction to pay to Bob's public key and also a hash, what is this hash? This hash represents a pointer to the transaction where Alice in fact received that coin from somebody else and that must be a pointer to a transaction that was included in some previous block in the consensus chain. So visually it's going to look something like this. Let's pause for a second here because there is something subtle going on. There are at least two different types of pointers in this diagram that I've showed you. There is in fact a third one corresponding to Merkle trees but we're not going to look at that at the present moment. But these two types of pointers that I refer to are blocks that include a hash of the previous block that they're extending and transactions that include a pointer to whatever the previous transaction that where the coin came from. Right, so this is the situation and this block was now generated by an honest node and now let's assume that the next time a random node is called, that node is a malicious node controlled by Alice, right? So this is the blockchain as it stands right now. Bob has already looked at this blockchain, decided that Alice has paid him and has allowed Alice to download the software or whatever it is that she was buying on his website. Right, so as far as Bob is concerned, he's satisfied the transaction has completed. Alice has now received her goods in exchange for the payment. Now what might happen is if Alice now gets to propose the next block, she could propose a block that looks like this, ignores altogether this valid block over here and instead contains a pointer to the previous block and furthermore, it's going to contain a transaction that contains a transfer of Alice's coins to another address A prime that's also controlled by Alice. So this is a classic double spend pattern. What is going on here is Alice now creates a new transaction that transfers that coin instead of to Bob's address to another address owned by her and visually it's going to look like this. This is a completely different transaction also with a hash pointer going back to the same transaction referred to earlier, right? So this is what an attempt at a double spend look like and how do we know if this double spend attempt is going to succeed or not? Well, that depends on whether this green transaction here or this red transaction is going to ultimately end up in the long-term consensus chain. So what determines that? That is determined by the fact that honest nodes are always following the policy of extending the longest valid branch. So now, which of these is the longest valid branch? You might look at this and say, aha, the first one is the longest valid branch, not the second one because it's a double spend attempt. But here's a very subtle point that I want you to appreciate. From sort of a moral point of view, this transaction in green and the transaction in red might look very different because based on the explanation that I've given you, the first one is an attempt by Alice to pay Bob, whereas the second one is an attempt by Alice to defraud Bob and pay coins back to herself. But from a technological point of view, these two transactions are completely identical. The nodes that are looking at this really have no way to tell which one is the legitimate transaction and putting legitimate in air quotes because it's a moral judgment that we apply to it. It's not a technical distinction versus which one is the attempt to double spend. It could easily be the other way around. Now, nodes often follow a heuristic of extending the block that they first heard about on the peer to peer network, but it's not a solid rule. And in any case, because of network latency, that could easily be the other way around. So now there is at least some chance that the next node that gets to propose a block will extend this block instead of this one. Or it could be that even if it's an honest node, Alice could try to write that node or try to subvert the process in a variety of ways. So for whatever reason, without going too much into the details, let's say that the next node extends the block with the red transaction instead of the green one. What this means is that at this point, the next honest node is much more likely to extend this block instead of this one because now this has become the longest valid chain. So let's say that after one more block, the situation looks like this. Now it's starting to look pretty likely that this double spin has succeeded. In fact, what might happen is that this ends up the long-term consensus chain and this block gets completely ignored by the network and this is now called an orphan block and this is an example of a successful double spin. So now let's look at this whole situation from Bob the merchant's point of view and understanding how Bob can protect himself from this double spending attack. It's really gonna be a key part of understanding Bitcoin security. So let's look at what happened here again. We have a couple of blocks in the blockchain and at this point, Alice broadcasts a transaction that represents her payment to Bob and so Bob is going to hear about it on the peer-to-peer network right here even before the next block gets created. And so Bob can do something even more foolhardy than what he did in the previous slide which is that as soon as he hears about the transaction on the peer-to-peer network, he can complete the transaction on the website and allow Alice to download whatever she's downloading. That's called a zero confirmation transaction or he could wait until the transaction gets one confirmation in the blockchain which means that at least some node has created a block and has proposed this transaction and that has gone into the blockchain. But as we saw earlier, even after one confirmation, there could be an attempt at a double spend. So let's say that this actually happens. If as in the previous slide, the double spend attempt succeeds, what Bob should do is to realize that the block that he thought represented Alice paying him has now been orphaned and so he should abandon the transaction. Instead, if it so happens that despite this double spend attempt, the next block that's generated turns out to extend the block that he's interested in. Now he sees that his transaction has two confirmations in the blockchain. Now he gets a little bit more confidence that his transaction is going to end up on the long-term consensus chain. So let's say there's one more and now there are three confirmations. In general, the more confirmations your transaction gets, the higher the probability that it is going to end up on the long-term consensus chain because if you recall the honest node's behavior that they will always extend the longest valid branch that they see, the chance that this one is going to catch up to this longer branch is now very minuscule, especially if only a minority of the nodes are malicious. Because typically the only reason that this double spend attempt block would be extended at this point is if the next node to be picked randomly was a malicious node and then you'd need another malicious node and then another for the shorter branch to then become the longer branch. In general, the double spend probability decreases exponentially with the number of confirmations. So if the transaction you're interested in has received K confirmations, then the probability that this other transaction is going to end up on the long-term consensus chain goes down exponentially as a function of K. And the most common heuristic that's used in the Bitcoin ecosystem is that you wait for six confirmations. There is nothing really special about the number six. It's just a good trade-off between the amount of time you have to wait and you're guaranteed that the transaction you're interested in ends up on the consensus blockchain. So let's recap what we saw here. Protection against invalid transactions, that is protection against a malicious node, simply making up a transaction to steal someone's Bitcoins is entirely cryptographic. But it is enforced by consensus, which means that if a node does attempt that, then the only reason that that transaction won't end up in the long-term consensus chain is because a majority of the nodes are honest and will treat that transaction as invalid. On the other hand, protection against double spending is purely by consensus. Cryptography has nothing to say about this and true transactions that represent a double-spending attempt kind of look identical from the perspective of signatures and so on, but it's the consensus that determines which one will end up on the long-term consensus chain. And finally, you're never 100% sure that a transaction you're interested in is on the consensus branch, but this exponential probability guarantee is pretty good. After about six transactions, there's virtually no chance that you're gonna go wrong. So in the previous section, we got a basic look at Bitcoin's consensus algorithm and a good intuition for why we believe that it's secure. But recall that at the beginning of the lecture, I told you that Bitcoin's decentralization is partly a technical mechanism and partly clever incentive engineering. So far, we've mostly looked at the technical mechanism. Now let's talk about the incentive engineering that happens in Bitcoin. I asked you to take a leap of faith with me earlier in assuming that we're able to pick a random node and perhaps more problematically that at least 50% of the time this process will pick an honest node. But of course, this assumption of honesty is quite problematic, especially if there are financial incentives for participants to subvert this, then why would we expect any node to be honest really? So what we wanna ask is, can we give nodes an incentive for behaving honestly? Let's look at this with respect to the picture we've been looking at. This is the long-term consensus chain and this block contains an attempt to double-spend. We can ask, can we penalize somehow the node that created this block? But this is problematic for a number of reasons, including the fact that nodes don't have identities and so there's no way to go after them to penalize them. So instead, let's flip the question around and ask, can we reward the nodes that created all these blocks that did end up on the long-term consensus chain? Well again, sort of the same problem, we don't have no identity so we can't mail them cash to their home addresses. If only there were some sort of digital currency that we can use to incentivize them, a decentralized one perhaps. You probably see where I'm getting at. In other words, we're gonna use bitcoins in order to incentivize the nodes that created these blocks. So how are we gonna do that? Well, so far everything that I've said is just an abstract algorithm for achieving distributed consensus. Now we're gonna break out of that model. What I'm gonna say now is specific to the fact that what we're achieving through this distributed consensus process is in fact a currency and we're gonna incentivize these nodes by paying them in units of this currency. So how do we do that? There are in fact two separate incentive mechanisms in Bitcoin and the first one is called the block reward. So what is the block reward? It's just this. According to the rules of Bitcoin, the node that creates each block gets to include a special transaction in that block and that special transaction is a coin creation transaction. And this node can also choose the recipient address of this transaction. So of course that node will typically choose an address belonging to itself as the recipient of this coin creation transaction thereby paying itself. It's sort of you can think of it as a payment and exchange for the service of creating that block to go on to the consensus chain. In fact, the value of this coin creation transaction has an interesting property. It's currently fixed at 25 Bitcoins but it actually halves every four years. We're now in the second period. For the first four years of Bitcoin's existence, it was 50 Bitcoins. Now it's 25 and it's going to keep having. This has some interesting consequences. We'll come back to that in the next slide. But let me ask you this. It appears based on what I've said here that this node gets the block reward regardless of whether it proposes a block with only valid transactions or it behaves maliciously. So how are we actually providing any incentives for honest behavior via this block reward? But think about this. Well, how will this node sort of get to collect its reward? That will only happen if this block ends up on the long-term consensus branch because that's the only case in which this coin creation transaction will be considered valid because the coin creation transaction is not special. It's just like every other transaction. It's only valid if it ends up on the consensus chain. So that's the incentive mechanism here. It's very subtle, but it's a very neat trick. And so it incentivizes nodes to behave honestly or at the very minimum, it incentivizes nodes to behave in a way that they think other nodes are going to agree with in creating the next blocks of the blockchain. So that's the first incentive mechanism. Let's come back to this point now, this weird sort of having phenomenon that we see here. And this can be best illustrated graphically. Here I'm gonna show you a graph of time on the x-axis versus the total number of bitcoins in circulation. And this over here was the first period where each block resulted in 50 new bitcoins being created. And roughly at the end of last year, that block reward halved from 50 to 25. And you can see that every four years extending well into the future, the slope of this curve is going to keep halving. And this is a geometric series. And you might know that it means that there is a finite sum. And in fact, there is a total finite supply of bitcoins. And if you add up all these numbers, it works out to 21 million based on the rate of new block creation, which I'm gonna get to in a second. Also worth noting is that this is the only way in which new bitcoins are created. There is no other coin generation mechanism. And that's why this is a final and total number as the rules stand now at least for how many bitcoins there can ever be. And this new block creation reward is actually gonna run out in 2040 as things stand now. So that sounds a bit weird. Does that mean that the system will stop working in 2040 and become insecure because nodes no longer have the incentive to behave honestly? Well, not quite because this is only the first of two incentive mechanisms. There is quite another incentive mechanism called the transaction fee. And what is a transaction fee? So the creator of any transaction, not the creator of a block, but the creator of a transaction when Alice is paying Bob, what she can do is she can choose to make the output value of that coin less than the input value. And the way that all the nodes interpret this difference according to the rules of Bitcoin is that it's a transaction fee and whoever creates the block that first puts that transaction into the blockchain gets to collect that transaction fee. So if you're a node that's creating a block that contains say 200 transactions, then the sum of all those 200 transaction fees accrues to you and to the address that you put into that block. Of course, this transaction fee is purely voluntary like a tip, but we expect, based on our understanding of the system, that as the block reward starts to run out, it'll become more and more important to almost mandatory for nodes to put a transaction fee into their transactions in order to get a reasonable quality of service. And to a certain degree, this is already starting to happen now. But precisely how the system will evolve, it really depends on a lot of game theory which hasn't been fully worked out yet. So that's an interesting area of open research in Bitcoin. So now we've acquired an understanding of how the nodes that create these blocks are incentivized to act honestly or follow the protocol. And so if we address a few more of these remaining problems we'll be all set to have a really good understanding of how Bitcoin achieves decentralization. What are these remaining problems? Well, one of them, the first major one is the leap of faith that I asked you to take which is that somehow we can pick a random node. And the second is that we've created a new problem by giving nodes these block rewards and incentives which is that you could easily get into a free-for-all where everybody wants to run a Bitcoin node in the hope of capturing some of these rewards. And a third one is an even trickier version of this problem which is that an adversary might create a whole different number of civil nodes in order to really try to subvert this consensus process. So number three is sort of a trickier version of number two. It turns out that all of these problems are related and all of them have the same solution. And that solution is called proof of work. So what is proof of work? Here's the key idea. Instead of picking a random node we do something a little bit different which is we approximate selecting a random node by instead selecting nodes in proportion to a resource that we hope that nobody can monopolize. What does that mean? Well, if that resource that we're talking about is computing power then it's a proof of work system where we somehow select nodes in proportion to their computing power. Alternately, it could be in proportion to ownership of the currency and this is a legitimate alternate model. It's not used in Bitcoin but it's been proposed and it's used in a lot of alternatives to Bitcoin and that's called proof of stake which we'll see in a later lecture. But let's come back to proof of work. Let's try to get a better idea of what this means. Selecting nodes in proportion to their computing power another way to understand this is that we're allowing nodes to compete with each other by using their computing power and that will result in nodes automatically being picked in that proportion. So those are two equivalent ways to view proof of work. You can also think of a third way which is that we're making it moderately hard through proof of work to create new identities. So it's sort of a tax on identity creation and on the civil attack. This may all appear a bit vague so let me actually go ahead and show you what is the exact proof of work system that's used in Bitcoin and that's gonna make things a lot clearer. So here it is. It's called hash puzzles and what this means is that in order to create a block the node that proposes that block is required to find a number of nones such that when you put together in the block the nones, the previous hash and the list of transactions that comprise that block and take the hash of this whole long string then that hash output should be a number that is very small that falls into this small target space here in relation to this very large space that is the output space of that hash function. Let's look at it one more time. As we looked at it earlier, normally a block contains a series of transactions that you're proposing. In addition, a block also contains a pointer to the previous block as we saw and a pointer is just a string in this context. But in addition here, we're requiring that a block also contain a nones. And why is this? And the idea is that we wanna make it moderately difficult to in fact find a nones that satisfies this required property which is that hashing the whole block together including that nones is going to result in a particular type of output. And so we believe that if the hash function is secure then the only way to succeed in solving this hash puzzle is to just try enough nones as one by one until you get lucky. So specifically if this target space were just 1% of the overall output space you would have to try about 100 nones before you got lucky. And if this hash function were to behave essentially randomly only one in 100 nones will result in an output that falls within this target space. In fact, the size of this target space is not nearly as high as 1% of the output space. It's much, much smaller than that which we'll get to in a second. But fundamentally this is the computational problem that a node is required to solve in order to produce the block. Now this notion of hash puzzles and proof of work completely does away with the requirement for somebody somehow to pick a random note. Instead nodes are simply all the time independently competing to solve these hash puzzles. And once in a while one of them will get lucky and will find a random nonce that satisfies this property and that node then gets to propose the next block. That's how it's completely decentralized. There is nobody deciding which note it is that gets to propose the next block. So let's look at it in a little bit more detail now. There are three properties that I want to show you, essential properties of this proof of work function of this hash puzzle. And the first is that it needs to be quite difficult to compute. I said moderately difficult what I mean by moderately difficult. As of today, and you'll see why it varies with time, it's about 10 to the 20 hashes per block that you need to compute. So the size of the target space is only one over 10 to the 20 of the size of the output space of this hash function. Right, so it's, and if you look at it in terms of the amount of computing that your laptop needs to do, for example, this is simply a humongous and infeasible number. And because of this, only some nodes even bother to compete in this block creation process. And this is what is known as Bitcoin mining, basically the process of repeatedly trying and solving these hash puzzles. And we call these nodes miners. And because of how capital incentive this process is, this goes back to what I said at the beginning, that even though technically anybody can be a miner, there's been a lot of concentration of power or concentration of participation in the mining ecosystem. So that's the first property of these proof of work puzzles. The second property is that we want this cost to be parameterizable. It's not a cost that is fixed over all time. And the way that that's accomplished is that all the nodes in the Bitcoin peer-to-peer network will automatically recalculate the target that is the size of the target space as a fraction of the output space every two weeks. And they do it in such a way that they maintain this invariant, which is that the average time between any two successive blocks produced globally in the overall Bitcoin network is about 10 minutes. So let's think about what this means. What this means is that if you're a miner and you've invested a certain fixed amount of hardware into Bitcoin mining, but the overall mining ecosystem is growing, more miners are coming in or they're deploying faster and faster hardware, that means that over a two week period, slightly more blocks are going to be found than expected. And so nodes will automatically readjust the target. And so the amount of work that you have to do to be able to find a block is going to increase. So if you put in a fixed amount of hardware investments, the rate at which you find blocks is actually dependent upon what other miners are doing. So there's a very nice formula to capture this, which is that the probability that any given miner, Alice is going to win the next block is equivalent to the fraction of global hash power that she controls. Which means that if she has mining hardware, that's about 0.1% of total hash power, she will compute roughly one in every thousand blocks. So why does this readjustment happen? Why do we want to maintain this 10 minute invariant? Well, the reason is simple. If blocks were to come very close together, then there would be a lot of inefficiency and we would lose the optimization benefits of being able to put a lot of transactions as it currently stands, several hundred transactions in a single block. If you went down from 10 minutes to five minutes, it would probably be okay. And there are a lot of discussions about if we're doing an altcoin now, what is the block latency that we should have, but everybody agrees that the block latency should be a fixed amount. It cannot be allowed to go down without limit. And that's why you have this automatic target recalculation property. Now, because of the way that this cost function and proof of work is set up, it allows us to reformulate our security assumption. Here's where we finally depart from the leap of faith that I asked you to take several slides ago. Instead of saying that somehow the majority of nodes are honest, in a context where nodes don't even have identities and not being clear about what that means, we can now state crisply that a lot of attacks on Bitcoin are infeasible if the majority of miners weighted by hash power are following the protocol or are honest. And the reason for that is if a majority of miners weighted by hash power are honest, because of this competition for proposing the next block, this will automatically ensure that there is at least a 50% chance that the next block to be proposed at any point is coming from an honest node instead of a malicious one. Let's now look at the consequences of the fact that solving hash puzzles is probabilistic. Why is it probabilistic? Because nobody can predict which nones is going to result in solving the hash puzzle. The only way to do it is to try nones as one by one and hope that one succeeds. And so this process is called mathematically Bernoulli trials. I won't go into detail on that, but you can look it up. But typically nodes try so many nones that a discrete probability process called Bernoulli trials can be well approximated by a continuous probability process called a Poisson process. And the end result of all of that is that the distribution, the probability density function of the time defined the next block by any node in the network globally looks something like this. It's called an exponential distribution, but really the upshot is that there is some small probability that if a block has been found now, the next block is going to be found very soon or within a few seconds or within a minute. And there's also some small probability that it'll take a long time, maybe an hour to find the next block. But overall, the network automatically adjusts the difficulty so that the interblock time is maintained at an average long term of 10 minutes. So this is a graph that shows how frequently blocks are going to be created by the entire network, not caring about which miner this is coming from. If you're a miner specifically interested in how quickly you're finding blocks, what does this probability density function look like? Well, it's going to have the same shape, but it's just going to have a different scale on the x-axis. Again, it can be represented by a nice equation. For a specific miner, the mean time to find a block, given that you've just found a block, is going to be 10 minutes divided by the fraction of hash power that you control. So again, if you have 0.1% of the total network hash power, you're going to find blocks once every 10,000 minutes, which is several days. And so not only is your mean time between blocks going to be very high, the variance of the time between blocks found by you is also going to be very high. And this has some important consequences that we're going to be looking at in later lectures. So now let's turn to the third important probability of this proof of work function, which is that it's actually trivial to verify that a node has computed proof of work correctly. What does that mean? Even if it takes a node on average, 10 to the 20 tries to find a nonce that succeeds in finding the right property of the hash function, that nonce must be published as part of the block. So it's trivial for any other node to look at the block contents, hash them all together, and verify that the output is less than the target. So this is an important property because once again, it allows you to get rid of centralization. You don't need any centralized authority verifying that miners are doing their job correctly. Any node or any miner can instantly verify that a block found by another miner satisfies this proof of work property, and thereby they can be sure that this miner put in a lot of computing power into finding that block. Let's now look at mining economics because we've said that it's quite expensive for miners to be in operation because finding a single block takes computing about 10 to the 20 hashes. At the same time, we've also seen that the block reward is about 25 bitcoins, which is quite a lot of money. So it really boils down to an economics question of whether or not it's profitable for a miner to mine. But we can write down a simple equation that represents what the inputs into this decision are. Fundamentally, the mining reward that the miner gets is in terms of the block reward and transaction fees. The miner asks himself whether that's bigger than or less than their total expenditure, which is the hardware and electricity cost. In fact, Bitcoin mining is so expensive in terms of electricity that that becomes a significant portion of the cost and not just the upfront cost of the hardware. And if the rewards are greater than the costs than the miner profits, if not the miner incurs a loss. But there are some complications to this simple equation. The first is that as you may have noticed, the hardware cost is a fixed cost, it's an upfront cost, whereas the electricity cost is a variable cost that has incurred over time. Another complication is that remember that a reward that the miner gets depends upon the rate at which they find blocks, which depends on not just the power of their hardware, but in fact, more accurately, as the ratio of the power of their hardware as a fraction of the total global hash rate. So that makes it more complicated as well. Another complication is note that the costs that the miner incurs are in terms of dollars or whatever currency that they're using, whereas they're rewarded in terms of bitcoins that are created or bitcoins that are transaction fees. So this equation is really going to depend on what the exchange rate of bitcoin is doing at any given time. And finally, so far we've assumed that the miner is interested in honestly following the protocol, but it could be the case that the miner could deploy some other mining strategy instead of always finding the next block that extends the longest valid branch. And so this equation doesn't capture all the nuances of the different strategies that the miner can employ. So even though we can write down the simple equation, actually analyzing what it makes sense for miners to do is a complicated game theory problem and we don't have simple answers to that. Okay, so now we've obtained a pretty good understanding of how bitcoin achieves decentralization. Let's put it all together now and do a little bit of a recap and understand some high level points in order to get an even better understanding. So what I'm gonna do is I'm gonna do a very quick recap of several of the major aspects of bitcoin that we've learned so far. Let's start from identities. As we've learned, there are no real world identities required to participate in the bitcoin protocol. Any user can create a pseudonymous key pair at any moment, any number of them. And when Alice and Bob want to make a transaction, when Alice, for example, wants to know what address Bob wants to get paid at, that's not part of the bitcoin protocol. That needs to be through some other process, for example, on Bob the Merchant's website. So given these pseudonymous key pairs as identities, transactions are basically messages that are broadcast to the bitcoin peer-to-peer network that are instructions to transfer a coin from one address to another. And the coin really is just a chain of transactions to the extent that we can call anything in bitcoin an actual coin and this is something we'll see in much more detail in future lectures. And so this peer-to-peer network that we've looked at, its goal is to propagate all new transactions to all the bitcoin peer nodes as well as new blocks to the bitcoin peer nodes, but it's just gonna do sort of the best effort that it can. The real security of the system doesn't come from the perfection of the peer-to-peer network, in fact, the underlying assumption that the network is in fact quite unreliable, but instead, where the security comes from is from the blockchain and the consensus protocol that we spent a lot of time looking at. So what it means for your transaction to be in the blockchain is that it achieves a lot of confirmations. It's not a fixed number, six is a commonly used heuristic, but the more confirmations your transaction has received, the more blocks are found that extend the block that contain your transaction, the more certain you can be that your transaction was part of the consensus chain. And now, often there are gonna be a variety of orphan blocks. These are blocks that don't make it into the consensus chain. This could represent an invalid transaction or a double spend attempt. It could simply represent the fact that there is latency in the network and two miners competing to solve this proof-of-work puzzle simply ended up finding new blocks within just a few seconds of each other. And so both of these blocks were broadcast nearly simultaneously onto the network. So another subtle point here is that if Alice and Bob are two different miners and Alice has 100 times as much computing power as Bob, what that means is not that Alice will always win the race against Bob to find the next block, but instead Alice and Bob have a ratio, a probability ratio of finding the next block in the proportion 100 to one. So in the long-term, Bob will find on average 1% of the blocks that Alice does. So those are some of the basics of blockchain and consensus in where the security of the system really comes from. And finally, we looked at hash puzzles and mining. Miners are a special type of nodes that bother to compete in this game of creating new blocks and they're rewarded for their efforts in terms of bitcoins. And we expect that miners are going to be typically somewhere near the economic equilibrium of the expenditure that they incur in terms of hardware and electricity being somewhere equal to the rewards that they obtain in terms of the new block creation reward and the transaction fee-based rewards. So that's a broad recap of the system. Let me show you in a pointed way how deeply this notion of distributed consensus permeates Bitcoin. Now in a traditional currency, there is a consensus does come into play in a certain limited extent, which is we have a consensus process around what is the exchange rate of the currency. You can make a rough analogy to consensus and distributed systems. And that is certainly true in Bitcoin as well. We need consensus around the value of the exchange rate of Bitcoin, but consensus goes much deeper in Bitcoin than in other say fiat currencies. In fact, you need consensus around state, which is what the blockchain accomplishes that is a record of which transactions are valid or which transactions have even happened. So even the idea of how many Bitcoins you own is subject to consensus. What it means when I say I own a certain amount or number of Bitcoins is that I mean that the Bitcoin peer-to-peer network, as recorded in the blockchain, considers me the sum total of all my addresses to own a certain number of Bitcoins. That is sort of the ultimate nature of truth in Bitcoin. So ownership of Bitcoins is nothing more than other nodes thinking that I own a certain number of Bitcoins. And finally, we need consensus about the rules of the system because occasionally the rules of the system have to change. There are things called soft forks and hard forks and we're gonna see a little bit more detail of this in later lectures. Now I wanna show you another subtle idea, which is very tricky and it's this very neat idea of bootstrapping that I really found intriguing the first time I encountered it and so I wanna share this with you. So what do I mean by bootstrapping? I mean the tricky interplay between three things in Bitcoin and what are these three things? Let's start from the notion of security of the blockchain. So obviously we want the blockchain to be secure for Bitcoin to have to be a viable currency but what is necessary for the blockchain to be secure? What this means is that an adversary shouldn't be able to overwhelm the consensus process, shouldn't be able to create a lot of nodes and take over 50% or more of the new block creation. But when will that be true? What is a prerequisite for that? A prerequisite for that is having a healthy mining ecosystem made up of largely honest protocol following nodes. So that's a prerequisite for security of the blockchain. But what's a prerequisite for that? When can we be sure that a lot of miners will put a lot of computing power into participating in this hash puzzle solving competition? Well, they're only gonna do that if the exchange rate of Bitcoin is pretty high. Why is that? Because they receive rewards that are dominated in Bitcoins whereas their expenditures and dollars. So the more the value of the currency goes up, the more incentivized these miners are going to be. But what ensures a high and stable value of the currency? That can only happen if users in general, people who wanna buy Bitcoins have trust in the security of the blockchain because if they believe that the network could be overwhelmed at any moment by an attacker, then Bitcoin is not going to have a lot of value as a currency. So you have this interlocking interdependence between these three things, right? So the existence of each of these is predicated on the existence of another. So one might flip that around and imagine at the beginning during Bitcoin's creation when none of these three things existed. When there were no miners other than what we believe to be Nakamoto himself or whoever the creator was running the mining software. And when Bitcoin didn't have a lot of value as a currency and when the blockchain was in fact insecure because there was not a lot of mining going on and so anybody could easily overwhelm this process. How do you go from there not having any of these three properties to having all three of them? And that is what I mean by bootstrapping and it's this very tricky process of how all of these three characteristics were acquired by the Bitcoin system in an interdependent manner with each other and this was of course fueled by a lot of media attention as well because the more people hear about Bitcoin the more they're going to get interested in mining and the more they get interested in mining the more confidence people will have in the security of the blockchain because there's now more mining activity going on and so on and so forth. And so Bitcoin went from having none of these properties to now having in some large measure all three of these properties and that's the interesting bootstrapping feature of Bitcoin and every new altcoin that wants to succeed also has to somehow solve this problem of pulling itself up by its bootstraps. Okay, let me leave you now with one final thing which is that in order to understand consensus and what it's responsible for and what it's not responsible for a good way to do that is to ask ourselves what would happen if consensus failed and there were in fact a 51% attacker somehow who controls 51% or more of the mining power in the Bitcoin network. So let's see what happens in that case and let's list a whole variety of things possible bad things that we think might happen and let's ask ourselves which of these are possible for a 51% attacker? First of all, can this attacker steal coins from an existing address? Well, you might guess that the answer is no because stealing from an existing address is not possible unless you subvert the cryptography it's not enough to subvert the consensus process. This is a bit tricky. Let's follow through this line of argument. Let's say that this 51% attacker creates an invalid block that contains an invalid transaction that represents stealing bitcoins from an existing address that the attacker doesn't control and transferring them to his own address. Now this attacker can pretend that that's a valid transaction and pretend that that's a valid block and keep building upon this block and even succeed in making that the longest branch but the other honest nodes are simply not going to accept this invalid block and are going to keep mining based on the last valid block that they found in the network. So what will happen is that there will be what we call a fork in the chain. Now imagine this from the point of view of the attacker trying to spend these invalid coins and send them to some merchant Bob and buy something in exchange. Now Bob will presumably be running a Bitcoin node himself and that will be an honest node and that node is going to say oh this might be the longest branch but it's not a valid branch because it contains an invalid transaction because the crypto the signatures didn't check out and so it's going to simply ignore this longest branch because it's an invalid branch and because of that subverting consensus is not enough you have to subvert cryptography to steal coins from an existing address so we conclude that this attack is not possible for a 51% attacker. By the way in saying all of this I should note that this is all somewhat hypothetical somewhat a thought experiment because if there were in fact actual signs of a 51% attack what will probably happen is that the developers will notice this and will try to react to it and will update the Bitcoin software and we might expect that the rules of the system of the P2P network might change in some form to make this attack more difficult to launch but we can't quite predict that so we're working in a simplified model where a 51% attack happens but other than that there are no changes or tweaks to the rules of the system. Okay, let's move on. Can the attacker suppress some transactions? Let's say there is some user, say Carol whom the attacker really doesn't like and the attacker knows some of Carol's addresses and wants to make sure that no coins belonging to any of those addresses can possibly be spent. Is that possible? Well, let's think about this. The attacker, since he controls the consensus process of the blockchain can simply refuse to create any new blocks that contain transactions from one of Carol's addresses and can in fact also refuse to build upon blocks that contain such transactions and the attacker will be successful at that. However, the attacker cannot prevent these transactions from even being broadcast to the peer-to-peer network because the peer-to-peer network doesn't depend on the blockchain, doesn't depend on consensus and we're assuming that the attacker doesn't fully control the network so the transactions are still going to find a way to reach the majority of nodes. So even if the attacker tries this attack it will be very clear that that attack is happening because the peer-to-peer network will still receive these transactions. Okay, what about this one? Can the attacker change the block reward? Can the attacker start pretending that the block reward is instead of 25 bitcoins, 100 bitcoins or something like that? Well, this sort of corresponds to changing the rules of the system and because of a reasoning similar to what we applied for stealing bitcoins from an existing address, this is also not possible because the attacker doesn't control the copies of the bitcoins software that all of the honest nodes are running. So that's also not possible. Finally, let's ask ourselves if the attacker can somehow destroy confidence in bitcoin. Well, let's imagine what would happen. If there were a variety of double-spended temps and behavior of not extending the longest valid branch and other such attempted attacks, then people are going to look at this and decide that bitcoin is no longer acting as a decentralized ledger that they can trust and so people will simply lose confidence in the currency and we might expect that the exchange rate of bitcoin is going to plummet. In fact, if there is a 51% attacker and this is known, even if the attacker is not necessarily trying to launch any attacks, it's possible that this might happen. So this we can classify as not only possible but in fact likely that a 51% attacker of any sort will simply destroy confidence in the currency and this last one is in fact the main practical threat if a 51% attack were ever to materialize. None of these others really considering the amount of expenditure that the adversary would have to put into attacking bitcoin and achieving a 51% majority really makes sense from a financial point of view to try any of these other attacks. Great, so now hopefully you've obtained a really good understanding of how decentralization is achieved in bitcoin and understood identities, understood transactions, understood the peer-to-peer network, understood the blockchain and consensus, understood hash puzzles and mining. So you should be at a really good point now and a good launching point for understanding a lot more of the subtle details and nuances of bitcoin which we're gonna start seeing in the next few lectures. So the next lecture is gonna be by Joe Bono where he will address a lot of questions that take off from the point where we've left off in this lecture. The first is how do we get from consensus to currency? So this is an assumption that I've already made in this lecture, not only are we solving a distributed consensus problem, but also we're treating the results of distributed consensus as a currency in order to incentivize participants, but a lot of details are missing. What exactly does it mean to be paid in bitcoin? How does that happen? How are those transactions represented and so on? We're gonna look at that. We're gonna look at what else can we do with consensus? I hinted at this a little bit but it turns out that bitcoin offers a lot in addition to just doing consensus, it has a whole scripting language so there are a lot of interesting things to see there and so Joe is gonna take it from there in the next lecture. Thank you.