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