Bitcoin Forum

I'd like to start a thread about this. So sue me. :-X

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki


Abstract

This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin scripting system that allows a transaction output to be made unspendable until some point in the future.


Freezing Funds

In addition to using cold storage, hardware wallets, and P2SH multisig outputs to control funds, now funds can be frozen in UTXOs directly on the blockchain. With the following scriptPubKey, nobody will be able to spend the encumbered output until the provided expiry time. This ability to freeze funds reliably may be useful in scenarios where reducing duress or confiscation risk is desired.

supcoin - https://github.com/supcoin/supcoin/commit/81e19c1b93da202479dfcb9eb84d7fd89c9db599

viacoin - https://github.com/viacoin/viacoin/pull/23

ziftrcoin - https://github.com/ZiftrCOIN/ziftrcoin/commit/42c932f50313a59cb1791e186417116fd71516d6

see also https://github.com/ElementsProject/elements/tree/checklocktimeverify

“how” is embodied in the source; I'm not in a position to comment on “why”.


Cheers

Graham

U would like to have some sort of safeguard key to unfreeze my funds.. Imagine locking the coins for 100 years instead of 10 years... :p

Thought the same thing. Have not read any of the technical details yet so not sure whether such an option is available or not. If not then this can be a very risky thing to do. Not just for fat finger problems like you describe but also if things change i.e. you might want to lock in some coins for your kids but things can change over time resulting in you having to unlock said coins.

I think a good ol password is better. With the password you can take the decision to spend them or not. Even with the benefit of forcing you to hold long term so you can become rich, i still don't like the idea of not having the option to hold with my own will. I don't like this feeling of "being forced to hold" so to speak.

it could be better if it was time based and you just need your private key that are holding the funds and nothing else

let's say that you want your fund to be available in one year at most, because you have a desease that will kill you in a short time

Imagine sending 50BTC with a 0.001BTC fee, and you end up sending 0.001BTC and a 50BTC fee... ;)

I don't know if it is possible to have a safeguard, but something like that would invalidate/wouldn't be more secure than a password in what concerns fund security, theft could still occur, and the fear of having funds confiscated would still be present.

Imagine you're taking a one month trip, and you want to make sure nobody touches your funds... If the safeguard key was found, funds could be spent anyways.

You can use http://coinb.in/#newTransaction.

GreenAddress online wallet use this nLockTime feature to secure users' funds.

Yea but thats a poor version of it, With that you can only make it so that the TX is stored on that website and they will broadcast it later, but the TX is already made.

So perhaps you can delay it, but if you send another TX before that, it will be invalid after. Because you need all outputs/inputs to make a new TX.

Sorry. Both GreenAddress and Coinb.in uses nLockTime not OP_CHECKLOCKTIMEVERIFY.


You are wrong. You can get the time locked transaction(s) both to your email or from the transactions details and you can broadcast it yourself if you want. For making broadcasting easy, they have made a website -- http://greenaddress.github.io/gentle/. You can download that website from Github so that you can redeem even when the website is down. https://github.com/greenaddress/gentle


No. OP_CHECKLOCKTIMEVERIFY will make other transaction(s) which spend the same input invalid.

P.S. If you are wondering the difference between nLockTime and OP_CHECKLOCKTIMEVERIFY, see

Wow... so what happens when this OPCODE is implemented and you receive coins you cant spend? I guess not all wallets will be updated to show that.

And what happens when a miner doesnt know this opcode and implements the transaction in a block? Would the block become invalid by the nodes?

Sounds risky and without matching advantage.

You won't receive locked coins. ::)


Transaction is invalid, so the block will be invalid.

Then when is that opcode implemented? I think opcodes can only be implemented in a transaction. Which means you actually have to send a transaction. Or is there some failsafe that only allows to send to the same address? Would still sound exploitable.


Sounds like a risk to miners. I believe there are not few miners that dont follow the latest updates so close that it could not be a problem.

Opcodes are added in transaction script (https://en.bitcoin.it/wiki/Script).  Script decides how the next person wanting to spend the Bitcoins being transferred can gain access to them.*

I think I misunderstood your question. I thought you asked what if a user receives locked Bitcoin. No person would receive locked coins. To answer your question: the coins will be locked until preset time has reached. After that, the person will be able to spend those coins.

* Line from Bitcoin wiki.


Majority of miners need to use version that supports this opcode for acceptance and enforcement. If majority uses new version, obviously, others will (eventually) update their clients for incentive. CMIIW.

Useful links:

 • http://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork
 • https://bitcoin.org/en/developer-guide#term-soft-fork
 • https://en.bitcoin.it/wiki/Softfork
 • https://en.bitcoin.it/wiki/Script
 • https://bitcoin.org/en/developer-guide#consensus-rule-changes
 • https://bitcointalk.org/index.php?topic=945977.0

Thanks for your help. You have a habit in this. ;)

