Enhancing Bitcoin transactions. Open an interesting read BIP-119 has stirred controversy within Bitcoin. The proposal for protocol modernization within Bitcoin has rekindled community attention toward the concept of decentralization after several years of calm. This story illustrates how multifaceted the issue of decentralization is and how many non-obvious problems exist in an open blockchain network to ensure its proper functioning.
In this article:
- I will present what BIP-119 entails—a controversial proposal for a softfork in the Bitcoin protocol.
- I will describe, using an example, how to implement a softfork-type change in a blockchain network, presenting the interest groups in the public blockchain and the dependencies between these groups.
What is BIP-119?
The issue concerns Jeremy Rubin, a Bitcoin developer. He introduced BIP-119, a proposal to add new functionality to Bitcoin that will enable, or rather expand, the ability to define so-called covenants, i.e., constraints on transactions. The softfork introduces a new operation into the Bitcoin scripting language: OP_CHECKTEMPLATEVERIFY, replacing the currently unused OP_NOP4 code.
BIP, known as Bitcoin Improvement Proposal, refers to a proposal for introducing changes or novelties to the Bitcoin blockchain. It is an informal document that, when published online (on GitHub), is confronted with the Bitcoin blockchain community—users, miners, exchanges, or developers.
BIP-119 is a controversial proposal that has been met with a significant amount of skepticism. This stems from its operational idea and the proposed implementation.
Pic.1
What are transaction covenants?
What are covenants? Bitcoin deliberately lacks the ability to create complex smart contracts like Ethereum, but its simple scripting language enables the creation of constraints on transaction transmission. For instance, Bitcoins can be sent only by obtaining signatures from multiple parties (classic multi-sig), or Bitcoins can be sent only at a specific future time after mining a certain block.
Pic.2
BIP-119 proposes to expand the ability to define transaction constraints in such a way that, for example, a transaction can be defined that can then be used only by another specific transaction. For instance, I’ll send 1 BTC to address, but that 1 BTC can only be spent by a specific transaction, perhaps only to specifically indicated addresses.
This mechanism allows for several useful use cases. For example, it solves to some extent the problem of congested transactions. An example is a cryptocurrency exchange that needs to send a transaction to the blockchain during peak hours (payouts to users), where fees are high. By utilizing BIP-119, the exchange achieves this by utilizing two transactions:
- The first transaction contains minimal data (it doesn’t yet send funds to final recipients), making it cheap because the number of recipients increases the transaction size, affecting the final transaction fee (especially when many other transactions are also sent during peak hours). This transaction can be described as follows: I send 100 Bitcoins that can only be sent to specific addresses in the future.
- The second transaction transfers the funds to specific recipients. The mechanism is structured in such a way that this second transaction utilizes the previously sent first transaction, where the sent funds are only usable by the second transaction. The second transaction is larger, but the exchange sends it when the blockchain fees are low, collectively saving costs and enabling blockchain utilization when fees are low.
The Bitcoin community is currently rather skeptical about the potentialities that would be introduced if BIP-119 were to function. There are assumptions that Jeremy Rubin’s company – Judica, might financially benefit from the proposed change, but it’s not entirely clear how much value (or problems) the change would add in other applications.
However, the topic raises an interesting problem that I’d like to explain.
How to implement a change in the blockchain network? Decentralization in practice.
Enhancing Bitcoin transactions. The proposed protocol modernization of Bitcoin with BIP-119 is a softfork. BIP-119 is a softfork. This means it does not break consensus rules. Nodes that do not update to the version containing the changes will still be able to correctly receive blocks from the network, even those containing changes from the softfork. Nodes that update to the new rules have new capabilities and can still process transactions from old nodes.
Changes in the blockchain network are a multi-faceted topic. Implementing changes requires coordination among network participants and is a game of interests where the ideal scenario is full agreement among all interest groups.
However, to practically demonstrate how changes are introduced into the blockchain and present the mentioned concept of the game of interests, I will describe the process of introducing a softfork-type change into the blockchain network. This will help understand how difficult this process is in practice and how resilient blockchain is to manipulations.
Pic.3
Source code
Enhancing Bitcoin transactions. Everything begins with the source code created by developers, in this case, Bitcoin developers (to whom the author of BIP-119, Jeremy, belongs). Bitcoin’s code is public, there are several independent implementations, and developers from around the world work on its development. The process of introducing changes to the public code (hosted on GitHub) is subject to many commonly used safeguards: a single developer cannot implement a fix, and an unauthorized user cannot make changes. Anyone can propose a change (as a BIP). Anyone can implement a change in their local copy of Bitcoin’s code. However, introducing changes to the public version of Bitcoin’s code requires the approval of developers. It should be noted that there isn’t a single Bitcoin repository that, in the event of developers’ rebellion attempting to destroy the protocol, would destroy Bitcoin. Bitcoin developers cooperate with the community, and even if developers create code and subsequently release a version of the Bitcoin node, the community ultimately installs a Bitcoin node based on code that is consistent with the community’s decisions. Therefore, Bitcoin’s development is coordinated with the needs of the community, not solely the will of developers developing Bitcoin code.
What happens with a softfork change that reaches the public Bitcoin code repository?
Nodes
Enhancing Bitcoin transactions. Nodes are built from the code, constituting the fundamental element of the blockchain network. These nodes process blockchain data and create the blockchain network. Nodes are run by Bitcoin users, exchanges, miners. Anyone can run them.
If participants in the blockchain network agree with the changes introduced to the blockchain, they can update their node by running a new version released by developers. This is where the interests of different groups become apparent. The community updates to new node versions not because they have to, but because they want to and can. Bitcoin developers cannot enforce users to install a specific node version or implement specific changes—developers serve the nodes, not vice versa. This is decentralization, or at least one of its aspects.
The impossibility of enforcing any change on nodes means that even if a widely accepted change is implemented, in practice, there will remain a part of the nodes that won’t update (and won’t cause harm because those nodes will still function correctly). We describe a case where the majority of the network, by approving the changes, has updated to a node version containing the softfork. This means nodes have new capabilities, for instance, they can create special types of transactions (similar to what is described in BIP-119). What’s next? Is that enough? Not necessarily. The majority of nodes have new capabilities, but there is a group of network participants whose update at this point matters—the miner nodes.
Miners
Enhancing Bitcoin transactions. I’ve emphasized multiple times that miners’ power is limited because miners serve the blockchain network. Their goal is to secure the network and create new blocks as they are rewarded for doing so. However, the fact that miners create new blocks gives them a form of power over the state of the blockchain.
Theoretically, in the case of softfork changes, if miners do not update their nodes to the version containing the softfork, they do not break consensus, so the network should correctly reward them for their work. However, there are mechanisms that protect the network from miners not following the “will” of the majority.
Miners who solve the puzzle create a new block. Using their nodes, they publish it to the network. The block contains transactions that the miners decided to include in that block. Including transactions in a block requires miners to process transactions on their nodes. If miners do not update their nodes to a version that has gained the network’s approval, i.e., one on which the majority of nodes in the network operate, they will not be able to correctly record transactions in a block that the network nodes expect to be processed correctly. As a result, the network may reject such a block because it is not valid, which means a loss for the miners. Miners’ dependency on the blockchain network forces them, in a way, to act in the way the network expects, even in the case of softfork changes. Ultimately, miners, wanting to participate in the network, update their nodes to a version containing the softfork, i.e., one approved by the network.
The network operates according to new rules
The majority of nodes in the network have nodes in a version that contains the softfork. Miners followed the majority’s will, as they didn’t want to risk their blocks being rejected (through lack of updates) and generate blocks according to the softfork rules. Nodes that didn’t update (without delving into the reasons) correctly process blocks created according to the new rules. The change has been successfully implemented.
Was the change from BIP-119 implemented?
Enhancing Bitcoin transactions. The change from BIP-119 wasn’t introduced into the Bitcoin blockchain network and probably won’t be for some time.
Jeremy proposed a so-called Speedy Trial Activation, meaning miners were to signal first whether they agree with the introduced change. This process allows assessing the network’s approval, in this case, the miners’ approval, of the proposed softfork. This involves miners, while mining blocks, adding certain information to the block data, signaling whether they agree or disagree with the change. This added information, of course, does not cause an error in nodes that receive a new block from miners. Its purpose is to examine miners’ approval for the proposed softfork. I mentioned it’s a softfork, which means miners can create blocks containing transactions that consider the softfork change, and non-updated nodes that form the network won’t reject the block (consensus preserved). Since a softfork doesn’t break consensus, the change is possible. Yes, it’s a form of “power” that miners have over the protocol, as changes that don’t break consensus can be enforced by miners. However, as described earlier, nodes can still reject blocks that don’t break consensus but, for instance, don’t process transactions according to softfork changes expected by the network. This rejection doesn’t happen automatically, but if such a state were to persist and miners didn’t want to follow the community’s will in the blockchain network, adding certain programmatic changes to nodes could cause the network to stop accepting miners’ blocks.
Ultimately, the BIP-119 change was rejected even before the Speedy Trial Activation was initiated because developers and the community want more time to analyze optimal solutions that would allow achieving the effects provided by BIP-119. The quintessence of Bitcoin philosophy: changes must be optimal, best, and backward-compatible.
What’s unique about the BIP-119 proposal?
Through BIP-119, the Bitcoin community once again turned its gaze to the concept of decentralization. The last similar situation was the SegWit change, which was implemented into the Bitcoin blockchain in 2017. There was a serious conflict of interests among network participants at that time. The history of these events is described in a book with an intriguing title, “The Blocksize War.”
Pic.4
A recent update in Bitcoin, Taproot—a significant protocol change—avoided any problems because it met approval from almost the entire Bitcoin environment. However, the BIP-119 case was different.
Enhancing Bitcoin transactions. Blockchain—network operation, management, introducing changes—is a complicated subject. This applies to every blockchain, and due to its complexity, introducing changes in other networks can be an even bigger problem than in Bitcoin. Changes in blockchain exist and will continue because blockchain evolves. The question is whether optimal ways will be found to solve certain conflicts of interests.
Bitcoin has undergone many similar trials, which in several cases resulted in the creation of alternative, niche projects that didn’t want to align with the majority (Bitcoin Cash, Bitcoin SV). The ideal scenario is agreement among all network participants, which is essentially a utopian dream but undoubtedly fascinating.
I design and build enterprise IT solutions based on blockchain technology.
I am blockchain architect in Trans.eu building ECMR (digital CMR Consignment Note) based on blockchain. I teachabout Bitcoin, blockchain and decentralization via Linkedin and blog: https://mobycrypt.com.
