I would like to know if its possible to use a Bitcoin at present in the following scenario.

When I send a Bitcoin to an another user,I set certain parameters on the Bitcoin, like it can only be used from this particular date to an another particular date. And restrict the usage of Bitcoin if its being used some other time.

Can I use it like this ?

1 Answer 1


This can be accomplished with a simple smart contract between you and the recipient using a transaction's locktime. Here are the steps:

  1. Create a transaction to the recipient's address spending UTXO's (unspent transaction outputs) that you own, and setting the locktime to the start date of your grace period.
  2. Create a second transaction spending the exact same UTXO's back to an address that you own, but without any locktime restriction.
  3. Sign the first transaction, and give it to the recipient.
  4. When the grace period begins, the recipient can broadcast the transaction and receive the coins.
  5. When the grace period is over, sign and broadcast the second transaction. If the first transaction has already been broadcast, it will be invalid and not relayed or included into a block. If the first transaction has not been broadcast, then you will want to reclaim the coins, thus invalidating the first transaction.

This plan assumes that you are in control of the second transaction and paying attention, such that you remember to broadcast the second transaction. It also assumes that the recipient trusts you to respect the grace period, and not broadcast your transaction until the time is up. Problems like these could be solved with a more complex scheme involving multi-sig transactions and setting locktime on both transactions, but it doesn't sound like you need anything that complex.

See also:



  • I have a doubt regarding the second transaction. What if I make a second transaction at the same time of the first and set the locktime as the grace period ending. And I will broadcast both the transactions. So when the grace period starts the second person can use the bitcoin and at the end of the grace period, it will be directed back to me. Will it work ?
    – jgm
    Commented May 5, 2016 at 14:20
  • The problem is that if locktime is set, yet the time period is not up, you nodes will not relay the transaction. It prevents the transaction from being included in a block. Miners and full nodes would have to store your transaction in their mempools until it is allowed in a block. Remember, only one of the two transactions will ever be included in a block, since they both use the same UTXOs as input. I think you are confusing locktime with BIP65's OP_CHECKLOCKTIMEVERIFY (en.bitcoin.it/wiki/BIP_0065), which could also be a solution for you.
    – Jestin
    Commented May 5, 2016 at 15:32
  • I want some thing like this, the second person should possess the bitcoin only for a certain period of time and return the bitcoin to the sender , when the time is up. Would it be possible with locktime ?
    – jgm
    Commented May 5, 2016 at 15:37
  • The contract I outlined above gives the recipient the ability to transfer the bitcoin to themselves for a limited amount of time. They have no obligation to return any portion to the sender. If unspent, it gets returned by an action of the sender. The Bitcoin network doesn't allow you to hand a transaction off to full nodes/miners for them to store and mine at a future time. In other words, you can't use it to automate a future transaction, but you can use it to guarantee that a future transaction won't take place until a certain time. You will still be in charge of initiating.
    – Jestin
    Commented May 5, 2016 at 16:08
  • Does this mean that the bitcoin will be the wallet of the recipient during the time frame and if unspent returned back to sender ?
    – jgm
    Commented May 5, 2016 at 16:22

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.