<p>It doesn't save space, as it still stores the witness data somewhere, but it allows the blocks (according to some canonical definition of "block") to <em>increase</em> in a subtle manner while being a soft-fork instead of a hard-fork (this basically means it doesn't break compatibility with previous Bitcoin clients).</p>

CC BY-SA 4.0
2019-12-09T21:22:22.920Z
2019-12-09T21:22:22.920Z
fiatjaf
<p>I've had a hard time finding a good source online that explains segwit.
I've read the basic idea is to store the scriptSigs separately as the scriptSig is potentially malleable, and then compute the txid without the scripSig.
But the scriptSig still needs to be somewhere on the blockchain, so how does this save space?</p>

CC BY-SA 3.0
2017-05-03T05:11:24.733Z
It doesn't. See https://bitcoin.stackexchange.com/q/52196/208
Pieter Wuille
CC BY-SA 3.0
2017-05-03T09:20:50.430Z
I don't get it. It sounds like you're putting the scriptSig in a separate place you're not calling a block, but still using the same amount of space. Why not just keep it in the block, and just compute the txid ignoring the scriptsig to get the non-malleability advantage?
relG
CC BY-SA 3.0
2017-05-03T14:04:07.473Z
That would not be a softfork, and thus require every node in the whole network to adopt new software before the change can be deployed. It would also break existing wallet software. The way it is done is fully backward compatible.
Pieter Wuille
CC BY-SA 3.0
2017-05-03T14:59:40.527Z
Is a softfork such a holy grail in itself, that anything that satisfies the definition is good? To me a natural softfork is one where the legitimate sender can get his tx unaccepted by new nodes if he doesn't upgrade his wallet to the new rules.. but here because the scriptSig is anyone_can_spend, anyone can fraudulently spend the output of the legitimate owner in the view of the old nodes. Thus, the old nodes will become completely useless almost immediately - they also cannot relay a legitimate transaction to the new nodes because they don't know they need to transfer the witness.
relG
CC BY-SA 3.0
2017-05-03T15:18:12.290Z
Softforks are not a holy grail. A softfork that freezes some specific person's coins would be a very bad thing. But what you're saying is an overstatement: old nodes indeed can't fully verify spends from segwit outputs, but they also don't care about them.
Pieter Wuille
CC BY-SA 3.0
2017-05-03T15:24:14.530Z
See https://segwit.org/on-the-security-of-soft-forks-2c0a00077399
Pieter Wuille
CC BY-SA 4.0
2020-09-04T23:08:45.863Z
Does this answer your question? [Is SegWit a blocksize increase or more efficient use of blockspace?](https://bitcoin.stackexchange.com/questions/52196/is-segwit-a-blocksize-increase-or-more-efficient-use-of-blockspace)
Antoine Poinsot
<segregated-witness>
Why does segwit save space on the blockchain?
relG
# Why does segwit save space on the blockchain?

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

I've had a hard time finding a good source online that explains segwit.
I've read the basic idea is to store the scriptSigs separately as the scriptSig is potentially malleable, and then compute the txid without the scripSig.
But the scriptSig still needs to be somewhere on the blockchain, so how does this save space?

**Tags:** segregated-witness

> **Comments:**
> **username_1**: It doesn't. See https://bitcoin.stackexchange.com/q/52196/208  
> **username_0**: I don't get it. It sounds like you're putting the scriptSig in a separate place you're not calling a block, but still using the same amount of space. Why not just keep it in the block, and just compute the txid ignoring the scriptsig to get the non-malleability advantage?  
> **username_1**: That would not be a softfork, and thus require every node in the whole network to adopt new software before the change can be deployed. It would also break existing wallet software. The way it is done is fully backward compatible.  
> **username_0**: Is a softfork such a holy grail in itself, that anything that satisfies the definition is good? To me a natural softfork is one where the legitimate sender can get his tx unaccepted by new nodes if he doesn't upgrade his wallet to the new rules.. but here because the scriptSig is anyone_can_spend, anyone can fraudulently spend the output of the legitimate owner in the view of the old nodes. Thus, the old nodes will become completely useless almost immediately - they also cannot relay a legitimate transaction to the new nodes because they don't know they need to transfer the witness.  
> **username_1**: Softforks are not a holy grail. A softfork that freezes some specific person's coins would be a very bad thing. But what you're saying is an overstatement: old nodes indeed can't fully verify spends from segwit outputs, but they also don't care about them.  
> **username_1**: See https://segwit.org/on-the-security-of-soft-forks-2c0a00077399  
> **username_2**: Does this answer your question? [Is SegWit a blocksize increase or more efficient use of blockspace?](https://bitcoin.stackexchange.com/questions/52196/is-segwit-a-blocksize-increase-or-more-efficient-use-of-blockspace)  

---

## 1 answers

### Answer by username_3 on 2019-12-09. Score: 1

It doesn't save space, as it still stores the witness data somewhere, but it allows the blocks (according to some canonical definition of "block") to *increase* in a subtle manner while being a soft-fork instead of a hard-fork (this basically means it doesn't break compatibility with previous Bitcoin clients).


---

