Miner Signals and Developer Intent: Who is Dominating the Innovation Chains of Bitcoin?

Summary

The development of Bitcoin is driven by a global open-source community, and changes to the protocol are standardized through Bitcoin Improvement Proposals (BIPs). These proposals must undergo rigorous community review and consensus mechanisms, including miner signaling votes. This open-source model, while promoting transparency and broad participation, also brings challenges in reaching consensus quickly and coordinating development. In a system without a central authority, the decision-making process can become lengthy and contentious.

ViaBTC Capital will break down the unique framework of decentralized Bitcoin development, reviewing the core role and controversies of Bitcore Core in protocol maintenance, revisiting the activation paths of key upgrades such as SegWit and Taproot, and delving into the ‘programmability’ controversy sparked by new BIPs like OP_CAT, pointing directly to a soul-searching question: Is Bitcoin’s doctrine of ‘immutability equals security’ becoming the ultimate shackles of 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 primary software implementation of the Bitcoin protocol and is considered its reference client. It contains full node software for full verification of the blockchain as well as a Bitcoin wallet. The majority of Bitcoin users and miners choose to use Bitcoin Core as their full node, which is essential for maintaining the decentralization of the network and defending against potential attacks. In addition, the project maintains related software, such as the cryptography library libsecp256k1.

