<blockquote>
  <p>So, the question: with current Script language, is it possible to create a transaction that becomes invalid if not included in a block before a certain time (or before a certain block height)?</p>
</blockquote>

<p>No, by design this is not possible.</p>

<p>The problem is that such a output would be very hard to assess the value of, when the timeout is close to being reached. Is the transaction going to be included, or become invalid? Even after it's confirmed, there are chances of it being reorganized out, and becoming invalid.</p>

<p>So by design no script features exist which depend on the context. A transaction is valid, or invalid. To deal with timing transactions can specify an <code>nLockTime</code> field which specifies the earliest possible time or height the transaction can be included in the chain at. The script language can introspect the <code>nLockTime</code> value, but not the actual time.</p>

CC BY-SA 3.0
2018-04-01T01:11:01.267Z
2018-04-01T01:11:01.267Z
Pieter Wuille
<blockquote>
  <p>with current Script language, is it possible to create a transaction
  that becomes invalid if not included in a block before a certain time
  (or before a certain block height)?</p>
</blockquote>

<p>well, maybe not directly with the standard way of scripting transactions. Bitcoin has two functions for adding delay to a tx. Locktime/Sequence would not be working, cause it allows to define, by when a tx can go into the blockchain. If delay is not reached, it will not be mined, and stay in mempool. So it is the opposite of your requirement. But: </p>

<p><strong>CSV</strong> (<a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki" rel="nofollow noreferrer">BIP112</a>) or <strong>CLTV</strong> (<a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow noreferrer">BIP68</a>): both allow to define a delay, before the next steps can be executed. One of the step could also be "OP_RETURN" or whatever leaves a "false" on the stack. This would terminate the script execution immediately, and mark the tx invalid.</p>

<blockquote>
  <p>If so, how many bytes it would take up?</p>
</blockquote>

<p>This is maybe an additional 10-20 bytes for the IF/ELSE/ENDIF and the CSV or CLTV codes. But you would probably need a another tx. One as a "funding transaction", and this logic with the spending tx. So it would end up with a "bloat" of the blockchain. </p>

<blockquote>
  <p>Such a transaction would be broadcast by common nodes, or they expect
  a certain specific signature format?</p>
</blockquote>

