<p>I am still having problems understanding the relative locktime:</p>
<p>I am aware that the scriptpubkey is &quot;Time Locked&quot; as mentioned above :</p>
<pre><code>   &quot;30d&quot; CHECKSEQUENCEVERIFY DROP
    &lt;Alice's pubkey&gt; CHECKSIG
</code></pre>
<p>So when I want to spend this output, do I actually have to set the nSequence Field by myself. I mean, what prevents me from just calculating the right values which satisfies the OP_Code. I am missing the actual connection to the real transaction, like which procedure checks that this transaction has really been 30 days in the blockchain since it appeared in a block.</p>
<p>To prevent older nodes from forking of, the final nSequence should also be calculated into a resulting locktime, to prevent older nodes form spending it?</p>

CC BY-SA 4.0
2021-10-29T14:58:48.810Z
What's crucial to understand is that the redeem script (the script that you quoted here) that is present must match the script hash in the UTXO. The spender does _not_ control the script. 

So the spend dictates the value in CSV(value). And CSV(value) WILL fail if value is less than the nSequence in your input which is trying to spend the UTXO (as specified in BIP-068). So BIP-068 sets a way for inputs to be valid only a relative amount of time, while BIP-112 with CSV makes the unlock script writer able to assert a minimum relative amount of time for the input.
joaquinlpereyra
CC BY-SA 4.0
2021-09-23T18:58:32.177Z
2021-09-23T20:42:11.640Z
2021-09-23T20:42:11.640Z
norisgOG
<p>I still have a problem understanding the order of transactions. Here's an example:</p>
<pre><code>//Blockheight(100000):
{
    nVersion: 00000001
    vin:[
        {
            prev_out_0:
            {
                txid: &lt;placeholder(a1b2c3d4e5f6)&gt;
                index: 00000000
                
                scriptSig:
                &lt;placeholder(a1b2c3d4e5f6)&gt;
                
                sequence: 0000186A0 //100000
            }
        }
        {
            prev_out_1:
            {
                txid: &lt;placeholder(a1b2c3d4e5f6)&gt;
                index: 00000001
                
                scriptSig:
                &lt;placeholder(a1b2c3d4e5f6)&gt;
                
                sequence: 0000186A0 //100000
            }
        }
    ]
    vout:[
        {
            value: 1234 satoshis
            
            lockingScript:
            3 OP_CHECKSEQUENCEVERIFY OP_DROP OP_DUP OP_HASH160 &lt;RIPE160Recipent(&lt;placeholder(a1b2c3d4e5f6)&gt;)&gt; OP_EQUALVERIFY OP_CHECKSIG
        }
    ]
    nLockTime: 00000000
}

//Blockheight(100001):
//Redeem-Transaction should fail -&gt; sequence: 0000186A0=100000 + 3 in redeemScript = 100003
//100003 != 100001

//Blockheight(100003):
{
    nVersion: 00000001
    vin:[
        {
            prev_out_0:
            {
                txid: &lt;placeholder(a1b2c3d4e5f6)&gt;
                index: 00000000
                
                scriptSig:
                &lt;placeholder(a1b2c3d4e5f6)&gt;(redeemScript of prev tx)
                
                sequence: ffffffff
            }
        }
    ]
    vout:[
        {
            value: 1234 satoshis
            
            scriptPubKey:
            OP_DUP OP_HASH160 OP_PUSHBYTES_20 &lt;placeholder(a1b2c3d4e5f6)&gt; OP_EQUALVERIFY OP_CHECKSIG
        }
    ]
    nLockTime: 00000000
}
</code></pre>
<p>why is this principal not working?</p>

CC BY-SA 4.0
2024-10-30T15:42:24.220Z
Hey a_confused_one, to ask a new question, please create a new topic by clicking the "Ask Question" button in the top right.
Murch
CC BY-SA 4.0
2024-10-30T11:05:18.630Z
2024-10-30T11:05:18.630Z
a_confused_one
<p>In order to use a relative time lock, you need to provide the requirements in the <code>scriptPubKey</code> to which the Bitcoin is sent.</p>
<h2>Example</h2>
<p><code>scriptPubKey</code> for escrow with 30 day timeout:</p>
<pre><code>IF
    2 &lt;Alice's pubkey&gt; &lt;Bob's pubkey&gt; &lt;Escrow's pubkey&gt; 3 CHECKMULTISIG
ELSE
    &quot;30d&quot; CHECKSEQUENCEVERIFY DROP
    &lt;Alice's pubkey&gt; CHECKSIG