! [Miner Signals vs. Developer Will: Who Dominates Bitcoin’s Innovation Shackles?] ](https://img.gateio.im/social/moments-55cfa3d6c350928738f6d2bc2008d9c4)

Even though Bitcoin development is decentralized, as of June 2025, around 90% of the network’s full nodes use Bitcoin Core, so Bitcoin Core’s status as a “reference implementation” has a unique, de facto impact. This de facto authority means that once changes are incorporated into Bitcoin Core’s codebase, they tend to become de facto standards, even if not explicitly mandated by a central authority. This widespread and voluntary adoption has allowed Bitcoin Core’s codebase to effectively define the rules and current state of the protocol. As a result, developers who contribute to the Bitcoin Core project, especially its maintainers, have significant influence. Their work, after being scrutinized and merged, has a direct impact on the overall functionality and security of the network. This creates a unique form of “soft centralization” around the Bitcoin Core project, but this centralization is constantly balanced by its transparent open-source nature and distributed peer review process.

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

The role of Bitcoin Core maintainers has undergone significant evolution, transitioning from the initial personal leadership of Satoshi Nakamoto to a collective management model shared by multiple maintainers.

Satoshi Nakamoto’s Initial and Exit: Satoshi Nakamoto, the mysterious creator of Bitcoin, initially developed and maintained the Bitcoin Core project until the end of 2010. In April 2011, Satoshi Nakamoto announced that he had “moved on to other projects” and handed over responsibility for the maintenance of Bitcoin Core to Gavin Andresen. This moment marks the first time that Bitcoin leadership has shifted from Satoshi Nakamoto to a community and is an important milestone in the project’s decentralized development. Gavin Andresen’s Succession and Controversy: Gavin Andresen is seen as Satoshi Nakamoto’s “heir”, he took over as the lead maintainer of Bitcoin Core and led the development of Bitcoin in the years that followed, making it more stable and widely accepted. However, in 2016, Gavin Andresen was embroiled in a major controversy when he publicly claimed that Australian Craig Wright was Satoshi Nakamoto. This claim was later widely questioned by the community, leading to Gavin Andreson’s commit privileges on the main Bitcoin repository 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 Andresen as the chief maintainer. Since then, the role of chief maintainer has gradually evolved into a collective effort shared by multiple maintainers, further decentralizing the release process. Currently, only a few developers have the permissions to modify the Bitcoin Core code, with responsibilities that include merging contributors’ patches, performing final checks to ensure the patches are safe and align with project goals.

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

At the same time, the composition of the maintainer team and the power dynamics within it also have a profound impact on the direction and stability of the entire Bitcoin ecosystem. Blockstream is a Bitcoin and blockchain infrastructure company that has worked for several developers involved in the maintenance of Bitcoin Core. By supporting these developers, Blockstream has become an important contributor to the Bitcoin Core code, raising questions in the community about its independence and corporatization implications. For example, Blockstream insists on solving the problem of Bitcoin scaling through the layer 2 network, and opposes the direct expansion of the main chain, which leads to community splits and Bitcoin forks. In addition, the crisis of trust between developers and miners, as well as fierce competition with the Ethereum community, has made Blockstream a point of constant controversy in crypto circles.

1.3 Contributions and Controversies of the Developer Community

The development of Bitcoin is an open and collaborative process where anyone can propose code changes, review, or test open pull requests. Since the project’s inception, over a thousand developers have contributed to it, responsible for improving software functionality, fixing bugs, and adding new features, while interacting with the community to gather feedback and address issues. The decision-making process is collaborative and typically relies on consensus between developers and the broader community.

However, this openness has also led to controversies within the community, especially after new use cases like Inscriptions emerged.

Luke Dashjr and the inscription controversy: Luke Dashjr, a Bitcoin developer and co-founder of the Ocean mining pool, has been heavily critical of inscriptions such as Ordinals and the BRC-20 token, calling them “spam” on Bitcoin. He argues that the inscription exploits a vulnerability in Bitcoin Core by disguising the data as program code to bypass the limits of the additional data size in transactions. Dashjr asserts that this “vulnerability” has been fixed in Bitcoin Knots v25.1 and hopes that Bitcoin Core will fix it before v27 is released as well. He even argues that once this vulnerability is fixed, Ordinals and BRC-20 tokens will cease to exist because they “never really existed and are both frauds.” Market power in the inscription: Ordinals and BRC-20 tokens, while considered “spam” by conservatives, are showing strong vitality in the market. According to Dune Analytics, as of December 2023, inscription-related transactions have generated $172 million in additional revenue for miners, an economic incentive of real money that is reshaping the Bitcoin ecosystem. Innovative projects such as Taproot Wizards continue to explore the boundaries of Bitcoin’s programmability, suggesting that market forces may be able to bypass developers’ technical limitations. In a decentralized system, economic incentives are becoming the most powerful weapon to break the shackles of ideology. The deeper meaning of the controversy: Some developers insist that Bitcoin should remain functionally pure, and that any non-core financial function could threaten cybersecurity. This philosophy of “immutability” avoids the ecological fragmentation caused by frequent hard forks, but it is also facing serious challenges. When developers try to purge innovative applications such as inscriptions by fixing “bugs”, they are effectively given de facto “feature moderation rights”, a centralization tendency that runs counter to Bitcoin’s decentralized ethos. If developers succeed in blocking innovative applications, “immutability” has become a shackle to innovation. The outcome of this game will determine whether Bitcoin can maintain its security advantage while avoiding falling prey to technological conservatism. In the context of the rapid innovation of competing public chains such as Ethereum, the Bitcoin community needs to find a balance: to maintain the core value of network security and stability, and to leave room for reasonable innovation. After all, in a world ruled by code and computing power, the market will ultimately give the fairest verdict.

2. Bitcoin Improvement Proposals (BIPs): Formal upgrade mechanism

2.1 Definition, Purpose, and Importance of BIPs

Bitcoin Improvement Proposals (BIPs) are standardized documents outlining potential changes, improvements, or new features 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 respond to emerging challenges and adapt to the changing needs of society, allowing anyone to contribute to its development while ensuring that changes are made in a transparent manner and have broad community consensus.

Types of BIPs

Bitcoin BIPs are mainly divided into three types, each with its unique purpose:

• Standards Track BIPs (Standards Track BIPs): These BIPs describe changes that affect the consensus rules of the Bitcoin protocol. They propose modifications to fundamental aspects of how Bitcoin operates and require broad community consensus for implementation. For example, Segregated Witness (SegWit) and Taproot upgrades fall into this category. Informational BIPs (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, helping them deepen their understanding of the network. These BIPs do not change Bitcoin’s code or rules, but are more like advice or recommendations designed to educate the community. Process BIPs (Process BIPs): Process BIPs propose changes to the development process of Bitcoin itself. They are designed to improve efficiency, governance, or decision-making mechanisms within the Bitcoin community. Process BIPs can address topics such as the code review process, project management methods, or community coordination initiatives. They are similar to standard tracking BIPs and also require community consensus, but the difference is that they are applied to processes outside of the Bitcoin protocol.

The classification and standardization process of BIPs reflects the strategies of the Bitcoin community in managing complex technological evolution in a decentralized environment. By categorizing proposals into different types, the community can apply varying degrees of review and consensus strength for changes of different natures. For instance, standards tracking BIPs that affect consensus rules require the highest consensus threshold, as they may lead to network splits; whereas informational BIPs have more lenient requirements. This structured approach, while it may seem cumbersome, minimizes the risks of malicious or poorly considered changes to the core stability of the network.

2.3 The Lifecycle and Activation Process of BIPs

A Bitcoin BIP needs to go through several different stages before it becomes part of the Bitcoin protocol:

1. Draft Phase (Draft Phase): In this phase, the proposal is created and refined by the author. The BIP will undergo initial review and community feedback.
2. Proposed Phase (: At this stage, the BIP gains more attention within the community. It is submitted to Bitcoin developers, researchers, and enthusiasts for further review and feedback. This stage allows for collective brainstorming and refinement of the proposal to ensure its robustness.
3. Final Phase )Final Phase(: Once the BIP has gained broad support in the community and has been thoroughly reviewed, it enters the final phase. At this stage, the proposal is included in the Bitcoin Improvement Proposal (BIP) repository, indicating that it is ready for implementation.
4. Implementation & Activation: Bitcoin developers then integrate the changes into the Bitcoin protocol via consensus. For significant changes at the protocol level, there is usually an activation threshold, and the improvements will only take effect when enough network participants upgrade to the new version. The upgrade can be a soft fork (backwards compatible), such as SegWit, which allows the old node to continue running; It can also be a hard fork (incompatible) that could lead to a split in the network, creating a new cryptocurrency, such as the Bitcoin Cash (BCH) hard fork in 2017.

![Mining Signals and Developer Intent: Who is Dominating the Innovation Shackles of Bitcoin?])https://img.gateio.im/social/moments-4f00671e10234a197f35d950c3ff412b(

This multi-stage BIP lifecycle and rigorous activation process is the core embodiment of Bitcoin’s decentralized governance model. It ensures that any changes to the protocol are not imposed by a few, but rather through extensive discussions and voluntary adoption by multiple stakeholders. This mechanism effectively combines technical decision-making with social consensus, making the evolution of the protocol an organic and highly censorship-resistant process. On the other hand, this consensus-driven model may lead to slow upgrades, but it greatly enhances the resilience and credibility of the Bitcoin network, as it avoids the risk of network fragmentation or centralization that could result from forced changes. With each successful BIP activation, it is a testament to the community’s ability to work together to maintain and grow this global, trustless monetary system through collaboration and compromise.

) 3. Main BIPs and Their Impact

The evolution of the Bitcoin protocol has been achieved through a series of key BIPs, which have significantly improved the network’s efficiency, privacy, and scalability.

3.1 Important BIPs Activated

BIP 16 ###P2SH(: Pay-to-Script-Hash (P2SH) was introduced, activated in 2012. P2SH simplifies complex scripting operations by allowing senders to send funds to a script hash instead of a direct public key address, improving transaction efficiency and privacy. It saves blockchain space and enhances privacy by hiding the spending conditions until the funds are spent. P2SH addresses usually start with “3”, which is distinguished from traditional Bitcoin addresses that start with “1”. The most common use case for P2SH is multisig transactions, which require multiple signatures to execute transactions, which provides an extra 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 funds to support off-chain transactions. BIP 16 is implemented as a soft fork, which means that older nodes can still validate and process transactions that follow the updated rules, maintaining backward compatibility. BIP 141 )SegWit(: SegreGated Witness (SegWit), which addresses transaction malleability and scaling, was activated in 2017. Transaction plasticity refers to the fact that the transaction ID (TXID) may change after the signature is modified, although the transaction effect remains the same, which poses a risk to the off-chain protocol. SegWit fixes this issue by moving the unlock code (signature) to the new “witness” field of the transaction data and excluding it from the calculation of TXID, making TXID reliable. In addition, SegWit actually increases the block size by introducing “weight units” instead of simple bytes to calculate the block size. Ordinary bytes count as 4 weight units, while witness bytes count as 1 weight unit, which equates to a 75% discount on unlocked data, freeing up more space in the block for transaction data. SegWit is also implemented as a soft fork, which means that older nodes that have not been upgraded will still consider the SegWit block as valid, ensuring network compatibility. It lays the foundation for Layer 2 protocols, such as the Lightning Network, allowing it to be securely built on top of Bitcoin.

• BIP 340, 341, 342 )Taproot(: These BIPs together constitute the Taproot upgrade activated in November 2021. Taproot is the most significant upgrade since SegWit, aimed at improving Bitcoin’s privacy, efficiency, and scalability, as well as enhancing the flexibility of smart contracts.
  • BIP 340 )Schnorr Signatures(: Introduces Schnorr signatures, a more secure and efficient signature scheme than traditional ECDSA signatures. The key advantage of Schnorr signatures is its key aggregation capability, which allows multiple public keys and signatures to be merged into one, making multisig transactions look indistinguishable on-chain as normal single-signature transactions, improving privacy and reducing the amount of data.
  • BIP 341 )Taproot(: Introduces a common framework that integrates mechanisms such as Schnorr signatures, Merkelized Abstract Syntax Trees (MAST), and Pay-to-Taproot (P2TR). MAST improves privacy and reduces the amount of on-chain data, helping with scalability by allowing unused complex conditions in transactions to be hidden, revealing relevant parts only when they are actually spent. P2TR provides a new way to spend Bitcoin, combining the features of P2PK and P2SH, further enhancing privacy and making all Taproot outputs look similar on-chain.

• BIP 342 )Tapscript(: Modifies the Bitcoin scripting language to be compatible with BIP 340 and BIP 341, thereby supporting Schnorr signatures, batch validation, and improvements in signature hashing. 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 continuous feature expansion and efficiency optimization while maintaining the stability and security of its core. By giving preference to 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 stability of the Bitcoin ecosystem. It shows that the evolution of the protocol does not happen overnight, but rather a gradual process of achieving a stronger, more private, and more efficient network through iterative, deliberate changes.

)# 3.2 BIPs Under Discussion or Proposal

