So finally, we'll talk about some built in limitations to the Bitcoin protocol and why it's challenging to actually improve them. There are a lot of hard coated [INAUDIBLE] that are implemented into the Bitcoin protocol which were chosen when Bitcoin was proposed in 2009 before we ever had any idea that it might grown into this globally important currency. So the most important limits are probably the limits on the average time per block, the size of blocks, the number of signature operations in a block, and the divisibility of the currency. The limitations on the total number of Bitcoins in existence as well as the structure of the mining rewards. Are very likely to never be changed, because the economic implications of changing them are too great. Miners have invested a lot of real world resources into becoming miners, assuming that Bitcoin rewards would take a certain shape and that the limited supply of Bitcoins would remain the way that its been planned so if you change that, that would have large financial implications for people. So for that reason the community has basically agreed that those values wether or not they were wisely chosen or basically stocked with. Some other changes that you would like to make seem like they make everybody better off. Things about Bitcoin it just it weren't quite properly designed at the beginning. But are also hard to change. The main aspect of Bitcoin that people are worried about and would probably like to change if they had time to design it over again are limits that affect the through-put of the system. How many transactions can the Bitcoin network process per second? This limitation comes from the hard coated limit on the size of blocks. Each block is limited to a million bytes. And each transaction has to be at least 250 bytes, so if you divide through, and the fact that blocks are found every 10 minutes, you're left with about 7 transactions per second which is all that the Bitcoin network can handle. And it seems like tweaking those numbers would be very easy, it's just one constant in a file somewhere that you'd have to change. It would be very hard to change this in practice for reason that will become clear in a few seconds. So how does 7 transactions per second compare. Well, if you went down to the offices of Visa and told them I'm proposing a new payment system that can handle 7 transactions per sec, they would probably tell you, that's stale and they would laugh and throw you out the door. They've been working for a long time to go to payment network that goes way bigger than this. So it's said that these handles on average about 2000 transactions per second around the world. And in the busiest times, so think the Saturday before Christmas when everybody's out shopping and swiping credit cards. The Visa network can handle about 10,000 transactions per second. And other payment networks are similarly big. You can also look at PayPal which is not as big or as old as Visa but even PayPal can handle 100 transactions per second at peak times so in order of magnitude more than Bitcoin. Another limitation that people are worried about in the long term, is that the cryptography is Bitcoin is fixed. There's only a couple of hash algorithms and there's only one signature algorithm, which is elliptic curve DSA. Over a specific elliptic curve called Sec P256. And there's some concern that over the lifetime of Bitcoin, which people would like to be for a long time, this algorithm might be broken. Cryptographers might come up with a clever new attack that we haven't foreseen, which makes this an insecure algorithm. And the same is true of the hash functions. Hash functions, in the last decade, have actually seen steady progress and cryptanalysis with SHA-1. Which is included in Bitcoin already having some known cryptographic weaknesses. So to change this we would have to extend the Bitcoin scripting language to support new cryptographic algorithms. So what would it look to make a change like this where we just said, we had a problem with Bitcoin, we're going to release a new version of the software, and everybody is going to have to switch. This is what we could call a hard-forking change. So in practice, it's impossible to assume that every node would upgrade. Some nodes in a network would fail to get the new software or fail to get it in time. And what would be the implications of that? Well lets take a look at a network here where most of the nodes have upgraded but there are a few that haven't. And now let's say one of the new nodes says, hey I found this nifty, great new block. Maybe it has some new signature algorithm in one of the transactions, using the new features that we've added to Bitcoin. So block four has found this and says, okay, I'm gonna update and say that's now the newest block. So I'm at block index 24, the rest of the network is at 23. But I'm gonna propagate that to all of my peers using the normal block flooding algorithm. So node 4 is gonna send block 24 out to it's neighbors, nodes 3 and 2. Node 3 is gonna get it and say. Great, I got that one, I'll update my version of the Blockchain to have that as the newest block. Where as Node 2 is going to say, that's crazy, you have some operation code that's disabled or reserved, I have to reject this Block, I don't understand it, I can't except it. And similarly when it gets over to Node 6, Node 6 is also going to say, no, I can't except that block either. And now you're gonna end up in a state where the new nodes have one picture of the block chain and the old nodes have all refused to accept this latest block. So the new nodes will go off and work on a version of the block chain including this block with the new fancy feature and the old nodes will all be stuck on an old version of the block chain and unfortunately they're never going to catch up because until they upgrade their software, they'll keep rejecting all of the blocks that are proposed by the nodes in the network that have upgraded to the new version of the protocol. So the reason it's called a hard-fork is that the block chain will split every node on the network would be on one side of it, based on which version of the protocol it's running and they'll never join together again. And this is considered unacceptable by the community that all nodes would effectively be cut out of the Bitcoin network if they don't upgrade their software. So by contrast, there's an approach called soft forking, which tries to avoid creating a permanent fork like this. The observation is that we can add new features to the Bitcoin protocol if it only restricts the set of valid transactions or the set of valid blocks. Because we want to avoid this hard forking situation, we can try to add new features in a way that will cause only a soft fork. So that the key to making this happen is that the new features can only make validation rules stricter. They can only limit the set of blocks or the set of transactions that are considered valid, so the new nodes in the network will be enforcing some new tighter set of rules. So we're relying on enough nodes switching to the new version of the protocol that they'll be able to enforce the new rules knowing that the old nodes won't be able to enforce the new rules cuz they haven't heard of them yet. There is a risk here. Which is that old nodes might be mining an invalid block, because they include some transaction which used to be valid, but according to the new, strict rules, is not valid anymore. So that could be bad, those nodes could waste a lot of time mining a block that the new nodes will reject. But when they try to announce that new block, the new nodes will reject it. The old nodes will at least figure out that, for some reason, even though I don't understand the reason, the rest of the network has rejected my new block. Therefore, I should move on to the version of the block chain that all of my peers have, and it won't be a hard fork. They'll have a temporary fork by virtue of the new block they tried to mine. It was rejected by the network, but they'll recover and get back on to the main chain. The classic example of a change that was made via soft fork was pay to script hash, which we introduced earlier in the section discussing the scripting language. So the view of pay to script hash from old nodes, and again, pay to script hash was not present in the first version of the Bitcoin protocol, they see this rift as really simple. All it's doing is hashing this one data value and checking to see if it's equal to the value specified in the output script. The old nodes never do that second step of verification in pay to script hash, where they then check to see that that value before being hashed runs as a valid script. So what could we possibly add with a soft fork? Pay to script task hash was successful. It's also possible that new cryptographic schemes could be added by a soft fork, or that we could add some extra metadata in blocks that had some meaning. And the place you'd add this is in the coin base parameter. So today any value is accepted in the coin base parameter, but we could in the future say that the coin base has to have some specific example. One idea that's been proposed, that in each new block, coin base contains merkleroot of the entire set of unspent transactions. It would only result in a soft fork because old nodes might mine a block that didn't have the required new coin base parameter that got rejected by the network. But they would catch up and join the main chain that the network is mining. Other changes might require a hard fork, that would be if we wanted to do new op codes to Bitcoin, change the limits on block or transaction size, or do a lot of bug fixes. So for example, the bug I showed earlier where the multi instruction pops an extra value off the stack, that would actually require a hard fork and that's the reason why even though it's annoying bug that people wish wasn't there anymore, it's much easier to just leave the bug in the protocol and have people work around it rather than have a hard fork changed a bit plan. So all of these hard forking changes even though they would be nice are very unlikely to happen, at least within the current climate of Bitcoin. But a lot of these ideas have been tested out and prove to be successful, and alternative currencies, which start over from scratch, and we'll be talking about those in a lot more detail in our lecture for altcoins. So I spent a lot of time talking about details today. I know this has been a long lecture with a lot of technical detail, very hard to absorb all at once. So like I said, I would certainly recommend you can go online and see some of this stuff in practice, see what blocks and transactions look like. It took me a couple of times looking at them before I really had a good sense of what was going on but I think the practical examples do really help. In the next lecture given all these mechanics we've introduced, we're gonna look at the human side of things. Cuz after all human beings aren't Bitcoin nodes and you're never gonna run Bitcoin node in your head. So how do you as a human actually interact with this network to get it to be useable as a currency? How do you find a node to tell about your transaction? How do you get Bitcoins in exchange for cash? How do you store your Bitcoins? So all of these questions are crucial for making a currency that will actually work for people as opposed to just software.
