<p>This is a controversial (but fair) question, so I'll try to be as fair as possible in answering.</p>

<blockquote>
  <p>Segwit was released in the summer or 2017 to resolve the network congestion</p>
</blockquote>

<p>I would not use the word "resolve" here, because that implies that Segregated Witness was intended to completely solve the issue.  This is not true.  Like with most software scalability issues, the goal was to mitigate the problem to a reasonable level.  In fact, Segwit was meant to mitigate several issues with Bitcoin (such as malleability and script versioning), and not just fitting more transactions into blocks.  The changes that were made set Bitcoin up to be in a better position for future scaling mitigations.  Segwit is not a one time fix.  The debate that often occurs is that people demand more transactions/block immediately, to which the only solution is increasing the block size.</p>

<blockquote>
  <p>Didn't it enable 1MB blocks to become 2MB blocks?</p>
</blockquote>

<p>No.  Segregated Witness allows for new, Segwit transactions to keep the bulk of their data (the signatures) in a separate tree structure that counts only 1/4th towards the block size limit.  As such it is possible for blocks to grow over 1MB, which makes it is possible for more transactions to fit in (about 2-3 times as many, when fully utilized), and miners can incentivize Segwit transactions with lower fees.</p>

<blockquote>
  <p>Or do you have to wait for wallet providers to make use of the segwit portion of the software?</p>
</blockquote>

<p>Yes, but this has mostly already happened.  As with any such upgrade, it takes time to start seeing the results (which was deemed unacceptable to some users).  As more users submit Segwit transactions, more space will be created in the blocks.  In addition, the malleability fixes brought on by Segwit will allow for tier-2 networks (like the Lightning Network), which may cause many users to choose an off-chain solution.  This, in turn will free up more space in the blocks.</p>

<blockquote>
  <p>Why is the network still congested?</p>
</blockquote>

<p>Some claim it is combination of increased interest/usage of Bitcoin, and the fact that we haven't fully realized all the potential positive effects of Segregated Witness.  Others argue that increasing the block size is the only route to real scalability, and messing with other aspects of the protocol go against the original intent of Bitcoin.  This is still being debated.</p>

CC BY-SA 3.0
2017-11-02T17:07:35.707Z
Light congestion is actually a requirement for a securely operating Bitcoin: there MUST always be enough fee paying transactions ready in the mempool to incentivize miners to mine the next block (and not stop mining or even attack the previous block). Without congestion you don't have a working fee market and fees would regularly drop towards 0.
Jannes
CC BY-SA 3.0
2017-11-03T07:18:09.920Z
Jannes comment is utterly wrong. there needs to be transactions and there needs to be fees, but congestion is not proven to be necessary for the survival of the miners. the fee market is one solution to keep users providing fees, but it isnt the only solution.
Jonathan Silverblood
CC BY-SA 3.0
2017-11-02T16:53:43.233Z
2017-11-02T17:04:47.387Z
2017-11-02T17:04:47.387Z
Jestin
<p>SegWit cannot, and was never designed to "resolve network congestion". It:</p>

<ul>
<li>fixes the <strong>third-party malleability</strong> issue that Bitcoin has had since its creation, vastly simplifying many multi-transaction smart contract constructions (like Lightning). </li>
<li>fixes the <strong>O(N<sup>2</sup>) signature hashing</strong> problem.</li>
<li>adds <strong>amount commitments</strong> to signature hashing, simplifying design of hardware signing modules ("hardware wallets")</li>
<li>adds <strong>script versioning</strong>, making it significantly easier to add new features later as a soft fork</li>
<li>introduces a scripthash mode with <strong>128-bit security</strong> (P2SH only has 80-bit security against certain attacks)</li>
<li>introduces a <strong>discount factor 4</strong> for signatures w.r.t. block size accounting, partially rectifying the issue that creating an output is far cheaper than spending one.</li>
</ul>

<p>All of the points above are improvements to Bitcoin in the long term w.r.t. scalability and security. In addition, the last point also indirectly provides a <strong>modest capacity increase</strong> - allowing a bit more throughput for those who choose to use new-style transactions. This is justified by the fact that simultaneously some of the worst-case costs to the network are removed (the O(N<sup>2</sup>) sighashing), and technological improvements for block relay (see BIP152). It is by no means a blanket "let's double capacity" - more an improvement in the accuracy in counting the cost of transactions, which happens to make things cheaper for the most common ones.</p>

