0

in this link, they say

“increasing the block size above 1 MB requires a hard fork.” In this example, an actual block chain fork is not required—but it is a possible outcome.

but i can't understand why actually it not require block chain fork. when block upgrade, soft fork or hard fork will occurred. but it say both of fork is not required actually.

thanks for your help :)

  • Block size is already above 1 MB and it didn't take a hard fork. – Jannes Feb 18 at 13:08
0

The definitions here are a bit confusing. It is important to understand the distinction between the "soft/hard fork" and the "blockchain fork".

  • Blockchain fork is an actual split in a chain of blocks. If two groups of people run incompatible software - two different chains will emerge. For example, Bitcoin and Bitcoin Cash follow two different chains that used to be one chain.

  • Soft or hard fork is a mechanism of performing consensus rule changes. Hard fork upgrade has a risk of causing a blockchain fork, but it does not have to cause it. If everyone will upgrade in time, there would be no chain split. For example, Ethereum has performed multiple "upgrades" through hard forks (such as Byzantium), and the chain did not split. Bitcoin prefers to stay on the safe side and introduces most of the changes to the protocol as soft forks.

To add to the confusion there are also user-activated forks and miner-activated fork, but these are not relevant to the question.

  • thanks but i have one more question. in individual miner's[like me :) ] side, how UASF 's agree and disagree is considered? – user10865941 Feb 19 at 2:04
  • @user10865941 as a miner you also run a full node, so your vote is considered together with all other nodes. Also if UASF is very popular, your blocks may have a higher chance of being propagated through the network, so in theory you have an advantage as a miner. – Dmitry Laptev Feb 19 at 5:58
0

First of all, current block size is not 1MB. Segwit soft fork (defined in BIP-141) allowed packing more transactions in a block by moving the witness data (signatures) outside the transaction. The current theoretically allowed weight of the block is 4,000,000 bytes. A little more on how this was achieved without a hard fork is at the end of the answer.

Now coming to your question, as to why a hard fork is required in order to increase block size, we need to understand when a hard fork should occur. A hard fork is a change in consensus rules that are not forward compatible. That means, previous consensus rules will lead to blocks mined after a hard fork as invalid. When a block is mined and propagated across the network, the full nodes first check the block across the different rules to ensure that the block is valid. One of the rules include checking that the block size is below 1MB. Thus including blocks with sizes above 1MB will require nodes to upgrade their consensus rules to verify such block sizes.

Segwit allowed increased block weight with a soft fork (back-war. That means, that the previous consensus rules still declare the new block weight as valid. This was achieved by taking the witness data (signatures that verify the transaction) outside the transaction data. For a non-Segwit aware client (one that did not upgrade to Segwit) these transactions will appear to be locked with signature that anyone can spend and hence are also valid. However, a Segwit aware client sees the Segregated Witness output and expect to find a valid witness for it in the transaction's witness data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.