Abstract

The development of Bitcoin is driven by a global open-source community, and changes to the protocol are normalized through Bitcoin Improvement Proposals (BIPs). These proposals are subject to rigorous community review and consensus mechanisms, including signaling votes from miners. This open-source model, while promoting transparency and broad participation, also poses the challenge of reaching consensus quickly and coordinating development. In a system with no centralized authority, the decision-making process can become lengthy and contentious.

ViaBTC Capital will analyze the unique framework of Bitcoin's decentralized development, review the core role and controversies of Bitcore Core in protocol maintenance, revisit the activation paths of key upgrades such as SegWit and Taproot, and delve into the 'programmability' debate sparked by new BIPs like OP_CAT. This leads to a profound question: Is Bitcoin's principle of 'immutability equals security' becoming the ultimate shackles on its ecological innovation?

1. Overview of Bitcoin's Decentralized Development Model

1.1 Bitcoin Core's Central Role in Protocol Maintenance

Bitcoin Core is the main software implementation of the Bitcoin protocol and is considered its reference client. It contains full node software for complete verification of the blockchain as well as a bitcoin wallet. Most Bitcoin users and miners choose to use Bitcoin Core as their full node, which is essential for maintaining the decentralization of the network and fending off potential attacks. In addition, the project maintains related software such as the cryptography library libsecp256k1.

Even though Bitcoin development is decentralized, as of June 2025, about 90% of all full nodes on the network use Bitcoin Core. Therefore, Bitcoin Core holds a unique and de facto influential position as the "reference implementation". This de facto authority means that once changes are merged into the Bitcoin Core codebase, they often become the de facto standard, even without explicit enforcement from a central authority. This widespread and voluntary adoption effectively defines the operational rules and current state of the protocol. Consequently, developers who contribute to the Bitcoin Core project, especially its maintainers, wield significant influence. Their work, after undergoing rigorous review and being merged, directly impacts the overall functionality and security of the network. This creates a unique form of "soft centralization" around the Bitcoin Core project, which is continuously balanced by its transparent open-source nature and distributed peer review process.

1.2 The Evolving Role of the Maintainer: From Satoshi Nakamoto to Collective Management

The role of Bitcoin Core's maintainers has evolved significantly, from Satoshi Nakamoto's personal leadership to a collective management model shared by multiple maintainers.

• Satoshi Nakamoto 's Beginnings and Exit: Bitcoin's mysterious creator, Satoshi Nakamoto, initially developed and was active in the Bitcoin Core project until late 2010, when he announced in April 2011 that he had "moved on to other projects" and handed over responsibility for Bitcoin Core to Gavin Andresen. This moment marked the first time that leadership of Bitcoin shifted from Satoshi Nakamoto to the community, and was an important milestone in the decentralization of the project.
• Gavin Andresen's Succession and Controversy: Considered to be Satoshi Nakamoto's "heir apparent", Gavin Andresen took over as the lead maintainer of Bitcoin Core and led the development of Bitcoin in the years that followed, resulting in greater stability and acceptance. However, in 2016, Gavin Andreessen was involved in a major controversy when he publicly claimed that Australian Craig Wright namely Satoshi Nakamoto. This claim was later widely disputed by the community, leading to Gavin Andreessen's access to the main Bitcoin codebase on GitHub being temporarily revoked by other maintainers.
• Wladimir J. van der Laan and Subsequent Collective Maintenance : On April 8, 2014, Wladimir J. van der Laan succeeded Gavin Andreessen as lead maintainer. Since then, the role of lead maintainer has evolved to be shared by multiple maintainers, further decentralizing the release process. Currently, only a few developers have access to the Bitcoin Core code, and their responsibilities include merging contributor patches and performing final checks to ensure that patches are secure and meet the project goals.

