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

<ol>
<li>Create a transaction to the recipient's address spending UTXO's (unspent transaction outputs) that you own, and setting the <code>locktime</code> to the start date of your grace period.</li>
<li>Create a second transaction spending the exact same UTXO's back to an address that you own, but without any <code>locktime</code> restriction.</li>
<li>Sign the first transaction, and give it to the recipient.</li>
<li>When the grace period begins, the recipient can broadcast the transaction and receive the coins.</li>
<li>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.</li>
</ol>

<p>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 <code>locktime</code> on both transactions, but it doesn't sound like you need anything that complex.</p>

<p>See also:</p>

<p><a href="https://en.bitcoin.it/wiki/Protocol_documentation#tx" rel="nofollow">https://en.bitcoin.it/wiki/Protocol_documentation#tx</a></p>

<p><a href="https://bitcoin.org/en/developer-guide#signature-hash-types" rel="nofollow">https://bitcoin.org/en/developer-guide#signature-hash-types</a></p>

CC BY-SA 3.0
2016-05-05T14:20:33.140Z
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
CC BY-SA 3.0
2016-05-05T15:32:38.257Z
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 (https://en.bitcoin.it/wiki/BIP_0065), which could also be a solution for you.
Jestin
CC BY-SA 3.0
2016-05-05T15:37:17.670Z
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
CC BY-SA 3.0
2016-05-05T16:08:13.523Z
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
CC BY-SA 3.0
2016-05-05T16:22:22.077Z
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
CC BY-SA 3.0
2016-05-05T16:26:08.210Z
No.  It will be in the sender's wallet, but during the timeframe, the recipient has the ability to transfer it to his own.  If transferred, the sender has no ability to get it back.  To end the timeframe, the sender must submit his own transaction, spending the original UXTO.  If the sender never submits his transaction, the timeframe never ends.
Jestin
CC BY-SA 3.0
2016-05-03T19:57:38.630Z
2016-05-03T19:57:38.630Z
Jestin
<p>I would like to know if its possible to use a Bitcoin at present in the following scenario. </p>

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

<p>Can I use it like this ?</p>

<transactions><blockchain><doublespend><locktime>
Restrict the Bitcoin usage only during a particular period
jgm
# Restrict the Bitcoin usage only during a particular period

(Asked by: username_0 on 2016-05-02)

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 ?

**Tags:** transactions, blockchain, doublespend, locktime


---

## 1 answers

### Answer by username_1 on 2016-05-03. Score: 3 | Accepted answer

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:

<https://en.bitcoin.it/wiki/Protocol_documentation#tx>

<https://bitcoin.org/en/developer-guide#signature-hash-types>

> **Comments:**
> **username_0**: 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 ?  
> **username_1**: 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 (https://en.bitcoin.it/wiki/BIP_0065), which could also be a solution for you.  
> **username_0**: 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` ?  
> **username_1**: 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.  
> **username_0**: Does this mean that the bitcoin will be the wallet of the recipient during the time frame and if unspent returned back to sender ?  
> **username_1**: No.  It will be in the sender's wallet, but during the timeframe, the recipient has the ability to transfer it to his own.  If transferred, the sender has no ability to get it back.  To end the timeframe, the sender must submit his own transaction, spending the original UXTO.  If the sender never submits his transaction, the timeframe never ends.  

---

