<p>No, there isn't a way to make a transaction that has to be included before a certain block number. </p>

<p>And there's a good reason for this: such a transaction would not be what is known as reorg-safe. Generally, transactions should be able to be included in either side of a block chain fork. If you make a transaction that can only be included before a certain block number, and then a fork occurs that makes a chain that doesn't include it before the designated block number, then that transaction gets reversed and so do all transactions that depend on the base transaction. </p>

CC BY-SA 3.0
2016-03-04T02:45:26.973Z
2016-03-04T02:45:26.973Z
morsecoder
<p>It seems like it would be useful to avoid replay attacks if your wallet could specify that a transaction must be confirmed before say the (current+100)th block before broadcasting it</p>

<p>I guess there could be a problem with this scheme if the tx was no longer able to be included into a block after a reorg (esp for dependent txs)</p>

CC BY-SA 3.0
2016-03-04T02:42:01.637Z
I don't know of any way to accomplish that.  Can you be more specific as to what kind of "replay attack" you are worried about?
Nate Eldredge
CC BY-SA 3.0
2016-03-04T06:33:20.527Z
here is an example http://qntra.net/2016/03/a-miner-problem/
djp
CC BY-SA 3.0
2016-03-04T06:41:39.207Z
This is not an attack. This is total misunderstaning how the Bitcoin network works.
amaclin
CC BY-SA 3.0
2016-03-06T22:05:16.963Z
In a scenario of permanent backlog of transactions this scenario will need better strategies however
djp
<transactions><confirmations>
Is there any way to make a transaction invalid if it is not confirmed before a certain block?
djp
# Is there any way to make a transaction invalid if it is not confirmed before a certain block?

(Asked by: username_0 on 2016-03-04)

It seems like it would be useful to avoid replay attacks if your wallet could specify that a transaction must be confirmed before say the (current+100)th block before broadcasting it

I guess there could be a problem with this scheme if the tx was no longer able to be included into a block after a reorg (esp for dependent txs)

**Tags:** transactions, confirmations

> **Comments:**
> **username_1**: I don't know of any way to accomplish that.  Can you be more specific as to what kind of "replay attack" you are worried about?  
> **username_0**: here is an example http://qntra.net/2016/03/a-miner-problem/  
> **username_2**: This is not an attack. This is total misunderstaning how the Bitcoin network works.  
> **username_0**: In a scenario of permanent backlog of transactions this scenario will need better strategies however  

---

## 1 answers

### Answer by username_3 on 2016-03-04. Score: 2

No, there isn't a way to make a transaction that has to be included before a certain block number.

And there's a good reason for this: such a transaction would not be what is known as reorg-safe. Generally, transactions should be able to be included in either side of a block chain fork. If you make a transaction that can only be included before a certain block number, and then a fork occurs that makes a chain that doesn't include it before the designated block number, then that transaction gets reversed and so do all transactions that depend on the base transaction.


---

