Upper bound on transaction confirmation time 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?
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.