<p>You can do this by creating a P2WSH output with the following script:</p>
<pre><code>OP_IF
  &lt;condition 1&gt;
OP_ELSE
  &lt;timestamp&gt;
  OP_CHECKLOCKTIMEVERIFY
  OP_DROP
  &lt;condition 2&gt;
OP_ENDIF
</code></pre>
<p>Then depending on what condition you're taking you put <code>1</code> or <code>0</code> on top of the initial stack when spending.</p>
<p>You can also do this more privately (and in most cases cheaply) by using P2TR and splitting the two conditions into separate tree leaves. If the first condition consists of a single public key (or a set of keys that can be aggregated) you can use it as the internal key, and when you're taking that condition using the key path you don't even need to reveal a script.</p>

CC BY-SA 4.0
2024-03-10T17:53:04.640Z
@kirti-singh note that after <timestamp> <condition 1> is still valid.
bordalix
CC BY-SA 4.0
2024-03-11T09:30:47.830Z
@bordalix True, how to make it such that after <timestamp>, the <condition 1> does not hold?
Kirti Singh
CC BY-SA 4.0
2024-03-11T11:43:09.240Z
That's impossible. Transaction validity is by design monotonous, i.e. once a transaction becomes valid it stays valid, unless one of its inputs is spent or a soft fork activates that invalidates it. See also Antoine's answer.
Vojtěch Strnad
CC BY-SA 4.0
2024-03-10T15:41:25.343Z
2024-03-10T15:41:25.343Z
Vojtěch Strnad
<p>It's not possible to set spend conditions which expire on a Script. It's sometimes referred to as an &quot;inverse timelock&quot;. It is widely believed to not be desirable as a valid Script becoming invalid makes it much harder to reason about reorgs and caching.</p>

CC BY-SA 4.0
2024-03-11T10:12:36.403Z
2024-03-12T12:11:09.237Z
2024-03-12T12:11:09.237Z
Antoine Poinsot
<p>How to make spending conditions of a UTXO in Bitcoin such that before a particular timestamp, say t, it can be spent only in one way and, after t, it can be spent only in another way.</p>

<transactions><p2sh><locktime><hash-time-locked-contract><checklocktimeverify>
Can a spend before a timestamp condition be put on a Bitcoin UTXO?
Kirti Singh
# Can a spend before a timestamp condition be put on a Bitcoin UTXO?

(Asked by: username_0 on 2024-03-10)

How to make spending conditions of a UTXO in Bitcoin such that before a particular timestamp, say t, it can be spent only in one way and, after t, it can be spent only in another way.

**Tags:** transactions, p2sh, locktime, hash-time-locked-contract, checklocktimeverify


---

## 2 answers

### Answer by username_1 on 2024-03-10. Score: 3

You can do this by creating a P2WSH output with the following script:

```
OP_IF
  <condition 1>
OP_ELSE
  <timestamp>
  OP_CHECKLOCKTIMEVERIFY
  OP_DROP
  <condition 2>
OP_ENDIF

```

Then depending on what condition you're taking you put `1` or `0` on top of the initial stack when spending.

You can also do this more privately (and in most cases cheaply) by using P2TR and splitting the two conditions into separate tree leaves. If the first condition consists of a single public key (or a set of keys that can be aggregated) you can use it as the internal key, and when you're taking that condition using the key path you don't even need to reveal a script.

> **Comments:**
> **username_2**: @username_0-username_0 note that after <timestamp> <condition 1> is still valid.  
> **username_0**: @username_2 True, how to make it such that after <timestamp>, the <condition 1> does not hold?  
> **username_1**: That's impossible. Transaction validity is by design monotonous, i.e. once a transaction becomes valid it stays valid, unless one of its inputs is spent or a soft fork activates that invalidates it. See also username_3's answer.  

---

### Answer by username_3 on 2024-03-11. Score: 2

It's not possible to set spend conditions which expire on a Script. It's sometimes referred to as an "inverse timelock". It is widely believed to not be desirable as a valid Script becoming invalid makes it much harder to reason about reorgs and caching.


---

