<p>If you're creating a version 2 transaction with the disable flag not set, then by definition the whole nSequence value will be less than 0xFFFFFFFE (because it will be at most 0x7FFFFFFF).</p>

<p>This implies that a transaction with an active relative locktime will always be replacable according to BIP125.</p>

<p>This is intentional. Nonreplacable transactions attempt to make use of the existing network policy rules to favor the first broadcasted version of a transaction. A transaction that will only become valid at a future point in time cannot make use of that, as it can't be broadcast until it becomes valid.</p>

CC BY-SA 4.0
2020-02-07T20:47:49.000Z
I don't see why the time delay means non-replaceability *can't* be useful.  I can't think of a use, but someone may, for whatever reason, not want their transaction replaced, even if they are spending an output with relative locktime.
Chan-Ho Suh
CC BY-SA 3.0
2017-07-02T01:00:00.770Z
2017-07-02T01:00:00.770Z
Pieter Wuille
<p>Reading the following BIPs: <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="noreferrer">68</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki" rel="noreferrer">112</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki" rel="noreferrer">125</a>, I got a few questions about the sematics of sequence numbers. As far as I understood, in version 1 transactions, sequence numbers have the following meaning:</p>

<ul>
<li>If any input has a sequence less than <code>0xfffffffe</code>, than the whole transaction is signalling replaceability</li>
</ul>

<p>On the other hand, in version >=2 transactions, the above rule applies, plus:</p>

<ul>
<li>If a sequence number has the disable flag (<code>1 &lt;&lt; 31</code>) set to <code>1</code>, then the sequence has no additional meaning (but can still be used to signal replaceability, right?)</li>
<li>If the disable flag is not set, then the sequence number is interpreted as a relative locktime with the format specified in BIP68. This means that transaction will not be included in a block until the output it spends reaches the specified age.</li>
</ul>

<p>So, putting it all together, if one wants to signal replaceability in a version >=2 transaction, one can just use a sequence number which is less than <code>0xfffffffe</code> but has an active disable flag (i.e. is greater than <code>0x80000000</code>), on the other hand, how should one set the sequence number if one wants to both signal replaceability and also spend a relative timelocked output? Would it be ok to use a sequence number according to BIP68 and increase the bits that have no meaning in that format to replace the transaction? (i.e. changing all bits except <code>1 &lt;&lt; 31</code>, <code>1 &lt;&lt; 22</code> and <code>0xffff</code>)</p>

<locktime><replace-by-fee><sequence><checklocktimeverify><checksequenceverify>
Sequence number semantics
Simone Bronzini
# Sequence number semantics

(Asked by: username_0 on 2017-05-16)

Reading the following BIPs: [68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), [112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki), [125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki), I got a few questions about the sematics of sequence numbers. As far as I understood, in version 1 transactions, sequence numbers have the following meaning:

* If any input has a sequence less than `0xfffffffe`, than the whole transaction is signalling replaceability

On the other hand, in version >=2 transactions, the above rule applies, plus:

* If a sequence number has the disable flag (`1 << 31`) set to `1`, then the sequence has no additional meaning (but can still be used to signal replaceability, right?)
* If the disable flag is not set, then the sequence number is interpreted as a relative locktime with the format specified in BIP68. This means that transaction will not be included in a block until the output it spends reaches the specified age.

So, putting it all together, if one wants to signal replaceability in a version >=2 transaction, one can just use a sequence number which is less than `0xfffffffe` but has an active disable flag (i.e. is greater than `0x80000000`), on the other hand, how should one set the sequence number if one wants to both signal replaceability and also spend a relative timelocked output? Would it be ok to use a sequence number according to BIP68 and increase the bits that have no meaning in that format to replace the transaction? (i.e. changing all bits except `1 << 31`, `1 << 22` and `0xffff`)

**Tags:** locktime, replace-by-fee, sequence, checklocktimeverify, checksequenceverify


---

## 1 answers

### Answer by username_1 on 2017-07-02. Score: 6 | Accepted answer

If you're creating a version 2 transaction with the disable flag not set, then by definition the whole nSequence value will be less than 0xFFFFFFFE (because it will be at most 0x7FFFFFFF).

This implies that a transaction with an active relative locktime will always be replacable according to BIP125.

This is intentional. Nonreplacable transactions attempt to make use of the existing network policy rules to favor the first broadcasted version of a transaction. A transaction that will only become valid at a future point in time cannot make use of that, as it can't be broadcast until it becomes valid.

> **Comments:**
> **username_2**: I don't see why the time delay means non-replaceability *can't* be useful.  I can't think of a use, but someone may, for whatever reason, not want their transaction replaced, even if they are spending an output with relative locktime.  

---