ENDIF
</code></pre>
<p>Then, in order to spend it before 30 days, the <code>scriptSig</code> that satisfies the first conditional statement (multisig script) must be provided, i.e.:</p>
<p><code>scriptSig</code>: <code>0 &lt;signature1&gt; &lt;signature2&gt;</code></p>
<p>Or after 30 days, alice can provide:</p>
<p><code>scriptSig</code>: <code>&lt;signature&gt;</code></p>
<p>See <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#escrow-with-timeout" rel="nofollow noreferrer">BIP112</a></p>
<h2>Sequence</h2>
<p>Note that in order to set a relative locktime: the tx must have the following properties:</p>
<ul>
<li>version must be 2 or greater</li>
<li>nSequence must not have 32nd bit set</li>
<li>nSequence must have the 23rd bit set (<code>0x400000</code>) if it is a lock-time type, unset for block height type</li>
<li>for relative lock-time type the granularity of each bit is 512 seconds</li>
<li>for relative block height type each bit represents 1 block</li>
</ul>
<p>For 30 days, I believe it would be as follows:</p>
<pre><code>30 * 24 * 60 * 60 = 2592000 seconds
2592000 / 512 = 5062.5 ~= 5063 or 0x13C7
sequence = 0x13C7 | 0x400000 = 0x4013C7 or 4199367
nSequence = 0xC7134000 (little endian)
</code></pre>
<p>The sequence is the last 4 bytes of an input, see <a href="https://en.bitcoin.it/wiki/Transaction" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Transaction</a></p>

CC BY-SA 4.0
2019-01-15T08:50:52.063Z
Thank you, very clear. Do u know where to add nSequence parameter inside a transaction?
Bruce Wayne
CC BY-SA 4.0
2019-01-15T12:54:24.833Z
The sequence or locktime is the very last 4 bytes of the transaction, see https://en.bitcoin.it/wiki/Transaction
JBaczuk
CC BY-SA 4.0
2019-01-15T19:24:38.713Z
@JBaczuk - Has the impact of little endian encoding been taken into consideration after performing BIP 68 bit encoding?
skaht
CC BY-SA 4.0
2019-01-15T21:19:34.627Z
@skaht right, you'd need to convert to little endian before putting it in the transaction
JBaczuk
CC BY-SA 4.0
2019-01-16T08:54:47.127Z
The `nSequence` field is not the same as the `nLockTime` field.  The `nSequence` field is per-input, and inputs can have different values set.  See _General format (inside a block) of each input of a transaction - Txin_ in the bitcoin wiki link.
arubi
CC BY-SA 4.0
2019-01-16T13:03:26.013Z
Right, thanks I was mixing the two terms, I'll try to clarify
JBaczuk
CC BY-SA 4.0
2019-01-17T03:57:41.617Z
nSequence is at the TX input level. Was referring to each TX output CSV opcode locktime needing to be BIP 68 encoded and converted to little endian format. nLockTime is associated with absolute time locks.
skaht
CC BY-SA 4.0
2019-01-17T15:53:59.780Z
TX version number must be set to 2 or greater per https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#summary.
skaht
CC BY-SA 4.0
2019-01-14T20:07:15.973Z
2023-11-28T19:04:54.143Z
2023-11-28T19:04:54.143Z
JBaczuk
<p>How does relative timelock work? I mean, I know the theoretical description, but how to use nSequence concretely ? Can you do me a practical example with 2 sample transactions one of which locked with nSequence from another?  </p>

<locktime><bip>
How does nSequence/Check Sequence Verify work?
Bruce Wayne
# How does nSequence/Check Sequence Verify work?

(Asked by: username_0 on 2019-01-14)

How does relative timelock work? I mean, I know the theoretical description, but how to use nSequence concretely ? Can you do me a practical example with 2 sample transactions one of which locked with nSequence from another?

**Tags:** locktime, bip


---

## 3 answers

### Answer by username_5 on 2019-01-14. Score: 6 | Accepted answer

In order to use a relative time lock, you need to provide the requirements in the scriptPubKey to which the Bitcoin is sent.
Example
scriptPubKey for escrow with 30 day timeout:
IF
    2    3 CHECKMULTISIG
ELSE
    "30d" CHECKSEQUENCEVERIFY DROP
     CHECKSIG
ENDIF

Then, in order to spend it before 30 days, the scriptSig that satisfies the first conditional statement (multisig script) must be provided, i.e.:
scriptSig: 0  
Or after 30 days, alice can provide:
scriptSig: 
See BIP112
Sequence
Note that in order to set a relative locktime: the tx must have the following properties:

