Time Lock feature?

[WhatsBitcoin]

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.

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

[jl777]

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.

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

[gregyoung14]

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.

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.

[BitUsher]

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?

[Cryddit]

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.

[LCSociety]

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

[belcher]

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