<p>Expiring a txout doesn't really make sense, since it would destroy the coins, and there is no way to destroy coins. (Coins not spoken for by any txout are contributed as fees.)</p>

<p>You could create a transaction with a lock_time in the future that sends the coins to another bitcoin address. If you give this transaction to a counterparty, they would then have the option to broadcast the transaction to the network after it becomes due, and it would take effect.</p>

<p>Before that time, you could create another transaction without the lock_time restriction, move the coins, and make the counterparty's transaction useless.</p>

CC BY-SA 3.0
2014-03-28T15:31:05.993Z
My comment is too long so is coming in several parts...

PART 1

This is a somewhat contrived example but illustrates the kind of thing I was contemplating. NB: The example would require the use of (currently) non-standard transactions featuring conditional scripting operations.
Phil Dann Ward
CC BY-SA 3.0
2014-03-28T15:31:42.527Z
PART 2

Conditions:

1) Alice wants to make give some bitcoins to Bob right now (time t0) but wants to stipulate that they have to be spent by a given future time (t2). Alice doesn't care what Bob spends the bitcoins on.

2) If Bob doesn't spend the bitcoins by time t2 then Alice wants the coins to be donated to a charitable foundation which is run anonymously by Eve.

3) Alice expects to die roughly at time t1 where t1<t2.
Phil Dann Ward
CC BY-SA 3.0
2014-03-28T15:33:14.397Z
PART 3

Corollaries:

1) Alice needs to submit a transaction (Tx0) at t0 with a txout that transfers the bitcoins to Bob so that Bob can spend them.

2) Alice and Bob don't want Alice to be a signatory on Bob's (as yet unwritten) spend transaction (Tx.Bobspend) principally because if Alice dies at t1<t2 before Bob has generated Tx.Bobspend, Alice is no longer around to sign Tx.Bobspend even though we haven't reached t2 yet.
Phil Dann Ward
CC BY-SA 3.0
2014-03-28T15:33:44.317Z
PART 4

3) Although Alice could generate a transaction (Tx.Alicecharity) now with a txout that transfers the bitcoins to the foundation she doesn't know Eve's identity and thus has nowhere to send Tx.Alicecharity to.
Phil Dann Ward
CC BY-SA 3.0
2014-03-28T15:34:03.690Z
PART 5

So the Alice's Tx0 would have a txout that works something like this when somebody tries to spend it with a transaction (Tx.future) at some time in the future (t.future):

If t.future < t2 and signatures on Tx.future match Bob's bitcoin address then let Bob spend the bitcoins,

Else if t.future > t2 and signatures on Tx.future match the foundation's bitcoin address then let the foundation spend the bitcoins,

Else t.future is invalid.
Phil Dann Ward
CC BY-SA 3.0
2014-04-01T01:04:34.787Z
There is no way to put a reference to the current time (or other monotonically increasing time-like function) in the script, so I don't see a way to do this with just one transaction. However, you could write a 1 of 2 multi-sig that transfers the coins to A1 and B1 (where A1 is controlled by Alice and B1 is controlled by Bob), and send Eve a transaction moving the multi-sig coins to E1 (an address controlled by Eve) with lock_time set to t2. Then, Eve is free to broadcast the transaction, snagging the coins from the multisig transaction after time t2.
Richard Kiss
CC BY-SA 3.0
2014-04-09T20:43:55.690Z
did you mean 'currently no way' (agreed) or 'never be a way'? I was floating the idea of one or two new scripting function(s) for scriptPubKey use that would push the previous block's height or time stamp to the stack preceded or followed by a push of a constant (expressing the 'expiry' time) and then an op_lessthan or op_greaterthan to determine if the 'current' time is before or after the constant. Given that nodes already have some concept of the 'current' time to check Tx NLock_time it didn't seem to much of a step onwards...but my understanding is probably too simplistic. :-/
Phil Dann Ward
CC BY-SA 3.0
2014-04-09T20:52:44.827Z
by the way, your (thoughtful) answer appeared to suggest that Alice would send a signed, lock_timed Tx to Eve but my (very contrived) example had already explicitly stated that Alice didn't know who Eve was so had no way to send Eve *anything*. (Notwithstanding the possibility of Alice's use of a trusted 3rd party to broadcast the lock_timed Tx on behalf of Eve once the lock_time had passed.)
Phil Dann Ward
CC BY-SA 3.0
2014-03-25T08:50:07.450Z
2014-03-25T08:50:07.450Z
Richard Kiss
<p>I read <a href="https://bitcoin.stackexchange.com/questions/1986/contracts-will-this-be-possible">Contracts: Will this be possible?</a> 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.</p>

<p>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.</p>

<p>Is the latter entirely impossible by any current method, e.g. scripting and/or a combination of transactions?</p>

<p>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 <b>new</b> bitcoin script operation that could be used in the scriptPubKey of the txout to push the '<i>current</i>' 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.</p>

<p>A note on what I mean by '<i>current</i>' 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 <b>previous</b> block in the blockchain; that way every node (assuming no fork) will be judging the txout expiration against the same 'current' time.</p>

