Limitations and Improvements in Bitcoin Protocol

Limitations & Improvements Blockchain technology powers the decentralized digital money known as Bitcoin. Even though Bitcoin has been around for more than ten years, it continues to have several issues that prevent its adoption and growth. In this post, we'll talk about some of the Bitcoin protocol's fundamental flaws and why fixing them is difficult. One of the most significant limitations of the Bitcoin protocol is 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. These values were chosen before we even knew that Bitcoin would become a significant global currency. Although some improvements can benefit everyone, these limits are difficult to change. The mining incentives and restrictions on the overall number of Bitcoins that can exist are also unlikely to be altered as they would have negative economic effects. Changing these values would have significant financial ramifications for people, as miners put a lot of real-world resources into becoming miners under the assumption that Bitcoin rewards would take a specific form, and the limited amount of Bitcoins would remain as planned. Aspects about Bitcoin were not initially built very well, and they are challenging to alter. Limits that impact the system's throughput are the main component of Bitcoin that people are concerned about and would likely prefer to modify if they could redo its design. The Bitcoin network can only handle about 7 transactions per second due to the hard-coded 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 are left with about 7 transactions per second which is all that the Bitcoin network can handle. Although it may seem easy to tweak these numbers, it is difficult to change this in practice for reasons that will become clear shortly. This limitation is significantly less than other payment networks like Visa, which can handle about 2000 transactions per second worldwide, and even PayPal can handle 100 transactions per second at peak times. Another limitation that people are worried about in the long term is that the cryptography used in Bitcoin is fixed. There are only a couple of hash algorithms and only one signature algorithm, which is elliptic curve DSA. This algorithm is insecure because cryptographers might devise a novel, cunning attack that we haven't anticipated. The same is true for hash functions as well. The solution to this is to expand the Bitcoin programming language to accommodate new cryptographic methods. We would need to fix this by releasing a new version of the Bitcoin protocol that supports new cryptographic algorithms. However, making such a change would require the cooperation of the entire Bitcoin community, which is not an easy feat. Fixing the limitations of the Bitcoin protocol is a difficult task. However, there are several proposed solutions to these problems. One of the proposed solutions is the implementation of the Lightning Network, which is a second-layer payment protocol that operates on top of the Bitcoin blockchain. The Lightning Network enables instant, low-cost, and private payments by leveraging the security of the Bitcoin network. It does not require any changes to the Bitcoin protocol, and it can significantly improve the network's throughput. By using this network, transactions can be made instantly, and the Bitcoin network can handle many more transactions per second. Another proposed solution is the implementation of Segregated Witness (SegWit), which is a protocol upgrade that modifies the way transaction data is stored. SegWit allows for more transactions to be included in a block by reducing the size of transaction data. By implementing SegWit, the Bitcoin network can handle more transactions per second. 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, the additional features can only make validation criteria stricter, which is the key to making this happen. It's a good idea to have a backup plan just in case. Since the old nodes won't be able to enforce the new rules since they haven't heard of them yet, we are depending on enough nodes migrating to the new version of the protocol so they can. 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. If we were to add additional operation codes to Bitcoin, alter the restrictions on block or transaction size, or make several bug fixes, such other changes might need a hard fork. Therefore, even though it's an irksome bug that people wish didn't exist any longer, it's much simpler to just leave the bug in the protocol and have people work around it rather than having a hard fork changed a little bit plan. As an example, the bug I demonstrated earlier where the multi instruction pops an extra value off the stack, that would actually require a hard fork. 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.