Bitcoin Forum

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?

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.

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?

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?

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.

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.

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.

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.

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

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.

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.

Is this possible with Bitcoin scripting?

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

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

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:


The sub-script is


It can be spent with


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.

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.

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.

So this is solved with OP_HODL? Confirmation now, broadcast later?

It allows transactions that cant be spent yet to be confirmed

Without this assurance, to rely on an offchain signed tx, even if all is valid, leaves you at the mercy of txid malleability.

Of course, depending on whether the spend script is a conditional or not, factors like who controls the spending in the non-timelock case, is it a multisig that is funded and other factors need to be carefully designed

James

Thanks for the note. I didn't really know myself if it is actually working. Good note also on Bitcoin, my same thoughts on the matter. Don't put a big amount on Bitcoin as it's very improbable of an investment.

And sorry to hear about your loss bro.

I would be interested to hear others opinions upon whether a large set of CLTV frozen tx's could potentially cause UTXO bloat or can this concern be mitigated simply by insuring the tx's don't all "unfreeze" at the same time? Additionally, could there be any method used by a third party to conclusively confirm that a TX was indeed held for a period of time with CLTV?

I don't think bloat ought to be a problem.  Clients need to keep track of txOuts that can be spent.  So clients don't need to keep timelocked txouts in memory until it is possible for them to be spent. 

You do your full-chain verification, and you get the "live" txOut set and don't load the already-spent txOuts; with the new feature you have the power to not load the timelocked txOuts either.  You can just save them in a file, in timelock sequence, and then every 24 hours or so you read into memory just the ones that could be spent in the next 36 hours.

I'm pretty sure that the time lock feature has always been built into the protocol and thus able to be used. You can create and sign a transaction that won't be confirmable until a certain criteria has been met. There are various command line tools that can be used to build such transactions. You can then store the private key on a portable device such as a flash drive.

We routinely execute this variant of transaction as a way to initialize digital non disclosure agreements and other contractual transactions

This feature has been implemented in a javascript GUI here: https://coinb.in/#newTimeLocked