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

<ul>
<li><p><em>Blockchain fork</em> 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.</p></li>
<li><p><em>Soft or hard fork</em> is a mechanism of performing consensus rule changes. <em>Hard fork</em> upgrade has a risk of causing a <em>blockchain fork</em>, 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 <em>hard forks</em> (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 <em>soft forks</em>.</p></li>
</ul>

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

CC BY-SA 4.0
2019-02-19T02:04:29.900Z
thanks but i have one more question. in individual miner's[like me :)  ] side, how UASF 's agree and disagree is considered?
user10865941
CC BY-SA 4.0
2019-02-19T05:58:01.650Z
@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
CC BY-SA 4.0
2019-02-18T14:00:18.167Z
2019-02-18T14:00:18.167Z
Dmitry Laptev
<p>First of all, current block size is not 1MB. Segwit soft fork (defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">BIP-141</a>) 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.</p>

<p>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. </p>

<p>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 <em>anyone can spend</em> 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. </p>

CC BY-SA 4.0
2019-02-18T16:14:40.783Z
2019-02-18T16:14:40.783Z
Ugam Kamat
<p>in this <a href="https://bitcoin.org/en/developer-guide#consensus-rule-changes" rel="nofollow noreferrer">link</a>, they say </p>

<blockquote>
  <p>“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.</p>
</blockquote>

<p>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.</p>

<p>thanks for your help :) </p>

CC BY-SA 4.0
2019-02-18T13:08:56.163Z
Block size is already above 1 MB and it didn't take a hard fork.
Jannes
<blockchain-fork>
why 'increasing the block size above 1 MB requires a hard fork.” actually not require fork?
user10865941
# why 'increasing the block size above 1 MB requires a hard fork.” actually not require fork?

(Asked by: username_0 on 2019-02-18)

in this [link](https://bitcoin.org/en/developer-guide#consensus-rule-changes), 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 :)

**Tags:** blockchain-fork

> **Comments:**
> **username_1**: Block size is already above 1 MB and it didn't take a hard fork.  

---

## 2 answers

### Answer by username_2 on 2019-02-18. Score: 0 | Accepted answer

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.

> **Comments:**
> **username_0**: thanks but i have one more question. in individual miner's[like me :)  ] side, how UASF 's agree and disagree is considered?  
> **username_2**: @username_0 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.  

---

### Answer by username_3 on 2019-02-18. Score: 0

First of all, current block size is not 1MB. Segwit soft fork (defined in [BIP-141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)) 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.


---