<p>Regarding network congestion, that's just a fact of life if the network is operating sanely. It's both necessary for the system's survival (as the miner subsidy diminishes, fees more and more directly define the incentive for miners to secure the network), and a logical result of any restriction in capacity - whether that is 1MB or 2MB or 100MB blocks. If capacity in blocks isn't being used, the price of block space will drop, and new use cases will develop. For example, if the available space isn't being used for extended periods of time, I expect the feerate to go so low that people will start to try to put their backups in those blocks - burdening the whole world. Essentially, what you call network congestion is just a sign of a functioning fee market: <em>if you don't limit the price, the demand will become infinite</em>.</p>

<p>Disclaimer: I designed a significant part of SegWit.</p>

CC BY-SA 3.0
2017-11-03T07:15:13.213Z
while strictly true, it was marketed over and over again as a partial solution to the scalability issues, and there are numerous quotes from its developers stating various expected scalability results.
Jonathan Silverblood
CC BY-SA 3.0
2017-11-03T15:54:40.523Z
@JonathanSilverblood, the question is about the technical realities, not marketing.  If inaccurate/misleading marketing claims were made, it isn't relevant here.  Maybe it's true, maybe it's not.  This is a question/answer forum, and nobody wants the politics of the scaling debate to detract from a technically correct answer to a technical question.
Jestin
CC BY-SA 3.0
2017-11-03T16:27:04.437Z
The question is about why the technical realities differ from the expected realities, as such it does make sense to mention what those expectations are/were. they're not part of the answer, but they are definately a part of the the question.
Jonathan Silverblood
CC BY-SA 3.0
2017-11-03T18:47:24.360Z
SegWit absolutely is an improvement to scalability issues, and has been communicated as such. Limited capacity is not a scalability problem however, despite many people having claimed and repeated that SegWit would somehow resolve that (although to the best of my knowledge, not its authors). I believe my answer exactly clarifies that, by stating the exact problems addressed by it.
Pieter Wuille
CC BY-SA 3.0
2017-11-02T16:52:31.513Z
2017-11-03T01:20:58.053Z
2017-11-03T01:20:58.053Z
Pieter Wuille
<p>Segwit was released in the summer of 2017 to resolve the network congestion. Why is the network still congested? Didn't it enable 1MB blocks to become 2MB blocks? Or do you have to wait for wallet providers to make use of the segwit portion of the software?</p>

CC BY-SA 3.0
2017-11-02T16:58:09.427Z
Released fall 2016 actually.
Jannes
<segregated-witness>
Bitcoin Segwit was released in the summer of 2017 to reduce the blocksize congestion. Why is it still congested?
Patoshi パトシ
# Bitcoin Segwit was released in the summer of 2017 to reduce the blocksize congestion. Why is it still congested?

(Asked by: username_0 on 2017-11-02)

Segwit was released in the summer of 2017 to resolve the network congestion. Why is the network still congested? Didn't it enable 1MB blocks to become 2MB blocks? Or do you have to wait for wallet providers to make use of the segwit portion of the software?

**Tags:** segregated-witness

> **Comments:**
> **username_1**: Released fall 2016 actually.  

---

## 2 answers

### Answer by username_4 on 2017-11-02. Score: 31 | Accepted answer

SegWit cannot, and was never designed to "resolve network congestion". It:

* fixes the **third-party malleability** issue that Bitcoin has had since its creation, vastly simplifying many multi-transaction smart contract constructions (like Lightning).
* fixes the **O(N2) signature hashing** problem.
* adds **amount commitments** to signature hashing, simplifying design of hardware signing modules ("hardware wallets")
* adds **script versioning**, making it significantly easier to add new features later as a soft fork
* introduces a scripthash mode with **128-bit security** (P2SH only has 80-bit security against certain attacks)
* introduces a **discount factor 4** for signatures w.r.t. block size accounting, partially rectifying the issue that creating an output is far cheaper than spending one.

All of the points above are improvements to Bitcoin in the long term w.r.t. scalability and security. In addition, the last point also indirectly provides a **modest capacity increase** - allowing a bit more throughput for those who choose to use new-style transactions. This is justified by the fact that simultaneously some of the worst-case costs to the network are removed (the O(N2) sighashing), and technological improvements for block relay (see BIP152). It is by no means a blanket "let's double capacity" - more an improvement in the accuracy in counting the cost of transactions, which happens to make things cheaper for the most common ones.