The Bitcoin community continues to discuss and propose new BIPs to address the evolving demands and technological challenges.

BIP-177 ### Redefine Satoshi Base Unit (: The proposal proposes to redefine the satoshi, the smallest unit of Bitcoin, to a new base unit, 1 Bitcoin, simplifying the display of amounts, eliminating decimal points, and being more in line with the Lightning Network’s payment habits. The proposal only involves the display adjustment of interfaces such as wallets and exchanges, and does not change the underlying protocol and total volume limit of Bitcoin. Proponents argue that this reduces cognitive load, eliminates “unit fear” for new users, and simplifies the user experience, as it is more in line with the real-world design of counting in integer units inside the Bitcoin protocol. For example, show “0.00010000 BTC” as “10,000 BTC”. However, the proposal also faces resistance, with the main objection being that it proposes to scrap the “Satoshi” unit named after Satoshi Nakamoto, which could cause confusion among users. **OP_CAT )BIP-347(:**OP_CAT is an opcode that allows merging two pieces of data on the Bitcoin script stack into one piece. “CAT” is an abbreviation for “concatenation”. OP_CAT was originally part of Bitcoin’s implementation, but was deactivated in 2010 due to concerns about potential vulnerabilities and denial-of-service attacks. In recent years, interest in reactivating OP_CAT has reignited as the Taproot upgrade introduced enhanced scripting features and size limits (520 bytes for Tapscript) in 2021, alleviating previous security concerns.