<p>This gets a bit tricky: these tx would need to be crafted annually, and they are defined as non-standard (which doesn't mean invalid though. But you have to find ways to bring it to a miner/into the network). </p>

CC BY-SA 3.0
2018-03-31T15:41:31.140Z
I downvoted; this is wrong. CSV and CLTV do not delay steps in a program. They are time independent, and simply check whether the transaction has an acceptable locktime/sequence. There is intentionally no way these can be used to make a transaction fail after a certain point in time in order to not hurt fungibility (coins that are about to expire and aren't confirmed would be worth less than others).
Pieter Wuille
CC BY-SA 3.0
2018-03-31T22:28:55.313Z
ACK. "Delay" was not precise enough, and the "tx invalid" was linked to the OP_Return, not CSV/CLTV (see also a previous  explanation/reply here:  https://bitcoin.stackexchange.com/questions/49303/op-return-marks-transaction-or-output-as-invalid). In the aftermath: the CSV/CLTV part  doesn't even answer OPs question for a logic, that tx is invalidated before it gets in a block - with CSV/CLTV it would be already in a block. thx.
pebwindkraft
CC BY-SA 3.0
2018-03-31T14:23:55.173Z
2018-03-31T14:23:55.173Z
pebwindkraft
<p>Today I saw a case where a transaction had a very low fee, so it got stuck in the mempool for days. The original wallet refused to allow a new transaction to be created with the same input, and in a case of mempool getting empty again, someone could rebroadcast that transaction and it would be accepted again.</p>

<p>So, the question: with current Script language, is it possible to create a transaction that becomes invalid if not included in a block before a certain time (or before a certain block height)? If so, how many bytes it would take up?</p>

<p>Such a transaction would be broadcast by common nodes, or they expect a certain specific signature format?</p>

CC BY-SA 3.0
2017-09-22T10:52:49.580Z
"that becomes invalid if not included in a block before a certain time (or before a certain block height)?" This is impossible.
MCCCS
<script>
Upper bound on transaction confirmation time
lvella
# Upper bound on transaction confirmation time

(Asked by: username_0 on 2017-09-21)

Today I saw a case where a transaction had a very low fee, so it got stuck in the mempool for days. The original wallet refused to allow a new transaction to be created with the same input, and in a case of mempool getting empty again, someone could rebroadcast that transaction and it would be accepted again.

So, the question: with current Script language, is it possible to create a transaction that becomes invalid if not included in a block before a certain time (or before a certain block height)? If so, how many bytes it would take up?

Such a transaction would be broadcast by common nodes, or they expect a certain specific signature format?

**Tags:** script

> **Comments:**
> **username_1**: "that becomes invalid if not included in a block before a certain time (or before a certain block height)?" This is impossible.  

---

## 2 answers

### Answer by username_2 on 2018-04-01. Score: 0 | Accepted answer

> So, the question: with current Script language, is it possible to create a transaction that becomes invalid if not included in a block before a certain time (or before a certain block height)?

No, by design this is not possible.

The problem is that such a output would be very hard to assess the value of, when the timeout is close to being reached. Is the transaction going to be included, or become invalid? Even after it's confirmed, there are chances of it being reorganized out, and becoming invalid.

So by design no script features exist which depend on the context. A transaction is valid, or invalid. To deal with timing transactions can specify an `nLockTime` field which specifies the earliest possible time or height the transaction can be included in the chain at. The script language can introspect the `nLockTime` value, but not the actual time.


---

### Answer by username_3 on 2018-03-31. Score: -1

> with current Script language, is it possible to create a transaction
> that becomes invalid if not included in a block before a certain time
> (or before a certain block height)?

well, maybe not directly with the standard way of scripting transactions. Bitcoin has two functions for adding delay to a tx. Locktime/Sequence would not be working, cause it allows to define, by when a tx can go into the blockchain. If delay is not reached, it will not be mined, and stay in mempool. So it is the opposite of your requirement. But:

**CSV** ([BIP112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)) or **CLTV** ([BIP68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)): both allow to define a delay, before the next steps can be executed. One of the step could also be "OP\_RETURN" or whatever leaves a "false" on the stack. This would terminate the script execution immediately, and mark the tx invalid.

> If so, how many bytes it would take up?

This is maybe an additional 10-20 bytes for the IF/ELSE/ENDIF and the CSV or CLTV codes. But you would probably need a another tx. One as a "funding transaction", and this logic with the spending tx. So it would end up with a "bloat" of the blockchain.

> Such a transaction would be broadcast by common nodes, or they expect
> a certain specific signature format?

This gets a bit tricky: these tx would need to be crafted annually, and they are defined as non-standard (which doesn't mean invalid though. But you have to find ways to bring it to a miner/into the network).

> **Comments:**
> **username_2**: I downvoted; this is wrong. CSV and CLTV do not delay steps in a program. They are time independent, and simply check whether the transaction has an acceptable locktime/sequence. There is intentionally no way these can be used to make a transaction fail after a certain point in time in order to not hurt fungibility (coins that are about to expire and aren't confirmed would be worth less than others).  
> **username_3**: ACK. "Delay" was not precise enough, and the "tx invalid" was linked to the OP_Return, not CSV/CLTV (see also a previous  explanation/reply here:  https://bitcoin.stackexchange.com/questions/49303/op-return-marks-transaction-or-output-as-invalid). In the aftermath: the CSV/CLTV part  doesn't even answer OPs question for a logic, that tx is invalidated before it gets in a block - with CSV/CLTV it would be already in a block. thx.  

---

