Post
Topic
Board Development & Technical Discussion
Merits 6 from 5 users
Re: Is it possible to let a transaction expire if it is not included in a block.
by
vjudeu
on 09/03/2022, 08:18:34 UTC
⭐ Merited by BlackHatCoiner (2) ,Pmalek (1) ,ETFbitcoin (1) ,pooya87 (1) ,d5000 (1)
He thought about it and he was asked specifically about it. You can find the reason in this topic: because adding transaction invalidation to the protocol is reorg-unsafe. Imagine Value Overflow Incident, where there are some transactions that are valid only before certain block number. Then, miners could ignore such transactions, and by not including them, they would also invalidate all transactions that were made later. Do you really want to find out that your previously-valid transaction is now invalid, because there were some kind of chain reorg, and some previous transaction was invalidated by such feature?
We can't safely do OP_BLOCKNUMBER.  In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block.  The OP_BLOCKNUMBER transaction and all its dependants would become invalid.  This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.

nTimeLock does the reverse.  It's an open transaction that can be replaced with new versions until the deadline.  It can't be recorded until it locks.  The highest version when the deadline hits gets recorded.  It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline.  The feature isn't enabled or used yet, but the support is there so it could be implemented later.

So, that means you cannot even have things like OP_BLOCKNUMBER, not to mention OP_BLOCKHASH proposed in decentralized lotteries. They are just reorg-unsafe, that's the reason, as you can read in the quote above.