From 4c81b3ecb96d97fedec2d2e689b6ffe844ce855a Mon Sep 17 00:00:00 2001 From: Abu Shifrah <35174370+muaawiyahtucker@users.noreply.github.com> Date: Sat, 5 Jul 2025 11:37:54 +0300 Subject: [PATCH] Corrected the use of nTimeLock to nLockTime, and deleted an erronious hex code --- 11_3_Using_CSV_in_Scripts.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/11_3_Using_CSV_in_Scripts.md b/11_3_Using_CSV_in_Scripts.md index 745f9b9..ec0a994 100644 --- a/11_3_Using_CSV_in_Scripts.md +++ b/11_3_Using_CSV_in_Scripts.md @@ -12,19 +12,19 @@ A relative timelock is a lock that's placed on a specific input of a transaction Easy! -> :information_source: **NOTE — SEQUENCE:** This is the third use of the `nSequence` value in Bitcoin. Any `nSequence` value without the 32nd bit set (1<<31), so 0x00000001 to 0x7ffffffff, will be interpreted as a relative timelock if `nVersion ≥ 2` (which is the default starting in Bitcoin Core 0.14.0). You should be careful to ensure that relative timelocks don't conflict with the other two uses of `nSequence`, for signalling `nTimeLock` and RBF. `nTimeLock` usually sets a value of 0xffffffff-1, where a relative timelock is disallowed; and RBF usually sets a value of "1", where a relative timelock is irrelevent, because it defines a timelock of 1 block. +> :information_source: **NOTE — SEQUENCE:** This is the third use of the `nSequence` value in Bitcoin. Any `nSequence` value without the 32nd bit set (1<<31), so 0x00 00 00 01 to 0x7f ff ff ff, will be interpreted as a relative timelock if `nVersion ≥ 2` (which is the default starting in Bitcoin Core 0.14.0). You should be careful to ensure that relative timelocks don't conflict with the other two uses of `nSequence`, for signalling `nLockTime` and RBF. `nLockTime` usually sets a value of 0xff ff ff ff-1, where a relative timelock is disallowed; and RBF usually sets a value of "1", where a relative timelock is irrelevent, because it defines a timelock of 1 block. -> In general, remember: with a `nVersion` value of 2, a `nSequence` value of 0x00000001 to 0x7fffffff allows relative timelock, RBF, and `nTimeLock`; a `nSequence` value of 0x7fffffff to 0xffffffff-2 allows RBF and `nTimeLock`; a `nSequence` value of 0xffffffff-1 allows only `nTimeLock`; a `nSequence` value of 0xffffffff allows none; and `nVersion` can be set to 1 to disallow relative timelocks for any value of `nSequence`. Whew! +> In general, remember: with a `nVersion` value of 2, a `nSequence` value of 0x00 00 00 01 to 0x7f ff ff ff allows relative timelock, RBF, and `nLockTime`; a `nSequence` value of 0x7f ff ff ff to 0xff ff ff ff-2 allows RBF and `nLockTime`; a `nSequence` value of 0xff ff ff ff-1 allows only `nLockTime`; a `nSequence` value of 0xff ff ff ff allows none; and `nVersion` can be set to 1 to disallow relative timelocks for any value of `nSequence`. Whew! ### Create a CSV Relative Block Time -The format for using `nSequence` to represent relative time locks is defined in [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) and is slightly more complex than just inputting a number, like you did for `nTimeLock`. Instead, the BIP specifications breaks up the four byte number into three parts: +The format for using `nSequence` to represent relative time locks is defined in [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) and is slightly more complex than just inputting a number, like you did for `nLockTime`. Instead, the BIP specifications breaks up the four byte number into three parts: * The first two bytes are used to specify a relative locktime. * The 23rd bit is used to positively signal if the lock refers to a time rather than a blockheight. * The 32nd bit is used to positively signal if relative timelocks are deactivated. -With that said, the construction of a block-based relative timelock is still quite easy, because the two flagged bits are set to `0`, so you just set `nSequence` to a value between 1 and 0xffff (65535). The new transaction can be mined that number of blocks after the associated UTXO was mined. +With that said, the construction of a block-based relative timelock is still quite easy, because the two flagged bits are set to `0`, so you just set `nSequence` to a value between 1 and 0xff ff (65535). The new transaction can be mined that number of blocks after the associated UTXO was mined. ### Create a CSV Relative Time @@ -65,7 +65,7 @@ Except pretty much no one does this. The [BIP 68](https://github.com/bitcoin/bip | | Absolute Timelock | Relative Timelock | |:--------------------:|-------------------|-------------------| -| **Lock Transaction** | nTimeLock | nSequence | +| **Lock Transaction** | nLockTime | nSequence | | **Lock Output** | OP_CHECKLOCKTIMEVERIFY| OP_CHECKSEQUENCEVERIFY | ## Understand the CSV Opcode @@ -93,7 +93,7 @@ CSV has many of the same subtleties in usage as CLTV: * The `nVersion` field must be set to 2 or more. * The `nSequence` field must be set to less than 0x80000000. -* When CSV is run, there must be an operand on the stack that's between 0 and 0xf0000000-1. +* When CSV is run, there must be an operand on the stack that's between 0 and 0xf0 00 00 00-1. * Both the stack operand and `nSequence` must have the same value on the 23rd bit. * The `nSequence` must be greater than or equal to the stack operand.