So you say its really part of a transaction and can bind the coins that might be owned by a seller then.

What i would like to know, cant this be used to scam someone? Its not like a chargeback would be possible. But it sounds dangerous. I mean i surely dont want to receive coins that i find out, cant spend till 2017 or so.

You should have told the payer not to do so. If the payer insisted to do so without your consent, he breached the contract and you (as merchant) should not deliver the product.

With P2SH, a CLTV address will look like an ordinary bitcoin address (starting with 3). Therefore, in your example, the payer actually deliberately sent the bitcoin to a different address.

Fat-finger trading is not uncommon even in traditional stock market and cost millions or billions dollar of loss. However, safeguarding should be done in UI (wallet) level, not in the underlying protocol.

Normally the addresses with 3 are multisig addresses. Do you say that the opcode is solving itself at one point in time because the time is somehow delivering the second key to spend the address? Then locking coins with the opcode only works when sending them to special bitcoin addresses that were created that way? A merchant does not have to fear anything then?

There is no restriction with the content of those "3" addresses. Multisig is the most common use case but it's simply common and we can do many fancy things with "3" addresses. CLTV is an example.

If the payer tries to manipulate the CLTV settings, it will become a different "3" address so the merchant is not mandated to honor the payment. Consider the following conversation:


So yes, the merchant has nothing to fear.

*lol* Ok. Then i think i understood it correctly and there is no risk involved at all. The usecase is only for someone who owns the private key of the receiving address. No possible risk involved.

Thanks for explaining!

No one can use this with bitcoin right now, until 95% of miners support it.

An example from https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Escrow

If Alice and Bob jointly operate a business they may want to ensure that all funds are kept in 2-of-2 multisig transaction outputs that require the co-operation of both parties to spend. However, they recognise that in exceptional circumstances such as either party getting "hit by a bus" they need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny, to act as a third-party.

With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer not to have immediate access to the funds to discourage bad actors from attempting to get the secret keys from him by force.

With CLTV, they may set the following rules for spending the funds:

• At any time the funds can be spent by Alice's and Bob's signature
• 3 months (or other specified time) later, the funds can be spent by Lenny's signature and one of Alice's or Bob's signature

If Alice is hit by a bus, Bob can get the money back 3 months later with Lenny's help.

It is almost ready to start the miner voting, but it will still take a few months until we have enough miner support

Nice! I didn't know bitcoin can do something like that. Things like that should be propagated more. Only when bitcoiners know about these things they can solve problems and show that bitcoin is attractive.

Does anyone know if there's testnet functionality to try this out? Or even just a single TxID on testnet I can refer to (EDIT: or if not Bitcoin testnet, what about an altcoin?)

It should be possible by running the latest bitcoin core from github under regtest.

https://github.com/viacoin/viacoin/pull/23

https://github.com/ElementsProject/elements/commits/checklocktimeverify


Cheers

Graham

CheckLockTimeVerify (CLTV) has been merged into Bitcoin Core.

https://bitcoinmagazine.com/articles/checklocktimeverify-or-how-a-time-lock-patch-will-boost-bitcoin-s-potential-1446658530

Perhaps would have been more useful to hold off commenting on the merge until the release, which will be in a couple days.

Old news, and there is nothing for people to do about it yet. Making noise about it now will only slow deployment, because you'll expend people's attention when there is no action for them to take. :)

Does "expending people's attention" amount to "violence"?

It's official. It's released. Huzzah!

https://np.reddit.com/r/Bitcoin/comments/3snpg9/bitcoin_core_version_0112_released_bringing_the/

https://bitcoin.org/en/release/v0.11.2

This is a nice feature!
good work!

Deployment Status:

https://www.reddit.com/r/Bitcoin/comments/3sx4wd/bip65_deployment_status_at_26_remind_your_mining/

It's now been activated at >75% penetration so now for someone to send the first transaction using it...

I'm eagerly awaiting the use of this for the first cross-blockchain transaction between bitcoin and an altcoin.  Should be pretty momentous if it sets the standard for decentralised trade without using exchanges. 

This is a good step forward.  With this and a few other BIPs in progress, the number of use cases will increase dramatically. 

