Potential Bitcoin Feature ‘CHECKLOCKTIMEVERIFY’ Makes Smart Contracts Smarter

One of the core Bitcoin devs, Peter Todd, posted a draft yesterday describing a potential Bitcoin feature that enables some exciting new decentralized possibilities. The feature, which extends the limited “smart contract” scripting system built into Bitcoin, is called “CHECKLOCKTIMEVERIFY” and builds upon an existing feature called “nlocktime.”

“Nlocktime” is a feature that makes it possible to instruct miners to delay adding a transaction into the block chain until an specified date in the future. Thus, a party can agree to a transaction but place it on hold until a specific future date, allowing them both to withdraw their money and cancel the transaction before it actually goes through, if the need arises. This can be used to create “dead man’s switches” in the event that one party in a transaction ceases to exist, to provide an automatic refund. This could have been used, for example, by the Silk Road to protect clients’ funds from seizure by the FBI. GreenAddress, a secure hybrid web wallet, uses transaction locking in this fashion.

The extension to that functionality is to alter the number of nature of parties in a transaction after a specified date – which allows for more sophisticated scenarios, particularly when combined with multisignature wallets. For example, a transaction can be designed such that, when a time limit is reached, an additional party is involved, allowing the money to be withdrawn via an external adjudicator. This could, for example, help to avoid situations in which several parties in a smart contract are all deprived of their stake because of of the secret key-holders died unexpectedly, permanently locking the wallet in question. The script in question might look like this example, from the draft:

  IF
<now + 3 months> CHECKLOCKTIMEVERIFY DROP
<Lenny’s pubkey> CHECKSIGVERIFY
1
ELSE
2
ENDIF
<Alice’s pubkey> <Bob’s pubkey> 2 CHECKMULTI

Integrating this sort of broad new functionality would likely require a hard fork of Bitcoin, though Gavin Andresen asked on the mailing list to delay discussion of deployment and rollout for the time being, saying:

“Very nice, semantics are clear and use cases are compelling. Can we defer discussion of how to roll this out for a little bit, and see if there is consensus that

a) benefits of having this outweigh risks

b) we’re all happy with exact semantics

Then we can have a knock-down drag-out argument about whether it should roll out as a soft fork, wait for a hard fork, be combined with some other things that it would be nice to add or change, etc…..”

The full draft is interesting and worth reading, and you can peruse it at Todd’s Github here.