Regarding network congestion, that's just a fact of life if the network is operating sanely. It's both necessary for the system's survival (as the miner subsidy diminishes, fees more and more directly define the incentive for miners to secure the network), and a logical result of any restriction in capacity - whether that is 1MB or 2MB or 100MB blocks. If capacity in blocks isn't being used, the price of block space will drop, and new use cases will develop. For example, if the available space isn't being used for extended periods of time, I expect the feerate to go so low that people will start to try to put their backups in those blocks - burdening the whole world. Essentially, what you call network congestion is just a sign of a functioning fee market: *if you don't limit the price, the demand will become infinite*.

Disclaimer: I designed a significant part of SegWit.

> **Comments:**
> **username_3**: while strictly true, it was marketed over and over again as a partial solution to the scalability issues, and there are numerous quotes from its developers stating various expected scalability results.  
> **username_2**: @username_3, the question is about the technical realities, not marketing.  If inaccurate/misleading marketing claims were made, it isn't relevant here.  Maybe it's true, maybe it's not.  This is a question/answer forum, and nobody wants the politics of the scaling debate to detract from a technically correct answer to a technical question.  
> **username_3**: The question is about why the technical realities differ from the expected realities, as such it does make sense to mention what those expectations are/were. they're not part of the answer, but they are definately a part of the the question.  
> **username_4**: SegWit absolutely is an improvement to scalability issues, and has been communicated as such. Limited capacity is not a scalability problem however, despite many people having claimed and repeated that SegWit would somehow resolve that (although to the best of my knowledge, not its authors). I believe my answer exactly clarifies that, by stating the exact problems addressed by it.  

---

### Answer by username_2 on 2017-11-02. Score: 4

This is a controversial (but fair) question, so I'll try to be as fair as possible in answering.

> Segwit was released in the summer or 2017 to resolve the network congestion

I would not use the word "resolve" here, because that implies that Segregated Witness was intended to completely solve the issue. This is not true. Like with most software scalability issues, the goal was to mitigate the problem to a reasonable level. In fact, Segwit was meant to mitigate several issues with Bitcoin (such as malleability and script versioning), and not just fitting more transactions into blocks. The changes that were made set Bitcoin up to be in a better position for future scaling mitigations. Segwit is not a one time fix. The debate that often occurs is that people demand more transactions/block immediately, to which the only solution is increasing the block size.

> Didn't it enable 1MB blocks to become 2MB blocks?

No. Segregated Witness allows for new, Segwit transactions to keep the bulk of their data (the signatures) in a separate tree structure that counts only 1/4th towards the block size limit. As such it is possible for blocks to grow over 1MB, which makes it is possible for more transactions to fit in (about 2-3 times as many, when fully utilized), and miners can incentivize Segwit transactions with lower fees.

> Or do you have to wait for wallet providers to make use of the segwit portion of the software?

Yes, but this has mostly already happened. As with any such upgrade, it takes time to start seeing the results (which was deemed unacceptable to some users). As more users submit Segwit transactions, more space will be created in the blocks. In addition, the malleability fixes brought on by Segwit will allow for tier-2 networks (like the Lightning Network), which may cause many users to choose an off-chain solution. This, in turn will free up more space in the blocks.

> Why is the network still congested?

Some claim it is combination of increased interest/usage of Bitcoin, and the fact that we haven't fully realized all the potential positive effects of Segregated Witness. Others argue that increasing the block size is the only route to real scalability, and messing with other aspects of the protocol go against the original intent of Bitcoin. This is still being debated.

> **Comments:**
> **username_1**: Light congestion is actually a requirement for a securely operating Bitcoin: there MUST always be enough fee paying transactions ready in the mempool to incentivize miners to mine the next block (and not stop mining or even attack the previous block). Without congestion you don't have a working fee market and fees would regularly drop towards 0.  
> **username_3**: username_1 comment is utterly wrong. there needs to be transactions and there needs to be fees, but congestion is not proven to be necessary for the survival of the miners. the fee market is one solution to keep users providing fees, but it isnt the only solution.  

---

