<p>When a specific locktime is specified in the <code>nLockTime</code> field in a transaction. It means that said transaction cannot be broadcasted/be accepted by miners until either the <code>blockheight</code> or <code>unixtime</code> has elapsed. </p>

<p>On the other hand, when a <code>OP_CSV</code> is used, it means that a transaction referencing said input cannot be spent until some <code>blockheight</code> or <code>unixtime</code> has elapsed. </p>

<p>If we merge both and use them together, basically, we will create a transaction that cannot be broadcasted to the Bitcoin network until some <code>nLockTime</code> has elapsed and it also cannot be spent until some <code>blockheight</code> or duration of time has elasped. <code>OP_CSV</code> specifically targets the <strong>spendability</strong> of a transaction, whereas a time-locked transaction simply prevents some transaction being broadcasted to the Bitcoin network until its locktime has elapsed.</p>

CC BY-SA 3.0
2016-07-13T15:11:10.183Z
So both time locks will be evaluated, no? Neither will override the other, in other words. If so, can you point to a source (other than the paragraph in BIP 68 I quoted)?
Rich Apodaca
CC BY-SA 3.0
2016-07-13T23:07:48.320Z
It depends on the `nsequence` field. If the disable flag is set, then it will not be evaluated (as there will be no consensus meaning). Otherwise, it will be evaluated. You can inspect this in the Bitcoin Core source code, script/interpretter.cpp line 334 onwards. The behavior of OP_CSV and Timelocks are different, they never override each other as they semantically mean different things.
rny
CC BY-SA 3.0
2016-07-11T23:38:54.750Z
2016-07-11T23:38:54.750Z
rny
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow">BIP 68</a> redefines the input sequence number field as bit vector that encodes a relative lock time.</p>

<p>A transaction can be encumbered with an absolute lock time by setting the nLockTime field to a non-zero value and by ensuring that at least one input sequence is non-maximal (not 0xffffffff).</p>

<p>What happens if a one-input transaction sets nLockTime > 0 <em>and</em> introduces a relative lock time under BIP 68? For example, nLockTime might expire in 12,000 blocks and the input's relative lock time might expire in 11,000 blocks. Conversely, the relative lock time might expire after the absolute lock time.</p>

<p>Which locking mechanism wins in these cases? Are both locks checked, or only one? If the latter, which one?</p>

<p>The "Compatibility" section of BIP 68 hints that both locks will be checked, but from my reading doesn't state this explicitly:</p>

<blockquote>
  <p>The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.</p>
</blockquote>

<locktime><sequence>
What happens when relative and absolute lock times are used in the same transaction?
Rich Apodaca
# What happens when relative and absolute lock times are used in the same transaction?

(Asked by: username_0 on 2016-07-11)

[BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) redefines the input sequence number field as bit vector that encodes a relative lock time.

A transaction can be encumbered with an absolute lock time by setting the nLockTime field to a non-zero value and by ensuring that at least one input sequence is non-maximal (not 0xffffffff).

What happens if a one-input transaction sets nLockTime > 0 *and* introduces a relative lock time under BIP 68? For example, nLockTime might expire in 12,000 blocks and the input's relative lock time might expire in 11,000 blocks. Conversely, the relative lock time might expire after the absolute lock time.

Which locking mechanism wins in these cases? Are both locks checked, or only one? If the latter, which one?

The "Compatibility" section of BIP 68 hints that both locks will be checked, but from my reading doesn't state this explicitly:

> The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.

**Tags:** locktime, sequence


---

## 1 answers

### Answer by username_1 on 2016-07-11. Score: 1

When a specific locktime is specified in the `nLockTime` field in a transaction. It means that said transaction cannot be broadcasted/be accepted by miners until either the `blockheight` or `unixtime` has elapsed.

On the other hand, when a `OP_CSV` is used, it means that a transaction referencing said input cannot be spent until some `blockheight` or `unixtime` has elapsed.

If we merge both and use them together, basically, we will create a transaction that cannot be broadcasted to the Bitcoin network until some `nLockTime` has elapsed and it also cannot be spent until some `blockheight` or duration of time has elasped. `OP_CSV` specifically targets the **spendability** of a transaction, whereas a time-locked transaction simply prevents some transaction being broadcasted to the Bitcoin network until its locktime has elapsed.

> **Comments:**
> **username_0**: So both time locks will be evaluated, no? Neither will override the other, in other words. If so, can you point to a source (other than the paragraph in BIP 68 I quoted)?  
> **username_1**: It depends on the `nsequence` field. If the disable flag is set, then it will not be evaluated (as there will be no consensus meaning). Otherwise, it will be evaluated. You can inspect this in the Bitcoin Core source code, script/interpretter.cpp line 334 onwards. The behavior of OP_CSV and Timelocks are different, they never override each other as they semantically mean different things.  

---

