summary

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

ViaBTC Capital will dismantle the unique framework of Bitcoin’s decentralized development, review the core role and controversy of Bitcore Core in protocol maintenance, revisit the activation paths of key upgrades such as SegWit and Taproot, and delve into the debate over “programmability” caused by new BIPs such as OP_CAT, pointing directly to a soul-searching question: Is Bitcoin’s creed of “immutability means security” becoming the ultimate shackles of its ecological innovation? "

1. Overview of Bitcoin’s decentralized development model

1.1 Bitcoin Core’s core role in protocol maintenance

Bitcoin Core is the main software implementation of the Bitcoin protocol and is considered its reference client . It includes full node software for full 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 protecting against potential attacks. In addition, the project also maintains related software, such as the cryptography library libsecp256k1 .

Even though Bitcoin development is decentralized, Bitcoin Core is used by around 90% of all full nodes in the network as of June 2025, giving Bitcoin Core a unique, de facto influence due to its status as the “reference implementation”. This de facto authority means that once changes are merged into the Bitcoin Core codebase, they tend to become de facto standards, even without explicit enforcement by a central authority. This widespread and voluntary adoption means that the Bitcoin Core codebase effectively defines the operating 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 rigorous review and when merged, directly affects 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 The evolution of the maintainer role: from Satoshi to collective management

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

• Satoshi Nakamoto's start and exit: Satoshi Nakamoto, the mysterious creator of Bitcoin, initially developed and actively maintained the Bitcoin Core project until the end of 2010. In April 2011, Satoshi Nakamoto announced that he had "moved to other projects" and handed over the maintenance responsibility of Bitcoin Core to Gavin Andresen. This moment marked the first time that Bitcoin leadership shifted from Satoshi Nakamoto to the community, and was an important milestone in the decentralized development of the project.
• Gavin Andresen's succession and controversy: Gavin Andresen is regarded as the "successor" of Satoshi Nakamoto. He took over as the chief maintainer of Bitcoin Core and led the development of Bitcoin in the following years, making it more stable and widely accepted. However, in 2016, Gavin Andresen was involved in a major controversy when he publicly claimed that Australian Craig Wright was Satoshi Nakamoto. This claim was later widely questioned by the community, resulting in Gavin Andresen's submission permissions to the Bitcoin main code base 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 to be shared by multiple maintainers, further decentralizing the release process. Currently, only a few developers have the right to modify the Bitcoin Core code, and their responsibilities include merging contributors' patches and performing final checks to ensure that the patches are safe and meet the 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 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 left, the risks of this model became increasingly apparent. Distributing authority to multiple maintainers can reduce the risk of single points of failure and ensure that the decision-making process is more robust and censorship-resistant. However, this also means that the project may be slower to reach consensus and implement major changes. This inherent trade-off reveals the complexity of decentralized system governance: how to maintain sufficient efficiency and direction without sacrificing core decentralized principles.

At the same time, the composition of the maintainer team and the power dynamics within it also have a profound impact on the development direction and stability of the entire Bitcoin ecosystem. Blockstream is a company focused on Bitcoin and blockchain infrastructure, and many developers involved in Bitcoin Core maintenance have worked at the company. Blockstream has become an important force in Bitcoin Core code contributions by supporting these developers, which has also raised questions in the community about its development independence and the impact of corporatization. For example, Blockstream insisted on solving the Bitcoin expansion problem through the second-layer network and opposed directly expanding the main chain, which led to community divisions and Bitcoin forks; in addition, the trust crisis between developers and miners and the fierce competition with the Ethereum community have also made Blockstream a focus of constant controversy in the crypto circle.

1.3 Contributions and Controversies in the Developer Community

Bitcoin's development is an open and collaborative process where anyone can propose code changes, review or test open pull requests. Since the project began, more than a thousand developers have contributed to it, responsible for improving software functionality, fixing bugs and adding new features, and interacting with the community to get feedback and solve problems. The decision-making process is collaborative and often relies on consensus between developers and the broader community.

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

