Flexible smart contracts are a USP of Ethereum and other blockchains. Currently, Bitcoin only enables basic smart contract functionality, such as a timelock that specifies when a transaction can be spent. BIP 119 proposes to add more flexibility for applying restrictions to transactions via a new programme operation code (opcode) called CheckTemplateVerify (CTV).

CTV would enable conditions on spending UTXOs that would limit, not when they are spent, but how. These are referred to as “covenants”. It is envisaged CTV could significantly enhance Bitcoin by enabling a raft of new and powerful applications to be developed; these could bring new security, privacy and scalability benefits.

The concern is that CTV is a significant change and could open up potential unknown security risks, or that if this functionality is desirable, it could be possible be better achieved with a different technical approach

BIP119 has been authored and enthusiastically promoted by Bitcoin developer, Jeremy Rubin. It has been around now for 2 years, and whilst Rubin has generated support for BIP119, he has also faced criticism from prominent Bitcoiners for his approach and so far there doesn’t seem to be consensus among the protocol development community on implementing the proposal.

The consideration, approval and activation of changes to Bitcoin are methodical and slow. Further, such changes normally involve the development of competing ideas, and a collaborative approach to combine the best elements from these efforts. Notable critics feel that BIP119 is being too forcefully promoted and that more time is needed to test and consider alternatives.

The pressure to innovate will always be there. The issue at hand is Bitcoin’s USP: it has never been hacked. This has been hard-won. So it seems BIP119 isn’t going to get a formal consensus at the moment. Rubin, however, could bypass the Core developers and implement a UASF. Could we again be about to test the limits of Bitcoin’s rough consensus process?