<p>No, that's not accurate. Witness data is on-chain, inputs have a similar byte length as before (they are just weighed differently), and the transaction throughput is increased because segwit is a defacto blocksize increase.</p>
<blockquote>
<p>Thus, with segwit, the witness data was separated from the rest of the input. More specifically, the witness data is now &quot;off-chain&quot;. This made the input much lighter and, in turns, it made spending an UTXO cheaper and faster to process.</p>
</blockquote>
<p>This is a common misunderstanding perpetuated by an abundance of (sometimes deliberately) confusing descriptions of how segwit works.</p>
<p>A transaction is not complete without the proof that it was authorized by the owner of the spent funds. As such, the witness is explicitly part of a &quot;complete transaction&quot;. What segwit did was to segregate the witness (read &quot;signature&quot;) out of the input script and move it to the &quot;witness section&quot; of the transaction. The witness section is at the same hierarchical level as the inputs and outputs.</p>
<p>The witness section is excluded when calculating the transaction id (txid), but it is part of the transaction, and used to calculate the <em>witness transaction id (wtxid)</em>. While the merkle root in the blockheader commits to the txids of the included transactions, each segwit block additionally commits to a merkle tree of the transactions' wtxids. In conclusion, the witnesses are a) part of the transaction, b) part of the blockchain, c) necessary to fully validate the blockchain.</p>
<p>Segwit replaced the blocksize limit with a blockweight limit. The blocksize was based on the raw byte length of transactions and capped at 1,000,000 bytes. The blockweight limit is capped at 4,000,000 weight units, where weight is calculated by counting witness bytes with a factor of one, and non-witness bytes with a factor of 4. This happens to result in an equivalent limit if a block only includes transactions without witness data.</p>
<p>The actual transaction data of a segwit input compared to a non-segwit input is only marginally smaller. It is the discount of witness data that allows blocks to exceed the previous blocksize limit, making segwit an effective blocksize increase with the <a href="https://blockchair.com/bitcoin/block/625861" rel="noreferrer">biggest block to date</a> having 2,422,858 bytes (but 3,993,379 weight units).</p>
<p>Segwit transactions and blocks are made forward compatible to pre-segwit nodes. Segwit nodes will strip the witness data before relaying the data to pre-segwit nodes. The stripped transactions and blocks are non-standard but valid according to the pre-segwit protocol rules, and thus pre-segwit nodes can follow the blockchain and converge on the same UTXO set.</p>
<p>Note that pre-segwit nodes have not been &quot;fully validating nodes&quot; since segwit was activated on August 24th 2017 as they do not unilaterally enforce all consensus rules of the Bitcoin protocol.</p>

CC BY-SA 4.0
2020-10-28T19:51:52.993Z
Thanks; this is much clearer to me, now.
Pascal Bergeron
CC BY-SA 4.0
2020-10-28T21:28:38.863Z
Just raising the blocksize limit to 4 MB would have not been forward compatible and old nodes would have been forked off.
Murch
CC BY-SA 4.0
2020-10-28T17:35:22.703Z
2020-10-29T04:11:02.170Z
2020-10-29T04:11:02.170Z
Murch
<p>I have several questions regarding the segwit witness data. My current understanding is as follows.</p>
<p>Before segwit, the witness data was part of the input that the user had to provide so that they could spend an UTXO. The witness data is the digital signature or any other solution that allows an UTXO to be spent. The input was not comprised only of the witness data, but the witness data could be a large part of the input.</p>
<p>Thus, with segwit, the witness data was separated from the rest of the input. More specifically, the witness data is now &quot;off-chain&quot;. This made the input much lighter and, in turns, it made spending an UTXO cheaper and faster to process.</p>
<p>My questions are:</p>
<ol>
<li><p>Is my understanding above correct?</p>
</li>
<li><p>What do we mean when we say that the witness data is &quot;off-chain&quot;? If it's not part of the blockchain, where does it reside? Does it mean that nodes process witness data differently from the rest of the input data?</p>
</li>
<li><p>While I understand that the input itself is now lighter, the user still has to provide the witness data in order to spend the UTXO. Wouldn't the witness data need to be relayed alongside the rest of the input so that nodes can make sure that the transactions are valid? How can there be a gain of efficiency?</p>
</li>
</ol>

