4

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.

Improve this question
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.
    – Murch ♦
    Commented Mar 25, 2014 at 9:40

1 Answer 1

Reset to default
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.

Improve this answer
8
  • 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
    Commented Mar 28, 2014 at 15:31
  • 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
    Commented Mar 28, 2014 at 15:31
  • 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
    Commented Mar 28, 2014 at 15:33
  • 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
    Commented Mar 28, 2014 at 15:33
  • 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
    Commented Mar 28, 2014 at 15:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.