• Luke Dashjr and the inscription 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 believes that inscriptions exploit a vulnerability in Bitcoin Core to bypass the limit on the size of additional data in transactions by disguising data as program code. Dashjr claims that this "bug" has been fixed in Bitcoin Knots v25.1 and hopes that Bitcoin Core will also fix it before the release of v27. He even believes that once this vulnerability is fixed, Ordinals and BRC-20 tokens will no longer exist because they "never really existed and are all frauds."
• Market power demonstrated by inscriptions: Although Ordinals and BRC-20 tokens are regarded as "spam" by conservatives, they have shown strong vitality in the market. According to Dune Analytics, as of December 2023, inscription-related transactions have generated $172 million in additional income for miners. This real money economic incentive is reshaping the Bitcoin ecosystem. Innovative projects such as Taproot Wizards continue to explore the boundaries of Bitcoin programmability, indicating that market forces may bypass the technical limitations of developers. In decentralized systems, economic incentives are becoming the most powerful weapon to break the shackles of ideology.
• The deeper meaning of the dispute: Some developers insist that Bitcoin should maintain its functional purity, and any non-core financial functions may threaten network security. This "immutability" philosophy avoids the ecological division caused by frequent hard forks, but it is also facing severe challenges. When developers try to remove innovative applications such as inscriptions by fixing "bugs", they actually obtain the de facto "functional review rights". This centralized tendency runs counter to the decentralized spirit of Bitcoin. If developers successfully block innovative applications, it will be confirmed 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 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, while leaving room for reasonable innovation. After all, in a world ruled by code and computing power, the market will ultimately give the most fair verdict.

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

2.1 Definition, Purpose and Importance of BIPs

Bitcoin Improvement Proposals (BIPs) are standardized documents that outline potential changes, improvements, or new features for 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 society's changing needs, allowing anyone to contribute to its development while ensuring that changes are made in a transparent manner and with broad community consensus.

2.2 Types of BIPs

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

• 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 works and require broad community consensus to be implemented. For example, Segregated Witness (SegWit) and the Taproot upgrade fall into this category.
• Informational BIPs: Informational BIPs provide educational materials, general guidelines, 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 suggestions or recommendations, intended 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 cover topics such as code review processes, project management methods, or community coordination initiatives. They are similar to Standards Track BIPs in that they also require community consensus, but differ in that they apply to processes outside of the Bitcoin protocol.

The classification and standardization process of BIPs reflects the Bitcoin community's strategy for managing the evolution of complex technologies in a decentralized environment. By dividing proposals into different types, the community is able to adopt different levels of review and consensus strength for changes of different natures. For example, standard tracking BIPs that affect consensus rules require the highest consensus threshold because they may cause network splits; while informational BIPs are more relaxed. This structured approach, although it may seem cumbersome, minimizes the risk of malicious or poorly considered changes to the core stability of the network.

2.3 Lifecycle and Activation Process of BIPs

A Bitcoin BIP goes through several different stages before becoming part of the Bitcoin protocol:

1. Draft Phase: During this phase, the proposal is created and refined by the author. The BIP undergoes initial review and community feedback.
2. Proposed Phase: During this phase, the BIP gains more attention in the community. It is submitted 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.
3. Final Phase: Once a BIP has broad support in the community and has been thoroughly reviewed, 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.
4. Implementation and Activation: Bitcoin developers then integrate the changes into the Bitcoin protocol through consensus. For major changes at the protocol level, there is usually an activation threshold, and the improvement will only take effect when enough network participants upgrade to the new version. Upgrades can be soft forks (backwards compatible), such as SegWit, allowing old nodes to continue to operate, or hard forks (incompatible), which may result in a network split and the creation of a new cryptocurrency, such as the Bitcoin Cash (BCH) hard fork in 2017.