<p>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.</p>

<p>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 <b>height</b> on to the stack. This way a user can write transactions which are self consistent in time reference or self consistent in height reference.</p>

CC BY-SA 3.0
2014-03-25T09:40:51.793Z
Forks work a bit differently than you assume: As soon as they diverge from a common source, they are completely independent from each other. They are diverging child branches from a common root, which will never find back together. Each fork considers its competitors to be invalid as they are incompatible to each other. Thus, there would never be any requeueing due to interaction with other forks, instead each fork will consider each transaction for itself as soon as it becomes available.
Murch
<script><contracts><time><utxo>
Is it possible (in some way or other) to expire a txout?
Phil Dann Ward
# Is it possible (in some way or other) to expire a txout?

(Asked by: username_0 on 2014-03-21)

I read [Contracts: Will this be possible?](https://bitcoin.stackexchange.com/questions/1986/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.

**Tags:** script, contracts, time, utxo

> **Comments:**
> **username_1**: Forks work a bit differently than you assume: As soon as they diverge from a common source, they are completely independent from each other. They are diverging child branches from a common root, which will never find back together. Each fork considers its competitors to be invalid as they are incompatible to each other. Thus, there would never be any requeueing due to interaction with other forks, instead each fork will consider each transaction for itself as soon as it becomes available.  

---

## 1 answers

### Answer by username_2 on 2014-03-25. Score: 1

Expiring a txout doesn't really make sense, since it would destroy the coins, and there is no way to destroy coins. (Coins not spoken for by any txout are contributed as fees.)

You could create a transaction with a lock\_time in the future that sends the coins to another bitcoin address. If you give this transaction to a counterparty, they would then have the option to broadcast the transaction to the network after it becomes due, and it would take effect.

Before that time, you could create another transaction without the lock\_time restriction, move the coins, and make the counterparty's transaction useless.

> **Comments:**
> **username_0**: My comment is too long so is coming in several parts...  PART 1  This is a somewhat contrived example but illustrates the kind of thing I was contemplating. NB: The example would require the use of (currently) non-standard transactions featuring conditional scripting operations.  
> **username_0**: PART 2  Conditions:  1) Alice wants to make give some bitcoins to Bob right now (time t0) but wants to stipulate that they have to be spent by a given future time (t2). Alice doesn't care what Bob spends the bitcoins on.  2) If Bob doesn't spend the bitcoins by time t2 then Alice wants the coins to be donated to a charitable foundation which is run anonymously by Eve.  3) Alice expects to die roughly at time t1 where t1<t2.  
> **username_0**: PART 3  Corollaries:  1) Alice needs to submit a transaction (Tx0) at t0 with a txout that transfers the bitcoins to Bob so that Bob can spend them.  2) Alice and Bob don't want Alice to be a signatory on Bob's (as yet unwritten) spend transaction (Tx.Bobspend) principally because if Alice dies at t1<t2 before Bob has generated Tx.Bobspend, Alice is no longer around to sign Tx.Bobspend even though we haven't reached t2 yet.  
> **username_0**: PART 4  3) Although Alice could generate a transaction (Tx.Alicecharity) now with a txout that transfers the bitcoins to the foundation she doesn't know Eve's identity and thus has nowhere to send Tx.Alicecharity to.  
> **username_0**: PART 5  So the Alice's Tx0 would have a txout that works something like this when somebody tries to spend it with a transaction (Tx.future) at some time in the future (t.future):  If t.future < t2 and signatures on Tx.future match Bob's bitcoin address then let Bob spend the bitcoins,  Else if t.future > t2 and signatures on Tx.future match the foundation's bitcoin address then let the foundation spend the bitcoins,  Else t.future is invalid.  
> **username_2**: There is no way to put a reference to the current time (or other monotonically increasing time-like function) in the script, so I don't see a way to do this with just one transaction. However, you could write a 1 of 2 multi-sig that transfers the coins to A1 and B1 (where A1 is controlled by Alice and B1 is controlled by Bob), and send Eve a transaction moving the multi-sig coins to E1 (an address controlled by Eve) with lock_time set to t2. Then, Eve is free to broadcast the transaction, snagging the coins from the multisig transaction after time t2.  
> **username_0**: did you mean 'currently no way' (agreed) or 'never be a way'? I was floating the idea of one or two new scripting function(s) for scriptPubKey use that would push the previous block's height or time stamp to the stack preceded or followed by a push of a constant (expressing the 'expiry' time) and then an op_lessthan or op_greaterthan to determine if the 'current' time is before or after the constant. Given that nodes already have some concept of the 'current' time to check Tx NLock_time it didn't seem to much of a step onwards...but my understanding is probably too simplistic. :-/  
> **username_0**: by the way, your (thoughtful) answer appeared to suggest that Alice would send a signed, lock_timed Tx to Eve but my (very contrived) example had already explicitly stated that Alice didn't know who Eve was so had no way to send Eve *anything*. (Notwithstanding the possibility of Alice's use of a trusted 3rd party to broadcast the lock_timed Tx on behalf of Eve once the lock_time had passed.)  

---

