<p>The sequence <code>004001fa</code> (big-endian, padded to 4 bytes) actually represents a relative locktime of 259,072 seconds, almost exactly 3 days.</p>
<p>The way you interpret a sequence number as a relative locktime (as specified in <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow noreferrer">BIP68</a>) is as follows:</p>
<ul>
<li>Check if the highest bit is set, if so then no locktime applies.</li>
<li>Interpret the lowest 16 bits as an unsigned integer, and:
<ul>
<li>If bit 22 is not set, this value is the locktime in blocks.</li>
<li>If bit 22 is set, multiply this value by 512 and you get the locktime in seconds.</li>
</ul>
</li>
</ul>
<p>Now, let's look at the sequence <code>004001fa</code> in binary, with the relevant bits highlighted:</p>
<pre><code>0000 0000 0100 0000 0000 0001 1111 1010
^          ^        ^^^^^^^^^^^^^^^^^^^
</code></pre>
<p>Since the highest bit is not set, bit 22 is set, and the lowest 16 bits give the number 506 (111111010 in binary, 1fa in hexadecimal), the locktime is 506 × 512 = 259,072 seconds.</p>

CC BY-SA 4.0
2024-11-15T01:37:14.117Z
2024-11-15T01:37:14.117Z
Vojtěch Strnad
<p>I was looking at this transaction: <a href="https://mempool.space/tx/3c1c9fb9d6b215efdeedb5caf6a951a9e6c6c1e3de6e5674f646c63e94667497" rel="nofollow noreferrer">3c1c9fb9d6b215efdeedb5caf6a951a9e6c6c1e3de6e5674f646c63e94667497</a></p>
<p>TapScript with <code>nSequence</code> also set to <code>0x4001fa</code></p>
<pre><code>OP_PUSHBYTES_3 fa0140
OP_CSV
OP_DROP
OP_PUSHBYTES_32 a4c184aae8b4ccba9682b5ea95faf15ff2f82820fa1eb34aa5a13220fb366285
OP_CHECKSIGVERIFY
OP_PUSHBYTES_32 2a9a53362dd63cb58cfe9a7ee7a05d84b9872054ac366e615fc2dc12eddf20fa
OP_CHECKSIG
</code></pre>
<p><code>fa0140</code> converts to 4194810, I believe it means seconds, which translates to roughly 48 days. But its output was created around 4 days ago, so how it was confirmed?</p>

<sequence><checksequenceverify>
How was this transaction's relative locktime satisfied?
0xMilk
# How was this transaction's relative locktime satisfied?

(Asked by: username_0 on 2024-11-14)

I was looking at this transaction: 3c1c9fb9d6b215efdeedb5caf6a951a9e6c6c1e3de6e5674f646c63e94667497
TapScript with nSequence also set to 0x4001fa
OP_PUSHBYTES_3 fa0140
OP_CSV
OP_DROP
OP_PUSHBYTES_32 a4c184aae8b4ccba9682b5ea95faf15ff2f82820fa1eb34aa5a13220fb366285
OP_CHECKSIGVERIFY
OP_PUSHBYTES_32 2a9a53362dd63cb58cfe9a7ee7a05d84b9872054ac366e615fc2dc12eddf20fa
OP_CHECKSIG

fa0140 converts to 4194810, I believe it means seconds, which translates to roughly 48 days. But its output was created around 4 days ago, so how it was confirmed?

**Tags:** sequence, checksequenceverify


---

## 1 answers

### Answer by username_1 on 2024-11-15. Score: 3 | Accepted answer

The sequence 004001fa (big-endian, padded to 4 bytes) actually represents a relative locktime of 259,072 seconds, almost exactly 3 days.
The way you interpret a sequence number as a relative locktime (as specified in BIP68) is as follows:

Check if the highest bit is set, if so then no locktime applies.
Interpret the lowest 16 bits as an unsigned integer, and:

If bit 22 is not set, this value is the locktime in blocks.
If bit 22 is set, multiply this value by 512 and you get the locktime in seconds.



Now, let's look at the sequence 004001fa in binary, with the relevant bits highlighted:
0000 0000 0100 0000 0000 0001 1111 1010
^          ^        ^^^^^^^^^^^^^^^^^^^

Since the highest bit is not set, bit 22 is set, and the lowest 16 bits give the number 506 (111111010 in binary, 1fa in hexadecimal), the locktime is 506 × 512 = 259,072 seconds.


---