Why are you so sure? Nobody on network uses this feature today. No-bo-dy.

Here's what's funny about all this. I started this thread in Beginners and Help; then a moderator moved it to Bitcoin Discussion; then another moderator moved it to Technical Development; then Gmax told me to stop talking about it.  :-X



I think it's a necessary feature for future payment channels?

I think it is. As far as i read it is one of the steps needed for every deposit in a payment channel. Just in case the other party vanishes.

Though it's interesting to hear that it is not ready yet. I guess that means that the lightning network can't come online as long as it isn't available.

Maybe the devs work on segwit, which in fact would be the more important step for now.

How would you know? It's a new feature but it has some use cases. I think it's good to have it around for whoever feels like there's need to.

Isn't is difficult to count the number of OP_CLTV operations in blocks for the day or for the week?

The public does not know whether the redeemScript involves OP_CLTV until they're redeemed. If somebody locked up funds for 10 years you wont know until 2026 when they spend them.

more than 10% (http://p2sh.info/dashboard/db/p2sh-statistics) of all bitcoins are held in p2sh addresses, so the upper bound of OP_CLTV usage is quite large.

Excelent.

redeemScript is known for most of them. Yes, there are addresses without spending transactions. But it is possible to hodl funds on such address till 2026 without OP_CLTV - just not spend funds :)

The Darkleaks protocol has three major shortcomings/vulnerabilities that appear to stem from fundamental functional limitations of Bitcoin’s scripting language when constructing contracts without direct communication between parties. That these limitations are fundamental is evidenced by calls for new, time-dependent opcodes. One example is CHECKLOCKTIMEVERIFY; apart from its many legitimate applications, proponents note that it can facilitate secret leakage.*


Fixed. Thanks Core. ;)




*Source: Using Smart Contracts for Crime
Ari Juels
Jacobs Institute, Cornell Tech
juels@cornell.edu
et al.

I'm not sure if I understand much of the technical gobbledy gook of this thread;however, I do find this to be a very interesting concept that could potentially turn western common law practices on it's head in a variety of ways.

Well, yeah, bitcoin already does that; however, in this thread we seem to be referring to the possibility of creating a contract that initially may be within the control of the creator(s), but could be written in such a way that it falls out of the control of the creator(s), and thereby becomes executable upon the meeting of various conditions at some point in the future.

If I understand correctly, in western common law, no contract controlling the disposition of property (or assets) (frequently applicable in the area of wills and trusts) can be valid if it violates the rule against perpetuities.

https://en.wikipedia.org/wiki/Rule_against_perpetuities


In summary, a contract needs to be created and under the control of human beings and no longer than a measuring life plus 21 years in order to free up the title.. blah blah blah.  The idea is that there is a societal value that property and assets remain controllable by living persons (rather than potentially completely controlled by someone who has been dead more than a measuring life plus 21 years (which may last 100 or more years).

If contracts are able to be created to tie up such property for longer periods of time, and neither the state nor any person has control of such tied up property, that could lead to very interesting difficulties and changes in the way we view certain kinds of property.. and ability of dead people to control property from their earlier execution of a contract that no longer can be controlled by anyone, including the state.

I do recognize that there are a lot of valid uses, and even that this whole technology could be very innovative and good, if the contracts are written well and people do not realize later that they fucked up the language of the contract and tied up the assets for a longer period than they had originally intended. 

I would only argue that it could be a bad thing in the sense that it does have the potential to tie up property for very long periods of time and beyond any kind of reasonable period that any living people could want, when the contract may have been created by someone who either loses control over it because of death or wrote in a mistaken way that causes the property to be tied up and therefore outside of the control of people (which ultimately, in my view, should be the beneficiaries and able to control actual assets in the real world within reasonable periods of time after the creation of such contracts)

Welcome to the thread, JJG! It'll be a brave new world, with such smart contracts (https://bitcointalk.org/index.php?topic=1362964.msg13884001;topicseen#msg13884001) in it. That's for sure. I'm excited. :)

Suggested reading: Cryptocurrencies, Smart Contracts, and Artificial Intelligence (https://steveomohundro.com/2014/10/22/cryptocurrencies-smart-contracts-and-artificial-intelligence/)

The legal codes of many countries have become quite complex. Several AI projects are trying to create formal digital versions of legal codes (CodeX, 2014). These systems will eventually be used to resolve legal issues and perhaps even act as arbitrators or judges. Sophisticated AI systems with knowledge of the legal system will be used to help craft and simplify new legislation.



 :o