The evolution of the Bitcoin Core maintainer role, from a single leader to multiple maintainers sharing the role, reflects the project's ongoing efforts to find a balance between decentralization and efficiency. Initially, Satoshi Nakamoto was able to move the project forward quickly as the sole decision maker. However, as the project matured and the community grew, especially after Satoshi Nakamoto's departure, the risks of this model became increasingly apparent. Decentralizing authority to multiple maintainers, on the other hand, reduces the risk of a single point of failure and ensures a more robust and censorship-resistant decision-making process. However, it also means that the speed at which projects can reach consensus on and implement major changes can be slowed. This inherent trade-off reveals the governance complexity of decentralized systems: how to maintain a sufficient sense of efficiency and direction without sacrificing core decentralization principles.

At the same time, the composition of the team of maintainers and the power dynamics within it have a profound impact on the direction and stability of the entire Bitcoin ecosystem.Blockstream is a company that specializes in Bitcoin and blockchain infrastructure, and several of the developers involved in the maintenance of Bitcoin Core used to work for this company. By supporting these developers, Blockstream has become an important contributor to the code of Bitcoin Core, raising questions in the community about its development independence and corporatization. For example, Blockstream's insistence on solving the Bitcoin scaling problem through layer 2 solution and its opposition to directly scaling the main chain has led to community divisions and Bitcoin forks; in addition, the crisis of trust between developers and miners and the fierce competition with the ethereum community have made Blockstream a center of controversy in crypto circles.

1.3 Contributions and Controversies from the Developer Community

Bitcoin development is an open and collaborative process, and anyone can make Pull Requests for code changes, reviews, or open testing. Since the program's inception, more than a thousand developers have contributed to it, improving software functionality, fixing bugs and adding new features, and interacting with the community to get feedback and resolve issues. The decision-making process is collaborative and often relies on consensus between developers and the wider community.

However, this openness has also led to controversy within the community, especially as new use cases such as Inscriptions have emerged.

Luke Dashjr and the Inscriptions Controversy: Bitcoin developer and Ocean Mining Pool co-founder Luke Dashjr has strongly criticized inscriptions such as Ordinals and BRC-20 tokens, calling them "spam" on Bitcoin. He argues that inscriptions exploit a vulnerability in Bitcoin Core that allows them to bypass the extra data size limit on transactions by disguising the data as program code. Dashjr argues that this "vulnerability" was fixed in Bitcoin Knots v25.1, and hopes that Bitcoin Core will also fix it before the release of v27. Dashjr argues that this "vulnerability" was fixed in Bitcoin Knots v25.1 and hopes that Bitcoin Core will also fix it before v27 is released. He even argues that once the vulnerability is fixed, Ordinals and BRC-20 tokens will cease to exist, as they "never really existed and are fraudulent.

Market Power of Ordinals and BRC-20 Tokens : Ordinals and BRC-20 tokens, while considered "spam" by conservatives, have shown great vitality in the market. According to Dune Analytics, as of December 2023, inscription-related transactions have generated an additional $172 million in revenue for miners, a real-money financial incentive that is reshaping the bitcoin ecosystem, and innovations such as Taproot Wizards continue to explore the boundaries of bitcoin's programmability, suggesting that market forces may be able to bypass the technological constraints of developers. In decentralized systems, economic incentives are becoming the most powerful weapon to break the shackles of ideology.

Deeper Implications of the Controversy: Some developers have insisted that Bitcoin should remain functionally pure, and that any non-core financial functions could threaten cybersecurity. This philosophy of "immutability" has avoided the ecological fragmentation that comes with frequent hard forks, but it is also facing serious challenges. When developers attempt to remove innovative applications such as inscriptions by fixing "bugs," they are effectively given de facto "functional vetting rights," a centralized tendency that runs counter to the decentralized spirit of Bitcoin. If developers succeed in blocking innovative apps, it will be clear that "immutability" has become a shackle on innovation. The outcome of this game will determine whether Bitcoin can maintain its security advantage while avoiding falling victim to technological conservatism. Against the backdrop of rapid innovation on competing public chains such as ethereum, the Bitcoin community needs to find a balance between preserving the core value of network security and stability, while leaving room for sensible innovation. After all, in a world ruled by code and arithmetic, the market will ultimately give the fairest verdict.