version must be 2 or greater
nSequence must not have 32nd bit set
nSequence must have the 23rd bit set (0x400000) if it is a lock-time type, unset for block height type
for relative lock-time type the granularity of each bit is 512 seconds
for relative block height type each bit represents 1 block

For 30 days, I believe it would be as follows:
30 * 24 * 60 * 60 = 2592000 seconds
2592000 / 512 = 5062.5 ~= 5063 or 0x13C7
sequence = 0x13C7 | 0x400000 = 0x4013C7 or 4199367
nSequence = 0xC7134000 (little endian)

The sequence is the last 4 bytes of an input, see https://en.bitcoin.it/wiki/Transaction

> **Comments:**
> **username_0**: Thank you, very clear. Do u know where to add nSequence parameter inside a transaction?  
> **username_5**: The sequence or locktime is the very last 4 bytes of the transaction, see https://en.bitcoin.it/wiki/Transaction  
> **username_6**: @username_5 - Has the impact of little endian encoding been taken into consideration after performing BIP 68 bit encoding?  
> **username_5**: @username_6 right, you'd need to convert to little endian before putting it in the transaction  
> **username_7**: The `nSequence` field is not the same as the `nLockTime` field.  The `nSequence` field is per-input, and inputs can have different values set.  See _General format (inside a block) of each input of a transaction - Txin_ in the bitcoin wiki link.  
> **username_5**: Right, thanks I was mixing the two terms, I'll try to clarify  
> **username_6**: nSequence is at the TX input level. Was referring to each TX output CSV opcode locktime needing to be BIP 68 encoded and converted to little endian format. nLockTime is associated with absolute time locks.  
> **username_6**: TX version number must be set to 2 or greater per https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#summary.  

---

### Answer by username_1 on 2021-09-23. Score: 1

I am still having problems understanding the relative locktime:
I am aware that the scriptpubkey is "Time Locked" as mentioned above :
   "30d" CHECKSEQUENCEVERIFY DROP
     CHECKSIG

So when I want to spend this output, do I actually have to set the nSequence Field by myself. I mean, what prevents me from just calculating the right values which satisfies the OP_Code. I am missing the actual connection to the real transaction, like which procedure checks that this transaction has really been 30 days in the blockchain since it appeared in a block.
To prevent older nodes from forking of, the final nSequence should also be calculated into a resulting locktime, to prevent older nodes form spending it?

> **Comments:**
> **username_2**: What's crucial to understand is that the redeem script (the script that you quoted here) that is present must match the script hash in the UTXO. The spender does _not_ control the script.   So the spend dictates the value in CSV(value). And CSV(value) WILL fail if value is less than the nSequence in your input which is trying to spend the UTXO (as specified in BIP-068). So BIP-068 sets a way for inputs to be valid only a relative amount of time, while BIP-112 with CSV makes the unlock script writer able to assert a minimum relative amount of time for the input.  

---

### Answer by username_3 on 2024-10-30. Score: 0

I still have a problem understanding the order of transactions. Here's an example:
//Blockheight(100000):
{
    nVersion: 00000001
    vin:[
        {
            prev_out_0:
            {
                txid: 
                index: 00000000
                
                scriptSig:
                
                
                sequence: 0000186A0 //100000
            }
        }
        {
            prev_out_1:
            {
                txid: 
                index: 00000001
                
                scriptSig:
                
                
                sequence: 0000186A0 //100000
            }
        }
    ]
    vout:[
        {
            value: 1234 satoshis
            
            lockingScript:
            3 OP_CHECKSEQUENCEVERIFY OP_DROP OP_DUP OP_HASH160 )> OP_EQUALVERIFY OP_CHECKSIG
        }
    ]
    nLockTime: 00000000
}

//Blockheight(100001):
//Redeem-Transaction should fail -> sequence: 0000186A0=100000 + 3 in redeemScript = 100003
//100003 != 100001

//Blockheight(100003):
{
    nVersion: 00000001
    vin:[
        {
            prev_out_0:
            {
                txid: 
                index: 00000000
                
                scriptSig:
                (redeemScript of prev tx)
                
                sequence: ffffffff
            }
        }
    ]
    vout:[
        {
            value: 1234 satoshis
            
            scriptPubKey:
            OP_DUP OP_HASH160 OP_PUSHBYTES_20  OP_EQUALVERIFY OP_CHECKSIG
        }
    ]
    nLockTime: 00000000
}

why is this principal not working?

> **Comments:**
> **username_4**: Hey username_3, to ask a new question, please create a new topic by clicking the "Ask Question" button in the top right.  

---

