Yesterday, Bitcoin Core developer Peter Todd posted his draft for a new Bitcoin opcode, CHECKLOCKTIMEVERIFY. This new script gives Bitcoin powerful new features and solves transaction malleability issues. In his BIP draft Todd reveals use cases for Escrow, Time-locked Refunds, Two-factor Wallets, Micropayment Channels, Trustless Payments, and more.
“Very nice,” Gavin Andresen responded on the Bitcoin-development mailing list, supportive of Todd’s request for peer review. He recommended deferring the “knock-down[sic] drag-out” deployment discussion. He stated his preference in achieving developer consensus on semantics and risk analysis. For the deployment, Todd’s update could be part of a soft or hard fork, and possibly combined with other features before making it to production.
Currently, Bitcoin can form agreements – Contracts. Though not all of these features are fully realized Todd’s code builds on one that is, nLockTime. Each Bitcoin transaction contains a lock field. The majority of transactions never use it. The lock field prevents the transaction from being mined until some point in the future. This lock means the recipient may not use those coins until that time. However, nLocktime does not prevent the coins from being spent by the original owner. Meaning there is no guarantee the locked transaction will be valid by the time it is mined.
At first that may not sound too impressive. However, the wallet service GreenAddress uses nLockTime to ensure their customers maintain ownership of their coins. Their wallet requires 2-of-2 multisig. Transactions must be signed by GreenAddress and on the client side. In the case of GreenAddress disappearing, every deposit transaction uses the lock field to ‘expire’, and the output may then be reclaimed by the depositor. Such a service could have been used by Silk Road to protect users from federal raids.
Use Cases: Advanced Escrow and Multisig
In his BIP draft Todd outlines a new escrow use case:
Alice and Bob own a business. All funds are store with 2-of-2 multisig. They recognize the risk of catastrophe, one getting “hit by a bus” thus locking the wallet forever. Using Todd’s script Alice and Bob could create a 2-of-3 transaction between themselves and their lawyer. Their funds remain 2-of-2 multisig for three months, or any time they desire. After that time passes, their wallet becomes 2-of-3 with their lawyer. Alice and Bob at any time still have 2-of-2 control. However, if something terrible were to happen their lawyer’s key could be used with Alice or Bob’s key to redeem the company’s funds once the lock expires. If time goes by and Alice and Bob are doing OK, they can move their coins and create another 2-of-3 escrow with their lawyer.
This form of escrow discourages bad actors by denying immediate access to funds. Todd also explained how his script could enhance sites like GreenAddress. CHECKLOCKTIMEVERIFY would make sure users are always able to spend their funds regardless of the service’s cooperation.
That means that it may become impossible to seize coins from websites in the future. Such a feature could certainly prevent economic catastrophes like Mt. Gox. It also means the current US Marshals bitcoin auction may be the last one of its kind in history.
It’s difficult to come up with an appropriate word to describe Peter Todd’s contributions to Bitcoin – maybe oodles will do? This recent contribution pushes Bitcoin further towards being its successor. More importantly, it elicits how Bitcoin can match the features of other vying to be Bitcoin 2.0. With continued innovations like these from the talented developers working on Bitcoin, there’s little doubt there will be plenty of competition in the future.
If you would like to support Bitcoin developers, please read this post from Jeff Garzik.
Images from Shutterstock.