2. Bitcoin Improvement Proposals (BIPs): A Formal Upgrade Mechanism

2.1 Definition, Purpose, and Importance of BIPs

Bitcoin Improvement Proposals (BIPs) are standardized documents outlining potential changes, improvements, or additions to the Bitcoin protocol. They provide a collaborative platform for developers, researchers, and community members to propose, discuss, and implement changes, ensuring transparency and broad community consensus.BIPs enable the Bitcoin community to address emerging challenges and adapt to the changing needs of the community, allowing anyone to contribute to their development while ensuring that changes are made in a transparent manner with broad community consensus.

2.2 Types of BIPs

There are three main types of Bitcoin BIPs, each with a unique purpose:

• Standards Track BIPs: These BIPs describe changes that affect the consensus rules of the Bitcoin protocol. They propose changes to fundamental aspects of how Bitcoin works that require broad community consensus to implement. For example, Segregated Witness (SegWit) and Taproot upgrades fall into this category.
• Informational BIPs: Informational BIPs provide educational materials, general guides, or research findings related to Bitcoin. They provide developers and enthusiasts with valuable insights into various aspects of the Bitcoin ecosystem and help them deepen their understanding of the network. These BIPs do not change the code or rules of Bitcoin, but are more like suggestions or recommendations designed to educate the community.
• Process BIPs: Process BIPs propose changes to the development process of Bitcoin itself. They are intended to improve efficiency, governance, or decision-making mechanisms within the Bitcoin community. Process BIPs can address topics such as code review processes, project management methodologies, or community coordination initiatives. They are similar to standardized tracking BIPs in that they require community consensus, but differ in that they apply to processes outside of the Bitcoin protocol.

The process of categorizing and standardizing BIPs reflects the Bitcoin community's strategy for managing the evolution of complex technologies in a decentralized environment. By categorizing proposals into different types, the community is able to apply different levels of review and consensus intensity to changes of different natures. For example, standards-tracking BIPs that affect consensus rules require the highest consensus threshold because they can lead to network fragmentation, while informational BIPs are more lenient. This structured approach, while it may seem cumbersome, minimizes the risk of malicious or insufficiently considered changes to the core stability of the network.

3.3 Lifecycle and Activation Process of BIPs

A Bitcoin BIP goes through several different phases before it becomes part of the Bitcoin protocol:

• Draft Phase: In this phase, proposals are created and refined by their authors, and the BIP undergoes initial review and community feedback.
• Proposed Phase: During this phase, the BIP receives more attention from the community. It is presented to Bitcoin developers, researchers, and enthusiasts for further review and feedback. This phase allows for collective brainstorming and refinement of the proposal to ensure its robustness.
• Final Phase: Once the BIP has gained widespread support in the community and has been thoroughly vetted, it enters the final phase. During this phase, the proposal is included in the Bitcoin Improvement Proposal (BIP) repository, indicating that it is ready for implementation.
• Implementation and Activation: Bitcoin developers then integrate the changes into the Bitcoin protocol by consensus. For major changes at the protocol level, there is usually an activation threshold, and improvements only take effect when enough network participants have upgraded to the new version. Upgrades can be soft forks (backward compatible), such as SegWit, which allow older nodes to continue to operate, or hard forks (incompatible), which can lead to the network splitting and creating new cryptocurrencies, such as the Bitcoin Cash (BCH) hard fork in 2017.

