Bitcoin developers doubt the technical integrity of the BIP-119
- Tech
- May 15, 2022
Key facts:
-
The BIP-119 has not yet been thoroughly analyzed at the technical level, some say.
-
The covenants hide some risks that in principle are not warned.
The Bitcoin Improvement Proposal 119 o BIP-119 is the brainchild of developer Jeremy Rubin, who it aims with it to introduce advanced parameters for Bitcoin transactions, for example, that some bitcoins can only be sent to a specific address and not to another.
But, in addition, and importantly, also it 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 restrictions are known as covenants and they are executed under the OP_CTV command, which in its two basic use cases allows to create a kind 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, the BIP 119 could make it possible to make batch transactions 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 executed to other addresses.
Thus, the owner or manager of a business could, hypothetically, deposit the amount of bitcoins necessary to pay his employees, and from this wallet the payments would be executed timely and in an automated way to each of the wallets or purses of the workers.
This type of batch transactions can also be programmed to run with other parameters. For example, when network commissions average less than 4 satoshis per byte (vbyte, the weight in data of these transactions).
The technical argument: Is OP_CTV a really safe development?
The discussion about OP_CTV, the function that introduces the BIP-119, continues through the Bitcoin developers mail. These are some of the recent opinions, from the technical point of view, of some of these programmers.
First of all, the developer Anthony Towns considered that, according to his analysis, most of the CTV test transactions seem to be scheduled with Sapio, a language created by Jeremy Rubin with the aim of “making smart contracts in Bitcoin”. Towns is of the opinion that perhaps, for this reason, CTV has not had much public scrutiny yet.
In addition, he believes that introduce the BIP-119 it can lead to risks for all Bitcoin users, even those who do not have the desire to use its functionalities, due to the changes that need to be made in the consensus mechanism.
The latter was seconded by the 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 does not seem to be much compatibility of the OP_CTV script or command with other Bitcoin scripts such as base58check, bech32 (SegWit) or bech32m (Taproot), so there would be a need for wallets to develop tools that allow using the BIP-119 without problems of coordination between the portfolio addresses used.
David Harding showed 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 arise. “This would leave the developers of the future with the burden of maintaining the code and having to analyze what the potential interactions of CTV with other upcoming changes of the consensus would look like,” he argued.
This series of opinions are the most technically based, unlike the political opinions that we covered in a previous installment, and that are usually seen more often on social networks. Bitcoin Core developers are still unsure about the need and feasibility of the BIP-119.
The sinister antecedent: The Covenants by Gregory Maxwell
As early as August 2013, developer Gregory Maxwell explained a type of covenant or BTC spending restriction based on the CoinWitness protocol. But by way of intellectual exercise, he illustrated some frightening ways in which these restrictions could result.
Basically, he 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 on the network, which could cause other people not to want to receive them or transact with them, and even that these bitcoins have a different purchase and sale price than the rest on the market.
Thus, Maxwell invited other readers of the BitcoinTalk forum, where he published his argument, to imagine other terrifying forms of covenants. The bitcoiners community of that time responded.
The other technical challenge: What is the best way to reach consensus in Bitcoin?
The way Jeremy Rubin proposed to activate the BIP-119, threatening to launch a client of his own and appeal to a speedy trial made by the miners, as happened with Taproot, it was one of the most controversial points raised around the debate.
Thus, 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 on Bitcoin.
Along with the CTV debate there is now a second debate 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 the BIP 8 [soft-fork activado por los usuarios] and what not, etc.
A significant reason for losing the good ways in this debate is that, because we have no ways to measure a user’s support for the proposed changes, this invariably results in people saying that their social circle approves or rejects a proposal, and that their circles represent the majority of Bitcoin users as a whole.
Keagan McClelland
Proposing this discussion, McClelland assures that appealing to miners may not be the best option to make changes to the Bitcoin software, because 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 increases the block production time).
The discussion continued with comments from other developers, who raised other mechanisms for the activation of this type of proposals.
Given the theoretical precedent on covenants as set forth by Gregory Maxwell and the early Bitcoin community, it is not clear to the developers whether the BIP-119 is desirable for all its users and for the protocol itself.
In a next installment we will explain the social side of this debate and what it represents for Bitcoin.