Have a number of questions in regards to the nVersion subject within the transaction serialization format and they’re associated to the aim of this subject.

  1. What does this subject inform us? Within the sense that whether it is model 1, the transaction fields are like this, whether it is model 2, the transaction fields are like that, and so forth. I do not see this subject being meant for this. I solely know that the transaction model have an effect on nSequence. If the model is 1, the nSequence worth has no function (it was meant as a substitute subject, however is now disabled and you’ll put no matter you need in model 1) and if model is 2 then nSequence is used for relative time lock. What are the opposite functions of this subject, if any?

  2. What are all the usual and consensus guidelines for this subject? Can it have any worth below the consensus guidelines, however only one and a couple of below the usual guidelines?

  3. If there’s consensus and commonplace guidelines for this subject, how are adjustments made to this subject? For instance, if the consensus and commonplace rule for this subject was that it should be 1, then how was the addition of a relative timelock context to nSequences within the presence of model 2 achieved? That’s, how was it doable that the worth of this subject can now be additionally 2 in an effort to add this modification? How will model 3, 4, 5 or 10 be enabled? Arduous fork?

LeaBit is a brand new contributor to this web site. Take care in asking for clarification, commenting, and answering.
Try our Code of Conduct.

  1. The nVersion doesn’t have an effect on the serialization of transactions. So, which fields are current doesn’t change relying on the nversion worth. There’s a mechanism for including extra fields, but it surely’s separate from the model (the prolonged serialization format launched in BIP144, with flags, at present solely used for segwit transactions to sign the presence of a witness). There are at present no makes use of for the sector other than enabling (v2) or disabling (v1) the relative locktime habits of nSequence launched in BIP68.

  2. There are not any consensus guidelines straight limiting the nVersion subject itself; any 32-bit integer is allowed. When the worth is 2 or increased (decoding the sector as a signed integer), the BIP68 habits is enabled (topic to the opposite circumstances listed there). Bitcoin Core’s present standardness guidelines solely allow nVersion equal to both 1 or 2.

  3. Since there are not any consensus guidelines limiting the sector, new variations might be launched with a softfork (if the brand new model provides new consensus guidelines) or only a coverage change (if the brand new model has no affect on consensus, just like the transaction v3 which is being mentioned).