<p>Through the use of <code>OP_CHECKLOCKTIMEVERIFY</code>, the Bitcoin scripting language allows users to set a &quot;cannot be spent before time T1&quot; constraint on the output (exact semantics are specified in <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki" rel="nofollow noreferrer">BIP-0065</a>). However, Bitcoin scripting language does NOT support a &quot;cannot be spent after T2&quot;.</p>
<p>This means that it isn't possible to implement your proposed contract because the 1st path would still be available even after the time limit, allowing your spender to circumvent the h(z)=z requirement by using the easier path.</p>
<p>The flipped scenario could be implemented, if you required h(x)=x AND h(z)=z before your GivenTimeLimit, and required only h(x)=x after the time limit. Note that the x&amp;z path would still be available, but there'd be no incentive to use it since the easier, x-only, path would still be open.</p>
<p>If you wanted to create a public task that becomes progressively harder as time goes on, then instead of directly coding the harder task you'd need to code in some admin signature, and then when the time limit expires you'd need to remember to spend it with the key and move the funds to a harder version of the task.</p>

CC BY-SA 4.0
2022-11-01T16:52:15.473Z
2022-11-01T16:52:15.473Z
bca-0353f40e
<p>I am very new to bitcoin scripts, and need to design some high level bitcoin protocols without enough time to really dive into the details of the language itself.</p>
<p>Is there a way to write a script that conditions on the current time?
something like this. where currentTime stands for the current time stamp.</p>
<pre><code>GivenTimeLimit=8.23.2013

if currentTime&lt;GivenTimeLimit: 
 redeeming requires knowing x s.t h(x)=x (input is x)
else: 
 redeeming requires knowing x s.t. h(x)=x AND z s.t. h(z)=z (inputs are x and z)
</code></pre>
<p>I am trying to create a situation where until time (or date) GivenTimeLimit, only one party p1 can redeem a certain amount, but after GivenTimeLimit, only the other party, p2, can redeem this amount. Is that possible?</p>
<p>Thank you very much!</p>

<script>
is there a way to write SCRIPTS that CONDITION OVER THE CURRENT TIME stamp?
mpcabe
# is there a way to write SCRIPTS that CONDITION OVER THE CURRENT TIME stamp?

(Asked by: username_0 on 2021-04-09)

I am very new to bitcoin scripts, and need to design some high level bitcoin protocols without enough time to really dive into the details of the language itself.

Is there a way to write a script that conditions on the current time?
something like this. where currentTime stands for the current time stamp.

```
GivenTimeLimit=8.23.2013

if currentTime<GivenTimeLimit: 
 redeeming requires knowing x s.t h(x)=x (input is x)
else: 
 redeeming requires knowing x s.t. h(x)=x AND z s.t. h(z)=z (inputs are x and z)

```

I am trying to create a situation where until time (or date) GivenTimeLimit, only one party p1 can redeem a certain amount, but after GivenTimeLimit, only the other party, p2, can redeem this amount. Is that possible?

Thank you very much!

**Tags:** script


---

## 1 answers

### Answer by username_1 on 2022-11-01. Score: 1

Through the use of `OP_CHECKLOCKTIMEVERIFY`, the Bitcoin scripting language allows users to set a "cannot be spent before time T1" constraint on the output (exact semantics are specified in [BIP-0065](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)). However, Bitcoin scripting language does NOT support a "cannot be spent after T2".

This means that it isn't possible to implement your proposed contract because the 1st path would still be available even after the time limit, allowing your spender to circumvent the h(z)=z requirement by using the easier path.

The flipped scenario could be implemented, if you required h(x)=x AND h(z)=z before your GivenTimeLimit, and required only h(x)=x after the time limit. Note that the x&z path would still be available, but there'd be no incentive to use it since the easier, x-only, path would still be open.

If you wanted to create a public task that becomes progressively harder as time goes on, then instead of directly coding the harder task you'd need to code in some admin signature, and then when the time limit expires you'd need to remember to spend it with the key and move the funds to a harder version of the task.


---

