 Okay, so we're in the middle of explaining Bitcoin design and gotten to the point of wanting there to be a global published record of all the transactions. All right, okay, and this requirement is very similar to the requirement for certificate transparency from last week and the solution is somewhat reminiscent of what we call the more sophisticated than certificate transparency solution. And a name, we want a public log, this is often also called a public ledger. Okay, so how are we going to build ourselves a public ledger so that everybody agrees on all the transactions that have already happened and furthermore, they agree on the order of the transactions because if Y tries to send this coin to both Z and Q at the same time, we want the first one to win and the second one to be ignored. Everybody agree on which transaction came first and which came second and should be ignored. Okay, so how to make a ledger? So here's a bad idea. Well, a good idea actually, the most simplest idea is to just pick somebody who everybody trusts and have that somebody maintain the ledger for you. Every time you want to do a transaction, you tell the trusted entity what the transaction is, it just accumulates a log and it's willing to give a copy of that log to anyone so anyone can inspect it and see if coins already been spent. And that actually is a good idea and if you could possibly do it, you should. For various reasons, the Bitcoin designers rejected this very obvious straightforward idea. And the fundamental reason is that in a big system, in a worldwide system, there's unlikely to be any single entity that everyone trusts and that is indeed trustworthy and has no corrupt employees, for example. And in a global system, that means that we can't have the United States government run the trusted entity because there's plenty of governments in the world who don't necessarily trust the United States similarly for any other individual government. So really for a global system, there's no, it's easy to argue against the idea of having a single central trusted entity. So that leaves us with, well, we want to run the system, make a system that's built out of mutually untrusting participants where we can survive malice by their participants. Okay, so here's a bad possibility. Let's just let anybody, let's build a system in which anybody can join. So it's gonna have thousands maybe of computers, we'll call them peers, they're scattered all over the internet and each one of them is gonna be running the software for our new cryptocurrency system. Anytime somebody wants to have a new transaction like Y wants to send a coin to Z, Y floods their new transaction, sends their new transaction to all the peers could send them directly or another design which is actually what Bitcoin uses that Y sends a new transaction to a couple of the peers and then the peers afford it sort of over individual TCP links to the entire rest of the system. So every transaction ends up being sent to all the peers and the peers, what they're trying to do is each of them maintain a complete copy of the log of all transactions. And what we really want is for all the peers, at least all the honest peers for their transaction logs to be identical, they'll agree on which transactions exist and just as important on the order of those transactions. So how can we arrange for all these peers to end up processing the adding the transactions to their logs in the same order? Remember, of course, Y may have sent the transaction to Z to these peers and at the same time sent its transaction to Q to some other set of peers and we wanna make sure that despite that, the peers end up with the same with identical logs even if Y is trying to trick them. Well, I actually don't know how to design this. One possibility that you can imagine is that the peers would somehow talk to each other about each new transaction and for each new slot in the log would vote on what transaction should fill that slot and have the majority, since they may disagree legitimately if they receive different transactions, we have a majority rule that says, well, all the peers are gonna look at all the votes and the transaction that gets the most votes is the one that'll go in the next slot in the log and then they'll vote again on the next slot. And maybe you could get this to work. You'd have to know who all the other peers are in order to know what a majority is. You don't have to know how many peers there are and you really wanna make sure that you never count any peer more than once. But in a completely open system like Bitcoin, actually we can't do either of those things. We don't know how many participants there are on Bitcoin and furthermore, the number changes all the time as people peers join and leave the system. So we don't know how many peers are so we don't know what a majority would be. Furthermore, we don't have a way to reliably count votes such that each participant only gets one vote, even assuming that was desirable. For example, we can't use IP addresses in order to decide distinct votes. We can't say, well, each IP address gets one vote or most one vote because it turns out to be extremely easy to either forge IP addresses or by breaking into people's computers to accumulate tens of thousands of real computers that you can control. And you of course would, you can get them all to vote on your, you can get them all to vote in the system. So an attacker could probably accumulate a majority of votes relatively easily in a sort of straightforward design like this. And if an attacker can get a majority of the votes then it can use this majority to sort of say different things, conflicting things, but with a majority each time. So if Z asks the system, oh, which of the two transactions came first, because remember the problem we're worried about is that Y is gonna double spend some coins. So it's gonna spend the same coin to Q wants Q to believe that and it's gonna send that same Q coin to Z and wants Z to believe that. So maybe when Q asks what's the next transaction to log the majority controlled by the attacker can say, oh, why is transferred to Q is the very next one to log and that comes before this transaction. And when Z asks, maybe the attacker's majority will say, well, the transfer to Z comes first and this other transaction to Q comes second. And that would mean the attacker can trick Q and Z into accepting the same coin. That's a double spend and that's a disaster. So without some very clever idea, it's very hard to build an open system without a controlled membership. It's very hard to build an open system in which you have reliable voting. Okay, but in fact, Bitcoin doesn't quite use voting, but it nevertheless manages to solve this problem. Of how to get agreement on a single ledger despite malice. So this is the Bitcoin blockchain and at this point, there's a lot of different blockchain systems out there. So actually I'm not even sure what blockchain as a term refers to, but I'm only talking about Bitcoin right now. Okay, so the goal is we want agreement on a single transaction log again, because we want to get a single transaction log and again, because we want to prevent double spending. And we're gonna be building, Bitcoin builds this thing called the blockchain that contains all the transactions on all the coins. So there's a single blockchain that describes all the transactions in the system. Again, as with the previous system, there's gonna be many peers. So we still have this kind of overlay network of peers and each peer is kind of building a copy of the log and a complete copy of the transaction log in its own memory. And we don't know how many peers there are, how many there are, who they are, but they form a sort of one of these overlay networks by with TCP connections. And anytime a peer hears about a new transaction like when Y wants to submit a payment transaction to Z or Q, it's gonna send it to one or more peers and that peer is gonna flood the transaction over the whole system. The way the log is built up, the way the blockchain is built up is that each of the peers accumulates transactions and packs many transactions, thousands into a block and then it's entire new blocks of transactions that are really appended to the ledger. Again, by flooding new blocks over the whole system so that at least in theory, every peer sees every new blocks. So the blockchain, all the blockchains consist of blocks. What each block looks like is the hash of the previous block and it's a bit like my previous transaction, broken transaction system. So we have the hash of the previous block, the cryptographic hash of the previous block. There's a set of transactions. So these are individual spends from, Y is trying to pay Q or whatever it happens to be. Couple hundred or couple thousand individual transactions and each transaction is actually much as I described before, it has the hash of the previous transaction for that coin which is gonna exist in a previous block typically. It has a signature by the private key the previous owner of that coin and it is the public key of the new owner. So this transaction would have that transfers money from Y to Q would contain Q's public key and a signature by with Y's private key plus a hash of a previous transaction, a previous block. As well as these transactions, there's a nonce, which we'll talk about in a moment, just a 32 bit number and then the current time, roughly. The way the system works is that the peers accumulate new transactions and roughly every 10 minutes, one of them produces a new block that should be the successor block containing all the transactions that have been sort of sent into the system in the 10 minutes, roughly since the previous block was created. And if somebody tells you they're paying you Bitcoin, then before you accept that they've really done it, you need to watch the blockchain as it evolves and the new blocks are sent everywhere so the blockchain is quite public. If you think somebody claims to have paid you, you need to watch the blockchain until you see a new block that contains the transaction that you're expecting from the person that claimed to have sent you money and with your public key in it and that looks valid, correctly signed. Okay, so everybody has to watch the blockchain for payments to them. All right, so who creates each block? This action of creating a new block is called mining and the technique that's used to produce a new block is often also called proof of work in the sense that it requires a lot of CPU time to produce a new block and so the production of a new block essentially proves that you control a real live CPU and you're not just mining new blocks on a fake computer. The new block needs to, in order to be valid, a new block when you hash it has to have a certain number of zeros at the beginning of the hash of the block. Now, of course, if you just take a bunch of arbitrary transactions and you do a cryptographic hash on it, it's highly unlikely that the hash of some, just whatever data is gonna have more than one or two or three zeros at the beginning of the cryptographic hash. However, the computer that's mining the block could put any value it likes here for the knots and so what the mining computers do is that they try different random values for the knots. Just pick one with a random number generator, they'll stick it in their copy of the block they're trying to mine and then they'll compute the hash on the block and they'll check how many zeros, how many leading zeros are on the hash with this particular knots. If it's enough leading zeros, I don't know how many it is but it's sort of on the order of dozens. If there's enough leading zeros then it's a valid block and whatever peer it was that found this knots that caused the block hash to have lots of leading zeros can flood this block over the network and all it's being equal, that'll be the new next block in the chain. But typically the hash of the block with any given knots won't have enough leading zeros and the peer will have to try another random knots. Keep doing that until it gets a block that hashes to a hash with enough leading zeros. And so this takes a lot of CPU time. It takes, it's a random process but the system is sort of tuned and the number of zeros that are required to exist at the beginning of the hash of the block is set so that it takes about 10 minutes with all the different peers, hundreds of thousands of peers out there who are doing Bitcoin mining the average amount of time before the first one of them finds a knots for a block that has enough leading zeros is set up to be 10 minutes. Okay, so question, how do peers or new peers discover other peers to communicate with? Yeah, it's a great question. So this is sort of a reference to the network of Bitcoin peers. If I'm a new peer, if I install a new computer, I get Bitcoin software installed on my computer and I want to join the Bitcoin network. How do I know who to talk to? And how do I know? Well, so the straightforward answer to that is that the Bitcoin software has built into it the IP addresses of a whole bunch of current peers. And so your software, when you first fired up the binary, the source, whatever the Bitcoin software has a whole bunch of IP addresses in it and you'll try to make TCP connections to those existing peers. And if all goes well, you'll be able to connect to them and you'll say, look, I'm new, please give me a copy of the blockchain as it exists now. And I'll send you the current blockchain, which is about a couple hundred gigabytes right now. So that's if all goes well. If all doesn't go well, then you may run into problems. Like for example, if your copy of the software has been modified by somebody malicious to have a list of IP addresses that are all controlled by the attacker or the attacker controls your computer network so that regardless of who you try to connect to, you end up actually talking to the attacker's machines. It may be that the attacker is running their own isolated network and that you think you're new install software thinks it's made a bunch of connections to Bitcoin nodes, but whoops, they're all attackers nodes. In that case, the blockchain you'll get will be a blockchain controlled by the attacker and you may well, you will be in trouble. And there's Bitcoin as some defenses against this. Maybe the main, well, if you downloaded correct Bitcoin software, the correct Bitcoin software has built in hashes of recent blocks in the blockchain. And that means that if you connect to some attackers and you're running proper Bitcoin software, at least the blockchain has to start with the first however many thousand blocks in the blockchain have to be correct. If you downloaded absolutely wrong software modified by the attacker, then there's just nothing Bitcoin can do to help you. And this is a potential weakness in the system. I haven't necessarily heard of anybody exploiting this, but it's definitely something to think about. Okay, back to mining. Okay, so if you wanna create a new block, you gotta find a knots that causes the new block you're trying to produce causes it's hash to have lots of leading zeros for an individual machine, the amount of time for an individual ordinary computer to find a knots that satisfies this requirement is like at least in the months of CPU time, but there's a very large number of Bitcoin miners out there. And so even though any one of them would take a very long time to find a new block or we really care about is the time for the very first one of them to find a block. And since they're all making these sort of random choices of knots, one of them is gonna find a, a knots that fulfills the requirements relatively soon. And the number of Bitcoin adjusts the number of leading required leading zeros in the hash in response to how fast new blocks seem to be appearing. And so if new blocks are appearing much faster than once every 10 minutes, Bitcoin will automatically increase the number of leading zeros that's required. And that'll make it correspondingly harder and take longer for the miners to find a new block. Then a blocks are of course arriving slower than every 10 minutes over a sustained period of time and Bitcoin will adjust the required number of leading zeros in the hash to be smaller. And that means it'll be easier, quicker to find new blocks. So there's sort of an adaptive scheme there to a new box to show up once every 10 minutes, roughly. Okay, so this is the proof of work scheme. And this is essentially a solution and in a funny way to the, that voting problem I mentioned a few minutes ago where you can't really have sound practice or have majority votes because we're not sure who the participants are or how many there are because people may sort of create fake computers, fake IP addresses, whatever it will. Here, you have to use CPU time, which is a sort of real resource that cannot be faked in order to contribute a new block and that means that while it's not really a voting scheme, what it's essentially doing is the new block gets to come from a effectively random choice over the different computers that are involved in mining. So this scheme is sort of a random sort of cryptographically reasonably strong random selection process for who gets to choose the next block. And so if there's a small number of attackers, they're highly unlikely to be selected by this process in order to contribute the next block. Now what that means is that if most of the participants or most of the CPU power in the system is controlled by non-malicious people, then most of the new blocks will be found by non-malicious people. And that's not an immediate solution to double spending, but we'll see that it's the key to the double spending defense. Okay. All right, so let's go back to our example. We have a block chain that maybe looks like we currently block five. Block five has been published to everybody. All the peers are working on mining a potential block six. So we don't know what it's gonna be yet because the miners are still working on finding a valid knots, but we know that it has a bunch of transactions in it. Well, if at this point, why broadcasts, say it's payment to Z, well, the miners are already working on this block. So why is new transaction, even if it sends it out now, probably not gonna be incorporated in the block that's been currently mined, but all the miners will kind of keep this new transaction and a buffer on the side. And when one of them does find a new block for block six, then why is transaction will be incorporated into the attempts to mine block seven. As soon as somebody does mine block seven, this YROZ will actually be really in the block chain. All right, so one question is, could there be two different successors to block six? Could there be sort of a block seven and a block seven prime, right? What prevents this structure from arising? And of course, the reason why we're interested in this is that if the structure could arise, then these two, maybe V seven prime, V seven double prime, then these two different B sevens, two different successors to B six might have different transfers from Y in them. So if you were aware of just B seven prime, you'd think why it paid its bit coin to Z. If you were aware only of B seven prime prime, this would look like a totally legitimate payment from Y to Q. Question is, can there be two different successors to a block? It turns out the answer is yes. And it's actually does happen reasonably frequently. And the reason is that there's thousands of peers out there mining away, trying to find the successors to block six. And they're likely mining that's, trying to produce somewhat different blocks with different sets of transactions in them. So it's easy to imagine a situation in which some of the peers, they happen to see just because of the way the transactions move through the network, they happen to see why it's transferred to Z first and they incorporated into the block they're mining. And other peers, for sort of the same successor to their version of the block they're mining as a successor to six, just happened to have seen this transaction first and included that in the block. So we can easily get different miners trying to work in a way, trying to produce different successors to B six. If two of them happen to find the nonce that satisfies the leading zeros and the hash rule at the same time, that means we have two different blocks, two totally valid blocks produced at the same time. And they're both gonna send those blocks out into the network and they'll be seen at, roughly the same time by all the other peers. So it could easily be the case that two quite different successors to block six may arise. And it's called a fork. And so we're very interested in what happens to forks. Because this can and does arise. Well, the most immediate rule is that as soon as any peer sees a successor, all the peers are trying to mine a successor to block six. As soon as any of them sees a new successor block be flooded from some peer that did successfully mine, it'll stop working on six and immediately switch to trying to work on a successor from B seven for B seven. So initially, every peer, as soon as it sees a successor block, switches to mining a successor for that successor block. So in this situation, some of the peers will see B seven prime first and start working on a successor to that. Then other peers will see B seven prime prime first, just depending on what they happen to see first if these two are mined at the same time. And they'll start working on a successor to B seven prime prime. So now we got some of the peers working on sort of extending this fork in the blockchain and the other peers working on extending this fork in the blockchain. However, another critical rule is that if somebody's mining away on this, trying to make one of these blocks and it sees a new block for a different fork that's longer than anybody working on extending this fork will switch to extending this longer fork. So that's a rule on the software that everybody is supposed to favor the longest chain. So at least initially, if we have some of the peers mining away on one fork and the other, and they're the same length than others mining on the other fork, it turns out the variance in how long it takes to produce a valid knots is pretty high. So even if there's equal number of peers mining both forks it's highly likely that one of them will find a successor significantly before the other. And so this successor will be flooded to a bunch of nodes, peers that were working on this successor and they'll all switch to the longer fork. And so that means that there's sort of an asymmetry here that causes a slight, you know, if this fork gets extended by the miner slightly before this fork, then that'll attract miners over onto this fork and there'll be more and more miners mining on this fork. And so the new blocks will be found more and more rapidly on the winning fork. So there's a tendency to sort of reinforce success as the longer fork gets longer and pretty soon once all the miners have heard about this longer fork nobody will be left to mining on this fork. Everybody will ignore it and everybody will only treat this longest fork as the real chain. Okay, so this is highly likely that one of the, if there's a fork that one of the two forks will see an X block first will be longer. Everybody, all the peers will switch to mining on it and that everybody will rapidly agree that one or the other is the longest fork. Of course, the transactions on the abandoned fork, you know, usually most of the, usually these two competing blocks have pretty much pretty similar set of transactions but there may well be a few transactions here that were not there and certainly if somebody's trying to double spend or, but if there are transactions in the abandoned fork that didn't happen also to be in the winning fork then these transactions, they just go away. There's no attempt in the sort of blockchain system itself to try to carry over these transactions now or there's no attempt to kind of directly merge the two forks. Now, in fact, you know, if you don't see your transaction show up you may reissue it and you know, because the blockchain is public it'll become apparent that your transaction needs to be reissued because it wasn't incorporated in the winning fork. However, it is also the case that for a brief period of time both of these transactions were in the blockchain. Right, so for a brief period of time there was a double spending of wise coin in the blockchain and that, you know, that's like a little bit of a dangerous situation. In fact, you know, it's an extremely dangerous situation right since the whole point was to avoid blockchains right until one of these two chains got longer now it was totally unclear which of these two chains to believe and indeed some of the peers may only know about one of them or the other of them. So this raises a sort of unhappy question about how Q or Z, you know, what procedure should they use to be sure that they've actually been paid? Right, apparently it's not enough for Z to say, well, as soon as the transaction appears in the blockchain, then I'm sure I've been paid because that's not true, right? Maybe this blockchain would end up being the shorter one and the YP's Q blockchain will win. Similarly, Q can't just look at, oh, you know, my transaction showed up in this block in the blockchain, therefore it's a valid transaction because it may end up being abandoned due to being on a shorter fork. And so this is the reason for the rule in that people who care don't really believe in transactions until there's a couple of blocks after them in the blockchain. And as the longer chain gets longer and longer or as what you think is the longer chain gets longer and longer, the chances that there might be some other chain that will become longer than it get vanishingly small because if you're on a slightly longer chain that's gonna attract miners to mining on it so no other chain can grow very rapidly. And of course, the rate at which a chain, a particular fork can grow is proportional to the number of peers that are mining on that chain. All right, and so this is the mechanism that prevents, that makes it so that if Y sends out two conflicting transactions at the same time, even though there can be a brief double spend if there's a fork, it will rapidly become only one or the other of the two transactions will be in the longest chain. And so one of them will win in the sort of official chain. Now, and indeed if this second transaction shows up is sent to peers later on after the Y transfer disease in the chain then all the peers will ignore newly arriving transactions that for coins that have already been spent in a transaction on the chain on the fork that they're mining for. So why can't send out this transaction again after the first transactions shows up in the chain in the blockchain? Okay, so there's some other attacks you might wonder about. One question is whether let's suppose that this is the chain, if Y is colluding with some peers and this is the official B7 and we have a B8, et cetera, supposing Y is in league with some of the peers could appear, take this block seven, that's now in the middle of the chain and change it to produce just a different block that doesn't have this transaction in it and just sort of substitute this new block for the old block seven and sort of pretend that block A refers to it and now block this new block seven doesn't have the transaction. And so that sort of very straightforward changing of a single block doesn't work. And the reason is that these arrows here are really, really means that there's a cryptographic hash in block eight that is the hash of the block seven it refers to the block seven. So that's the reason that block seven that is the hash of the block seven it refers to. And so this hash in block eight, for a block seven that already exists, this hash in block eight is a hash of the original block seven. If someone changes this content it's gonna have a different hash. And so this block eight hash, if you try to pawn off this modified block on somebody who knows about block eight they're gonna say, wait a minute block eight hash doesn't hash to the same block, this block seven prime doesn't hash to the same value that's embedded in block eight. So you can't trick anybody who knows about subsequent blocks into accepting a modified intermediate block. All right, question. Let's see, why is a Q store buys coffee and it shows up in one of the blocks? Oh, I see. Okay, so this is a, let me just back up a little bit. So I think the scenario we have is that there was a blockchain and then a brief fork and in that brief fork, why paid the same coin to two different parties and let's say this is block seven prime prime and it's block seven that wins and is on the main chain and block seven prime prime is just forgotten and ignored. And the question is, geez, for briefly at least Q saw this transaction show up in the chain and gave the cup of coffee to Y and then Y left the store, but then this part of the chain is discarded and Q is left with no money. They've given away some coffee, but they did not get paid. And that just is what happens in this scenario. If Q was willing to hand over the cup of coffee after seeing the transaction in just the last block in the blockchain, then they risk this scenario and there's nothing they can do about it and they can't get the money back. I mean, unless you run down the street, catch up with the person and take the cup of coffee away and that is the reason why for high value transactions, Starbucks probably doesn't care very much, right? The cup of coffee really only costs like, 50 cents to make. Like if they occasionally, these forks don't happen that often, they occasionally lose the cup of coffee well. They can probably willing to deal with that. But if Y was buying a car from Q for $20,000 in Bitcoin, then Q probably would rather not let Y walk off with this level of assurance about being paid. And that's the reason why if you care, you'll wait until multiple blocks show up after the block in which your transaction was in. So Z won't actually hand, if it's a high value transaction, Z won't hand over the goods until there's at least some number of five, six blocks showing up after the block the transaction showed up in. And it's very unlikely that a fork could be extended five or six times. Like over a period of an hour now can blocks show up only every 10 minutes and then turn out to be the shortest, not the longest chain, because that means that there was some other fork that was extending faster. And the only way some other fork could extend faster is that if a majority of the CPU power is working on it and we're assuming that a majority of the CPU power is non-malicious and is therefore switching to the current longest chain. All right, so this is, you have to be, if you're doing large value transactions, you have to be careful and wait until the chain grows long after your transaction shows up. Okay, so I explained why you can't simply modify a block in the middle of the chain. There's a related question, which is supposing there's an existing blockchain that's some amount long and your transaction, why arrow transaction, why does he shows up here in the blockchain and you wanna get rid, you wanna hide that transaction now, somehow make it so it doesn't exist. Well, gosh, why don't you produce a new sort of alternate chain that is mostly identical to the main, to real chain, but it's longer and just happens to omit wise transfer to Z and instead includes wise transfer to Q. And if you do the mining correctly for this and the hashes work out, your chain's longer and it just will be accepted under the rules of Bitcoin, which everybody's supposed to switch to the longest chain. So how come you can't do this? And this would also allow you to double spend by essentially unspending a previous spent quantity. And my earlier comment about, oh, you're supposed to wait, Z is supposed to wait until the blockchain gets extended. This is now a way to defeat Z waiting for the blockchain to extend it. So we're really because serious trouble if you could make this work. Okay, so at some level, the answer is yes, this can be made to work. And here's how to do it. The main blockchain is being extended by the non-malicious participants at some rate. They have enough CPU power to produce a new block every 10 minutes. If you're the attacker and you have more CPU power than the entire non-malicious set appears, then you're gonna be able to generate blocks faster than the real chain. So your chain may start out shorter and it may take you a while to generate each block, but maybe you can generate two blocks every 10 minutes, whereas the main chain is only capable of generating one block every 10 minutes. So that means after a while, you'll have caught up and exceeded the length of the main chain, the main fork, and by the rules of Bitcoin, everyone, non-malicious, totally correct Bitcoin peers, they'll all switch to your longer chain. And that means they'll all effectively forget this transaction and accept this other transaction, this second spend of the same coin. So if you're an attacker and you have more CPU power than the entire rest of the network, you can produce this chain and that means you can double spend. And that's certainly something to think about, but the reason why you might hope or be somewhat confident that it couldn't arise is that in a big system with lots of participants, it might be very hard to assemble more CPU power than the entire rest of the system. So once Bitcoin grew big, people were somewhat confident that the main non-malicious system had enough CPU power that it would be expensive for an attacker to assemble more CPU power than the rest of the system. Of course, for new cryptocurrencies that don't yet have very large mining operations going, they're actually easy to shoot down. It's easy for a new cryptocurrency like Bitcoin, it's easy for an attacker for whatever reason to put it out of business by getting more CPU power. But for a big system like Bitcoin, it's somewhat difficult. Now that said, people who've looked into, tried to figure out who controls mining CPU power in Bitcoin suspect that the biggest players have fractions of the total that are not that far from 50%. And that certainly if two or three of the largest mining operations combined forces that they would have a majority of the mining power in Bitcoin and could produce alternate forks like this. So that's a somewhat troubling development. Whether there be motivated to do something bad, especially since sort of everything that's done in Bitcoin is public. So people really noticed that, gosh, there was a long chain and then we switched to a chain that started way far back. Boy, would people ever notice that. And that would destroy confidence in Bitcoin and may undermine anything that the malicious parties were hoping to achieve. So since it is very expensive actually, the big players in mining Bitcoin has spent a huge amount of money to buy the mining hardware that they own. And so they probably wouldn't wanna undermine people's trust in Bitcoin because that would destroy the value of their vast collections of hardware. All right, any questions about the machinery here? All right, so I have a couple of questions that I can ask and answer. One question is that the 10 minutes between blocks is actually a serious annoyance. It means that if I wanna buy something, it takes up to 10 minutes before the transaction shows up in the blockchain at all, even in the first block. And either I have to wait around for 10 minutes to get my cup of coffee or the store owner has to give me my cup of coffee before the transactions in the blockchain at all, thus having to trust me. So why can't we make the 10 minutes much shorter? And actually the 10 minutes probably could be made shorter. The practical reasons why it isn't shorter is that it actually, it takes a while for new blocks to be flooded over the system. Right after a miner finds the next block, it has to be sent to thousands of peers at Bitcoin over possibly slow network connections. And it may take quite a while before that block is known to all the other peers. And that means that there's some period of time in which other peers are mining on blocks or wasting their time mining blocks that have been superseded by a block that hasn't yet reached them. And basically the fraction of time you spend wasting your time mining blocks that have been superseded is related to how long it takes to mine each block compared to how long it takes to flood the block. And so if you make the interblock interval shorter and shorter, then it starts to get small enough that it approaches the amount of time it takes to flood new blocks. And that would cause most peers to waste most of their mining effort. And since the miners are actually making money, making Bitcoin by mining, because there's a little reward to the successful miner beach block, the miners are very uninterested in wasting resources, mining for blocks that have been superseded. And so they're very uninterested in having this 10 minutes be much shorter than it is now. And that's a significant constraint. So this is a question, what prevents why from double spending much in a much later block when peers might have forgotten about the first transaction? And so the question is, oh, in a very early block, why transferred a coin to Z? And then a thousand blocks later, why tries to transfer the same coin to Q? Like a year later or something. And the answer to how this plays out is that all the peers remember this forever. They absolutely remember every unspent transaction forever. And that means that actually, that can't be the full story. Like I think nominally, to tell you the truth, I don't understand all the ins and outs of this. But one way, the most straightforward way to solve this problem is for all peers to remember every transaction forever. And every incoming transaction they check to make sure that the coin hasn't been spent yet. They just maybe, of course, create a database or index or something, but allows them to essentially check every record to see if this coin has already been spent. And I think you can, although I don't fully understand this, I think peers can discard a lot of the, a lot of this information by only remembering information about unspent transactions. So they keep a database of unspent transactions, but that doesn't include spent coins. And if a new transactions coin isn't in the database of unspent transactions, then it's just ignored. But this database has to be, every peer has to keep this database forever. So just, of course, this is in a way a very expensive system because what we're talking about is maintaining a record of every transaction essentially forever. And if you think about how many transactions there are per second or per year on earth, it's a vast number. And so people really were serious about using Bitcoin. They used it for everything in the way they use cash now. It would be an enormous system and there would be enormous performance streams on the system. And indeed, Bitcoin is not really capable of supporting every transaction. You couldn't run the entire financial system of the world on Bitcoin as it exists today. And there's a bunch of limits. One limit is that the full Bitcoin database already consumes a couple of hundred gigabytes. That's actually not so bad because you can fit it on a disk. But if it was a thousand times larger, it would start to be a serious problem to even store it, let alone search for stuff in it. The most immediate problem, anyway, it turns out the processing of transactions is not terribly expensive because for the peers it's mostly about hashing and these cryptographic hashes are pretty quick. But the sort of most current, you know, ugly restriction is that these blocks, there's a limit to how big these blocks can be. These blocks can only be a couple of megabytes in size and new blocks appear only every 10 minutes. And so that means you only get, you know, less than a megabyte of new transactions per minute, each transaction, the sort of value. There's various ways of abbreviating them, but you know, each transaction is at least dozens or a hundred bytes. And that means that the system can really only, because of this block size limit and the 10 minute limit, the system can only process sort of thousands or tens of thousands of transactions. Well, I'm not sure I can divide properly, but it's not nearly enough to run the current way that Bitcoin setup is not nearly high capacity enough to run all the world's financial transactions off. And so, you know, people change it, it evolves, but it's not really fast enough for everything. Of course, nobody's really using it for commerce. It's mostly used for speculation as far as anyone can tell. So it's not yet a problem, but from a design point that there needs to be some things fixed. Okay, so I mentioned before that the Bitcoin software adjusts the hardness of finding nonces. That is the number of required leading zeros in the block hash adjusts that dynamically to cause there to be 10 minutes per block. One thing that has to be the case though is that all the participants have to agree on the required number of leading zeros. They actually all have to agree on the hardness of finding a knots. And so, if one peer sort of looks at the rate at which blocks have been produced and decides that it's too slow and it should make the require fewer leading zeros, but the other peers haven't made the same decision, then that first peers will be generating blocks that are rejected by the other peers, because all the peers demand what they think is the correct number of leading zeros in the hash. So there has to be agreement on the hardness of finding a knots. The peers have to agree exactly on what the current hardness is. Otherwise, they'll reject each other's blocks. So how do they reach that agreement? It turns out actually to be totally straightforward. They all are looking at the same block chain after all. That's the whole point is that, except for temporary forks, there's just one block chain. Everybody has a copy of the exact same bits in the block chain. And so, the Bitcoin just defines a deterministic function that takes the current block chain as its argument and uses that to deterministically produce the current hardness of finding a knots. And the way it does that is basically it looks at the time stamps in the blocks to decide how fast the recent blocks have been produced. But since everybody's looking at the same blocks and the same time stamps and is running the same function to adjust the hardness, they all come to exactly the same conclusion about what the hardness ought to be for each successive block in the block chain. So there's a kind of interesting agreement that's being enforced there because they all see the identical same logs. All right, another interesting question is that one of the motivations that some people have for being interested in new cryptocurrencies is that they might be more anonymous than credit cards. And indeed credit cards are deeply non-anonymous since the credit card company knows exactly what you're up to and keeps a record of it. Whereas Bitcoin, at least on the face of it, there was nothing about a Bitcoin transaction that say had my name on it. Now you might think, well, each Bitcoin transaction has my public key in it. And it's true, if I don't change my public key and I always use the same public key then once somebody figures out my public key which is relatively easy since whenever I pay somebody they get to know my public key, then people can track my activities by looking for my public key or my signature in the Bitcoin log. And it's a public log so anybody can look. Now people, everybody who cares and I think most Bitcoin wallet software actually generates fresh public keys for each transaction. So at any time, if somebody wants to pay me money, my wallet will generate a new and never used before public private key payer. Remember the private key and give the public key to the person who wants to send me money. And that makes the tracking harder. But it turns out that if you're up against a determined sleuth, there's enough clues. If you make transactions often enough since the transactions are often tied to your real identity. Like if you buy something from Amazon with Bitcoin, yeah, maybe the Bitcoin transaction, it's not clear it's you but it probably needs to be shipped to you by FedEx to your home address. And that's a little piece of identifying information there and that will allow somebody to figure out it was you who spent that money and they'll be able to sort of track backwards to see where that money came from to get another clue about who you are and what you're up to. So in fact, against amateurs, amateurs Bitcoin is reasonably anonymous against serious adversaries. Bitcoin has turned out not to be particularly anonymous. Okay, so that's a little bit disappointing from a little bit disappointing for people who are interested in privacy or doing drug deals or financing a legal activity. All right, sum up the sort of key idea here is the blockchain, like a public ledger that everybody agrees on and that has every transaction on it. And all that has a lot of problems, like with scalability. If you can make it work, it's a great idea. Another sort of key technical problem is how to do this without any centralization. Now, whether the centralization or decentralizations of valuable property is kind of not really a technical question, but if you value it, then it's just really cool and amazing that it's possible to have agreement on a single log with no central trust and using participants, many of whom are actively malicious. And the final key idea is that this is the idea of mining a proof of work where it too has problems, but it's very surprising that a technique existed at all that allowed agreement in a way that can't be fooled by these sort of fake IP address attacks that doesn't suffer the same problems that voting suffers. So that was a very surprising and interesting development. All right, that's all I have to say. The actually kind of continuing some of this line of thought in the next lecture, which is a sort of different kind of decentralized system partially built on top of Bitcoin.