This multi-stage BIP lifecycle and strict activation process are the core embodiment of Bitcoin's decentralized governance model. It ensures that any modification to the protocol is not imposed by a few people, but is achieved through extensive discussion 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 because it avoids the risks of network splits or centralization that may result from mandatory changes. Every successful BIP activation proves that the community can work together to maintain and develop this global, trustless monetary system through collaboration and compromise.

3. Major BIPs and their impact

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

3.1 Important BIPs Activated

• BIP 16 (P2SH): Introduced the Pay-to-Script-Hash (P2SH) feature, activated in 2012. P2SH simplifies complex script operations and improves transaction efficiency and privacy by allowing senders to send funds to a script hash rather than a direct public key address. It saves blockchain space and enhances privacy by hiding the spending conditions until the funds are spent. P2SH addresses usually begin with "3" to distinguish them from traditional Bitcoin addresses (which begin with "1"). The most common use case for P2SH is multi-signature transactions, which require multiple signatures to execute a transaction, providing an additional layer of security for businesses and organizations. It is also key to the development of second-layer solutions such as the Lightning Network, which significantly increases Bitcoin's transaction capacity by conditionally locking funds to support off-chain transactions. BIP 16 was implemented as a soft fork, which means that old nodes can still verify and process transactions that follow the updated rules, maintaining backward compatibility.
• BIP 141 (SegWit): Activated in 2017, it addresses transaction malleability and scalability issues through Segregated Witness (SegWit). Transaction malleability refers to the fact that a transaction ID (TXID) may change after a signature is modified, even though the transaction effect remains unchanged, which poses a risk to the off-chain protocol. SegWit fixes this problem by moving the unlocking code (signature) to a new "witness" field in the transaction data and excluding it from the calculation of the TXID, making the TXID reliable. In addition, SegWit actually increases block capacity by introducing "weight units" instead of simple bytes to calculate block size. Ordinary bytes are counted as 4 weight units, while witness bytes are counted as 1 weight unit, which is equivalent to a 75% discount on the unlocking data, making more space for transaction data in the block. SegWit was also implemented as a soft fork, which means that old nodes that have not been upgraded will still consider SegWit blocks valid, ensuring network compatibility. It lays the foundation for second-layer protocols, such as the Lightning Network, to be securely built on top of Bitcoin.
• BIP 340, 341, 342 (Taproot): Together, these BIPs make up the Taproot upgrade that will be activated in November 2021. Taproot is the most important upgrade since SegWit, designed to improve Bitcoin's privacy, efficiency, and scalability, and enhance 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 their key aggregation capability, which can combine multiple public keys and signatures into one, so that multi-signature transactions look the same as ordinary single-signature transactions on the chain, improving privacy and reducing the amount of data.
  • BIP 341 (Taproot): Introduces a general framework that integrates mechanisms such as Schnorr signatures, Merkelized Abstract Syntax Trees (MAST), and Payment to Taproot (P2TR). MAST allows unused complex conditions in transactions to be hidden, revealing the relevant parts only when they are actually spent, thereby improving privacy and reducing the amount of on-chain data, which helps scalability. P2TR provides a new way to spend Bitcoin, combining the functions of P2PK and P2SH, further enhancing privacy, and making all Taproot outputs look similar on the chain.
  • BIP 342 (Tapscript): Modifies the Bitcoin script language to make it compatible with BIP 340 and BIP 341, thereby supporting Schnorr signatures, batch verification, and signature hashing improvements. The introduction of Tapscript also lays the foundation for further updates to Bitcoin scripts in the future.

These activated BIPs reflect the Bitcoin protocol's strategy of continuously expanding functionality and optimizing efficiency while maintaining its core stability and security. By prioritizing soft forks over hard forks, the Bitcoin community has successfully introduced major improvements while avoiding the risk of network splits. This emphasis on backward compatibility is a key factor in the stability of the Bitcoin ecosystem. It shows that the evolution of the protocol is not achieved overnight, but a process of gradually achieving a more powerful, more private, and more efficient network through iterative and prudent changes.

