I read Contracts: Will this be possible? where part of the question related to expiring a transaction and one of the replies said that it would never be possible since it causes problems. Unfortunately the reply didn't indicate what problems it would cause.
I can't quite understand from the question/reply whether it was a question of expiring an (unconfirmed?) transaction (which might well be problematic) or expiring a txout from a previously confirmed transaction.
Is the latter entirely impossible by any current method, e.g. scripting and/or a combination of transactions?
One way that I perceive that it might be possible (and I'm only a bitcoin newbie so please take pity on me and help me understand if this suggestion is patently ridiculous to bitcoin experts) would be to have a new bitcoin script operation that could be used in the scriptPubKey of the txout to push the 'current' time on to the stack so that it can be compared (using OP_LESSTHAN, OP_GREATERTHAN, OP_LESSTHANOREQUAL or OP_GREATERTHANOREQUAL) to a fixed expiry time (which is in scriptPubKey and pushed to the stack by scriptPubKey) and only if the current time is less than the expiry time will the rest of the scriptPubKey allow the transaction (i.e. bitcoin payment) to be confirmed.
A note on what I mean by 'current' time...there could be a lengthy debate over the source of current time and the trustworthiness of that source but I'd propose that 'current' time doesn't truly need to be the actual current time so long as it's a reasonably close approximation in the bitcoin realm (about 10 minutes on average but maybe longer, maybe shorter). Thus it could be the timestamp of the previous block in the blockchain; that way every node (assuming no fork) will be judging the txout expiration against the same 'current' time.
An undesirable but arguably acceptable side effect is if a transaction spending the txout is submitted and confirmed in a short blockchain fork then it will get requeued on the longer fork and there is a chance that txout might have expired before the transaction is reprocessed and thus the transaction will fail the second time around.
Another subtlety to aid usability might be to offer two variants of the new 'current' time operation to mirror the two 'variants' of lock_time, one variant to push the previous block's timestamp on to the stack and the other variant to push the previous block's height on to the stack. This way a user can write transactions which are self consistent in time reference or self consistent in height reference.