“Better safe than sorry”, argue Bitcoin developers before BIP 119

This week there will be 2 forks in Ethereum to advance the merger

Some developers continue to delay the adoption of the proposal to improve Bitcoin BIP 119 presented by Jeremy Rubin, while debating the degree of priority that it has in relation to the benefits it offers to the network and its users.

BIP 119 (Bitcoin Improvement Proposal number 119) offers, in theory, the way to make multiple scheduled payments. This was created and exposed by developer Jeremy Rubin and shows a high level of acceptance among bitcoiners.

However, even though many recognize that adopting this improvement will bring benefits to Bitcoin, they also fear that it is not secure enough yet.

Advertising

"Better safe than sorry", argue Bitcoin developers before BIP 119

Rubin claims that BIP 119 is ready to become part of the Bitcoin protocol. In fact, the developer is so sure of it that he offers a loot of 5.5 BTC to whoever discovers and demonstrates vulnerabilities present in the code of his proposal.

According to Jeremy Rubin, adding his proposal to the Bitcoin codebase would not require drastic changes to the protocol. In fact, a soft fork would suffice to implement it. This means that Bitcoin nodes that do not adopt BIP 119 would still be compatible to continue operating on the main chain, only they would not have the features added by Rubin’s proposal.

As easy and beneficial as adding BIP 119 to Bitcoin might be (in theory), many developers and node operators believe that the proposal still lacks proof that check that it is ready for the main network without putting it at risk.

Advertising

"Better safe than sorry", argue Bitcoin developers before BIP 119

Arguments Against Rubin’s BIP 119 Proposal

There is a lot of comment on social networks like Twitter and Reddit both for and against the activation of BIP 119 in Bitcoin. Although, most of them seem to prefer that the addition of the Rubin proposal to the protocol be postponed.

The main reason presented by the majority of those who oppose BIP 119 has not to do with the quality of the proposal, but with the low priority that it currently has.

For many bitcoiners there are other priority improvements that need to be worked on and dedicating yourself to adding the one presented by Rubin would not be worth it. In addition, there is a possibility that the new Bitcoin improvement proposal still has flaws that put the integrity of the network at risk.

Eric Lombrozo, one of the Bitcoin Core developers and part of the team that worked on activating SegWit in Bitcoin, at a discussion with renowned journalist and bitcoiner Leigh Cuen, hinted that Rubin was putting the entire network at risk by publishing the lines of code that would allow his proposal to be adopted in Bitcoin, without the approval of the Bitcoin Core team for it..

Tweet where a journalist asks what are the arguments against the BIP 119 update for Bitcoin.
Many times Bitcoin updates are discussed for years and the arguments against or in favor of a certain proposal are not always effectively disclosed. Source: @La_Cuen / Twitter.

Lombrozo acknowledged that Bitcoin Core does not have enough members to verify all the BIPs that arrive in a short time. He also admitted that proposals like Taproot, which was activated in Bitcoin relatively quickly, had in its favor the endorsement of developer Peter Wuille. While Rubin does not enjoy the same prestige before Bitcoin Core.

Although the case of Taproot could be an exception to how thorough they usually are in Bitcoin Core to make changes to the protocol, the truth is that traditionally each proposal that is approved and activated in the Bitcoin network is usually thoroughly tested.

Adam Back, Bitcoin technology expert and co-founder of Blockstream, also advocates postponing the activation of BIP 119. Among the tweets published about it, Back comments that there are several proposals similar to 119 on the table in which conventions are used and that it would be worthwhile to evaluate them all before choosing one.

Back also adds that Rubin’s proposal works in very specific contexts and that he has seen others that are more modular or versatile, which, in particular, seem better to him.

Matt Corallo, another experienced Bitcoin technology developer and co-founder of Blockstream with Adam Back, Explain who is also not in favor of adding Rubin’s BIP 119.

Among his greatest criticisms of the potential adoption of said proposal, Corallo mentions that there is probably a better way to get the results than through the solution that Rubin offers, which would imply discarding BIP 119.

The problem is that this would become a useless part of the Bitcoin code base that could hinder the evolution of this technology, its maintenance and the addition of new proposals.

The fact that the Bitcoin Core team is so meticulous in applying improvements to Bitcoin is one of the reasons why this network has not gone through the bitter pills that others, because they are in a hurry, have to go through.

Arguments in favor of Rubin’s proposal

Rubin, as the creator of this proposal, is the first of the developers to defend it and to want it to be part of the Bitcoin code base.

Among the advantages offered by BIP 119 are the automation of transactions, through which it would be possible to schedule the spending of the balance contained in a purse. Payment could be scheduled for a specific date or multiple dates when a set amount of BTC is sent. In addition, the amounts and the number of wallets to which bitcoin will be transferred simultaneously may also vary.

In defense of his proposal, Rubin listed a number of reasons why he actively promotes the addition of BIP 119 to the Bitcoin protocol as soon as possible. Firstly, according to the developer, the proposal has already passed a series of pre-takeoff evaluationsLike the fact that it hasn’t needed specification-level reforms for more than two years and that the haul of vulnerabilities is still intact.

Jeremy Rubin, author and promoter of BIP 119, offered 5.5 BTC to whoever finds vulnerabilities in his proposal. Source: rubin.io

One of Rubin’s most interesting arguments for speeding up the adoption of BIP 119 is what he presents as “unforced errors.” With that term, the developer refers to mistakes a person makes even when they had the choice and ability to prevent thembut he didn’t.

Jeremy Rush.
Jeremy Rubin, author and promoter of BIP 119, offered 5.5 BTC to whoever finds vulnerabilities in his proposal. Source: rubin.io.

This concept seeks to defend the proposal of those who believe that it is not currently a relevant improvement, so it would be an unnecessary effort and risk to adopt it for now.

The promoter of BIP 119 has also expressed his desire to turn the page with this proposal and focus on the development of other innovations that benefit Bitcoin and its users. Besides, Rubin has complaints about the desire of many bitcoiners to slow down the integration process of an improvement like the one he promotes..

For Rubin, the arguments presented against him today in order to postpone the adoption of BIP 119 they can be recycled and used again in a couple of yearssince the conditions of the ecosystem at that time could be resized and it would be like going around in circles.

Suppose we want to reach a point where 50% of the community (bitcoiner) has reviewed a change. In two years, what if the community is twice as big? Even if we managed to reach 50% of the community today, we would only have 25% of the community (back then).

Jeremy Rubin, creator and promoter of BIP 119.

In conclusion, both perspectives have valid arguments to defend their ideas and actions before BIP 119. The more optimistic side is that both groups show the best of intentions for Bitcoin growth.

However, as Eric Lombrozo pointed out in one of his tweets On this topic, “it only takes a well exploited systemic vulnerability to destroy the network. And there is no second chance.”

See also  Bitcoin Lightning Network will allow issuing and exchanging stablecoins and other tokens

Leave a Comment

Your email address will not be published.