Scalability is a hot topic in the bitcoin world right now. The rising number of btc transactions keeps moving us toward the point in which transaction volume will become a problem for the network. The debate on whether to increase the maximum block size to combat this issue is ongoing -- more on that in Gavin Andresen’s scalability roadmap and Hearn’s commentary, among others. Decentralization is key for bitcoin, and one of the primary arguments against increasing block size is that it could lead to increased centralization of the network, where only certain nodes would be able to participate. Losing that trustless, distributed nature would be crippling to the protocol.
Bitcoin allows multiple parties who lack trust in one another to transact digitally without needing a mutually trusted third-party arbiter, but when the additional layer of complexity related to time is introduced into the equation, this becomes challenging to do cryptographically. That’s why often the default solution is to look to a previously agreed upon third party to serve this function. In some instances though, if you need a third party, you’re not much better off than you were before the bitcoin protocol even came about. For those of us who would rather trust math than people, this isn’t ideal.
Core developer Peter Todd has proposed a solution in BIP 65, which describes a new opcode, OP_CHECKLOCKTIMEVERIFY. CHECKLOCKTIMEVERIFY was merged just a couple days ago, and Todd plans to put out a concrete soft fork proposal shortly. Since its inception, BIP 65 has been met with almost unanimous agreement from the community, as Jeff Garzik tweeted in November 2014. The idea underlying BIP 65 is not new. Todd himself has mentioned that it’s often been defined as ‘What you thought nLockTime did until you tried to use it’. What it is, instead, is both more secure and more flexible than what currently exists.
nLockTime is a parameter that can be attached to a transaction that specifies the minimum amount of time (blocks or unix time) before which a transaction cannot be included into a block. One of the main problems with nLockTime derives from concerns about double spend attacks. Right now, time locked transactions are not included in a block until the time lock has passed. However, there is nothing preventing the owner of the private key from simply creating another transaction (without nLockTime specified) spending the funds before the time lock expires.
CHECKLOCKTIMEVERIFY instead compares the nLockTime in the script to that of the most recent block, and if that time has not elapsed yet, flags the spending transaction as invalid. The script locks the output and the funds cannot be spent elsewhere, effectively eliminating any double spend concerns. It would be impossible for Bitcoin to take hold as a platform where escrow, insurance, and other related services matter if double spends can occur. For that reason alone CHECKLOCKTIMEVERIFY is a substantial upgrade over nLockTime, but it’s actually useful from a structural, scalability perspective as well.
One of the benefits of BIP 65 is that it enables a lot of transactions to happen off blockchain and only later be combined into one, therefore substantially decreasing the load on the network. This is also useful in lowering costs, because it enables near-zero fee transactions. In a micropayment scenario for instance, payment channels can be extended from an untrusted hub to any number of parties. Each payor then sends funds to the hub, which then pays the payee.
There are a number of ways in which this could work using CHECKLOCKTIMEVERIFY. Todd described such one way in an interview with CoinTelegraph: “the sender first sends an upfront deposit to an address controlled by both the sender and receiver. Each "payment" is then just a half-signed transaction sending the money from that address to the receiver, with more money signed each time. When the session is finished the receiver signs the most recent transaction.” CHECKLOCKTIMEVERIFY is then used to guarantee that if the receiver disappears, the bitcoin eventually "unlock". At this point only the sender needs to sign, so they are able to retrieve the funds.
In addition to micropayment “hub-and-spoke” scenarios, there are many other use cases: lock a trust fund until a kid turns 18, enable a landlord and tenant to hold deposit funds in escrow, and so on. At its core though, BIP 65 enables the network to scale while staying close to its original foundations. While it will likely end up being necessary to increase the block size anyway, BIP 65 can play a substantial role in mitigating the problem.