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?

1 Answer 1

  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, 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.

  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 which is being discussed).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.