<p>This is intentionally not possible.</p>
<p>If a transaction would be valid in block X, we want it (absent double spend) to remain valid in any successor of X. This guarantees that (temporary, otherwise harmless) forks that result in small reorgs will never invalidate unrelated transactions - and they will just be able to be mined again in the new branch.</p>
<p>It also simplifies wallet assessment of incoming transactions. Imagine a transaction that was just confirmed in the last block where it would be valid. 1-block reorgs are infrequent, but not rare. You'd need special logic to detect this and factor the risk of a reorg that permanently invalidates the transaction into the decision of when to accept it. It's even worse for unconfirmed transactions, though there are other issues with those as well.</p>

CC BY-SA 4.0
2020-09-07T23:07:06.947Z
2020-09-08T02:31:30.937Z
2020-09-08T02:31:30.937Z
Pieter Wuille
<p>For example, an <code>nLockTime == 500</code> prevents a transaction from being included in any blocks before the block 500.</p>
<p>Why isn't there a parameter like <code>nExpireTime == 500</code> that prevented a transaction from being included in any block over the 500? Would it be theoretically possible to have one or it's a flawed approach for some reason?</p>

<transactions><validation>
Is it theoretically possible to have an inverted nLockTime?
fiatjaf
# Is it theoretically possible to have an inverted nLockTime?

(Asked by: username_0 on 2020-09-07)

For example, an `nLockTime == 500` prevents a transaction from being included in any blocks before the block 500.

Why isn't there a parameter like `nExpireTime == 500` that prevented a transaction from being included in any block over the 500? Would it be theoretically possible to have one or it's a flawed approach for some reason?

**Tags:** transactions, validation


---

## 1 answers

### Answer by username_1 on 2020-09-07. Score: 6 | Accepted answer

This is intentionally not possible.

If a transaction would be valid in block X, we want it (absent double spend) to remain valid in any successor of X. This guarantees that (temporary, otherwise harmless) forks that result in small reorgs will never invalidate unrelated transactions - and they will just be able to be mined again in the new branch.

It also simplifies wallet assessment of incoming transactions. Imagine a transaction that was just confirmed in the last block where it would be valid. 1-block reorgs are infrequent, but not rare. You'd need special logic to detect this and factor the risk of a reorg that permanently invalidates the transaction into the decision of when to accept it. It's even worse for unconfirmed transactions, though there are other issues with those as well.


---

