Time Lock feature?

[Elwar]

Has the time lock feature been implemented yet? My wife passed away and she wanted the money from selling her boutique to go to her neice when she turns 18. She is 12 now so I would like to put a portion of that money in a bitcoin address I created for her and lock it until she is 18.

I understand that it is likely not in any of the clients, but does the protocol support it?

[Mike Hearn]

I'm sorry to hear about your loss.

The time lock feature has always worked. You can create and sign a transaction that won't be confirmable until the niece is 18. The bitcoinj library has a command line tool that can be used to create such transactions. The private key for the receiving address could then be put onto a USB key.

However, Bitcoin is highly experimental and anything could happen in the next few years. In your position I would only be willing to put a small amount in, and the rest would go into a bank.

[Elwar]

I'm sorry to hear about your loss.

The time lock feature has always worked. You can create and sign a transaction that won't be confirmable until the niece is 18. The bitcoinj library has a command line tool that can be used to create such transactions. The private key for the receiving address could then be put onto a USB key.

However, Bitcoin is highly experimental and anything could happen in the next few years. In your position I would only be willing to put a small amount in, and the rest would go into a bank.

Thank You. I do have the bitcoinj code so I will go that route.

I agree that putting all of it into Bitcoin over such a long time period is a high risk. I will likely combine it with gold or silver and put it in a safety deposit box or have her mother do so.

[jwzguy]

Hey Mike, when you say the transaction isn't confirmable, does that mean it won't be included in any blocks? If so, won't it drop out of the memory pools after it's a day or two old?

[Mike Hearn]

You don't broadcast it until the time lock is expired.

[Elwar]

You don't broadcast it until the time lock is expired.

So does that mean that the original client has to be running when the time lock expires, in order to broadcast the transaction?

[Timo Y]

The time lock feature has always worked. You can create and sign a transaction that won't be confirmable until the niece is 18. The bitcoinj library has a command line tool that can be used to create such transactions. The private key for the receiving address could then be put onto a USB key.

So if I understand correctly, the secure way of doing this is as follows:

1. Create transaction
2. Store signed transaction in a safe place
3. Store receiving wallet in a safe place
4. Delete private keys for sending addresses. Or empty the whole sending wallet and delete it.

[kjj]

Generate three random private keys, print them on different pieces of paper.  Calculate the public keys for them, generate a P2SH 2-of-3 multisig address from them.  Send the funds to the new P2SH address.

Next, put each key into an envelope, and give the three envelopes to three different lawyers with instructions to deliver them to her when she is 18.  Cost of having a lawyer do escrow of an envelope for 6 years should be minimal.

[grau]

Very sorry for your wife.

I believe that Bitcoin will exist and whatever is on the chain now will be there in 6 years.

Chain inclusion rules might however evolve. Since you can not get it before lock time to the chain, a transaction gets risky storage for long term, not because of the media but that there is no guarantee miner in 6 years will include it into the chain. They might e.g. consider it has not enough fee or they might no longer support that version of transaction.

[maaku]

Elwar, I'm very sorry for you loss. And I'm sorry for reviving a month-old thread, but I don't think it was clearly answered. Specifically, nLockTime does not do what you think it does. If I understand you correctly, you want to make the coins unspendable until your niece is 18, correct? This is not the function of nLockTime. Rather, you should send the coins to an offline, paper wallet, and use oldschool techniques (lawyers, trusts, time capsule, etc.) to make sure that the paper wallet containing the private key (and instructions for how to use it) come to her at the right time.

[Mike Hearn]

nLockTime can make the transaction unconfirmable until the 18th birthday, why do you think it's not capable of that?

[maaku]

It does not prevent a double spend, has the problem of keeping a node with the transaction online and broadcasting until then,  and still has the problem of safeguarding the output key until then. Confirmation now would eliminate the first two problems.

[Mike Hearn]

You don't have to keep the node online. You can just put the transaction on a usb stick and put that in a safe box.

There's no double spend risk. The goal is to ensure the recipient doesn't spend before a certain date. Why would you double spend against yourself? If you did that, it would presumably be for a good reason.

[crazy_rabbit]

Is this possible with Bitcoin scripting?

[str4wm4n]

very interested in this as well, could somebody make a tutorial?

[str4wm4n]

Is this now possible with OP_CHECKLOCKTIMEVERIFY?

[jl777]

Is this now possible with OP_CHECKLOCKTIMEVERIFY?

yes and it is live on mainnet.

you need a custom script that starts with: <timestamp> CHECKLOCKTIMEVERIFY OP_DROP <normal spend script>

where timestamp is unixtime of when you want it to be able to be spent

James

P.S. I will ask my GUI guys to add a way to send timelocked payments to iguana

[TierNolan]

Is this now possible with OP_CHECKLOCKTIMEVERIFY?

It was always possible, but yeah, now the sender can do it in a way that they can prove that they can't cheat.

The previous protocol was

- Ask the recipient to create a receiving wallet (W)
- Having them send you and address for the wallet (W_address)

- Create a private key (b)
- Generate the address for B, B_address
- Send the money to B_address (TX-AB)
- broadcast TX-AB

- Create a transaction (TX-BW) which sends the money from B_address to W_address with a locktime 6 years in the future
- Print the transaction 10 times
- Wait for TX-AB to confirm (worth waiting a day)
- Store the transaction in 10 different places
- Check that the transaction is definitely OK and did in fact confirm
- delete the private key B

At this point, the only way to spend the output from TX-AB is to use TX-BW.  You don't even need to keep TX-BW secure.  Just give it to recipient.  They will broadcast it when the locktime expires.

This method isn't secure, if the recipient doesn't trust you to have deleted the private key.

You can now use P2SH and CLTV to make it work.  It will be mined by all miners.  Once is it confirmed in the blockchain, there is no way to spend it early.

The standard script is:

Code:

HASH160 <hash160(sub_script)> EQUAL

The sub-script is

Code:

<expiry date> CLVT DROP <public key> CHECKSIG

It can be spent with

Code:

<signature> <sub_script>

None of the clients will be able to understand it though, since they only see hash160(sub_script).  The client would have to have a list of addresses to watch for.  This would be a change of the wallet format and that is very risky.

[DannyHamilton]

You don't have to keep the node online. You can just put the transaction on a usb stick and put that in a safe box.

I'm not sure that I'd trust a "USB stick" to store valuable data for more than a few years.  I'd be really concerned about trusting it for more than five years.

I'd be quite tempted to store the transaction written on paper along with the USB stick just in case the USB stick wasn't readable in the future.  I'd probably do the same thing with any private keys that might need to be stored that long.

[TierNolan]

I'd be quite tempted to store the transaction written on paper along with the USB stick just in case the USB stick wasn't readable in the future.  I'd probably do the same thing with any private keys that might need to be stored that long.

The transaction doesn't have to be kept secure anyway.  Printing it out multiple times and store it in lots of places.  The transaction would be around 200-300 bytes, so no big deal.  That could be encoded as a QR-code but easiest would be basic hex encoded.