<p>This isn't possible with a single bitcoin sript, but your example can be realized quite easily by simply adding one more transaction to the equation:</p>
<blockquote>
<p>So the premise is that given an input, it can be spent by either party A or party B. The restriction is that party B must spend it within the 1st 30 mins else after that A must spend it.</p>
</blockquote>
<ul>
<li>Party A and party B cooperate to create a 1-of-2 multisig address, and then have coins sent to it</li>
<li>After 30 minutes, party A will create a second transaction which pays the coins to an address that only party A controls</li>
<li>Now party A can spend the coins, party B cannot</li>
</ul>
<p>This depends on party A publishing the second transaction, but that step could also be automated and happen during the initial setup of the multisig address. The second transaction could even have a timelock added, such that it could not be published early (though party A can otherwise spend the coins at any time, so this seems unnecessary).</p>
<p>Otherwise, as mentioned in the comments, this sort of construction isn't possible using bitcoin script alone.</p>

CC BY-SA 4.0
2020-06-26T04:01:38.140Z
What if OP_RETURN is used to make the output unspendable if a locktime of say 30 mins has elapsed? Sort of burning the output in order to punish B for the delay. Then it that case neither A nor B can spend, right?
Subhra Mazumdar
CC BY-SA 4.0
2020-06-23T02:58:27.563Z
2020-06-23T02:58:27.563Z
chytrik
<p>So I want to write a bitcoin script so that after a certain time period (say for example after 30 mins), the verification fails and transaction is marked invalid even if it gets broadcasted. Time locks are used so that a transaction is considered valid after a certain time period. I want the opposite to happen. So can I just enter some bogus lines of code after  OP_CHECKLOCKTIMEVERIFY so that script check intentionally fails? Or is there any opcode by which I can achieve the same functionality?</p>

CC BY-SA 4.0
2020-06-22T04:49:26.940Z
That isn't supported by Bitcoin because it isn't reorg-safe.  A valid transaction remains valid until its inputs are spent. This ensures that the blockchain can always be reorganized.
G. Maxwell
CC BY-SA 4.0
2020-06-22T05:52:31.400Z
Yes that's true. So the premise is that given an input, it can be spent by either party A or party B. The restriction is that party B must spend it within the 1st 30 mins else after that A must spend it.
Subhra Mazumdar
CC BY-SA 4.0
2020-06-22T16:15:09.740Z
Again. Not something that can happen in bitcoin.
Claris
<bitcoin-core><script><p2sh><input-script><opcodes>
Bitcoin script verification fails after certain time period
Subhra Mazumdar
# Bitcoin script verification fails after certain time period

(Asked by: username_0 on 2020-06-22)

So I want to write a bitcoin script so that after a certain time period (say for example after 30 mins), the verification fails and transaction is marked invalid even if it gets broadcasted. Time locks are used so that a transaction is considered valid after a certain time period. I want the opposite to happen. So can I just enter some bogus lines of code after OP\_CHECKLOCKTIMEVERIFY so that script check intentionally fails? Or is there any opcode by which I can achieve the same functionality?

**Tags:** bitcoin-core, script, p2sh, input-script, opcodes

> **Comments:**
> **username_1**: That isn't supported by Bitcoin because it isn't reorg-safe.  A valid transaction remains valid until its inputs are spent. This ensures that the blockchain can always be reorganized.  
> **username_0**: Yes that's true. So the premise is that given an input, it can be spent by either party A or party B. The restriction is that party B must spend it within the 1st 30 mins else after that A must spend it.  
> **username_2**: Again. Not something that can happen in bitcoin.  

---

## 1 answers

### Answer by username_3 on 2020-06-23. Score: 1

This isn't possible with a single bitcoin sript, but your example can be realized quite easily by simply adding one more transaction to the equation:

> So the premise is that given an input, it can be spent by either party A or party B. The restriction is that party B must spend it within the 1st 30 mins else after that A must spend it.

* Party A and party B cooperate to create a 1-of-2 multisig address, and then have coins sent to it
* After 30 minutes, party A will create a second transaction which pays the coins to an address that only party A controls
* Now party A can spend the coins, party B cannot

This depends on party A publishing the second transaction, but that step could also be automated and happen during the initial setup of the multisig address. The second transaction could even have a timelock added, such that it could not be published early (though party A can otherwise spend the coins at any time, so this seems unnecessary).

Otherwise, as mentioned in the comments, this sort of construction isn't possible using bitcoin script alone.

> **Comments:**
> **username_0**: What if OP_RETURN is used to make the output unspendable if a locktime of say 30 mins has elapsed? Sort of burning the output in order to punish B for the delay. Then it that case neither A nor B can spend, right?  

---

