<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](https://mempool.space/tx/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](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)) 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.


---