This multi-stage BIP lifecycle and rigorous activation process is a core manifestation of Bitcoin's decentralized governance model. It ensures that any modifications to the protocol are not imposed by a select few, but rather through extensive discussion and voluntary adoption by multiple stakeholders. This mechanism effectively combines technical decision-making with social consensus, making the evolution of protocols an organic and highly censorship-resistant process. On the other hand, however, this consensus-driven model may result in slow upgrades, but it greatly enhances the resilience and trustworthiness of the Bitcoin network because it avoids the risk of network fragmentation or centralization that could result from mandatory changes. Each successful BIP activation proves that the community, through collaboration and compromise, is able to work together to maintain and grow this global, trust-less monetary system.

3. Major BIPs and Their Impact

The evolution of the Bitcoin protocol has been made possible through a series of key BIPs, proposals that have significantly improved the efficiency, privacy, and scalability of the network.

3.1 Activated Key BIPs

• BIP 16 (P2SH): Introduced the Pay-to-Script-Hash (P2SH) feature, which was activated in 2012.P2SH simplifies complex scripting operations and improves transaction efficiency and privacy by allowing senders to send funds to a scripted hash instead of a direct public key address. It improves transaction efficiency and privacy by allowing senders to send funds to a scripted hash rather than to a direct public key address. It saves space on the blockchain and enhances privacy by hiding the spend condition until the funds are spent.P2SH addresses typically begin with a "3" to distinguish them from traditional Bitcoin addresses (which begin with a "1"). The most common use case for P2SH is multi-signature transactions, where multiple signatures are required to execute a transaction, providing an additional layer of security for businesses and organizations. It is also key to the development of Layer 2 solutions such as the Lightning Network, which significantly increases Bitcoin's transaction capacity by conditionally locking in funds to support off-chain transactions.BIP 16 was implemented as a soft fork, meaning that older nodes can still validate and process transactions that follow the updated rules, maintaining backward compatibility.
• BIP 141 (SegWit): Addresses transaction malleability and scaling through Segregated Witness (SegWit), activated in 2017. Transaction malleability is the risk that the transaction ID (TXID) may change when the signature is modified, even though the effect of the transaction remains the same, which poses a risk to the off-chain protocol.SegWit fixes this problem by moving the unlock code (the signature) to a new "witness" field in the transaction data and excluding it from the calculation of the TXID. This makes the TXID reliable. In addition, SegWit actually increases the block size by introducing "weight units" instead of simple bytes to calculate the block size. Normal bytes are counted as 4 weight units, while witness bytes are counted as 1 weight unit, which translates into a 75% discount on unlocked data, thus making more room in the block for transactional data.SegWit is also being implemented as a soft fork, which means that legacy nodes that have not been upgraded will still treat SegWit blocks as valid, ensuring network compatibility. It lays the groundwork for Layer 2 protocols such as the Lightning Network, allowing it to be securely built on top of Bitcoin.
• BIP 340, 341, 342 (Taproot): Together, these BIPs make up the Taproot upgrade, which will be activated in November 2021.Taproot is the most significant upgrade since SegWit, and is designed to improve Bitcoin's privacy, efficiency, and scalability, as well as to increase the flexibility of smart contracts.
• BIP 340 (Schnorr Signatures): Introduced Schnorr signatures, a more secure and efficient signature scheme than traditional ECDSA signatures. The key advantage of Schnorr signatures is their key aggregation capability, which allows multiple public keys and signatures to be combined into one, making multi-signature transactions look the same as a normal, single-signature transaction on-chain. The key advantage of Schnorr signatures is their ability to combine multiple public keys and signatures into a single one, making multi-signature transactions look like normal single-signature transactions on the chain, improving privacy and reducing data volume.
• BIP 341 (Taproot): introduces a generic framework that integrates the mechanisms of Schnorr signatures, Merkleized Abstract Syntax Trees (MAST), and Pay-to-Taproot (P2TR). MAST allows for the concealment of unused complexity in a transaction, only revealing the relevant portion of the transaction at the time it is actually spent, improving privacy and reducing the amount of data on the chain. P2TR provides a new way to spend Bitcoin, combining the functionality of P2PK and P2SH to further enhance privacy and make all Taproot outputs look similar on the chain.
• BIP 342 (Tapscript): Modified the Bitcoin scripting language to be compatible with BIP 340 and BIP 341 to support Schnorr signatures, batch verification, and signature hash improvements.The introduction of Tapscript also lays the groundwork for further updates to Bitcoin scripting in the future.