<segregated-witness><transaction-input><off-chain>
How can the segwit witness data be "off-chain"? What does it really mean?
Pascal Bergeron
# How can the segwit witness data be "off-chain"? What does it really mean?

(Asked by: username_0 on 2020-10-28)

I have several questions regarding the segwit witness data. My current understanding is as follows.

Before segwit, the witness data was part of the input that the user had to provide so that they could spend an UTXO. The witness data is the digital signature or any other solution that allows an UTXO to be spent. The input was not comprised only of the witness data, but the witness data could be a large part of the input.

Thus, with segwit, the witness data was separated from the rest of the input. More specifically, the witness data is now "off-chain". This made the input much lighter and, in turns, it made spending an UTXO cheaper and faster to process.

My questions are:

1. Is my understanding above correct?
2. What do we mean when we say that the witness data is "off-chain"? If it's not part of the blockchain, where does it reside? Does it mean that nodes process witness data differently from the rest of the input data?
3. While I understand that the input itself is now lighter, the user still has to provide the witness data in order to spend the UTXO. Wouldn't the witness data need to be relayed alongside the rest of the input so that nodes can make sure that the transactions are valid? How can there be a gain of efficiency?

**Tags:** segregated-witness, transaction-input, off-chain


---

## 1 answers

### Answer by username_1 on 2020-10-28. Score: 9 | Accepted answer

No, that's not accurate. Witness data is on-chain, inputs have a similar byte length as before (they are just weighed differently), and the transaction throughput is increased because segwit is a defacto blocksize increase.

> Thus, with segwit, the witness data was separated from the rest of the input. More specifically, the witness data is now "off-chain". This made the input much lighter and, in turns, it made spending an UTXO cheaper and faster to process.

This is a common misunderstanding perpetuated by an abundance of (sometimes deliberately) confusing descriptions of how segwit works.

A transaction is not complete without the proof that it was authorized by the owner of the spent funds. As such, the witness is explicitly part of a "complete transaction". What segwit did was to segregate the witness (read "signature") out of the input script and move it to the "witness section" of the transaction. The witness section is at the same hierarchical level as the inputs and outputs.

The witness section is excluded when calculating the transaction id (txid), but it is part of the transaction, and used to calculate the *witness transaction id (wtxid)*. While the merkle root in the blockheader commits to the txids of the included transactions, each segwit block additionally commits to a merkle tree of the transactions' wtxids. In conclusion, the witnesses are a) part of the transaction, b) part of the blockchain, c) necessary to fully validate the blockchain.

Segwit replaced the blocksize limit with a blockweight limit. The blocksize was based on the raw byte length of transactions and capped at 1,000,000 bytes. The blockweight limit is capped at 4,000,000 weight units, where weight is calculated by counting witness bytes with a factor of one, and non-witness bytes with a factor of 4. This happens to result in an equivalent limit if a block only includes transactions without witness data.

The actual transaction data of a segwit input compared to a non-segwit input is only marginally smaller. It is the discount of witness data that allows blocks to exceed the previous blocksize limit, making segwit an effective blocksize increase with the [biggest block to date](https://blockchair.com/bitcoin/block/625861) having 2,422,858 bytes (but 3,993,379 weight units).

Segwit transactions and blocks are made forward compatible to pre-segwit nodes. Segwit nodes will strip the witness data before relaying the data to pre-segwit nodes. The stripped transactions and blocks are non-standard but valid according to the pre-segwit protocol rules, and thus pre-segwit nodes can follow the blockchain and converge on the same UTXO set.

Note that pre-segwit nodes have not been "fully validating nodes" since segwit was activated on August 24th 2017 as they do not unilaterally enforce all consensus rules of the Bitcoin protocol.

> **Comments:**
> **username_0**: Thanks; this is much clearer to me, now.  
> **username_1**: Just raising the blocksize limit to 4 MB would have not been forward compatible and old nodes would have been forked off.  

---

