Topic: Time Lock feature? (Read 3439 times)

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

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

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 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?

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.

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

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

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.

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.

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.

yes and it is live on mainnet.

you need a custom script that starts with: CHECKLOCKTIMEVERIFY OP_DROP

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

Is this now possible with OP_CHECKLOCKTIMEVERIFY?

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

Is this possible with Bitcoin scripting?

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.

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.

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

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.

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.

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.