These activated BIPs reflect the Bitcoin protocol's strategy of continuing to expand functionality and optimize efficiency while maintaining its core stability and security. By prioritizing soft forks over hard forks, the Bitcoin community has succeeded in introducing significant improvements while avoiding the risk of network fragmentation. This emphasis on backward compatibility is a key factor in the Bitcoin ecosystem's ability to remain stable. It demonstrates that the evolution of the protocol does not happen overnight, but rather is a process of iterative, deliberate changes that gradually lead to a stronger, more private, and more efficient network.

3.2 BIPs Being Discussed or Proposed

The Bitcoin community continues to discuss and propose new BIPs in response to changing needs and technical challenges.

• BIP-177 (Redefine Bitcoin's Base Unit): This proposal suggests redefining the smallest unit of Bitcoin, the satoshi, as a new base unit of 1 bitcoin, which would simplify the display of amounts, eliminate decimal points, and be more in line with the payments of the Lightning Network. This would simplify the display of amounts, eliminate the decimal point, and be more in line with Lightning's payment practices. The proposal involves only adjustments to the display of wallets and exchanges, and does not change the underlying protocol or the total amount limit of Bitcoin. Proponents argue that this would reduce cognitive load, eliminate "unit fear" for new users, and simplify the user experience by better aligning with the true design of counting in whole numbers within the Bitcoin protocol. For example, "0.00010000 BTC" would be displayed as "10,000 BTC". However, the proposal has also faced resistance, with the main objection being that it proposes to discard the "Satoshi" unit named after Satoshi Nakamoto, which could lead to confusion among users.
• OP_CAT (BIP-347): OP_CAT is an opcode that allows two pieces of data on the Bitcoin script stack to be merged into one. "CAT" stands for "concatenation." OP_CAT was originally part of the Bitcoin implementation, but was discontinued in 2010 due to concerns about potential vulnerabilities and denial-of-service attacks. In recent years, interest in reactivating OP_CAT has been rekindled with the introduction of the Taproot upgrade in 2021, which will introduce enhanced scripting capabilities and a size limit (520 bytes for Tapscript), alleviating previous security concerns.
• Potential Uses: OP_CAT is capable of a variety of complex functions, such as constructing and verifying Merkle trees directly on the stack to enable unilateral withdrawal paths, transaction dependency on other transactions already contained in the block, etc . It can also emulate "covenants" through the nature of Schnorr signatures, allowing for fine-grained introspection and commitment to individual fields of a transaction. This makes it possible to build more complex smart contracts and decentralized applications such as CatVM.
• Activation Path and Challenges: Reintroducing OP_CAT will require a soft fork . The process includes a formal BIP proposal with a thorough community review, implementation and extensive testing in Bitcoin Core, and broad consensus among miners, developers, and users. Although OP_CAT has been "heavily tested and researched" and is technically "straightforward," and OP_CAT was activated in the Bitcoin Signet on 5/1/24, its path to activation is still dependent on reaching a consensus in the Bitcoin Core. "broad consensus among miners, developers, and users." Some developers predict that Bitcoin Core developers may reach consensus on OP_CAT or OP_CTV in 2025, with actual implementation likely to take another 1-2 years .
• Promoter:
• Fractal Bitcoin has enabled OP_CT on its mainnet since September 2024 as a real-time testbed for new protocols that utilize its features .
• StarkWare has set up a $1 million OP_CAT research fund with the aim of advancing research on activating OP_CAT on Bitcoin. Meanwhile, on the other hand, by combining OP_CAT with its Proof of Zero Knowledge technology (STARK).
• CatVM is a trustless cross-chain bridge based on OP_CAT proposed by Taproot Wizards.
• BIP-420 (Unofficial BIP): The official number is actually BIP-347. BIP-420 was originally created by community members as an unofficial number for the OP_CAT proposal in the Bitcoin network to address the slow distribution of proposal numbers. Traditionally, BIP numbers were assigned by a single developer, Luke Dashjr, resulting in a wait of approximately six months for OP_CAT proposals to receive an official number. In early 2024, developer Anthony Towns created an alternative numbering system, BINANA, and assigned OP_CAT the number BIN-2024-0001.Subsequently, the Members of Taproot Wizards launched the "BIP-420" campaign, using the symbolic number "420" to build momentum for the proposal. At the same time, core developer Ava Chow proposed adding more BIP editors to speed up the numbering process. In the end, after the community push and the expansion of the editorial team, the OP_CAT proposal was officially assigned the number BIP-347 on April 24, 2024, marking the official recognition of the proposal and a broader discussion base.
• BIP-119 (OP_CTV): Proposed by Jeremy Rubin in 2021, this proposal enables more flexible transaction rules through CheckTemplateVerify and supports covenant functionality. In a similar vein to OP_CAT, this proposal aims to add an ethereum smart contract-like "covenant" feature to the Bitcoin network, such as allowing instructions to limit the transfer of funds to a specific address or automating transactions, such as timed transfers, in order to increase Bitcoin's programmability. Also currently inactive, community discussions are ongoing, with some developers turning to OP_CCV ( BIP-443 ) as an alternative.
• BIP-348 OP_CHECKSIGFROMSTACK (CSFS): a new opcode for Bitcoin, OP_CSFS, proposed by Jeremy Rubin and Brandon Black in November 2024. the opcode allows for verification of whether a signature is valid for an arbitrary message, not limited to the hash of the current transaction, by obtaining the signature from the data stack. the opcode is also used to verify that a signature is valid for a message, not just the hash of the current transaction, OP_CSFS is an important tool for enabling more flexible Covenants, enabling the creation of complex conditional logic to limit the spending of money, enhance security (e.g., Vaults and Decentralized Protocol Theft Prevention), and can be combined with opcodes such as OP_CAT to build more complex smart contracts. bip-119 (CTV) and bip-348 (CSFS), two opcodes that are relatively new to Bitcoin, have been proposed for Bitcoin. CSFS), both of which are more cautious and conservative relative to BIP-347 (OP_CAT), are instead expected to go live on the main Bitcoin network earlier than OP_CAT
• Quantum-Resistant Address Migration Protocol" (QRAMP).

