As Bitcoin trickles into the mainstream, it’s easy to forget that it is still in Beta. The source code is constantly evolving with daily updates to the development repository, which has helped make it the most successful decentralized value store and immutable record that we have ever encountered. These updates range from minor changes, such as syntax and documentation updates, to major fixes that affect Bitcoin’s functionality.
Major development proposals are formulated into BIPS, or Bitcoin Improvement Proposals. BIPS are formal proposals to change how Bitcoin will function by making modifications to the code base. BIPS consensus is determined by developer approval, unit tests, and exploration of possible edge cases.
Sometimes there are competing implementations proposed to solve similar or identical issues, like the decision to implement P2SH, where the pros and cons must be weighed to choose the best candidate. On one hand the lengthy process of accepting new BIPS stalls Bitcoin progress, but with open-source development, it is best to seek the input of all contributors and perform rigorous testing to establish stability and security throughout the codebase, which helps avoid potential risk to users.
BIPS often start from a discussion on the developer mailing list or on Github. Such discussions are what inspired Peter Todd, a long time contributor to Bitcoin core and related projects, who is currently working towards getting his proposal, BIP 65 titled: OP_CHECKLOCKTIMEVERIFY, accepted. The proposal suggests adding an additional opcode, which is a function or command in the Bitcoin scripting language.
- Peter Todd
Functionalities like multi-signature addresses are examples of opcodes processed by miners solidifying Bitcoin as programmable money. The idea was formulated out of the limitations of nLockTime, a transaction parameter that specifies the minimal amount of time that must pass in either Unix Time or blockheight before a transaction can be included in a block. As of December 22, the functionality of BIP65 has also been implemented into an altcoin named Viacoin, which Peter Todd acts as an advisor and chief scientist for.
BIP65 would allow users to specify the time that a transaction can be spendable, in blockheight or unix time, as well as add additional parameters, such as requiring a specific combination of key signatures. BIP65 has a number of use cases, including Escrow, Non-interactive time-locked refunds, Two-factor Wallets, Micropayment Channels, Trustless Payments for Publishing Data, and Proving sacrifice to miners' fees, which are detailed further in the proposal for those that wish to delve deeper into the technical explanation and see code examples.
Similarly to nLockTime, the proposal of BIP65 would allow users to set a time limit in which funds become spendable but with more flexibility. For instance, BIP65 can be used with a multi-signature escrow output with instructions specifying the time and combination of keys needed to release the funds. To give you an example, think about this in terms of inheritance. Suppose two parents give their child 10 BTC and send it to a multisignature address with 3 signatures. Mom and Dad each have an individual private key, and the child has a private key. In order to make the funds spendable, Mom and Dad must both sign the transaction.
Any other combination of two (the child and the mom or the child and the dad) will not unlock the funds. However, once a certain amount of time passes, say a year, the child can release funds with either parent’s private key. The additional functionality of BIP65 protects the funds from being spent prior without permission of both parents, and in case of a disaster, only one parent is needed to release the funds.
Adding new functionality directly into the Bitcoin code base is a long process because it takes time for developers to agree, feedback has to be taken from the community, and significant testing must pass before implementation. Of the many changes proposed overtime, some require a hard fork.
An entertaining read is the Hard Fork Wish List, which details what developers might change if they could forego the hassle and risk of a hard fork. Someday we may see a hard fork, but since the BIP65 functionality can be included in a soft fork (requiring only majority acceptance by miners), it has a much greater chance of succeeding.
There are many nuances and details behind major Bitcoin proposals. Luckily, we had a chance to interview Peter Todd to learn more about BIP65 and how it would affect Bitcoin’s functionality.
Gavin Knight: How did the idea for CHECKLOCKTIMEVERIFY first arise?
Peter Todd: The funny thing about CHECKLOCKTIMEVERIFY is it's often been described as ‘What you thought nLockTime did until you tried to use it’ - it's the way you'd expect transaction time locking to work, when in reality it works completely differently. So I can't really claim credit for the basic idea.
GK: How do you think this functionality will be used?
PT: While the easiest to understand use-cases for the "layman" are things like "lock a child's university funds until they're 18" what's actually really exciting is the "under the hood" applications for financial protocols. Micropayment channels are a great example. Basically they let you send small amounts of money to another party repeatedly over a period of time, turning what would be hundreds, even thousands, of tiny transactions into one.
Where this gets really exciting is the hub-and-spoke model: If Alice, Bob, and Charlie all have micropayment channels with a shared hub, they can effectively send money to each other instantly and trustlessly by sending a small amount to the hub; and having the hub in-turn resend it to the final destination. This enormously increases the scalability of Bitcoin as all these transactions happen off the blockchain, yet the hub never actually has control of the money.
The way micropayment channels will work with CHECKLOCKTIMEVERIFY is 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 ensure that if the receiver vanishes, the funds eventually "unlock" so only the sender needs to sign, letting them get the money back.
There's other ways to do this too with pre-signed refund transactions, but they're all insecure and complex due to transaction mutability; CHECKLOCKTIMEVERIFY makes the protocol simple and robust.
GK: Can you describe the consensus process of the Bitcoin developers on a BIP?
PT: The closest example is the P2SH/OP_EVAL/OP_ CHECKHASHVERIFY soft-fork, which saw three competing proposals from roughly two groups for how to make multisig - and other applications - more viable. What's interesting about that prior example is how political the whole process became - Gavin Andresen strongly wanted the upgrade to happen in very little time, citing potential security improvements as the reason to upgrade. Each of the proposals had different trade-offs advantaging and disadvantaging different applications. Predictably "vigorous debate" ensured.
The other big problem with that soft-fork was in the end no-one actually wrote any demo applications for the new feature; it took about two years after the network was upgraded for applications using it to start popping up. When those applications were written a bunch of serious limitations of P2SH - the chosen solution - were found.
I'm hoping that we'll see people write demos using CHECKLOCKTIMEVERIFY before the soft-fork, not after, so we can prevent this mistake happening again. Secondly it also helps that unlike P2SH there isn't much room for alternate designs - we have much more consensus that
CHECKLOCKTIMEVERIFY is the simplest way of doing what it does.
GK: What potential risks could a soft fork pose if this were to be implemented using one?
PT: The feature itself may have a bug in it. However it's implemented in about five lines of easy to review code, so that's a relatively small risk. The bigger risk is to miners: during and after the upgrade it's possible that non-upgraded miners could create invalid blocks accidentally, losing the funds associated with those blocks. However Bitcoin Core includes protections against this - partly written by myself - that mostly ensure old miners are forward compatible with new miners by ensuring they'll never mine blocks containing transactions with opcodes reserved for upgrades.
Finally, if non-upgraded miners do on occasion produce invalid blocks it could trick some SPV [Simplified Payment Verification] clients into thinking a transaction is confirmed when it actually isn't; SPV clients do no real validation of the blockchain and thus trust miners to validate for them.