Peter Todd and Gregory Maxwell submitted BIP65 at the beginning of October. The proposed change attempts to improve the network's behavior in handling "locked transactions", by introducting a new opcode OP_CHECKLOCKTIMEVERIFY. Yesterday, Jeff Garzik sent out a tweet hinting the protocol improvement may be approved relatively soon:

"Greg Maxwell and @petertoddbtc's CHECKLOCKTIMEVERIFY meeting near-universal approval: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki . #bitcoin #SmartContracts"

A feature in the Bitcoin Protocol, a small variable occupying the last 32 bits of a transaction named nLockTime, allows users to lock a transaction's validity until a future block height or UTC timestamp is reached. In theory this allows users to send Bitcoin transactions in the form of a basic time delay trust, with the Blockchain serving as the trustee. The system implemented in its current state does not allow for transactions containing a future nLockTime to be mined into a block until the lock time passes – the transaction sits in the mempool of full nodes on the network. Due to miners not including this type of transaction into a block, a user can spend the inputs of the locked transaction with a non-time-locked transactions, effectively making the recipient of the locked transaction the victim of a double spend attack.

When used as part of an output script the new opcode OP_CHECKLOCKTIMEVERIFY checks if the original transaction's nLockTime is larger than the most recent block, and if true the network deems the transaction invalid. This script locks the output of a transaction, preventing them from being spent in a future transaction unless a certain duration has passed.

OP_CHECKLOCKTIMEVERIFY would replace the current NO_OP2 opcode, and would require a softfork to release. The change is theoretically backwards compatible, and requires miners to run software that implements the new protocol feature.