A major proposal by a Bitcoin developer to protect Bitcoin from future quantum computing threats through a single hard fork, the plan is to force the Bitcoin network to migrate from older wallets encrypted using traditional ECDSA (Elliptic Curve Digital Signature Algorithm) to newer wallets that employ post-quantum cryptography techniques. Quantum computers threaten Bitcoin's security by utilizing the ability of quantum bits (qubits) to exist in multiple states at once, dramatically increasing computing power and potentially cracking existing encryption algorithms. The proposal sets a block height as the migration cutoff point, at which point nodes will refuse to process transactions that still use traditional cryptographic addresses, forcing users to migrate their funds to a more secure wallet. While this is a precautionary measure, and quantum computing is not yet at a point where it threatens Bitcoin, the proposal has sparked intense community discussion and concern about hard forks with recent breakthroughs in the field of quantum processors by companies such as Microsoft.

These ongoing discussions and proposed BIPs reflect the Bitcoin community's continued efforts to balance innovation, security, and decentralization.The reactivation of opcodes such as OP_CAT, OP_CTV, and others is intended to unlock more advanced functionality in Bitcoin scripts to support more complex smart contracts and applications. However, such functionality extensions must be done under strict security scrutiny to avoid repeating historical mistakes that could lead to potential denial-of-service attacks. At the same time, seemingly simple user interface changes like BIP-177 have sparked deep discussions about culture, user perception, and brand image, suggesting that Bitcoin's evolution is not just a technical issue, but also a reflection of social and cultural phenomena.

