фото показано с : bitcoinmagazine.com

Explaining the controversy around Bitcoin’s BIP 119 (CTV) proposal and debunking some myths that in part fueled it.

It’s 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.

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.

CTV was first proposed in May 2019 under a different name. At the time, the proposal, coined CheckOutputHashVerify, focused on enabling congestion control on Bitcoin — 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. Later that year, it was again improved and renamed to CTV.

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, where its author, Jeremy Rubin, lays out its design and reasoning as well as some use cases the proposal could enable.

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’s ethos of sovereignty, there are instances where restrictions on where bitcoin can be spent can be desirable.

A third party would not be able to restrict how you spend your 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.

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 – and not the sender.

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 “unlocking” that bitcoin output.

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).

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.

With CTV, the user constructing the address would be able to add more information necessary to be satisfied to spend that bitcoin — 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.

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.

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 – through the transfer limits – in case an attacker managed to get control over the user’s cold storage wallet private keys. Without a vault, having the private keys would allow the attacker to sweep all of the user’s funds at once.

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

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.

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

Some people have articulated fears that, if activated, BIP 119 would facilitate governments and exchanges to create and enforce whitelists.

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.

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.

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.

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

Antonopoulos said that recursive covenants, in some cases, could be used to create blacklists and whitelists of Bitcoin addresses, potentially compromising Bitcoin’s 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 that he was referring to CTV specifically — or simply bundling all “covenant” designs into one basket.

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

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.

The uproar began after Rubin posted to the bitcoin-dev mailing list on April 19 outlining a suggested plan for activating his proposal on the Bitcoin protocol. His email linked to an extensive blog post which began with a conclusion: “Within a week from today, you’ll find software builds for a CTV Bitcoin Client.”

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.

Rubin said “a lot of people” 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.

Additionally, as summarized by Bitcoin Optech, 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.

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.

The CTV client would bring code that would make it possible to activate the proposal with Speedy Trial (ST), Taproot’s activation method from last year that involved miner signaling of readiness.

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 “locked in” for activation in November. Then, anyone running Rubin’s Bitcoin client would be able to use CTV and begin enforcing its rules.

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 than the network’s de facto reference client, Bitcoin Core.

As a result, a sea of arguments ensued as people advocated for what they thought was the best course of action.

It is just as hard to determine readiness as it is to gauge consensus — and both are likely intertwined as it can be argued that consensus is a driver for readiness. However, it isn’t clear how either one or the other are measured in the Bitcoin ecosystem.

While BIP 119’s imminent activation is clearly not overwhelmingly supported, and hence not desired by everyone, the idea of covenants apparently has wider support from the development community.

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.

Bitcoin developer Matt Corallo expressed in the unofficial CTV Telegram group chat that various use cases enabled by covenants would probably be “best served” with a combination of the different proposals on the table.

“But there’s 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,” he said.

“Of course there’s no ‘optimal solution for all use-cases.’ But there is a world where we study what we’re designing for and build things that work well together,” he added.

Corallo had posted on the mailing list 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’s sure it provides the best value for a change — something that would require a more extensive analysis and comparison between proposals.

“We don’t add things to Bitcoin just to find out whether we can,” he wrote.

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’t laid out such steps.

Most of Rubin’s complaints stem from the lack of answers to his main question: What does CTV need to be considered ready for activation into Bitcoin?

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 — so that users interested in using the features enabled by the soft fork had the chance to see them live.

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?

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 and it is unclear if the community wants to repeat it in future soft forks.

“ST [Speedy Trial] itself was fairly controversial, but specifically what made it work for Taproot is Taproot had wide support and technical consensus,” Blockstream CEO and early cypherpunk Adam Back said in the unofficial CTV Telegram group chat. “CTV has some but IMO less wide support and does not [have] technical consensus.”

Lightning Labs CTO Olaoluwa Osuntokun tweeted late last month comments that in part echo Back’s thoughts but at the same time introduce a broader discussion. He said that Taproot enabled the community to “kick the can down the road and not address the critical question” of how changes should happen to Bitcoin.

“Some think that [it] doesn’t need to be spelled out and ‘rough consensus’ (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,” Osuntokun said in a reply tweet.

“Reading between the lines, some think a clear process gives a sort of blueprint for future ‘attackers’ and the process is better murky to ‘protect’ the system,” he added. “Some think without a process, statements like ‘not technically ready’ can’t be determined ‘objectively.’”

Besides the “technical consensus” 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.

Casa co-founder and CTO Jameson Lopp disagrees.

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

“What is Bitcoin’s change process? It’s very meta – none of the conventions MUST be followed. It is whatever works,” Lopp argued in a previous tweet in that discussion thread with Back.

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 potential “drama” of what he calls “non-consensus changes” — making parallels with the blocksize wars.

For Back, 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 “murky” upgrade process to Bitcoin, it is hard to define what technical consensus is.

It is unclear why, specifically, Rubin’s blog post generated so much discussion and fear in the community. However, there are some likely scenarios.

First, as nontechnical users tend to rely on the opinion of prominent developers 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 — casting doubts on its merits and whether it was a good idea after all.

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.

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’t do that himself. Those in favor of a UASF were also nervous partly due to the previously-mentioned controversies with Speedy Trial — a miner-activated soft fork (MASF). Rubin posted to the mailing list explaining some of these nuances and what he meant with the blog post.

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

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’t agree on would be “forced” onto the network by its proponents — potentially risking a chain split.

However, as argued by Lopp, undertaking a Speedy Trial for a proposal that doesn’t have overarching consensus would likely have resulted in nothing.

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

Thanks to Aaron van Wirdum for information and feedback and to Jeremy Rubin for information.

For a more detailed explanation on CTV, see this article. If you prefer audio, see this podcast episode on CTV.

Similar to Notcoin - Blum - Airdrops In 2024

origin »

114 +