• Potential Use Cases: OP_CAT can implement various complex functions, such as directly constructing and verifying Merkle trees on the stack, enabling unilateral withdrawal paths, and transactions dependent on other transactions already included in the block, etc. It can also simulate “covenants” through the characteristics of Schnorr signatures, allowing for fine-grained introspection and commitment to individual fields of transactions. This makes it possible to build more complex smart contracts and decentralized applications, such as CatVM.
  • Activation Path & Challenge: Reintroducing OP _CAT will require a soft fork. The process includes a formal BIP proposal with a thorough review by the community, implementation in Bitcoin Core and extensive testing, and broad consensus among miners, developers, and users. Although the OP _CAT has been “extensively tested and researched” and technically “straightforward”, with the OP _CAT activated on Bitcoin Signet on 5/1/24, its activation path still depends on “broad consensus among miners, developers, and users”. Some developers predict that Bitcoin Core developers may reach a consensus on OP_CAT or OP_CTV by 2025, and that the actual implementation may take another 1-2 years.
  • Facilitator:
    1. Fractal Bitcoin has enabled OP_CAT on its mainnet since September 2024 as a real-time testing platform for new protocols leveraging its features.
    2. StarkWare has established a $1 million OP_CAT research fund aimed at promoting research on activating OP_CAT on Bitcoin. At the same time, on the other hand, by combining OP_CAT with its zero-knowledge proof technology (STARK).
    3. CatVM is a trustless cross-chain bridge based on OP_CAT proposed by Taproot Wizards.

