<p>The answer to the question "Are the segwit witnesses part of the blockchain" depends on what you define as the blockchain:</p>

<ul>
<li><p>According to old pre-segwit nodes, the answer is <strong>no</strong>, as they don't care or receive the witnesses.</p></li>
<li><p>According to new segwit nodes, the answer is <strong>yes</strong>; the witnesses are as much part of the chain as everything else, and subject to just as many validation rules.</p></li>
</ul>

<p>So segwit increases throughput slightly, at the cost of increasing the size of the blockchain. There is no magic bullet here, and this aspect of segwit is simply a block size increase. It is not a scalability improvement.</p>

<p>Segwit was primarily a solution for the transaction malleability problem, opening the door for various higher-level protocols that were handicapped by being unable to reason about future on-chain transactions that weren't published yet. In addition it also improved he incentive structure a bit (making spending relatively cheaper w.r.t. creating outputs). As a final side effect of that, it also increased the block size a bit in a backward compatible way.</p>

<p>As for your question about another fork that goes even further: what your software does has no effect on those who don't adopt it. Even if it has all the hashrate in the world on board, old nodes won't care or see your additional data.</p>

CC BY-SA 4.0
2018-12-07T20:07:50.030Z
But what makes this change able to not trigger a hard fork? And how can something both be and not be on the blockchain? I thought there was only one chain.
wlad
CC BY-SA 4.0
2018-12-07T20:09:21.393Z
I can't just take what you say on faith
wlad
CC BY-SA 4.0
2018-12-07T20:10:16.150Z
The only real explanation would be a story of a segwit transaction between Alice and Bob making it through the network. Everything else is "It magically can do this!" Though James C.'s explanation is starting to help
wlad
CC BY-SA 4.0
2018-12-07T20:16:22.293Z
I'm reading the BIP. If I have a breakthrough, I'll post an answer
wlad
CC BY-SA 4.0
2018-12-07T20:29:14.447Z
Segwit nodes simply strip out the witnesses when relaying to non-segwit peers. As the witnesses do not affect the txid, there is nothing in a transaction that alludes or refers to its witness in any way, so nothing is broken for nodes who don't care about those witnesses. However, the *block* does contain a hash of all witnesses (in a way that looks like a piece of random data to old nodes), making it part of the chain for those who care about it.
Pieter Wuille
CC BY-SA 4.0
2018-12-07T20:32:44.183Z
It helps to realize that the blockchain is not just a blob of bytes. It's a structure with pieces of data that refers to other pieces of data with hashes. Whether a node requires the data pointed to by those hashes is its own decision (for example, light nodes have the headers but don't require the transactions). Segwit simply added a new piece of data, which new nodes care about and others don't.
Pieter Wuille
CC BY-SA 4.0
2018-12-07T20:54:48.957Z
So it's almost like saying that we make a backwards-compatible dialect of C where some comments (which older compilers would ignore) become executable. I kind of get that. But then you're saying that the block contains only the *hash* of the witnesses
wlad
CC BY-SA 4.0
2018-12-07T20:55:20.217Z
My understanding is that hashing is an irreversible operation. So you only put a scrambled version of the witness data onto the blockchain
wlad
CC BY-SA 4.0
2018-12-07T21:06:40.590Z
It's wrong to think of blocks to "contain" anything. They're *all* just hashes. In the same way you can also say transactions are not "part" of the blockchain, because block headers just contain a hash of the transactions. Whether you think of transactions being an essential part of the chain depends on the context: full nodes do (they won't accept a block with tx hashes without the actual transactions), light nodes don't (they see the hashes and are happy with that). The same is true for segwit witnesses.
Pieter Wuille
CC BY-SA 4.0
2018-12-07T21:13:06.120Z
What is the point of a light node then? What on Earth can it do? I'm lost
wlad
CC BY-SA 4.0
2018-12-07T21:32:40.243Z
It can verify that transactions were included in the chain, selectively, without verifying that their signatures are valid. This is not as secure as a full node, but assuming enough others do run full node, it has much better usability with a security level that's acceptable to some use cases. Note that I'm not saying that segwit is related to this security tradeoff (it isn't), but it's a similar principle. You need to stop thinking about the chain being just a blob of data that contains some things and not other things. It's a structure with commitments, which some care about.
Pieter Wuille
CC BY-SA 4.0
2018-12-07T17:23:23.343Z
2018-12-07T17:31:05.240Z
2018-12-07T17:31:05.240Z
Pieter Wuille
<p>The 1MB block limit still stands after segwit activation, but it solely refers to the block transactions serialised in the pre-segwit format, which includes no witnesses. This 1MB is still consensus today.</p>

<p>With segwit activated, there is an additional block size constraint, which DOES apply to segwit data: It is a "weight" limit of 4M per block.</p>

<p>The weight is computed as follows:</p>

<ul>
<li>Transaction Bytes (Pre-segwit serialisation) x 3</li>
<li>Plus Transaction Bytes with Segwit (Segwit serialisation) x 1</li>
</ul>

<p>As the witness portion of the total transaction data increases towards 100%, the effective block size limit in Bytes approaches 4MB.</p>

CC BY-SA 4.0
2018-12-07T11:58:22.260Z
So the witnesses are *not* stamped onto the blockchain?
wlad
CC BY-SA 4.0
2018-12-07T11:59:37.467Z
The block size constraint is to avoid DDOSes via the Segwit channel?
wlad
CC BY-SA 4.0
2018-12-07T12:00:37.300Z
Good question: they are committed as witness root(like the merkleroot) together with the coinbase witness in a coinbase op_return output, which is validated for correctness.
James C.
CC BY-SA 4.0
2018-12-07T12:02:08.977Z
Does the `op_return` field not count towards the classical 1MB block size?
wlad
CC BY-SA 4.0
2018-12-07T12:02:23.640Z
There is no separate channel. If a node is not segwit ready, peers recognize this on the P2P level and refrain from sending witness data to the older peer. Witness data is “stripped” from the tx data.
James C.
CC BY-SA 4.0
2018-12-07T12:03:08.800Z
Yes op_return is not witness data and therefore contributes to the 1MB block limit.
James C.
CC BY-SA 4.0
2018-12-07T12:06:44.553Z
"committed as witness root". Onto the blockchain? Thanks.
wlad
CC BY-SA 4.0
2018-12-07T12:12:57.913Z
Yes in the coinbase transaction, which is the first tx in every block :) you can find details in one of the segwit BIPs. Something like dsha256(witnessroot|coinbasewitness).
James C.
CC BY-SA 4.0
2018-12-07T20:24:05.880Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/86773/discussion-between-man-on-laptop-and-james-c).
wlad
CC BY-SA 4.0
2018-12-07T11:49:49.743Z
2018-12-07T14:20:34.103Z
2018-12-07T14:20:34.103Z
James C.
<p>I'm posting this after reading the answers to this: <a href="https://bitcoin.stackexchange.com/questions/60171/where-is-the-signature-stored-in-a-segwit-transaction">Where is the Signature stored in a SegWit transaction?</a></p>