4. The Impact of Mining Pools on Protocol Upgrades

Miners play a key role in the activation of Bitcoin protocol upgrades, especially during the adoption of soft forks.

4.1 Miner Signaling and Activation Mechanisms

Bitcoin protocol upgrades are typically activated through a "signal vote" by miners. Miners indicate their support and readiness for a BIP by including specific signals in the blocks they mine (e.g., using a specified version number in the block header). For soft forks, a preset activation threshold (e.g., 95% of the blocks signaling over a period of time) usually needs to be reached in order to activate a new rule. Once this threshold is reached, the soft fork is implemented and the community (including miners, full nodes, exchanges, payment service providers, etc.) must upgrade their software to the new version.

4.2 Potential for Miner Veto

Miners have a de facto veto power in the activation of a soft fork. If the miners do not signal readiness, the upgrade cannot be activated . This is particularly evident in the activation of Segregated Witness (SegWit): miners initially have low support and do not signal readiness until the market shows weak demand for competing proposals. This phenomenon suggests that miners' decisions are not always based on purely technical considerations, but are significantly influenced by market dynamics and economic incentives.

4.3 Economic incentives for miners

Mining pools, as a collection of miners' computational resources, have enormous influence in the Bitcoin network, which gives them significant decision-making power in the adoption and activation of BIPs. At the same time, miners' behavior is often driven by financial incentives. For example, the rise of inscriptions has led to a significant increase in transaction fees on the Bitcoin network, generating significant revenue for miners, which has led many miners to embrace inscriptions even though some developers view them as "spam". This economic rationalization explains why, even though controversial, certain use cases are still supported by miners and included in blocks. By choosing which version of the software to run and whether or not to signal their support, they are in effect exercising a kind of "soft vote". This power is not absolute, as users and all nodes can enforce consensus by rejecting blocks that do not conform to their rules, but the collective behavior of miners is certainly a key variable in the evolution of the protocol.

5. A Lengthy Upgrade Process

Because Bitcoin is a decentralized network, any change requires a broad consensus among developers, miners, and users, and this consensus process is complex and time-consuming, making the Bitcoin upgrade process slow. Historically, such as the 2017 block size debate (which led to the Bitcoin Cash fork) has shown the risk of divergence, and the Taproot upgrade (activated in 2021) has taken years of discussion and testing. Additionally, technical complexities such as the potential security risks of OP_CTV and OP_CAT make it a long process for the Bitcoin community to move forward with these BIPs. As a result, Bitcoin wallet Xverse has launched a community petition site (https://whatthefork.wtf/) for people to sign a wallet signature indicating that they want the BTC soft fork to support OP_CTV and OP_CAT, to try to push it forward through the community's voice.

Due to slow upgrades, many Bitcoin ecosystem projects are designing complex solutions with current limited functionality. For example, BitVM (Bitcoin Virtual Machine) proposes to implement smart contract functionality through a prover-verifier model that computes off-chain and verifies on-chain without changing consensus rules. Another strategy is to use Bitcoin as a Data Availability Layer (DA), which utilizes the security of Bitcoin to store data and support sidechain or Rollup extensions.

6 Conclusion

The development and maintenance of Bitcoin is a unique and continuously evolving decentralized process. It is driven by a global community of open-source developers, and with no single entity controlling its development, Bitcoin's development model is a complex balancing act: technological innovation is prudently driven through a structured BIPs process and a multi-stakeholder consensus mechanism under the principles of openness, decentralization, and community-drivenness. As a result, this model has inevitably led to a slower pace of Bitcoin development, and we will need to continue to see if it is able to continue to adapt to new challenges and needs while ensuring the resilience, security, and censorship resistance of the Bitcoin network.