The planned March 1, 2016 "hard fork" - that is, a significant change to the Bitcoin core code that would increase the maximum block size on the Bitcoin network from the current value of 1 MB to 20 MB - is causing a lot of controversy. This is one of the most significant changes since the project's inception. On online forums related to cryptocurrencies, the discussion between supporters and opponents of this modification has heated up. Planned on March 1, 2016 "hard fork" - that is, a significant change to the Bitcoin core code, as a result of which the maximum block size in the Bitcoin network would increase from the current value of 1 MB to 20 MB raises a lot of controversy. It is one of the most significant changes since the project's inception. On online forums related to cryptocurrencies, a discussion between supporters and opponents of this modification has heated up. If you do not know why it is necessary to change the block size and what it consists in, read our previous article. Supporters of the block size modification argue that the change is necessary for the continued growth of Bitcoin which is becoming increasingly popular and the number of transactions is steadily increasing approaching a limit, threatening to clog the entire network. Opponents, on the other hand, have concerns that the blockchain will grow at a much higher rate than it is now and that any change of this nature carries risks for the entire project. Of course, the growth of the blockchain depends on the number of transactions in it and simply changing the maximum block size does not automatically increase the size of the chain but.... ...it does, however, have one downside. The current transaction acceptance policy allows you to filter out transactions that have an unfavorable transaction size to fee ratio. In other words, large and complex transactions with minimal or no fee wait a long time in the queue, or are not even added to the blocks by Mines. This makes an attack on the network based on generating a large number of low-cost transactions not so cheap to carry out. Increasing the block size can cause mines to download all transactions, regardless of the fee. Consequently, the size of the blockchain stored will grow faster and faster. As for the risk of hard fork itself, it does exist (2 parallel chains, Doube Spent, etc) and such significant changes should only be considered as a last resort. We can imagine a situation when 20MB will be too little and another hard fork will be necessary. The same if the number of transactions in the network suddenly drops. Gavin Andresen's previous solution is therefore not an optimal solution. In response to community criticism, developer Jeff Garzik presented BIP100 (Bitcoin Improvement Proposals). Garzik's new idea also includes a "hard fork" but only once to lift the lock on the maximum block size. Subsequent changes would be made using a much more secure soft fork. Soft fork - the changes made are backwards compatible, software that has not been updated still works fine. BIP100 also allows mines to vote every 12000 blocks (about 3 months) what block size they would like to support. Mines would be able to include in the generation transaction (payout per block found) what their preferred block size is. After 20% of the marginal votes have been rejected, subsequent blocks could be 2x larger or 2x smaller than the currently resolved block size (of course if the vote indicates the current block size there will be no change). With BIP100, we thus avoid further hard-forks. Subsequent changes to the block size will be "soft-fork" and will not require further code updates in the client. This solution allows us to continue to implement a completely decentralized and mine-regulated way of managing the network (similar to how difficulty regulation or block reward changes are done). This solution again does not appeal to those who use the technology as consumers. They believe that adding additional decision-making power to miners in an ecosystem made up of several groups will result in miners seeking to maximize profits at the expense of ordinary users. The introduction of BIP100 implies the following steps: Hardfork on testnet (Bitcoin test network) - 1st of October 2015 Hardfork on the main Bitcoin network - 11. December 2015 - block size remains at current level (1MB) but no longer blocked Changing the limit every 12`000 blocks (about 3 months) from the introduction of hardfork based on data from dug up blocks The hardfork implementation will of course require 90% of dug blocks marked as BIP100 compatible (similar to what happened with the recently introduced BIP34 in Core v0.10). Photo under Creative Commons license: Flickr.com Tags
No comments:
Post a Comment