Limitations and Development of Bitcoin

How Bitcoin Works – Limitations And Development Of Bitcoin

Limitations and Development of Bitcoin

Limitations and Development . The Bitcoin protocol also has its limitations. However, developers have also been challenged to develop it further. There are some constraints on some hard-coded Bitcoin protocols when Bitcoin was first introduced in 2009 by Satoshi Nakamoto.

The existence of this limitation, long before Bitcoin grew and developed as it is in the present. Some of the limitations are on the average time limit per block, block size, number of block signing operations, currency division, total amount of Bitcoin, and also reward block structure.

In relation to the total amount of Bitcoin present, the structure of the block reward on Bitcoin mining may never change. That’s because of the economic implications that will be able to change and make growth too big.

Miners, as well as investors have made a big difference to the Bitcoin system. Therefore, the Bitcoin block reward structure and limited supply will continue to run as planned. If this is changed, it will have a major impact on financial implications. Because basically Bitcoin people agree on that aspect. Agree to not change that.

Meanwhile, there are some changes that have been made in order to make better than the original design. One such change concerns how many transactions can be processed in a Bitcoin network in seconds. Especially about the limits that will affect the throughput of the Bitcoin system.

Initially this limitation arises from hard coded block size limits. In Bitcoin, each block is limited to 1 megabyte in size. Each transaction consists of at least 250 bytes. Dividing 1,000,000 by 250 bytes, will be able to generate approximately 4,000 transactions on blocks every 10 min. Estimated there will be 7 transactions processed per second. All of these transactions are processed in the Bitcoin network . And we have discussed it in the discussion before.

If changing the limit is done, it could be a problem in tweaking the source code. However, it is quite difficult to change it. So how is the comparison to the seven transactions that occur every second?

Comparison of the seven transactions was lower when compared to some credit card processors in general. In the Visa network, able to handle an average transaction of approximately 2,000 transactions per second. On the whole transactions are done around the world. When network traffic is in dense conditions, the Visa network is capable of handling 10,000 transactions in every second. When compared with Paypal, also still lower.Paypal is capable of handling 100 transactions per second in solid transactions.

In addition, there are other limitations in Bitcoin. Some people are worried about the long-term Bitcoin. It comes with the choice of algorithm used in Bitcoin to be permanent. While there are only a few hash algorithms available. Namely one signature algorithm, ECDSA (The Elliptic Curve Digital Signature Algorithm ) . .

The worries are based on the idea that if the algorithm is used permanently, they worry if the algorithm might be damaged. They are also worried that in the event of an attack that may be more intelligent and telling, which could make the algorithm unsafe again.

Concerns also arise in the hash functions used in Bitcoin. Despite the fact that, in the last decade, there has been an improvement in cryptanalysis, there are still concerns. For example on SHA-1 which is also used in Bitcoin. SHA-1, has a weakness though not so fatal.While to be able to change this, it should extend the Bitcoin scripting language. So it can support the existence of new cryptographic algorithm.

Then what are the steps that can be done to make some necessary changes to overcome these concerns?

Changing the Protocol

Bitcoin has also had new features incorporated into the Bitcoin protocol. How, by creating a new version release on Bitcoin software. Then tell all the nodes to upgrade to the new version.

However, in practice it is also quite complicated. Because it can not assume that all nodes in the Bitcoin network will be completely upgrading their Bitcoin software. Some nodes may also experience some annoyances or failures while trying to upgrade the new software.

While, there are also implications if some nodes have upgraded new versions, while some other nodes still use older versions. The implications will depend on the nature of the changes that can be generated in the software. Differences arising from the changes are differentiated in two types. That is causing the Hard Fork , and also Soft Fork . Let’s discuss these two types of differences.

Hard Fork

In this type of change, it will create a new feature, from what was previously considered invalid, into a valid block or transaction. That is, in the previous version of Bitcoin software, a block or transaction is considered invalid, while in the new version of the block it is considered to be valid. So what happens if some nodes have upgraded Bitcoin software version, and some still use the old version, when reading a block or transaction?