• BIP-420 ) Unofficial BIP(: The official designation is actually BIP-347. BIP-420 was originally an unofficial number created by community members for OP_CAT proposals in the Bitcoin network to solve the problem of slow proposal number allocation. Traditionally, BIP numbers have been assigned by a single developer, resulting in an OP_CAT proposal waiting about six months for an official number. In early 2024, developer Anthony Towns created an alternative numbering system, BINANA, and assigned the OP_CAT the number BIN-2024-0001. Subsequently, members of the 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 to add more BIP edits to speed up the numbering process. Eventually, the OP_CAT proposal was officially assigned the designation BIP-347 on April 24, 2024, following community promotion and the expansion of the editorial team, marking the official acceptance of the proposal and a broader basis for discussion.
• BIP-119 )OP_CTV(: Proposed by Jeremy Rubin in 2021, it implements more flexible transaction rules through “CheckTemplateVerify” and supports the covenant function. In a similar context to OP_CAT, the proposal aims to add a “contract” feature similar to Ethereum smart contracts to the Bitcoin network, such as allowing instructions to restrict the transfer of funds to specific addresses, or automating transactions, such as timed transfers, thereby improving Bitcoin’s programmability. It is also not activated at this time, community discussions are still ongoing, and some developers have turned to support OP_CCV (BIP-443) as an alternative.
• BIP-348 OP_CHECKSIGFROMSTACK )CSFS(: A new Bitcoin opcode OP_CSFS proposed by Jeremy Rubin and Brandon Black in November 2024. This opcode allows you to verify that the signature is valid for any message, not just the hash of the current transaction, and to obtain the signature, public key, and message from the data stack for verification. OP_CSFS is an important tool for implementing more flexible covenants, with the ability to create complex conditional logic to limit capital spending, enhance security (such as vaults and decentralized protocol anti-theft), and can be combined with opcodes such as OP_CAT to build more complex smart contracts. BIP-119 (CTV) and BIP-348 (CSFS) are more cautious and conservative than BIP-347 (OP_CAT), and some people expect to launch Bitcoin mainnet sooner than OP_CAT Quantum-Resistant Address Migration Protocol (QRAMP) :* a major proposal from a Bitcoin developer to protect Bitcoin from future quantum computing threats through a hard fork. The plan is to force the Bitcoin network to migrate from an old wallet that uses traditional ECDSA (Elliptic Curve Digital Signature Algorithm) encryption to a new wallet that uses post-quantum cryptography. Quantum computers use qubits to be able to exist in multiple states at the same time, greatly increasing computing power and potentially cracking existing encryption algorithms, thus threatening the security of Bitcoin. The proposal sets a block height as a migration cutoff point, at which point nodes will refuse to process transactions that still use traditional crypto addresses, forcing users to migrate funds to more secure wallets. While this is a precautionary measure, and quantum computing has not yet reached the level of a threat to Bitcoin, the proposal has sparked intense discussion and attention in the community about a hard fork with recent breakthroughs in the field of quantum processors by companies such as Microsoft.

![Miner Signals and Developer Intent: Who is Dominating Bitcoin’s Innovation Shackles?])https://img.gateio.im/social/moments-1c444d265b9cf1f0227f706b53651e0d(

