<p>This question was <a href="https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119" rel="noreferrer">answered by Satoshi</a>. My attempt to paraphrase: Suppose a transaction T specified an expiration height, X, and was mined in block X. Then its outputs were spent, possibly many times over through multiple generations (the original transaction had, for example, great-great-grandchildren). Now a reorg occurs and there's a new version of the block at height X that doesn't include T.</p>
<p>Most (now unconfirmed) transactions are simply re-mined in the new branch, possibly at different block heights than before. But T can't be re-mined, since it is now invalid (it has expired), as are all of its descendants. As Satoshi puts it,</p>
<blockquote>
<p>This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.</p>
</blockquote>
<p>It's true that any reorg can cause previously-mined transactions to never be mined. But such double-spending would likely require malicious intent -- a 51% attack by miners, rather than, say, an innocuous temporary network partition.</p>
<p>It would be bad if this scenario (a previously-mined transaction is un-mined and then expires) could happen routinely because it would make payments less certain and would give payment receivers an incentive to verify the provenance of the coins they're being paid with, lest they be from a recent-expiring transaction. This is similar to the motivation for the <a href="https://bitcoin.stackexchange.com/questions/1991/what-is-the-block-maturation-time">100 block coinbase maturation</a> consensus rule.</p>

CC BY-SA 4.0
2023-01-27T01:51:23.557Z
And, importantly, this type of scenario where there's confusion about the final state of a transaction is precisely what this change would be intended to prevent. And, worse, this would be confusion about a transaction that some parties thought was confirmed. If a fix creates a worse version of the very problem it's intended to fix, it's not a very good fix.
David Schwartz
CC BY-SA 4.0
2023-01-26T17:35:07.137Z
2023-01-27T15:53:26.443Z
2023-01-27T15:53:26.443Z
Larry Ruane
<p>Transactions with low fees may remain in the mempool for as long as <a href="https://bitcoin.stackexchange.com/a/100959/97099">14 days</a>. This indeterminism is a source of confusion for users and wallets. It's <a href="https://bitcoin.stackexchange.com/questions/84008/transaction-with-expiration-time">not possible</a> to cause a transaction in the mempool to expire (become invalid) at a certain time in the future, if not yet mined.</p>
<p>Allowing a transaction to specify a block height after which it <em>cannot</em> be mined would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. This would allow a payment to be re-attempted without having to wait up to 14 days and without having to satisfy the <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md" rel="noreferrer">BIP125 rules</a> or submitting a <a href="https://bitcoin.stackexchange.com/questions/53852/how-to-unstuck-a-low-fee-transaction-with-blockchain-info">CPFP</a> transaction. This would also have the advantage of optimizing mempool performance by removing transactions that are no longer desired or that may not be mined.</p>
<p>Adding this functionality today would probably require a hard fork, but why didn't the protocol initially provide this feature?</p>

CC BY-SA 4.0
2023-10-22T11:46:35.993Z
Why would it require a hardfork?
Antoine Poinsot
<unconfirmed-transactions><mempool>
Why doesn't the protocol allow unconfirmed transactions to expire at a given height?
Larry Ruane
# Why doesn't the protocol allow unconfirmed transactions to expire at a given height?

(Asked by: username_0 on 2023-01-26)

Transactions with low fees may remain in the mempool for as long as [14 days](https://bitcoin.stackexchange.com/a/100959/97099). This indeterminism is a source of confusion for users and wallets. It's [not possible](https://bitcoin.stackexchange.com/questions/84008/transaction-with-expiration-time) to cause a transaction in the mempool to expire (become invalid) at a certain time in the future, if not yet mined.

Allowing a transaction to specify a block height after which it *cannot* be mined would provide certainty around how long a transaction has to confirm before it is rejected by the network and must be re-sent. This would allow a payment to be re-attempted without having to wait up to 14 days and without having to satisfy the [BIP125 rules](https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md) or submitting a [CPFP](https://bitcoin.stackexchange.com/questions/53852/how-to-unstuck-a-low-fee-transaction-with-blockchain-info) transaction. This would also have the advantage of optimizing mempool performance by removing transactions that are no longer desired or that may not be mined.

Adding this functionality today would probably require a hard fork, but why didn't the protocol initially provide this feature?

**Tags:** unconfirmed-transactions, mempool

> **Comments:**
> **username_1**: Why would it require a hardfork?  

---

## 1 answers

### Answer by username_0 on 2023-01-26. Score: 11 | Accepted answer

This question was [answered by Satoshi](https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119). My attempt to paraphrase: Suppose a transaction T specified an expiration height, X, and was mined in block X. Then its outputs were spent, possibly many times over through multiple generations (the original transaction had, for example, great-great-grandchildren). Now a reorg occurs and there's a new version of the block at height X that doesn't include T.

Most (now unconfirmed) transactions are simply re-mined in the new branch, possibly at different block heights than before. But T can't be re-mined, since it is now invalid (it has expired), as are all of its descendants. As Satoshi puts it,

> This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.

It's true that any reorg can cause previously-mined transactions to never be mined. But such double-spending would likely require malicious intent -- a 51% attack by miners, rather than, say, an innocuous temporary network partition.

It would be bad if this scenario (a previously-mined transaction is un-mined and then expires) could happen routinely because it would make payments less certain and would give payment receivers an incentive to verify the provenance of the coins they're being paid with, lest they be from a recent-expiring transaction. This is similar to the motivation for the [100 block coinbase maturation](https://bitcoin.stackexchange.com/questions/1991/what-is-the-block-maturation-time) consensus rule.

> **Comments:**
> **username_2**: And, importantly, this type of scenario where there's confusion about the final state of a transaction is precisely what this change would be intended to prevent. And, worse, this would be confusion about a transaction that some parties thought was confirmed. If a fix creates a worse version of the very problem it's intended to fix, it's not a very good fix.  

---

