<p>Segwit does not use the transaction version field at all.</p>

<p>One reason for this is that it isn't really the right scope. Outputs and inputs are witness-specific, but whole transactions are not.</p>

<p>The transaction version also cannot be used to indicate the presence of the optional witness record. Because the transaction version is part of the "base" transaction data (covered under the txid hash), you'd get compatibility problems when a segwit transaction would be relayed to an old node, and back to a new node. That new node would see the new transaction version number, expect a witness encoding, but the old node cannot give that. Instead, BIP144 introduces a new extensible transaction format with optional records. The encoding used is independent of any data "inside" the base transaction.</p>

<p>It also isn't needed. Specific template transaction outputs are fine to indicate new semantics.</p>

<p>All in all, segregated witness just adds extra records to existing transactions. It does not modify the structure of the existing base part (including the version number).</p>

CC BY-SA 3.0
2016-10-26T20:42:55.207Z
2016-10-26T20:42:55.207Z
Pieter Wuille
<p>Do transactions have to have a minimum version to denote that they are using seg-wit? What changes have been made to the transaction's version field?</p>

<p>The <code>MAX_STANDARD_VERSION</code> is still set to 2 in src/primitives/transaction.h, will that change when seg-wit reaches the soft-fork thresholds? </p>

<segregated-witness>
How is the transaction's nVersion field changed with segregated witness?
morsecoder
# How is the transaction's nVersion field changed with segregated witness?

(Asked by: username_0 on 2016-10-24)

Do transactions have to have a minimum version to denote that they are using seg-wit? What changes have been made to the transaction's version field?

The `MAX_STANDARD_VERSION` is still set to 2 in src/primitives/transaction.h, will that change when seg-wit reaches the soft-fork thresholds?

**Tags:** segregated-witness


---

## 1 answers

### Answer by username_1 on 2016-10-26. Score: 4 | Accepted answer

Segwit does not use the transaction version field at all.

One reason for this is that it isn't really the right scope. Outputs and inputs are witness-specific, but whole transactions are not.

The transaction version also cannot be used to indicate the presence of the optional witness record. Because the transaction version is part of the "base" transaction data (covered under the txid hash), you'd get compatibility problems when a segwit transaction would be relayed to an old node, and back to a new node. That new node would see the new transaction version number, expect a witness encoding, but the old node cannot give that. Instead, BIP144 introduces a new extensible transaction format with optional records. The encoding used is independent of any data "inside" the base transaction.

It also isn't needed. Specific template transaction outputs are fine to indicate new semantics.

All in all, segregated witness just adds extra records to existing transactions. It does not modify the structure of the existing base part (including the version number).


---