These BIPs, which are being discussed and proposed, reflect the Bitcoin community’s ongoing efforts to balance innovation, security, and decentralization. The reactivation of opcodes such as OP_CAT, OP_CTV, etc., is designed to unlock more advanced features of Bitcoin Script, thereby supporting more complex smart contracts and applications. However, this expansion of functionality must be carried out under strict security scrutiny to avoid repeating the mistakes of history 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 social and cultural phenomenon.

) 4. The Impact of Mining Pools on Protocol Upgrades

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

4.1 Miner Signals and Activation Mechanism

Protocol upgrades for Bitcoin are usually initiated through a “signal vote” by miners. Miners indicate their support and readiness for a certain BIP by including a specific signal in the block they mine (e.g., using a specified version number in the block header). For soft forks, it is usually necessary to reach a preset activation threshold (e.g., signaling 95% of blocks over a period of time) in order for a new rule to be activated. 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 The Possibility of Miners’ Veto Power

Miners have de facto veto power in the activation of soft forks. If miners do not issue a readiness signal, the upgrade cannot be activated. This was particularly evident during the activation process of Segregated Witness (SegWit): miners initially showed low support until the market exhibited weak demand for competitive proposals before they issued a readiness signal. This phenomenon indicates that miners’ decisions are not always based solely on 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’ computing resources, have a huge influence in the Bitcoin network, which gives mining pools significant decision-making power in the adoption and activation of BIPs. At the same time, miners’ behavior is often driven by economic 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 made many miners happy to accept inscriptions, even if some developers dismiss them as “spam”. This economic justification explains why, even if there is controversy, certain use cases are still able to gain support from miners and be included in blocks. They effectively exercised a kind of “soft voting” by choosing which version of the software to run, and whether or not to signal their support. This power is not absolute, as users and full nodes can enforce consensus by rejecting blocks that do not conform to their rules, but the collective behavior of miners is undoubtedly a key variable in the evolution of the protocol.

5. Long upgrade process

Since Bitcoin is a decentralized network, any changes require a broad consensus among developers, miners, and users, which is complex and time-consuming, so the Bitcoin upgrade process is slow. Historically, such as the 2017 block size battle (which led to the Bitcoin Cash fork), the risk of divergence, and the Taproot upgrade (activated in 2021) has been discussed and tested for years. In addition, technical complexities such as OP_CTV and potential security risks for 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 (

Due to slow upgrades, many Bitcoin ecosystem projects design complex solutions with limited functionality at present. For example, BitVM (Bitcoin Virtual Machine) proposes to implement smart contract functionality through a provers-validator model, computational off-chain and on-chain verification, without changing the consensus rules. Another strategy is to use Bitcoin as a data availability layer (DA), which leverages Bitcoin’s security to store data and support sidechain or rollup scaling.

6. Conclusion

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