<p>Yes and no. It depends on how you frame the question.</p>

<ol>
<li><p><strong>It is a block size increase, because you can fit a larger number of
useful transactions into a block.</strong></p>

<p>If you want to make a useful Bitcoin transaction, it has to be signed so that nobody else can change it. If you can find a way to make the block size limit not count the signature, then you can fit more transactions into a block. Therefore, segwit is a block size increase.</p></li>
<li><p><strong>It isn't a block size increase, because increasing the block size
would be a hard fork, which segwit isn't.</strong></p>

<p>There's a constant within Bitcoin:</p>

<pre><code>static const unsigned int MAX_BLOCK_SIZE = 1000000;
</code></pre>

<p>If you raise this, even by a little, it becomes possible to create a block which new clients will accept, but old ones will not. This is commonly called a hard fork.</p>

<p>Segwit is not a hard fork. It does not amend or remove any rules; it only adds new rules. Increasing the block size requires modifying a rule, and segwit does not modify a rule, therefore segwit is not a block size increase.</p></li>
<li><p><strong>It is a block size increase, because a block requires more space to
store and send.</strong></p>

<p>You have a segwit block with 800KB of transaction data, and 800KB of witness data. This is 1.6MB, which is bigger than the previous limit. Since segwit full nodes must have this data to validate a block, segwit is a block size increase.</p></li>
<li><p><strong>It isn't a block size increase, because a node requires less or the same amount of space to store and send blocks if it doesn't understand segwit.</strong></p>

<p>You have the same block as the previous example, but it's sent to a node that doesn't understand segwit. It only receives the 800KB of transaction data. This is all it needs to store. Since that isn't larger than 1MB, segwit is not a block size increase. However, if it does not store the witness data, it cannot meaningfully validate the block.</p></li>
</ol>

CC BY-SA 3.0
2017-03-22T13:36:57.853Z
So, TL;DR: it is a blocksize increase if you upgrade to software that understands SegWit, but it isn't if you choose not to upgrade to software that understands SegWit. Funny how that reflects the prevalent opinions among certain Bitcoin user communities.
Murch
CC BY-SA 3.0
2017-04-29T19:38:21.917Z
Very nice answer.
Pieter Wuille
CC BY-SA 3.0
2017-06-16T20:54:28.343Z
If old clients can't meaningfully validate the block, what problems does that cause?
B T
CC BY-SA 3.0
2017-06-17T00:37:01.410Z
@BT Those clients effectively operate at an SPV level of security.
Nick ODell
CC BY-SA 3.0
2017-10-03T07:33:46.970Z
epic SegWit thread here as well, need to ignore the politics: https://bitcointalk.org/index.php?topic=1398994.20
pebwindkraft
CC BY-SA 3.0
2017-03-18T03:31:50.713Z
2017-06-17T04:06:05.007Z
2017-06-17T04:06:05.007Z
Nick ODell
<p>This question gets asked frequently on reddit, and I think it would be beneficial to have a canonical answer here:</p>

<p><strong>Is SegWit a blocksize increase or more efficient use of blockspace?</strong></p>

<segregated-witness><block-size-increase><blocksize>
Is SegWit a blocksize increase or more efficient use of blockspace?
Murch
# Is SegWit a blocksize increase or more efficient use of blockspace?

(Asked by: username_0 on 2017-03-17)

This question gets asked frequently on reddit, and I think it would be beneficial to have a canonical answer here:

**Is SegWit a blocksize increase or more efficient use of blockspace?**

**Tags:** segregated-witness, block-size-increase, blocksize


---

## 1 answers

### Answer by username_1 on 2017-03-18. Score: 29 | Accepted answer

Yes and no. It depends on how you frame the question.

1. **It is a block size increase, because you can fit a larger number of
   useful transactions into a block.**

   If you want to make a useful Bitcoin transaction, it has to be signed so that nobody else can change it. If you can find a way to make the block size limit not count the signature, then you can fit more transactions into a block. Therefore, segwit is a block size increase.
2. **It isn't a block size increase, because increasing the block size
   would be a hard fork, which segwit isn't.**

   There's a constant within Bitcoin:

   ```
   static const unsigned int MAX_BLOCK_SIZE = 1000000;

   ```

   If you raise this, even by a little, it becomes possible to create a block which new clients will accept, but old ones will not. This is commonly called a hard fork.

   Segwit is not a hard fork. It does not amend or remove any rules; it only adds new rules. Increasing the block size requires modifying a rule, and segwit does not modify a rule, therefore segwit is not a block size increase.
3. **It is a block size increase, because a block requires more space to
   store and send.**

   You have a segwit block with 800KB of transaction data, and 800KB of witness data. This is 1.6MB, which is bigger than the previous limit. Since segwit full nodes must have this data to validate a block, segwit is a block size increase.
4. **It isn't a block size increase, because a node requires less or the same amount of space to store and send blocks if it doesn't understand segwit.**

   You have the same block as the previous example, but it's sent to a node that doesn't understand segwit. It only receives the 800KB of transaction data. This is all it needs to store. Since that isn't larger than 1MB, segwit is not a block size increase. However, if it does not store the witness data, it cannot meaningfully validate the block.

> **Comments:**
> **username_0**: So, TL;DR: it is a blocksize increase if you upgrade to software that understands SegWit, but it isn't if you choose not to upgrade to software that understands SegWit. Funny how that reflects the prevalent opinions among certain Bitcoin user communities.  
> **username_2**: Very nice answer.  
> **username_3**: If old clients can't meaningfully validate the block, what problems does that cause?  
> **username_1**: @BT Those clients effectively operate at an SPV level of security.  
> **username_4**: epic SegWit thread here as well, need to ignore the politics: https://bitcointalk.org/index.php?topic=1398994.20  

---

