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 issuesthat prevent its adoption and growth. In this post, we'll talk about some of the Bitcoinprotocol'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 thedivisibility of the currency. These values were chosen before we even knew that Bitcoinwould become a significant global currency. Although some improvements can benefiteveryone, 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 thesevalues would have significant financial ramifications for people, as miners put a lot ofreal-world resources into becoming miners under the assumption that Bitcoin rewards wouldtake 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 areconcerned 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 eachtransaction has to be at least 250 bytes. So, if you divide through, and the fact that blocksare found every 10 minutes, you are left with about 7 transactions per second which is allthat 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 otherpayment networks like Visa, which can handle about 2000 transactions per secondworldwide, 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 signaturealgorithm, which is elliptic curve DSA. This algorithm is insecure because cryptographersmight devise a novel, cunning attack that we haven't anticipated. The same is true for hashfunctions 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 Bitcoinprotocol that supports new cryptographic algorithms. However, making such a change wouldrequire 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 implementationof the Lightning Network, which is a second-layer payment protocol that operates on top ofthe 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 itcan significantly improve the network's throughput. By using this network, transactions canbe 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 moretransactions to be included in a block by reducing the size of transaction data. Byimplementing 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 gooff and work on a version of the block chain including this block with the new fancy featureand the old nodes will all be stuck on an old version of the block chain and unfortunatelythey're never going to catch up because until they upgrade their software, they'll keeprejecting all of the blocks that are proposed by the nodes in the network that have upgradedto 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 andthey'll never join together again. And this is considered unacceptable by the community thatall nodes would effectively be cut out of the Bitcoin network if they don't upgrade theirsoftware. 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 Bitcoinprotocol 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 nodeswon't be able to enforce the new rules since they haven't heard of them yet, we aredepending 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 validanymore.

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 understandthe reason, the rest of the network has rejected my new block. Therefore, I should move onto the version of the block chain that all of my peers have, and it won't be a hard fork. They'llhave a temporary fork by virtue of the new block they tried to mine. It was rejected by thenetwork, 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'sdoing is hashing this one data value and checking to see if it's equal to the value specified inthe output script. The old nodes never do that second step of verification in pay to scripthash, where they then check to see that that value before being hashed runs as a validscript. 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 hadsome meaning. And the place you'd add this is in the coin base parameter. So today anyvalue is accepted in the coin base parameter, but we could in the future say that the coinbase 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 nodesmight mine a block that didn't have the required new coin base parameter that got rejectedby 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 muchsimpler to just leave the bug in the protocol and have people work around it rather thanhaving a hard fork changed a little bit plan. As an example, the bug I demonstrated earlierwhere the multi instruction pops an extra value off the stack, that would actually require ahard 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 detailin 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 certainlyrecommend you can go online and see some of this stuff in practice, see what blocks andtransactions look like. It took me a couple of times looking at them before I really had a goodsense 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 nevergonna 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 inexchange for cash? How do you store your Bitcoins? So all of these questions are crucial formaking a currency that will actually work for people as opposed to just software.