<p>I've found out from reading that, that in Segwit, the "witnesses" (or signatures) that verify a transaction's authenticity are <em>still</em> stored on the blockchain. In which case, the same amount of bits ought to be used up by a given transaction as if Segwit weren't being used. If the block size remains the same, let's say 1MB, then it ought to hold the exact same number of transactions.</p>

<p>I've got an alternative possibility. Let's say that what <em>actually</em> gets sent to the nodes is a transaction with an empty signatures field (I think that such a field doesn't quite exist because of multi-sig stuff and scripts, but bear with me). Then the signatures can be sent through a separate channel. What <em>actually</em> gets stamped onto the blockchain is a transaction with an empty signatures field. And then because of the longest-blockchain-always-wins rule, the non-Segwit nodes will simply accept that the blockchain with the most number of transactions, which includes some funny signature-less transactions, is the authoritative blockchain.</p>

<p>But apparently reality is more complicated.</p>

<p>Also, there's a question about how much the longest-blockchain-always-wins rule can be abused. (The word "abused" does not imply a negative opinion). For instance, let's say I come up with FoobarWit. FoobarWit is the same as Bitcoin but with a larger blocksize (no Segwit). Once enough nodes adopt FoobarWit, then more such nodes will win the mining race, and so other nodes will effectively accept bigger blocks because the history is longer. I know that's not the case, but why?</p>

CC BY-SA 4.0
2018-12-07T17:45:52.153Z
related: https://bitcoin.stackexchange.com/q/52196/5406
Murch
CC BY-SA 4.0
2018-12-07T20:02:51.040Z
@Murch I read that. Didn't really help
wlad
<segregated-witness><best-chain>
How can Segwit increase transaction throughput if the same amount of data is stored in the blockchain?
wlad
# How can Segwit increase transaction throughput if the same amount of data is stored in the blockchain?

(Asked by: username_0 on 2018-12-07)

I'm posting this after reading the answers to this: [Where is the Signature stored in a SegWit transaction?](https://bitcoin.stackexchange.com/questions/60171/where-is-the-signature-stored-in-a-segwit-transaction)

I've found out from reading that, that in Segwit, the "witnesses" (or signatures) that verify a transaction's authenticity are *still* stored on the blockchain. In which case, the same amount of bits ought to be used up by a given transaction as if Segwit weren't being used. If the block size remains the same, let's say 1MB, then it ought to hold the exact same number of transactions.

I've got an alternative possibility. Let's say that what *actually* gets sent to the nodes is a transaction with an empty signatures field (I think that such a field doesn't quite exist because of multi-sig stuff and scripts, but bear with me). Then the signatures can be sent through a separate channel. What *actually* gets stamped onto the blockchain is a transaction with an empty signatures field. And then because of the longest-blockchain-always-wins rule, the non-Segwit nodes will simply accept that the blockchain with the most number of transactions, which includes some funny signature-less transactions, is the authoritative blockchain.

But apparently reality is more complicated.

Also, there's a question about how much the longest-blockchain-always-wins rule can be abused. (The word "abused" does not imply a negative opinion). For instance, let's say I come up with FoobarWit. FoobarWit is the same as Bitcoin but with a larger blocksize (no Segwit). Once enough nodes adopt FoobarWit, then more such nodes will win the mining race, and so other nodes will effectively accept bigger blocks because the history is longer. I know that's not the case, but why?

**Tags:** segregated-witness, best-chain

> **Comments:**
> **username_1**: related: https://bitcoin.stackexchange.com/q/52196/5406  
> **username_0**: @username_1 I read that. Didn't really help  

---

## 2 answers

### Answer by username_2 on 2018-12-07. Score: 6

The answer to the question "Are the segwit witnesses part of the blockchain" depends on what you define as the blockchain:

* According to old pre-segwit nodes, the answer is **no**, as they don't care or receive the witnesses.
* According to new segwit nodes, the answer is **yes**; the witnesses are as much part of the chain as everything else, and subject to just as many validation rules.

So segwit increases throughput slightly, at the cost of increasing the size of the blockchain. There is no magic bullet here, and this aspect of segwit is simply a block size increase. It is not a scalability improvement.

Segwit was primarily a solution for the transaction malleability problem, opening the door for various higher-level protocols that were handicapped by being unable to reason about future on-chain transactions that weren't published yet. In addition it also improved he incentive structure a bit (making spending relatively cheaper w.r.t. creating outputs). As a final side effect of that, it also increased the block size a bit in a backward compatible way.

As for your question about another fork that goes even further: what your software does has no effect on those who don't adopt it. Even if it has all the hashrate in the world on board, old nodes won't care or see your additional data.

> **Comments:**
> **username_0**: But what makes this change able to not trigger a hard fork? And how can something both be and not be on the blockchain? I thought there was only one chain.  
> **username_0**: I can't just take what you say on faith  
> **username_0**: The only real explanation would be a story of a segwit transaction between Alice and Bob making it through the network. Everything else is "It magically can do this!" Though username_3 C.'s explanation is starting to help  
> **username_0**: I'm reading the BIP. If I have a breakthrough, I'll post an answer  
> **username_2**: Segwit nodes simply strip out the witnesses when relaying to non-segwit peers. As the witnesses do not affect the txid, there is nothing in a transaction that alludes or refers to its witness in any way, so nothing is broken for nodes who don't care about those witnesses. However, the *block* does contain a hash of all witnesses (in a way that looks like a piece of random data to old nodes), making it part of the chain for those who care about it.  
> **username_2**: It helps to realize that the blockchain is not just a blob of bytes. It's a structure with pieces of data that refers to other pieces of data with hashes. Whether a node requires the data pointed to by those hashes is its own decision (for example, light nodes have the headers but don't require the transactions). Segwit simply added a new piece of data, which new nodes care about and others don't.  
> **username_0**: So it's almost like saying that we make a backwards-compatible dialect of C where some comments (which older compilers would ignore) become executable. I kind of get that. But then you're saying that the block contains only the *hash* of the witnesses  
> **username_0**: My understanding is that hashing is an irreversible operation. So you only put a scrambled version of the witness data onto the blockchain  
> **username_2**: It's wrong to think of blocks to "contain" anything. They're *all* just hashes. In the same way you can also say transactions are not "part" of the blockchain, because block headers just contain a hash of the transactions. Whether you think of transactions being an essential part of the chain depends on the context: full nodes do (they won't accept a block with tx hashes without the actual transactions), light nodes don't (they see the hashes and are happy with that). The same is true for segwit witnesses.  
> **username_0**: What is the point of a light node then? What on Earth can it do? I'm lost  
> **username_2**: It can verify that transactions were included in the chain, selectively, without verifying that their signatures are valid. This is not as secure as a full node, but assuming enough others do run full node, it has much better usability with a security level that's acceptable to some use cases. Note that I'm not saying that segwit is related to this security tradeoff (it isn't), but it's a similar principle. You need to stop thinking about the chain being just a blob of data that contains some things and not other things. It's a structure with commitments, which some care about.  

---

### Answer by username_3 on 2018-12-07. Score: 1

The 1MB block limit still stands after segwit activation, but it solely refers to the block transactions serialised in the pre-segwit format, which includes no witnesses. This 1MB is still consensus today.

With segwit activated, there is an additional block size constraint, which DOES apply to segwit data: It is a "weight" limit of 4M per block.

The weight is computed as follows:

* Transaction Bytes (Pre-segwit serialisation) x 3
* Plus Transaction Bytes with Segwit (Segwit serialisation) x 1

As the witness portion of the total transaction data increases towards 100%, the effective block size limit in Bytes approaches 4MB.

> **Comments:**
> **username_0**: So the witnesses are *not* stamped onto the blockchain?  
> **username_0**: The block size constraint is to avoid DDOSes via the Segwit channel?  
> **username_3**: Good question: they are committed as witness root(like the merkleroot) together with the coinbase witness in a coinbase op_return output, which is validated for correctness.  
> **username_0**: Does the `op_return` field not count towards the classical 1MB block size?  
> **username_3**: There is no separate channel. If a node is not segwit ready, peers recognize this on the P2P level and refrain from sending witness data to the older peer. Witness data is “stripped” from the tx data.  
> **username_3**: Yes op_return is not witness data and therefore contributes to the 1MB block limit.  
> **username_0**: "committed as witness root". Onto the blockchain? Thanks.  
> **username_3**: Yes in the coinbase transaction, which is the first tx in every block :) you can find details in one of the segwit BIPs. Something like dsha256(witnessroot|coinbasewitness).  
> **username_0**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/86773/discussion-between-man-on-laptop-and-username_3-c).  

---

