<ol>
<li><p>The <code>nVersion</code> does not affect the serialization of transactions. So, which fields are present does not change depending on the nversion value. There is a mechanism for adding additional fields, but it's separate from the version (the extended serialization format introduced in <a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki" rel="noreferrer">BIP144</a>, with flags, currently only used for segwit transactions to signal the presence of a witness). There are currently no uses for the field apart from enabling (v2) or disabling (v1) the relative locktime behavior of <code>nSequence</code> introduced in <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="noreferrer">BIP68</a>.</p>
</li>
<li><p>There are no consensus rules directly restricting the <code>nVersion</code> field itself; any 32-bit integer is allowed. When the value is 2 or higher (interpreting the field as a signed integer), the BIP68 behavior is enabled (subject to the other conditions listed there). Bitcoin Core's current standardness rules only permit <code>nVersion</code> equal to either 1 or 2.</p>
</li>
<li><p>Since there are no consensus rules restricting the field, new versions can be introduced with a softfork (if the new version adds new consensus rules) or just a policy change (if the new version has no impact on consensus, like the <a href="https://bitcoinops.org/en/topics/version-3-transaction-relay/" rel="noreferrer">transaction v3</a> which is being discussed).</p>
</li>
</ol>

CC BY-SA 4.0
2023-10-29T03:14:08.637Z
2023-10-29T03:26:38.303Z
2023-10-29T03:26:38.303Z
Pieter Wuille
<p>Have a few questions about the <code>nVersion</code> field in the transaction serialization format and they are related to the purpose of this field.</p>
<ol>
<li><p>What does this field tell us? In the sense that if it is version 1, the transaction fields are like this, if it is version 2, the transaction fields are like that, and so on. I don't see this field being intended for this. I only know that the transaction version affect <code>nSequence</code>. If the version is <strong>1</strong>, the <code>nSequence</code> value has no purpose (it was intended as a replacement field, but is now disabled and you can put whatever you want in version 1) and if version is <strong>2</strong> then <code>nSequence</code> is used for relative time lock. What are the other purposes of this field, if any?</p>
</li>
<li><p>What are all the standard and consensus rules for this field? Can it have any value under the consensus rules, but only 1 and 2 under the standard rules?</p>
</li>
<li><p>If there is consensus and standard rules for this field, how are changes made to this field? For example, if the consensus and standard rule for this field was that it must be 1, then how was the addition of a relative timelock context to nSequences in the presence of version 2 done? That is, how was it possible that the value of this field can now be also 2 in order to add this change? How will version 3, 4, 5 or 10 be enabled? Hard fork?</p>
</li>
</ol>

<consensus><sequence><checksequenceverify><transaction-version>
What does nVersion represent in Bitcoin transaction?
LeaBit
# What does nVersion represent in Bitcoin transaction?

(Asked by: username_0 on 2023-10-29)

Have a few questions about the `nVersion` field in the transaction serialization format and they are related to the purpose of this field.

1. What does this field tell us? In the sense that if it is version 1, the transaction fields are like this, if it is version 2, the transaction fields are like that, and so on. I don't see this field being intended for this. I only know that the transaction version affect `nSequence`. If the version is **1**, the `nSequence` value has no purpose (it was intended as a replacement field, but is now disabled and you can put whatever you want in version 1) and if version is **2** then `nSequence` is used for relative time lock. What are the other purposes of this field, if any?
2. What are all the standard and consensus rules for this field? Can it have any value under the consensus rules, but only 1 and 2 under the standard rules?
3. If there is consensus and standard rules for this field, how are changes made to this field? For example, if the consensus and standard rule for this field was that it must be 1, then how was the addition of a relative timelock context to nSequences in the presence of version 2 done? That is, how was it possible that the value of this field can now be also 2 in order to add this change? How will version 3, 4, 5 or 10 be enabled? Hard fork?

**Tags:** consensus, sequence, checksequenceverify, transaction-version


---

## 1 answers

### Answer by username_1 on 2023-10-29. Score: 5 | Accepted answer

1. The `nVersion` does not affect the serialization of transactions. So, which fields are present does not change depending on the nversion value. There is a mechanism for adding additional fields, but it's separate from the version (the extended serialization format introduced in [BIP144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki), with flags, currently only used for segwit transactions to signal the presence of a witness). There are currently no uses for the field apart from enabling (v2) or disabling (v1) the relative locktime behavior of `nSequence` introduced in [BIP68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki).
2. There are no consensus rules directly restricting the `nVersion` field itself; any 32-bit integer is allowed. When the value is 2 or higher (interpreting the field as a signed integer), the BIP68 behavior is enabled (subject to the other conditions listed there). Bitcoin Core's current standardness rules only permit `nVersion` equal to either 1 or 2.
3. Since there are no consensus rules restricting the field, new versions can be introduced with a softfork (if the new version adds new consensus rules) or just a policy change (if the new version has no impact on consensus, like the [transaction v3](https://bitcoinops.org/en/topics/version-3-transaction-relay/) which is being discussed).


---

