How is nSequence interpreted with CHECKSEQUENCEVERIFY?

Question

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)?

Answer 1

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.