3.2 BIPs under discussion or proposed

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

• BIP-177 (Redefine Satoshi as the Basic Unit): This proposal proposes to redefine the smallest unit of Bitcoin, "satoshi", as the new basic unit "1 bitcoin", thereby simplifying the amount display, eliminating decimal points, and being more in line with the payment habits of the Lightning Network. The proposal only involves display adjustments to interfaces such as wallets and exchanges, and does not change the underlying protocol and total amount limit of Bitcoin. Supporters believe that this can reduce cognitive burden, eliminate the "unit fear" of new users, and simplify the user experience because it is more in line with the real design of counting in integer units within the Bitcoin protocol. For example, "0.00010000 BTC" will be displayed as "10,000 BTC". However, the proposal also faces resistance, with the main objection being that it proposes to abandon the "Satoshi" unit named after Satoshi Nakamoto, which may cause user confusion.
  
• 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" is short for "concatenation". OP_CAT was originally part of the Bitcoin implementation but was deactivated in 2010 due to concerns about potential vulnerabilities and denial of service attacks. In recent years, there has been renewed interest in reactivating OP_CAT with the introduction of enhanced script capabilities and size limits (520 bytes for Tapscript) in 2021, alleviating previous security concerns.
  
  • Potential uses: OP_CAT is capable of implementing a variety of complex functions, such as building and verifying Merkle trees directly on the stack to achieve unilateral withdrawal paths, transactions that depend on other transactions already included in the block, etc. It can also simulate "covenants" through the characteristics of Schnorr signatures, allowing fine-grained introspection and commitment to various fields of the 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 and thorough community review, implementation in Bitcoin Core and extensive testing, and broad consensus among miners, developers, and users. Although OP_CAT has been "extensively tested and studied" and is technically "simple and clear", OP_CAT was activated in Bitcoin Signet on May 1, 24, but its activation path still depends on whether "broad consensus can be reached among miners, developers, and users." Some developers predict that Bitcoin Core developers may reach a consensus on OP_CAT or OP_CTV in 2025, and actual implementation may take another 1-2 years.
  • Promoter:
    1. Fractal Bitcoin has enabled OP_CAT on its mainnet since September 2024, serving as a live testbed for new protocols that utilize its capabilities.
    2. StarkWare has set up a $1 million OP_CAT research fund to promote 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 number is actually BIP-347. BIP-420 was originally an unofficial number created by community members for the OP_CAT proposal in the Bitcoin network to solve the problem of slow proposal number allocation. Traditionally, BIP numbers are assigned by a single developer, causing the OP_CAT proposal to wait for about six months before receiving an official number. In early 2024, developer Anthony Towns created the alternative numbering system BINANA and assigned OP_CAT the number BIN-2024-0001. Subsequently, 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 a plan to add more BIP editors to speed up the number allocation process. Finally, after community promotion and the expansion of the editor group, the OP_CAT proposal was officially assigned the number BIP-347 on April 24, 2024, marking the official recognition and broader discussion basis of the proposal.
  
• BIP-119 (OP_CTV): Proposed by Jeremy Rubin in 2021, it implements more flexible transaction rules through "Check Template Verify" and supports covenant functions. The background is similar to OP_CAT. This proposal aims to add a "covenant" function similar to Ethereum smart contracts to the Bitcoin network, such as allowing instructions to limit funds to be transferred to specific addresses, or to automate transactions, such as timed transfers, thereby improving Bitcoin's programmability. It is also not activated at present, and community discussions are still ongoing. 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 verification that a signature is valid for any message, not just the hash of the current transaction, and obtains signatures, public keys, and messages from the data stack for verification. OP_CSFS is an important tool for implementing more flexible Covenants. It can create complex conditional logic to limit the spending of funds, 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). On the contrary, some people expect them to be launched on the Bitcoin mainnet 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 hard fork, planning to force the Bitcoin network to migrate from old wallets using traditional ECDSA (Elliptic Curve Digital Signature Algorithm) encryption to new wallets using post-quantum cryptography technology. Quantum computers use quantum bits (qubits) to exist in multiple states at the same time, greatly improving computing power and potentially cracking existing encryption algorithms, 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 encryption addresses, forcing users to migrate funds to safer wallets. Although this is a preventive measure and quantum computing has not yet reached the level of threatening Bitcoin, with recent breakthroughs in quantum processors by companies such as Microsoft, the proposal has sparked heated discussions and attention in the community about hard forks.
  

