{"id":9306,"date":"2022-05-20T15:47:22","date_gmt":"2022-05-20T15:47:22","guid":{"rendered":"http:\/\/ci02a1a70ba0002709"},"modified":"2022-05-20T15:47:22","modified_gmt":"2022-05-20T15:47:22","slug":"what-is-bip-119-bitcoin-controversy-explained","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/what-is-bip-119-bitcoin-controversy-explained","title":{"rendered":"What Is BIP 119 And Why Did It Fuel Such Heated Discussions In Bitcoin?"},"content":{"rendered":"
<\/div>

It\u2019s been hard to ignore the discussion around CheckTemplateVerify (CTV) over the past few weeks as it has apparently been generating a divide in the Bitcoin community with developers, users and companies taking sides on whether the activation of the proposed upgrade would be a net positive or negative to the network.<\/p>\n

Amid the discussion, however, many misconceptions surfaced on what CTV actually is and what it can and cannot do. Therefore, an easy-to-follow explanation is in order to clear up misconceptions before diving into the details of the recent debate.<\/p>\n

What Is CTV? Clearing Up Misconceptions<\/h2>\n

CTV was first proposed in May 2019 under a different name. At the time, the proposal, coined CheckOutputHashVerify<\/a>, focused on enabling congestion control on Bitcoin \u2014 a technique that lets multiple payments be sent and confirmed to many users without burdening the blockchain until a later time. It also enabled other use cases, however, including vaults. In the following month, the proposal was refined after feedback was received and it was renamed to SecureTheBag<\/a>. Later that year, it was again improved and renamed<\/a> to CTV.<\/p>\n

CTV is a proposal to improve Bitcoin through a soft fork, a type of upgrade that ensures that nodes that choose not to update can still participate in the network as long as a majority of hash power enforces the new rules. It is specified in Bitcoin Improvement Proposal (BIP) 119<\/a>, where its author, Jeremy Rubin, lays out its design and reasoning as well as some use cases the proposal could enable.<\/p>\n

CTV allows a user to restrict where they can spend some of their own bitcoin (beyond private key ownership or timing rules such as in the case of a timelock), a setup known as a covenant. Although this seems contradictory and against Bitcoin\u2019s ethos of sovereignty, there are instances where restrictions on where bitcoin can be spent can be desirable.<\/p>\n

Who Could Restrict How You Spend Your Bitcoin With BIP 119?<\/h3>\n

A third party would not be able to restrict how you<\/em> spend your<\/em> bitcoin if CTV gets added to the network. Rather, the proposed soft fork allows spending conditions to be restricted only by the party receiving the bitcoin<\/a>. <\/p>\n

This actually ties back to the way Bitcoin fundamentally works: the party receiving bitcoin is the one to determine the conditions for spending those funds next \u2013 and not the sender. <\/p>\n

The way it works is the receiving party constructs an address that embeds some information and sends that to the sending party. At the very least, this information lays out the conditions someone needs to satisfy in order to spend that bitcoin. Since the receiver is the one to define the information used to construct the receiving address, only the receiver can define the spending conditions necessary to spend that bitcoin after it gets to that address. The process of satisfying those spending conditions is commonly known as \u201cunlocking\u201d that bitcoin output.<\/p>\n

This information in the address could also define how many signatures are necessary to unlock the bitcoin funds in that address (multisignature) or how long one needs to wait before being able to unlock those funds (timelock).<\/p>\n

Therefore, today, most of the restrictions the receiving party can define relate to conditions for unlocking the bitcoin. But after those conditions are satisfied and the bitcoin is unlocked, the user is free to spend it to any address they want in nearly any transaction they can think of.<\/p>\n

With CTV, the user constructing the address would be able to add more information necessary to be satisfied to spend that bitcoin \u2014 information that would let the user restrict where the coins can be sent to after the correct signature is provided. In other words, the user can programmatically define in advance what transactions will be able to spend the bitcoin in that address. <\/p>\n

What Could BIP 119 Bring To Bitcoin?<\/h3>\n

CTV enables vaults, which could limit withdrawals out of cold storage to pre-specified addresses in predetermined amounts. In practice, this could allow a user to configure how much BTC they want available for removing out of their long-term savings within a given time frame and to which addresses. <\/p>\n

For example, the user could determine that no more than 0.1 BTC can flow out of their vault and into their hot wallet per week. This setup would limit losses \u2013 through the transfer limits \u2013 in case an attacker managed to get control over the user\u2019s cold storage wallet private keys. Without a vault, having the private keys would allow the attacker to sweep all of the user\u2019s funds at once.<\/p>\n

Beyond vaults, CTV has other interesting applications as well, including congestion control<\/a> and payment pools and at least two<\/a> improvements<\/a> to the Lightning Network. See a more extensive list of use cases in this webpage<\/a>.<\/p>\n

Some BIP 119 Use Cases Can Already Be Achieved Today \u2014 With One Difference<\/h3>\n

All software has risks. That being said, one interesting aspect of CTV is that most of the use cases it enables can already be achieved today. However, right now they would require users to be online and coordinate signing and broadcasting transactions, as well as at times deleting private keys. This arguably makes them nearly impractical, while some aspects, such as key deletion with counterparties, introduce the component of trust. <\/p>\n

CTV simply allows such use cases to be completed programmatically, that is, without human interaction after the creation of the contract \u2014 an allegedly more trustless way that is also less prone for error.<\/p>\n

Can BIP 119 Be Used To Implement Whitelists And Compromise Fungibility?<\/h3>\n

Some people have articulated fears that, if activated, BIP 119 would facilitate governments and exchanges to create and enforce whitelists<\/a>. <\/p>\n

In the context of Bitcoin, a whitelist is simply a list of Bitcoin addresses that are approved for use by some authority. This authority would only allow transactions to and from whitelisted addresses, banning all other addresses. <\/p>\n

The fear is that this could be leveraged in an authoritarian way by governments worldwide through policy dictating that bitcoin could only be sent to addresses whitelisted by regulators. <\/p>\n

It appears that some believe CTV would be able to allow governments or exchanges to restrict where the bitcoin they send to users in withdrawals could be spent through whitelisting.<\/p>\n

This fear likely became popular after prominent Bitcoin educator Andreas Antonopolous posted a video on YouTube commenting on CTV and covenants in general<\/a>, where he discussed that covenants can be risky depending on their design. <\/p>\n

Antonopoulos said that recursive covenants, in some cases, could be used to create blacklists and whitelists of Bitcoin addresses, potentially compromising Bitcoin\u2019s fungibility as some BTC coins would be different than others given their spending abilities. But despite the fact that Antonopoulos did not say this would be possible with CTV, many people assumed<\/a> that he was referring to CTV specifically \u2014 or simply bundling all \u201ccovenant\u201d designs into one basket. <\/p>\n

CTV does not allow for recursive covenants or such authoritarian whitelists. (Some Bitcoin developers actually advocate<\/a> that CTV is too simple<\/a> in its form and more general covenant designs<\/a> that cover a wider range of use cases<\/a> would be desirable instead.)<\/p>\n

What Is All The Controversy About?<\/h2>\n

Perhaps the biggest part of the controversy surrounding CTV over the past couple of weeks has actually been related to its activation method rather than its technical specification, as people weighed in on whether the proposal should move forward in an attempted soft fork upgrade to Bitcoin or not. <\/p>\n

The uproar began after Rubin posted to the bitcoin-dev mailing list<\/a> on April 19 outlining a suggested plan for activating his proposal on the Bitcoin protocol. His email linked to an extensive blog post<\/a> which began with a conclusion: \u201cWithin a week from today, you\u2019ll find software builds for a CTV Bitcoin Client.\u201d<\/p>\n

Rubin explained how he attempted to gather feedback from different members of the Bitcoin community about CTV during the Bitcoin 2022 conference, which gathered over 20,000 people in early April in Miami.<\/p>\n

Rubin said \u201ca lot of people\u201d told him that CTV could help them in a tangible way and were interested to know what the next step was for the proposal as well as what his plans were for getting it activated. <\/p>\n

Additionally, as summarized by Bitcoin Optech<\/a>, Rubin elicited multiple reasons in the blog post for why CTV could be seen as ready to activate, including consistency, popularity, viability and desirability. The developer argued that CTV has a stable specification and implementation, a number of well-known people and organizations support the upgrade, there apparently is not a significant objection that CTV violates desirable Bitcoin properties, and the upgrade would bring about new features that users allegedly want.<\/p>\n

The developer planned on releasing a Bitcoin client that would enable miners to signal whether they intended to enforce CTV rules or not. A Bitcoin client is a software application that interfaces user interaction with the Bitcoin network. A client can fully connect to the peer-to-peer network, like Bitcoin Core. While Bitcoin Core is the original, most popular Bitcoin client, it is not the only one.<\/p>\n

The CTV client would bring code that would make it possible to activate the proposal with Speedy Trial (ST), Taproot\u2019s activation method from last year that involved miner signaling of readiness. <\/p>\n

If 90% of the Bitcoin blocks in any of the many 2,016-block (two-week) difficulty periods signaled positively for CTV, the upgrade would be \u201clocked in\u201d for activation in November. Then, anyone running Rubin\u2019s Bitcoin client would be able to use CTV and begin enforcing its rules.<\/p>\n

Under the original plan, Rubin would release the client software on April 26. The first signaling period would begin on May 5 and the signaling window would end on August 12. This tight timeline made people anxious about the future of Bitcoin, especially due to the fact that the upgrade would be put forth through Speedy Trial by a client other<\/em> than the network\u2019s de facto reference client, Bitcoin Core. <\/p>\n

As a result, a sea of arguments ensued as people advocated for what they thought was the best course of action.<\/p>\n

Is BIP 119 Ready To Be Added To Bitcoin?<\/h3>\n

It is just as hard to determine readiness as it is to gauge consensus \u2014 and both are likely intertwined as it can be argued that consensus is a driver for readiness. However, it isn\u2019t clear how either one or the other are measured in the Bitcoin ecosystem.<\/p>\n

While BIP 119\u2019s imminent activation is clearly not overwhelmingly supported<\/a>, and hence not desired by everyone, the idea of covenants apparently has wider support from the development community.<\/p>\n

Most prominent Bitcoin developers seem to be leaning toward encouraging a more extensive research in the covenants subject and the proposed alternatives to enabling it on the protocol.<\/p>\n

Bitcoin developer Matt Corallo expressed<\/a> in the unofficial CTV Telegram group chat that various use cases enabled by covenants would probably be \u201cbest served\u201d with a combination of the different proposals on the table.<\/p>\n

\u201cBut there\u2019s precious little analysis of how these things would work together, how to build them so that they work well together, how to build a good solution that has both,\u201d he said.<\/p>\n

\u201cOf course there\u2019s no \u2018optimal solution for all use-cases.\u2019 But there is a world where we study what we\u2019re designing for and build things that work well together,\u201d he added<\/a>.<\/p>\n

Corallo had posted on the mailing list<\/a> one day before his comments on the Telegram group. His post warranted caution and highlighted that multiple covenant-based designs have been proposed. In his opinion, the community should strive to attempt a soft fork only when it\u2019s sure it provides the best value for a change \u2014 something that would require a more extensive analysis and comparison between proposals.<\/p>\n

\u201cWe don\u2019t add things to Bitcoin just to find out whether we can,\u201d he wrote.<\/p>\n

However, in the same way that it is unclear whether CTV is ready to be activated, it is also unclear what the next steps should be to either gauge that readiness or make it ready. And reviewers haven\u2019t laid out such steps.<\/p>\n

Most of Rubin\u2019s complaints stem from the lack of answers to his main question: What does CTV need to be considered ready for activation into Bitcoin?<\/p>\n

Such lack of directives from Bitcoin Core maintainers and fellow Bitcoin developers was also what drove him to attempt the release of his software client \u2014 so that users interested in using the features enabled by the soft fork had the chance to see them live.<\/p>\n

Moreover, this unclear process from proposal to activation in regards to Bitcoin soft forks has brought to the fore a broader issue: How should we change Bitcoin?<\/p>\n

How Should Changes To Bitcoin Be Made?<\/h3>\n

Taproot, the last major upgrade to the Bitcoin protocol, activated last year after the Speedy Trial process proved successful in gathering traction with the mining community. However, ST itself did not have particularly large consensus<\/a> and it is unclear if the community wants to repeat it in future soft forks.<\/p>\n

\u201cST [Speedy Trial] itself was fairly controversial, but specifically what made it work for Taproot is Taproot had wide support and technical consensus,\u201d Blockstream CEO and early cypherpunk Adam Back said<\/a> in the unofficial CTV Telegram group chat. \u201cCTV has some but IMO less wide support and does not [have] technical consensus.\u201d<\/p>\n

Lightning Labs CTO Olaoluwa Osuntokun tweeted late last month<\/a> comments that in part echo Back\u2019s thoughts but at the same time introduce a broader discussion. He said that Taproot enabled the community to \u201ckick the can down the road and not address the critical question\u201d of how changes should happen to Bitcoin.<\/p>\n

\u201cSome think that [it] doesn\u2019t need to be spelled out and \u2018rough consensus\u2019 (know it when you see it) is enough, others think we need a clear process\/progression so we can create more rigorous process around it,\u201d Osuntokun said in a reply tweet<\/a>.<\/p>\n

\u201cReading between the lines, some think a clear process gives a sort of blueprint for future \u2018attackers\u2019 and the process is better murky to \u2018protect\u2019 the system,\u201d he added. \u201cSome think without a process, statements like \u2018not technically ready\u2019 can\u2019t be determined \u2018objectively.\u2019\u201d<\/p>\n

Besides the \u201ctechnical consensus\u201d argument made by Back, ordering is also of importance. In the case of Taproot, the proposal gathered overwhelming buy in from the community before being handed off to miner signaling with Speedy Trial. The opposite would happen with CTV under the original proposal for activation, with Speedy Trial being used as a means to gather or gauge consensus instead of a means to fast-track a widely-supported upgrade to activation.<\/p>\n

Casa co-founder and CTO Jameson Lopp disagrees.<\/p>\n

\u201cIt seems to me that if one proposes a speedy trial without technical \/ ecosystem consensus, nothing happens,\u201d he tweeted<\/a> in response to Back, who was arguing<\/a> that any upgrade proposal to Bitcoin should gather technical and ecosystem consensus before an attempted activation to the protocol.<\/p>\n

\u201cWhat is Bitcoin\u2019s change process? It\u2019s very meta \u2013 none of the conventions MUST be followed. It is whatever works,\u201d Lopp argued in a previous tweet in that discussion thread with Back.<\/p>\n

The need for an upgrade proposal to be technically ready, or have technical consensus, is a point Back has been trying to drive home over the past few weeks as the discussion around CTV heated up. The cypherpunk has also cited<\/a> potential \u201cdrama\u201d of what he calls \u201cnon-consensus changes\u201d \u2014 making parallels with the blocksize wars<\/a>.<\/p>\n

For Back<\/a>, technical consensus arises from the people analyzing and proposing covenant-enabling variants for Bitcoin. But that is arguably also subjective, and as highlighted by Osuntokun, given the \u201cmurky\u201d upgrade process to Bitcoin, it is hard to define what technical consensus is.<\/p>\n

Ultimately, Nothing Happened<\/h2>\n

It is unclear why, specifically, Rubin\u2019s blog post generated so much discussion and fear in the community. However, there are some likely scenarios.<\/p>\n

First, as nontechnical users tend to rely on the opinion of prominent developers<\/a> and educators, seeing them not agreeing with each other on a clear path forward likely brought doubts about the future, which ended up bleeding into the proposal itself \u2014 casting doubts on its merits and whether it was a good idea after all.<\/p>\n

Second, there appears to have been some slight misunderstandings about what Rubin intended to do with his blog post and the release of the software.<\/p>\n

Some assumed he would be releasing a user-activated soft fork (UASF) and got nervous about it, while others got frustrated exactly because he wouldn\u2019t do that himself. Those in favor of a UASF were also nervous partly due to the previously-mentioned controversies with Speedy Trial \u2014 a miner-activated soft fork (MASF). Rubin posted to the mailing list<\/a> explaining some of these nuances and what he meant with the blog post.<\/p>\n

It also appears from the discussions in the community that many did not notice that Rubin jointly announced the release of code to resist<\/em> the CTV activation in his blog post \u2014 giving users both for and against the proposal a chance to voice their opinion in the network.<\/p>\n

All of these misunderstandings generated a lot of the drama that Back spoke about as users were faced with fear mongering that an update which technical Bitcoiners couldn\u2019t agree on would be \u201cforced\u201d onto the network by its proponents \u2014 potentially risking a chain split.<\/p>\n

However, as argued by Lopp, undertaking a Speedy Trial for a proposal that doesn\u2019t have overarching consensus would likely have resulted in nothing.<\/p>\n

Despite the conversations and feedback, up to this point, pretty much nothing has happened with the proposal as Rubin posted<\/a> to the mailing list explaining that he would not be releasing any code as previously intended.<\/p>\n

Thanks to Aaron van Wirdum for information and feedback and to Jeremy Rubin for information.<\/em><\/p>\n

For a more detailed explanation on CTV, see <\/em>this article<\/em><\/a>. If you prefer audio, see <\/em>this podcast episode<\/em><\/a> on CTV.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Explaining the controversy around Bitcoin\u2019s BIP 119 (CTV) proposal and debunking some myths that in part fueled it.<\/p>\n","protected":false},"author":2572,"featured_media":4071,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[2289,1927,2291,57,894,422,1286,2290],"class_list":{"0":"post-9306","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bip-119","9":"tag-bip119","10":"tag-checktemplateverify","11":"tag-consensus","12":"tag-ctv","13":"tag-feature","14":"tag-op-ctv","15":"tag-speedy-trial"},"author_data":{"id":2572,"name":"Namcios","nicename":"namcios","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/pfp-96x96.png"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/bitcoin-numbers.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/9306","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/2572"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=9306"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/9306\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/4071"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=9306"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=9306"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=9306"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}