What are the most important characteristics of Bitcoin?
TechFlow Selected TechFlow Selected
What are the most important characteristics of Bitcoin?
What is Bitcoin? What should it strive to become?
Navigating Web3 tides with focused insightsAuthor: Jameson Lopp
Translation: BTC Study
What is Bitcoin? Many have tried to answer this question, but I believe our quest for understanding is inherently endless. What is Bitcoin? What should it strive to become? The cutting-edge research and discussions will determine the evolution of the Bitcoin protocol.
Newcomers may find it difficult to discern which Bitcoin proposals are most likely to be adopted, as there are many unwritten rules governing changes to the Bitcoin protocol. Some rules lean more toward philosophy, others toward engineering and security, and some balance both.
Consensus Is Not Command and Control
There is no central authority in the Bitcoin system, and even the principles outlined here carry no official authority—they stem solely from my own observations and those of other participants within the ecosystem.
-
Bitcoin is a system that automatically and continuously discovers consensus among its participants. It enforces human consensus through machine consensus.
-
Failure of consensus leads to loss of trust in the Bitcoin system by participants, potentially destroying the entire system.
-
Changes to consensus code should be avoided whenever possible.
-
Users should never be forced into adopting protocol changes without their consent. In other words, users who wish to adopt changes should be free to join, rather than forcing unwilling users to exit.
-
Therefore, software clients should not auto-update, as this would transfer power from users into the hands of developers.
-
Because Bitcoin is inherently a distributed network, we cannot assume every user is constantly monitoring protocol changes.
How can we change the Bitcoin system? Before modifying consensus code, we must first achieve human consensus on the proposed change. This document details the process for Bitcoin Improvement Proposals (BIPs). While far from perfect, the process of forming consensus is highly complex.
Johnson Lau once wrote an article explaining different types of forks (methods of changing machine consensus), and Paul Sztorc further analyzed the varying degrees of coercion across different fork types.
What methods have historically been used for Bitcoin protocol upgrades?
-
On-chain miner voting (BIP 16)
-
Flag day upgrades (BIP 30)
-
IsSuperMajority (dual threshold switching) mechanism (BIP 34, BIP 65, BIP 66)
-
Version bits (BIP 9)
Who has the right to accept or reject protocol change proposals? Developers aim for "rough consensus"—meaning a proposal doesn't need 100% agreement, but it must gain sufficient support.
How do we measure ecosystem support for a given proposal? Developers engage in discussions with stakeholders who might be affected. Anyone following development can contribute via mailing lists, repositories, social media, and other channels.
Ultimately, protocol governance does not proceed top-down through predefined mechanisms. Quite the opposite of traditional governance models, Bitcoin's governance is bottom-up.
Minimizing Trust
“Bitcoin is peer-to-peer electronic cash that holds greater value than traditional systems because it grants users monetary self-sovereignty through decentralization. Bitcoin aims to solve the fundamental flaw of traditional money: reliance on trust. This isn’t to say trust is bad—it just makes systems fragile, opaque, and expensive to operate. When trust breaks, systems collapse. When trust gates access, inequality and closed monopolies emerge, creating bottlenecks that hinder legitimate participation.”
“Through cryptographic proofs and decentralized networks, Bitcoin minimizes and replaces trust costs wherever possible. Fundamentally, with current technology, we still face trade-offs between scalability and decentralization. If running the system becomes too costly, individuals can no longer independently enforce its rules and must rely on third parties. If the Bitcoin blockchain consumes vastly more resources than available technology allows, it loses competitiveness against traditional systems—because high validation costs (beyond what many users can afford) inevitably reintroduce trust. If throughput is too low and transaction mechanisms inefficient, resolving disputes on-chain becomes prohibitively expensive, allowing trust to creep back in.”
— Greg Maxwell
Bitcoin developer Matt Corallo has also emphasized the importance of minimizing trust:
“Among Bitcoin’s many features, trustlessness—requiring no trust beyond open-source software running locally—remains paramount. More specifically, much of the interest in Bitcoin stems from one core desire: eliminating the need to trust any individual or consortium of third parties. While this is widely acknowledged, understanding why trustlessness matters (and how it manifests) is crucial for developing and improving Bitcoin technology.”
Many of the other principles described in this article are rooted in the requirement to minimize trust. These principles arise from and aim toward reducing reliance on trust. We can never achieve 100% trustlessness, as no one has the resources to audit all the software and hardware they use to interact with the network. However, we can come very close. Thus, we can reasonably trust that transparent participants with aligned incentives won’t collude to harm the ecosystem.
Decentralization
An open system like Bitcoin cannot maintain its desirable properties if it becomes so centralized that a single entity or cartel controls the network. Decentralization is a means, not an end. By distributing power as widely as possible, we minimize the need to trust any single entity, knowing no party can interfere with our use of the system.
“Many assume electronic currency is doomed to fail because every company attempting it since the 1990s has failed. Let me clarify: the sole reason these e-currency ventures failed was centralized control. I believe this is our first attempt at building a decentralized system that doesn’t rely on trust.”
Potential dimensions of centralization—and ones that are difficult to quantify—include:
-
Exchanges
-
Developers
-
Software clients
-
Mining pools
-
Mining software
-
High-income nodes
-
Broad distribution of value ownership
-
Percentage of users controlling their own private keys
-
Percentage of users running nodes to audit the ledger
Any single metric being highly centralized doesn’t necessarily mean the entire system is centralized. But we must remember that a system is only as strong as its weakest link. Therefore, before making any change, we must carefully consider whether it could concentrate power along any dimension.
Censorship Resistance
No one should have the power to prevent others from interacting with the Bitcoin network or indefinitely block valid transactions from confirmation. While miners are free to choose which transactions to confirm, any valid transaction with sufficiently high fees will eventually be confirmed by rational miners.
Pseudonymity
Anyone holding or using Bitcoin should not be required to provide official identification. This principle strengthens censorship resistance and fungibility, as screening for “tainted” transactions becomes harder when the system itself doesn’t track users. It also implies: the system does not require its users to be human.
Open Source
The source code of Bitcoin clients should always be open for anyone to view, modify, copy, and share. Bitcoin’s value rests on transparency and audibility. Because we can fully audit the system, we don’t need to trust any entity to be honest. Economic incentives encourage participants to behave honestly, knowing misconduct brings consequences. What value does auditing serve if the code used to interact with the system cannot itself be audited by users?
Open Collaboration
While anyone can conduct private research and development, any attempt to change the protocol—especially non-backward-compatible changes—should be advanced publicly, not secretly. Bitcoin belongs to humanity, so all improvement proposals should be open to public scrutiny. Using the Bitcoin Improvement Proposal process is encouraged but not mandatory, as no authority exists to enforce it.
Spontaneous organization and resulting power dynamics may create the illusion that certain individuals or groups are in control, but this is an illusion.
Permissionless
No gatekeeper should prevent anyone—from participating in the network as traders, nodes, miners, etc. This is enabled by minimizing trust, censorship resistance, and pseudonymity.
Legal Neutrality
Bitcoin development does not consider the laws of any nation or jurisdiction, just like other internet protocols. Bitcoin does not cater to regulation; instead, regulators must adapt to the functionalities enabled by Bitcoin technology.
Fungibility
Fungibility is a crucial property of sound money. If every user had to analyze whether received bitcoins were “tainted,” Bitcoin’s utility would drastically diminish.
All UTXOs should be equal when spent. Unfortunately, this isn’t currently true—services now exist to track UTXOs linked to criminal activity. This discriminatory treatment has side effects: innocent users may be arrested for spending UTXOs derived several hops from a tainted one.
Fungibility requires privacy. Privacy means outsiders cannot identify the owner of any transaction within a large user base. The problem is, Bitcoin users’ privacy faces many known threats. Thus, today’s Bitcoin is far from fully fungible.
Forward Compatibility
Bitcoin allows signing transactions without broadcasting them. Therefore, any signed but un-broadcast transaction remains valid and can later be broadcast. Transactions with timelocks are prime examples—they can only be confirmed after a specified time, useful for inheritance or delayed actions. Changing this rule could have severe consequences: an unknown number of un-broadcast transactions would become invalid. No one wants to break user expectations and cause financial losses.
In fact, Bitcoin’s adherence to forward compatibility builds confidence in the protocol. Users can design and deploy any measures to protect their bitcoins without permission. As long as users follow protocol rules, the worst-case scenario is nodes stop relaying certain transactions by default.
Minimizing Resource Usage
To keep validation costs low, block space is a scarce resource. Thus, consuming large amounts of block space is expensive for everyone. A key principle is encouraging spending (consuming) UTXOs over creating new ones. This principle might shift if UTXO accumulators successfully address UTXO bloat.
Validation should be low-cost, enabling more users to afford auditing the system, supporting trust minimization. Low validation cost also raises the bar for resource exhaustion attacks. Bitcoin includes mechanisms to quickly reject cheap invalid blocks—a core idea behind hash cash, where attackers pay dearly to spam. Before syncing a block’s transactions, nodes can download the 80-byte block header, obtain proof-of-work, and perform fast, accurate validation.
Additionally, we should prioritize efficient block space usage, storing only the minimal data needed to verify complex operations on-chain, rather than storing and executing complex logic directly on-chain.
Verification > Computation
This falls under minimizing resource usage. Ideally, as few people as possible should execute complex logic. Other full-node operators shouldn’t retrace every step of logic—just ensure it was executed correctly. Correctness matters more than completeness.
“Let the blockchain do what it does best.”
— Andrew Poelstra
For any system, the best optimization is avoiding computation altogether. Blockchains excel at timestamped data storage for auditability. Rather than requiring all participants to compute irrelevant transaction logic, it’s sufficient to store proofs of computation that relevant parties can verify.
Convergence
Assuming two Bitcoin clients are connected to the same honest peer, they should eventually converge on the same chain tip. As a counterexample, Bitcoin ABC’s proposal for limiting chain reorganizations to the latest 10 blocks violates this principle. As a result, during network partitions or censorship events, affected miners continue mining alternate chains. After network reunification, the chains may not converge onto the chain with the most cumulative proof-of-work.
All transaction operations must be deterministic. Given identical system states, a transaction must execute in exactly one way, unaffected by external factors. Similarly, scripts should not behave differently across machines. The only solution is isolation—smart contracts and transactions must be independent of non-deterministic inputs.
Protocol changes should not introduce risks of transactions becoming invalid due to chain reorganization. Transaction operations should not only be deterministic but also stateless. For example, the 2010 OP_BLOCKNUMBER proposal.
Some have proposed opcodes that could invalidate transactions after reorganization. Such proposals are typically asked to be redesigned using OP_CLTV to ensure forward compatibility. Yet sometimes this is redundant or impractical. One suggestion is introducing an opcode preventing a transaction from being included within 100 blocks—similar to coinbase transactions or setting a 100-block timelock via OP_CSV.
Transaction Immutability
Given a block, the deeper it is buried under subsequent blocks, the less likely it is to become orphaned due to chain reorganization. While the Bitcoin protocol technically allows arbitrarily long reorganizations, excessively long ones could be disruptive, as some software or nodes may not handle them properly. Moreover, reorganizations deeper than 100 blocks are especially destructive—they invalidate previously spent coinbase transactions, destroying that value.
While immutability cannot be guaranteed technically, we can ensure that rolling back transactions becomes prohibitively expensive when sufficient cumulative proof-of-work exists.
Anti-DoS Protection
Remote peers should not be able to send messages that consume excessive local resources. However, the introduction of SPV Bloom filters broke this principle. Attackers can exploit this feature to force target peers to scan massive block data, consuming significant disk I/O. Search for “misbehave” to see numerous anti-DoS rules. Malicious behaviors are scored; once a peer’s score exceeds a threshold, your node disconnects to avoid further harm.
Avoiding Race Conditions
If system behavior depends on the order or timing of uncontrollable events, race conditions occur. In distributed, permissionless systems like Bitcoin, events are often unpredictable. The UTXO model helps avoid races because outputs can only be spent once—their state is binary (spent or unspent).
This is another reason transactions should not depend on system state: if state changes during reorganization, it could introduce races and complexity.
Robustness
-
Over the long term, money should remain stable.
-
We should approach change conservatively—to minimize systemic risk and allow users to continue using the system as they see fit.
-
Don’t expect users to actively mitigate system issues. Therefore, we must act cautiously and proactively avoid such problems!
What does robustness truly mean? It supports social scalability.
The secret to Bitcoin’s success is that it trades high energy consumption and poor computational scalability for something far more valuable: social scalability.
Many human-run systems suffer from a fundamental flaw: rules are applied inconsistently or subject to individual interpretation, undermining reliability.
If we can replace traditional accountants, regulators, investigators, police, and lawyers with computer science to secure financial systems, we can transform weak, manual, localized systems into strong, automated, global ones.
Aligned Incentives
Bitcoin works because its rules incentivize honest behavior. For instance, miners could theoretically launch double-spend attacks via chain reorganization, but doing so would be self-destructive—costing massive hardware and electricity investments while risking heavy losses. It’s far more profitable for miners to spend resources protecting the blockchain.
Entrenchment
It’s widely believed that as the ecosystem grows, changing the base protocol becomes increasingly difficult. As user positions and motivations diversify, fewer changes will be non-controversial. Therefore, improvements are more likely to occur on layers built atop Bitcoin.
Immutable Consensus Rules
-
Issuing more than the 21 million supply cap. While precision/divisibility might increase, ownership proportions must remain unchanged.
-
Introducing any rule that inevitably increases centralization. For example, requiring all blocks to be signed by a centralized authority.
-
Demurrage (deleting or redistributing bitcoins deemed “lost” or “never used”). Objectively, we cannot assume a UTXO’s private key is lost simply because it hasn’t been spent within a certain timeframe. At the time of writing, while over 1 million BTC are suspected lost, only around 5,000 BTC have been confirmed destroyed.
Conflicting Principles
Improving fungibility (via privacy) to make supply unauditable is impossible, just as enhancing fungibility at the cost of auditability is controversial.
Sometimes, we may want certain UTXOs to be unspendable for network protection—for example, P2PK bitcoins vulnerable to quantum attacks. Such proposals are contentious, but users might accept them if benefits clearly outweigh drawbacks.
Bitcoin’s validity isn’t permanent, as chain reorganizations could occur before coinbase transactions mature—i.e., before new bitcoins are created. The 100-block maturity rule for coinbase transactions helps prevent this. At publication, Bitcoin mainnet rarely sees reorganizations deeper than one block.
Finally, a major source of conflict within the Bitcoin ecosystem is that Bitcoin cannot satisfy everyone’s needs simultaneously. Otherwise, Bitcoin would decay, as many critical principles are mutually exclusive, such as:
-
Achieving both low system-wide validation costs and low transaction costs
-
Using rich programming languages while maintaining a small attack surface
Collaborative Progress
For users to continue trusting and using Bitcoin for transactions, the Bitcoin community must insist on changes only with broad consensus. Conversely, to prevent Bitcoin from stagnating, the community must be willing to reach consensus on changes that benefit the system without harming others, regardless of form. Crucially, this means that whenever possible, changes that enhance Bitcoin’s utility across use cases without diminishing it elsewhere should be implemented.
— Matt Corallo
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Jameson Lopp
