BIP-119 has not yet been thoroughly scrutinized on a technical level, some say.
The covenants hide some risks that in principle are not noticed.
The Bitcoin Improvement Proposal 119 o BIP-119 is the brainchild of developer Jeremy Rubin, who aims with it to introduce advanced parameters for Bitcoin transactionsfor example, that some bitcoins can only be sent to a specific address and not to another.
But also, and importantly, also can condition the spending of those bitcoins in the future, so that once they are sent to an initial address, from there they can only be sent to other specified addresses.
These types of constraints are known as covenants and are executed under the OP_CTV commandwhich in its two basic use cases allows you to create a sort of vault (vault). With this instruction, for example, funds from a cold or hardware wallet could only be withdrawn to another address under the control of the fund owner.
In addition, BIP 119 could allow batch transactions to be made with a certain regularity or rhythm, in a harmonious way. For example, it would be possible that when a certain amount of bitcoins are deposited in a wallet, from this other payments are made to other addresses.
Thus, the owner or manager of a business could, hypothetically, deposit the amount of bitcoins necessary to pay their employees, and from this wallet the payments would be executed in a timely and automated manner to each of the workers’ wallets or purses.
These types of batch transactions can also be scheduled to run with other parameters. For example, when network fees average less than 4 satoshis per byte (vbyte, the data weight of these transactions).
The technical argument: is OP_CTV a really safe development?
The discussion about OP_CTV, the function introduced by BIP-119, follow via Bitcoin developers mail. These are some of the recent opinions, from a technical point of view, of some of these programmers.
First of all, developer Anthony Towns felt that based on his analysis, most CTV test transactions seem to be programmed with toad, a language created by Jeremy Rubin with the goal of “making smart contracts on Bitcoin”. Towns thinks that perhaps for this reason, CTV hasn’t had much public scrutiny yet.
Furthermore, he believes that introduce BIP-119 can create risks for all Bitcoin userseven those who do not have the desire to use its functionalities, due to the changes that must be made in the consensus mechanism.
The latter was seconded by developer Matt Corallo, who warned that an update or soft fork of this type it should provide the greatest possible benefit to as many users as possible.
On the other hand, Russell O’Connor, also a developer, pointed out that there doesn’t seem to be much compatibility of the OP_CTV script or command with other Bitcoin scripts like base58check, bech32 (SegWit) or bech32m (Taproot), so there would be a need for wallets to develop tools that allow the use of BIP-119 without problems coordination between the portfolio addresses used.
David Harding expressed his concern about the fact that CTV it can be a type of agreement or covenant that in the long term is not widely used, either due to low user demand or because other types of better-designed covenants emerge. “This would leave future developers with the burden of maintaining the code and having to analyze what CTV’s potential interactions would be like with other upcoming consensus changes,” he argued.
This series of opinions are the most substantiated on a technical level, unlike the political opinions that we covered in a previous installment, and which tend to be seen more often on social networks. Bitcoin Core developers are still unsure about the necessity and feasibility of BIP-119.
The Sinister Antecedent: Gregory Maxwell’s Covenants
As early as August 2013, developer Gregory Maxwell explained one type of covenant o BTC spending restriction based on the CoinWitness protocol. But as an intellectual exercise, he illustrated some frightening ways in which these restrictions could play out.
Basically, explained in a post that by adding arbitrary clauses to spend a few bitcoins, everything from now on could go wrong. Maxwell argues that by requiring bitcoins to be spent in a specific way “you will have created a currency that is forever subject to a spending condition. [covenant] and forever restrict its use and that of its descendants, degrading its fungibility.
In other words, these bitcoins conditioned to be spent in a specific way would be different from the rest of the bitcoins circulating in the network, which could cause other people not to want to receive or transact with themand even that these bitcoins have a purchase and sale price different from the rest in the market.
Thus, Maxwell invited other readers of the BitcoinTalk forum, where he posted his argument, to imagine other terrifying forms of covenants. The bitcoin community back then responded.
The other technical challenge: What is the best way to reach consensus in Bitcoin?
The way in which Jeremy Rubin proposed to activate BIP-119, threatening to launch a client of his own and appeal to a speedy trial made by miners, as happened with Taproot, It was one of the points that raised the most controversy around the debate.
In this way, the most debated aspect in principle was not the technical qualities of the BIP-119, but the best activation method. Developer Keagan McClelland takes advantage of the BIP-119 debate to propose a discussion on what is the best way to reach a consensus in Bitcoin.
Along with the CTV discussion there is now a second discussion that was not fully addressed during the Taproot activation. There is a lot of argument about what is a Speedy Trial and what is not, what is BIP 8 [soft-fork activado por los usuarios] and what not etc
A significant reason for losing good manners in this debate is that, because we have no way of measuring a user’s support for proposed changes, this invariably means that people say that their social circle approves or rejects a proposal, and that their circles represent the majority of Bitcoin users as a whole.
Proposing this discussion, McClelland assures that appealing to the miners may not be the best option to make changes to the Bitcoin software, since these may have different incentives to those that the user market has (for example, a soft fork that raises the minimum commissions per transaction or that increases the block production time).
The discussion continued with comments from other developers, who proposed other mechanisms for activating this type of proposal.
Given the theoretical precedent on covenants such as that expounded by Gregory Maxwell and the early Bitcoin community, it is not clear to the developers if BIP-119 is desirable for all its users and for the protocol itself.
In a future installment we will explain the social side of this debate and what it represents for Bitcoin.