These BIPs under discussion and proposal reflect the Bitcoin community's ongoing efforts to balance innovation, security, and decentralization. The reactivation of opcodes such as OP_CAT and OP_CTV aims to unlock more advanced features of Bitcoin scripts, thereby supporting more complex smart contracts and applications. However, this functional expansion must be carried out under strict security review to avoid repeating historical mistakes and leading to potential denial of service attacks. At the same time, seemingly simple user interface changes like BIP-177 have also triggered deep discussions about culture, user perception, and brand image, which shows that the evolution of Bitcoin is not just a technical issue, but also a manifestation of social and cultural phenomena.

4. Impact of mining pools on protocol upgrades

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

4.1 Miner Signals and Activation Mechanism

Bitcoin protocol upgrades are typically initiated through a "signaling 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 blocks signaling over a period of time) is usually required to activate the new rules. 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 Possibility of Miner Veto

Miners have a de facto veto power in the activation of soft forks. If miners do not signal readiness, the upgrade cannot be activated. This was particularly evident during the activation of Segregated Witness (SegWit), where miners initially had low support and did not signal readiness until the market showed weak demand for competing proposals. This phenomenon shows 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' computing resources, have great 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, bringing considerable income to miners, which makes many miners happy to accept inscriptions, even if some developers regard them as "spam". This economic rationality explains why certain use cases are still able to gain miners' support and be included in blocks even if there are disputes. They actually exercise a kind of "soft voting power" by choosing which version of the software to run and whether to signal support. This power is not absolute, because 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. Lengthy upgrade process

Since Bitcoin is a decentralized network, any change requires broad consensus among developers, miners, and users. This consensus process is complex and time-consuming, so the Bitcoin upgrade process is slow. Historically, the block size dispute in 2017 (which led to the Bitcoin Cash fork) has shown the risk of divergence, and the Taproot upgrade (activated in 2021) has also taken years of discussion and testing. In addition, technical complexities such as the potential security risks of OP_CTV and OP_CAT also make it a long process for the Bitcoin community to promote these BIPs. Therefore, the Bitcoin wallet Xverse launched a community petition website ( https://whatthefork.wtf/ ), allowing everyone to sign through the wallet to indicate that they hope the BTC soft fork supports OP_CTV and OP_CAT, and to promote it through the community's voice.

Due to the slow upgrade, many Bitcoin ecosystem projects have designed complex solutions under the current limited functions. For example, BitVM (Bitcoin Virtual Machine) proposes to implement smart contract functions through the prover-verifier model, which performs calculations off-chain and verifies on-chain without changing the consensus rules. Another strategy is to use Bitcoin as a data availability layer (DA), using Bitcoin's security to store data and support sidechain or Rollup expansion.

6. Conclusion

The development and maintenance of Bitcoin is a unique and evolving decentralized process. It is driven by a global open source developer community. Since there is no single entity controlling its development, the Bitcoin development model is a complex balancing act: under the principles of openness, decentralization, and community-driven, through a structured BIPs process and a consensus mechanism of multiple stakeholders, prudently promote technological innovation. Therefore, this model inevitably leads to a slower pace of Bitcoin development, and we need to continue to observe whether it can continue to adapt to new challenges and needs while ensuring the resilience, security, and censorship resistance of the Bitcoin network.