Bitcoin’s Contentious Soft Fork: A Cause of Discord

Some software developers are advocating for a new soft fork in the bitcoin code, despite facing more resistance than previous updates. Modifying the bitcoin code, especially the part related to the 21 million limit, is a challenging task due to strong incentives to maintain its integrity.

While certain code evolutions are necessary, there are instances where changes are less crucial. However, there will always be developers with differing opinions seeking to introduce alterations that may not align with the broader consensus.

Proposed code changes are typically submitted through “Pull Requests,” ranging from minor adjustments to significant ones that may lead to Bitcoin Improvement Proposals (BIPs) and potentially “soft forks.”

In contrast to hard forks that create incompatible code versions, a soft fork allows for coexistence of different codes on the same blockchain, ensuring backward compatibility. For example, adjusting the block size to 0.3 MB would maintain compatibility with the original protocol’s 1 MB limit.

Previous soft forks like SegWit (2016) and Taproot (2021) have been successful. Presently, developers are advocating for a new soft fork to enable the creation of “covenants” by introducing new OP_codes.

Understanding bitcoin transaction mechanisms is crucial to grasp the concept of covenants. Transactions involve creating and destroying “utxos,” which link bitcoins to specific addresses through scripts.

Bitcoin transactions involve executing OP_codes, which act as digital gears during validation. The OP_CHECKSIG instruction plays a key role in verifying signatures and creating new utxos.

Bitcoin Script, a simple programming language, has limitations in supporting complex smart contracts due to disabled OP_codes like OP_OR, OP_MUL, OP_DIV, and OP_CAT to prevent network vulnerabilities.

The introduction of covenants aims to enhance smart contract capabilities within bitcoin transactions. OP_CHECKTEMPLATEVERIFY (CTV) allows shared utxos, while OP_VAULT enables control over bitcoin movement in subsequent transactions.

OP_CAT, a controversial OP_code, introduces recursive spending conditions, impacting not only the next but also all future transactions involving the bitcoins concerned.

The necessity and implications of these new OP_codes remain subjects of debate, especially considering their potential impact on bitcoin’s role as a store of value versus a means of payment. The complexity of these solutions raises questions about their practicality and necessity in the current bitcoin ecosystem.