In a long block branch, the node that uses the old version will read on that branch there is an invalid block. Then the node will pass and work on another block in the branch. Until the node upgrades its software. And this node will assume the shortened branch has become a valid block in the longest branch.

So this hard fork conversion will have two different views on a branch of the block chain.Each node will generate views over the block based on the type and version of the protocol contained in the software it uses. Well, the effect is, the block in the branch that the node using the old version will not join in the block chain. The node can ultimately be deemed not accepted by the Bitcoin network. Because they do not want to upgrade their Bitcoin device.

Soft Fork

The second conversion is called Soft Fork. The second type is by adding strict validation rules. By limiting valid transaction set or validation of blocks. So if on the old version will receive all the blocks, while in the new version, may be rejected some of them.

In this change, will be able to avoid the split caused by changes due to hard fork earlier. Try to imagine what would happen if the soft fork is run. Nodes that have run the new device, will enforce strict new rules. As long as the majority of nodes in the network have also used this new version of soft fork . So that node with this new device will be able to push other nodes to apply the new rule.

Soft fork is quite dependent on the node to also use the latest Bitcoin software version.While on the old node will not be able to enforce the new rules, because they have never heard the rules before. Then whether there will be a risk later?

Yes, there is also a risk to this soft fork change. Because it could be later, the miners in the old version will mine on a block that is considered invalid, based on the new rules that already exist. At least the nodes with the old version know that their block has been rejected. Although they may not understand the reason why their block is rejected. Though the reason is because they do not use the latest version of soft fork . So they are not aware of stricter regulations.

In addition, it can also happen, if the block branch is done by the old miners followed by new miners, then the old miners will also switch to the new miner’s branch. Because the blocks are equally considered valid, by new miners, as well as old miners using the old version. With this kind of thing, there will be no hard fork. There is only a temporary fork.

The example of using soft fork is done on pay-to-script-hash . This discussion can be read again in Bitcoin Script In Bitcoin’s Way . Pay-to-script-hash , not used in early versions of the previous Bitcoin protocol.

In the pay-to-script example it is called soft fork , because the transaction is valid by pay-to-script-hash will still be verified again correctly. As will be seen by old node with old device version. In the script, do it by doing a hashing of a data value, and check if the hash matches the output value specified in the script.

If pay-to-hash-script has worked, then what else can be added in this soft fork? It is still possible to add some additional metadata in the coinbase parameters. Now, any value is accepted in the coinbas parameter e. In the future, it may take several new formats in the coinbase parameter.

One of them is, maybe on every new block, coinbase will put it into the root of the merklecontaining the entire set of unused transactions. So this change can later produce soft fork .Because the old node will probably mine blocks that do not require coinbase parameters, which were previously rejected in the network.

While on other changes, it will probably need a hard fork. For example by adding a new opcode in Bitcoin. By changing the block size limit, or also in bug fixes .

In connection with the effort to fix the bug, we have previously seen in the previous MULTISIG discussion. Can be seen again the discussion on How it Works Bitcoin – Bitcoin Script Application . The MULTISIG instruction set, requires a hard fork . From this, it can be seen that even if there are bugs that interfere, it would be easier to leave them in the Bitcoin protocol. Instead of having to run a hard fork to change Bitcoin.

Because basically, when using hard fork, although it can make the situation more fun, it is quite impossible to do in the current situation. While testing of these ideas have been done and proven successful in some other cryptocurrency.

Cloud Faucet Net

Cloud Faucet Net

Cloud Faucet Net is an online medium for sharing knowledge and information about Bitcoin and cryptocurrency. It was first established in March 2017. Hopefully, it can be used as a source of information as well as a reference to the addition of useful knowledge, related to Bitcoin and the technology that surrounds it.

Leave a Reply

Your email address will not be published. Required fields are marked *