Bitcoin Forum

Is it possible to construct a transaction such that if the coins are not spent after some pre-determined time period the transaction becomes null?

For example, I want to give 1 btc as a gift, but I don't want that gift to be thrown away.... I create a transaction that says I will spend 1 btc to address A. The coins can be spent from address A by the appropriate private key for 1 year. However, after 1 year the coins can no longer be spent and the original sender is free to re-spend the coins.

If you're handing out paper wallets, just add that you'll be swiping the funds after X months if they're not used. Problem solved.

I like you thinking! If I were a teacher I give you an A (I wish more teacher would give credit for answers out side the box)

But my example was only illustrative.

But I'm still curious if the protocol (script??) supports this feature.

No. All bitcoin transactions are non reversible. The only thing you can do is spend the coins to a new address, you can't revoke them.

Edit: Just to be clear, that goes for transactions that end up in a block. As long as it's not in a block (and not sent out to the network), you can obviously choose to spend the inputs of a transaction in another one, rendering the first one invalid. But I figured you meant transactions already in a block.

nLockTime?
https://en.bitcoin.it/wiki/Protocol_specification#tx

Create a transaction spending Coin X to receiver's public adress, but do not transmit it yet. Send txOUT to receiver. (eg the output, so the receiver knows what to write in input in the next transaction with nLockTime)
Ask receiver to sign a transaction spending Coin X with a nLockTime set to 1 year and seq=0 to your adress and send to you.

Broadcast both transactions.

Now, if receiver does not spend Coin X (which is done by resending transaction with same nLockTime but seq set to UINT_MAX), coin will automatically return to you after 1 year.

If you create a bonus card or a gift card, you simply create both transactions yourself, and broadcast. If the receiver of the physical card does not redeem the card Before nLockTime expires, funds return to you.



However, I don't know if nLockTime and sequence is enabled yet in network.

Locktime and Sequence is not completely implemented in mainnet.

You can create a transaction that uses Locktime with Sequence = 0. If you try to broadcast the transaction before locktime, it will fail.
In Testnet, you are able to broadcast the transaction, and it will be included in a block sometime after locktime. Take note that the prev_outputs will be on hold, until included in a block.
I'm not sure how Sequence is implemented in testnet, there is talk about being able to replace transactions in mempool if you use a bigger Sequence number. That would enable prev_outputs to get unstuck from a broadcasted locktime transaction far in the future.

In mainnet Sequence = 0 is the only sensible value to use when specifying locktime, because there is only two possible outcomes:

• locktime have expired, broadcast is successful
• locktime is in the future, broadcast failed

If your intention is to plant very small amounts in paperwallets with an expire date, you could use ALL|ANYONECANPAY to sign every "return to sender" transactions.
That would enable you to collect every unspent output and combine them in a single transaction to save on fees.

When all transactions are signed and saved for use when locktime have expired, you can purge all traces of private keys on your system :-)

I like this idea.

Note, today you can do this by relying on a third party service (e.g. Coinbase). With Coinbase you can send BTC to someone as a gift, and if they don't claim it, it automatically goes back to you.

Handing out paper wallets is also a cool idea, but works better on the tech-savvy. Mere mortals* can use Coinbase.

*Normal people