<blockquote>
  <p>First of all I am not sure what it means when e.g. the type flag of the sequence number is referred to as bit (1 &lt;&lt; 22). Does it just mean it is the bit at position 22?</p>
</blockquote>

<p>Yes. It means the bit position that is set in the integer 4194304 (in decimal) or 0x400000 (in hexadecimal).</p>

<blockquote>
  <p>Similarly with the disable flag (1 &lt;&lt; 31), is the bit at position 31? And what is its implication? It must be "unset" (=0?) to use the NEW consensus rules for the sequence number? Why is it necessary when the version field of the transaction > 2 already tells to use the new consensus rule? </p>
</blockquote>

<p>Maybe some day we introduce a version 3 transaction that adds more possibilities. Maybe somebody wants to use one of the new features introduces at that time, but does not want relative locktime. He would be out of luck, as 3 is larger than 2.</p>

<blockquote>
  <p>I also don't understand this sentence: "The flag (1&lt;&lt;22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112)." A 3-byte integer has 24 bits, or not? And one bit is used as sign. Then since the flag is the highest order bit, why is it not at position 23? And why is it represented as a signed integer, when obviously negative block-counts is marked as error by BIP112?</p>
</blockquote>

<p>Integers in Bitcoin Script are always signed, and this is not changed for OP_CHECKSEQUENCEVERIFY, to avoid introducing more specific logic. As a result, the highest bit that is not a sign bit is (1 &lt;&lt; 22).</p>

<p>I'll add an example later.</p>

CC BY-SA 3.0
2016-02-29T23:18:03.250Z
Thank you for taking your time to comment and answer my questions! I think I do understand it now better, also some of the uncertanties which are left open in case the consensus rules need to be changed with a soft-fork.
Bjarne Magnussen
CC BY-SA 3.0
2016-02-29T23:24:44.670Z
So fx this sequence number (in bits): 0xxxxxxxx0xxxxxx1111111111111111 enables the new rule to regard sequence numbers as relative sequences, sets the type flag as blocks, and sets the block number to the maximum = 2^16-1 relative blocks? Furthermore, if using OP_CSV in the scriptPubKey, the data that must be pushed and be available on the stack prior to the op-code must be of exactly the same format, right?
Bjarne Magnussen
CC BY-SA 3.0
2017-09-24T13:56:12.083Z
Would be great to see an example.
Jonathan Cross
CC BY-SA 3.0
2016-02-29T22:17:16.727Z
2016-02-29T22:17:16.727Z
Pieter Wuille
<p>I am trying to understand the implementation/specification of OP_CSV with BIP112 and BIP68.
I understand the implication of the op-code and new consensus rules. I just don't understand exactly how the sequence number is represented. </p>

<p>First of all I am not sure what it means when e.g. the type flag of the sequence number is referred to as bit (1 &lt;&lt; 22). Does it just mean it is the bit at position 22?</p>

<p>Similarly with the disable flag (1 &lt;&lt; 31), is the bit at position 31? And what is its implication? It must be "unset" (=0?) to use the NEW consensus rules for the sequence number? Why is it necessary when the  version field of the transaction > 2 already tells to use the new consensus rule?  </p>

<p>I also don't understand this sentence:
"The flag (1&lt;&lt;22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112)."
A 3-byte integer has 24 bits, or not? And one bit is used as sign. Then since the flag is the highest order bit, why is it not at position 23?
And why is it represented as a signed integer, when obviously negative block-counts is marked as error by BIP112?</p>

<p>Maybe somebody could give me an example of how exactly the sequence number would look like for the following:</p>

<p>Transaction confirmed with block 400,000 and:
scriptPubKey: "30days" OP_CHECKSEQUENCEVERIFY</p>

<p>Transaction that spends the output:
scriptSig: OP_TRUE
nSequence: ?</p>

<p>Does somebody know how the exact data of "30days" would look like (the bit/byte-wise number represenation with flags and all)?</p>

<script>
How is nSequence interpreted with CHECKSEQUENCEVERIFY?
Bjarne Magnussen
# How is nSequence interpreted with CHECKSEQUENCEVERIFY?

(Asked by: username_0 on 2016-02-29)

I am trying to understand the implementation/specification of OP\_CSV with BIP112 and BIP68.
I understand the implication of the op-code and new consensus rules. I just don't understand exactly how the sequence number is represented.

First of all I am not sure what it means when e.g. the type flag of the sequence number is referred to as bit (1 << 22). Does it just mean it is the bit at position 22?

Similarly with the disable flag (1 << 31), is the bit at position 31? And what is its implication? It must be "unset" (=0?) to use the NEW consensus rules for the sequence number? Why is it necessary when the version field of the transaction > 2 already tells to use the new consensus rule?

I also don't understand this sentence:
"The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP\_CHECKSEQUENCEVERIFY (BIP 112)."
A 3-byte integer has 24 bits, or not? And one bit is used as sign. Then since the flag is the highest order bit, why is it not at position 23?
And why is it represented as a signed integer, when obviously negative block-counts is marked as error by BIP112?

Maybe somebody could give me an example of how exactly the sequence number would look like for the following:

Transaction confirmed with block 400,000 and:
scriptPubKey: "30days" OP\_CHECKSEQUENCEVERIFY

Transaction that spends the output:
scriptSig: OP\_TRUE
nSequence: ?

Does somebody know how the exact data of "30days" would look like (the bit/byte-wise number represenation with flags and all)?

**Tags:** script


---

## 1 answers

### Answer by username_1 on 2016-02-29. Score: 2 | Accepted answer

> First of all I am not sure what it means when e.g. the type flag of the sequence number is referred to as bit (1 << 22). Does it just mean it is the bit at position 22?

Yes. It means the bit position that is set in the integer 4194304 (in decimal) or 0x400000 (in hexadecimal).

> Similarly with the disable flag (1 << 31), is the bit at position 31? And what is its implication? It must be "unset" (=0?) to use the NEW consensus rules for the sequence number? Why is it necessary when the version field of the transaction > 2 already tells to use the new consensus rule?

Maybe some day we introduce a version 3 transaction that adds more possibilities. Maybe somebody wants to use one of the new features introduces at that time, but does not want relative locktime. He would be out of luck, as 3 is larger than 2.

> I also don't understand this sentence: "The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP\_CHECKSEQUENCEVERIFY (BIP 112)." A 3-byte integer has 24 bits, or not? And one bit is used as sign. Then since the flag is the highest order bit, why is it not at position 23? And why is it represented as a signed integer, when obviously negative block-counts is marked as error by BIP112?

Integers in Bitcoin Script are always signed, and this is not changed for OP\_CHECKSEQUENCEVERIFY, to avoid introducing more specific logic. As a result, the highest bit that is not a sign bit is (1 << 22).

I'll add an example later.

> **Comments:**
> **username_0**: Thank you for taking your time to comment and answer my questions! I think I do understand it now better, also some of the uncertanties which are left open in case the consensus rules need to be changed with a soft-fork.  
> **username_0**: So fx this sequence number (in bits): 0xxxxxxxx0xxxxxx1111111111111111 enables the new rule to regard sequence numbers as relative sequences, sets the type flag as blocks, and sets the block number to the maximum = 2^16-1 relative blocks? Furthermore, if using OP_CSV in the scriptPubKey, the data that must be pushed and be available on the stack prior to the op-code must be of exactly the same format, right?  
> **username_2**: Would be great to see an example.  

---

