Bitcoin Vulnerabilities — Attack Vectors and Real Bugs

A neutral examination of Bitcoin's weaknesses: the 2010 overflow bug, 51% attacks, network- and mining-layer attacks, quantum risk, and the user layer.

15 min readLast updated: August 15, 2026

Key points

Bitcoin has run for over 17 years but not unscathed — serious bugs like the 2010 integer overflow and 2018's CVE-2018-17144 actually occurred, each detected and fixed within hours to days. Alongside protocol-level risks like 51% attacks, network-layer attacks, and quantum computing, it shows that most bitcoin ever lost was lost to user-side failures such as phishing and poor key management, not to protocol breaks.

Not a Perfect System — Why Honest Weaknesses Matter

This site's editorial policy is neutrality. Our purpose is neither to praise Bitcoin nor to dismiss it, but to treat verifiable facts—favorable and unfavorable alike—by the same standard. This page covers the latter: Bitcoin's known weaknesses and the failures that actually occurred.
The Bitcoin network has run for more than 17 years, but not unscathed. Serious bugs surfaced in live operation at least twice, and a third was found and fixed before anyone exploited it. All of these remain in the public record; none were hidden.
Knowing the vulnerabilities has practical value. It lets you size the risk correctly, and it surfaces an uncomfortable fact: the most breakable part of the system is usually not the protocol but your own operational practices.
This page outlines attack techniques; it is not a how-to guide. Individual misconceptions are examined in Bitcoin Myths & Facts, the course of specific events in Incidents & Turning Points, and the history of governance conflict in Forks & Chain Divergence.

Serious Bugs That Actually Happened

On August 15, 2010, block 74638 was found to contain a transaction creating 184,467,440,737.09551616 BTC (roughly 184 billion BTC) across three addresses. The cause was that the validation code did not account for output values so large that their sum overflowed. For a period, Bitcoin's foundational 21 million cap was broken by an implementation defect.
A corrected client was published within about five hours of the discovery, introducing a consensus rule change that rejected transactions with overflowing outputs. The valid chain overtook the invalid one at block 74691, and the enormous amount created does not exist on today's chain.
On March 11, 2013, the chain split starting at block 225430. Version 0.8 used LevelDB, while 0.7 and earlier used Berkeley DB, whose database lock limit prevented them from processing a block with an unusually high number of inputs—so they rejected it. According to BIP 50, the post-mortem document, the 0.8 side held roughly 60% of hash power, so the split would not resolve itself; major pools deliberately downgraded to 0.7 to move the majority back to the older chain. At least one large double spend occurred during the incident (the perpetrator is understood to have been experimenting rather than stealing).
In September 2018, CVE-2018-17144 was fixed. The root cause was an optimization in Bitcoin Core 0.14 that dropped the check for whether a single transaction spent the same output twice. Per the official disclosure, versions 0.14.x through 0.16.2 carried a denial-of-service flaw that crashed nodes validating such a block, and versions 0.15.x through 0.16.2 additionally carried an inflation flaw that, under the right conditions, let a miner create BTC beyond the cap. It was reported privately as a DoS bug on September 17, fixed in version 0.16.3 on September 18, and fully disclosed on September 20 (there is no evidence it was ever exploited on mainnet).
What these three cases show is that consensus rules are implemented as code, so implementation bugs can break the rules themselves. At the same time, each was detected and fixed within hours to days, and the network recovered—that is part of the same record and should be read alongside it.

51% Attacks — Theory Versus Reality

A 51% attack is one in which an adversary controlling a majority of hash power extends a chain favorable to itself faster than everyone else. What this enables is narrower than commonly assumed: reversing transactions the attacker itself sent (double spending), excluding specific transactions from blocks (censorship), and orphaning other miners' blocks.
What it cannot do matters more. It cannot move coins without the owner's private key, cannot issue BTC that does not exist, and cannot unilaterally change the 21 million cap or any other rule—because full nodes reject rule-breaking blocks even when the majority produced them.
On cost: as of August 2026 the total network hash rate stands at roughly 900 EH/s by mempool.space's estimate (hash rate is inferred rather than measured, so figures range from about 900 to 1,000 EH/s depending on the source and window). An attacker would need to assemble comparable hardware, power, and sites, and a visible attack would simultaneously damage the value of BTC and of the attacker's own equipment. This is why the economics are usually described as working against such an attack.
No 51% attack has occurred on BTC. In 2014, the large pool GHash.io briefly exceeded 50% of hash power and set off considerable debate, but no attack followed and the pool publicly committed to keeping its share below 40%.
On smaller Proof of Work chains, however, attacks have happened for real. Bitcoin Gold suffered double spends of roughly 388,000 BTG (about $18 million at the time) in May 2018, and Ethereum Classic was attacked repeatedly in January 2019 and August 2020, causing losses at exchanges. The lesson is not that Proof of Work is safe, but that the safety of Proof of Work depends on the scale and distribution of hash rate. Because markets exist for renting hash power by the hour, smaller chains are structurally exposed.
For BTC itself, the live concern is mining pool concentration. Over the trailing week as of August 2026, mempool.space's data shows the largest pool at about 24% of blocks found, the top three at just under 60%, and the top five at just under 80%. Two counterweights belong in the same assessment: pools do not own their hash rate—participants can leave at any time—and standards that return block construction authority to individual miners (such as Stratum V2) are seeing growing adoption.

The Network Layer — Cutting Off Information

A Sybil attack is one in which an adversary spins up large numbers of fake nodes to inflate its presence on the network. In Bitcoin this alone cannot overturn consensus, because the majority that matters is hash power rather than node count—but it is the precondition for the eclipse attack below.
An eclipse attack fills all of a target node's connections with attacker-controlled peers, letting the attacker control what that node sees of the blockchain. The paper by Heilman and colleagues at USENIX Security 2015 quantified the resources such an attack requires, and Bitcoin Core has since steadily strengthened peer selection and address management diversity.
Internet routing, including BGP, sits outside Bitcoin, so manipulating it can produce an attack without touching a line of Bitcoin's code. As a real example, Secureworks (now Sophos) research found that between February and May 2014 an unknown party issued fraudulent BGP announcements against 51 networks belonging to 19 ISPs, redirecting miners' connections to attacker-controlled pools and taking roughly $83,000 in cryptocurrency. That was not a partitioning of the network but a route hijack that siphoned off miners' hash power and rewards.
Using the same routing layer to split the network itself—the partition attack—has been demonstrated in research such as Apostolaki and colleagues' 2017 work, "Hijacking Bitcoin: Routing Attacks on Cryptocurrencies." That work argues that a successful partition could isolate blocks on one side and thereby enable double spends or waste mining effort.
Current mitigations include diversifying connectivity (multiple ISPs, Tor, satellite reception), the encrypted P2P transport specified in BIP 324, and block-relay-only connections. Internet routing itself, however, sits outside Bitcoin and cannot be fully controlled at the protocol level.

The Mining Layer — Gaps in Incentive Design

Selfish mining was set out by Ittay Eyal and Emin Gün Sirer in their 2013 paper "Majority is not Enough: Bitcoin Mining is Vulnerable." The strategy is to withhold discovered blocks so that other miners waste work, letting the withholder earn more than its proportional share. The paper argued that without countermeasures the attack can pay off with roughly a quarter to a third of hash power, depending on the attacker's advantage in block propagation, and proposed a protocol modification alongside it.
Several reasons are offered for why it has not been observed at scale: executing it requires an advantage in block propagation; pool behavior is comparatively easy to detect from public statistics; and if discovered, participants leave, damaging both the pool's own revenue and the value of BTC. The gap between theoretical feasibility and operational incentives is worth stating explicitly.
The time-warp attack exploits an off-by-one flaw in how the difficulty adjustment measures elapsed time. Difficulty is retargeted every 2,016 blocks, but the elapsed time is computed from the timestamp of the first block in the period—so an attacker with majority hash power can push that timestamp backward, make the period appear longer than it was, drive difficulty down improperly, and compress block intervals dramatically.
The soft fork proposal that includes a fix is BIP 54 (Consensus Cleanup), which closes it by forbidding the first block of a retarget period from carrying a timestamp earlier than the previous block's, with a two-hour grace period. Originally proposed by Matt Corallo in 2019 and reworked by Antoine Poinsot from 2024, it was assigned a BIP number in April 2025 and merged into the BIPs repository later that month. Its status is "Complete" as a specification, but it has not been activated and remains under review and discussion as of 2026.
Fee sniping is the strategy of declining to build on a block with unusually large fee revenue and instead re-mining it to capture those fees. Its relative appeal is expected to grow as the block subsidy shrinks; wallets mitigate it by setting a transaction's nLockTime to the current block height, making it harder for a re-org to sweep the transaction along.
What these share is that they are not protocol bugs but gaps in incentive design. Fixing them requires changing consensus rules—that is, broad agreement—so even well-known flaws can take a long time to address.

Quantum Computing Risk — What Is at Risk, and When

What quantum computers threaten is the elliptic curve cryptography (ECDSA) used for signatures. Their impact on SHA-256, used in mining, is considered limited. The risk is not that mining gets taken over, but that private keys could be derived from public keys.
Breaking it is estimated to require a fault-tolerant machine on the order of tens of thousands to hundreds of thousands of physical qubits, with estimates varying by hardware architecture and study. Real machines keep growing in qubit count across several architectures, but the number of error-corrected "logical" qubits remains orders of magnitude smaller, leaving a substantial distance to practical large-scale systems (the range of published estimates is covered in Bitcoin Myths & Facts).
Exposure is not uniform. The coins at risk first are those whose public keys are already visible on-chain: early pay-to-public-key (P2PK) outputs that received mining rewards directly to a public key, and pay-to-public-key-hash outputs whose addresses were reused after signing. A Deloitte analysis estimated that over 4 million BTC—roughly a quarter of the circulating supply, comprising about 2 million BTC in P2PK and about 2.5 million BTC in reused P2PKH—fall into this category, and some counts run higher depending on methodology.
The migration itself is considered technically feasible as a soft fork to quantum-resistant signatures. The hard part is agreement: which algorithm to adopt, how to handle the block capacity impact of larger signatures, and whether exposed coins that no owner can move (including early mined coins) should be frozen or left as they are.
In other words, this is a governance problem as much as a technical one. Expert views differ on when a practical threat might materialize, and this site does not assert any particular timeline.

The Largest Attack Surface Is the User

Most of the Bitcoin lost to date was lost not to protocol failure but to user-side failure: lost private keys, inadequate backups, phishing, and malware. However strong the cryptography, keys are handled by humans—and that is where the system breaks most easily.
Phishing and social engineering are the most common entry points: fake wallet apps, fake support desks, fake sites prompting for a seed phrase. Even a hardware wallet offers no protection once a person types the seed phrase into a screen.
SIM swapping is a technique in which an attacker deceives a mobile carrier into porting the victim's phone number to a device they control, defeating SMS-based two-factor authentication and password resets. In the case of crypto investor Michael Terpin, roughly $24 million was stolen; litigation over the carrier's responsibility ran for years, and on September 30, 2024 the U.S. Ninth Circuit Court of Appeals revived his claim under the Federal Communications Act. SMS-based two-factor authentication is among the weakest authentication methods available.
Supply chain compromise is a real threat as well. In July 2020, hardware wallet maker Ledger disclosed that its e-commerce and marketing database had been breached, exposing about 1 million email addresses plus detailed records—names, postal addresses, phone numbers—for roughly 9,500 customers. In December of that year the stolen data circulated as a public dump, revealing that the detailed records ran to roughly 272,000 entries. Funds and private keys were unaffected, but a wave of targeted phishing followed, including counterfeit devices mailed to victims, showing how leaked customer data can become a physical target list.
The software supply chain is no different. On September 8, 2025, a set of npm packages with more than 2.6 billion combined weekly downloads (18 packages including chalk and debug) were tampered with following a phishing attack on a maintainer, injecting code that rewrote cryptocurrency payment destinations in the browser. It was detected and removed in about two hours, but it demonstrated how the depth of a dependency tree becomes an attack surface.
Finally there is physical coercion—the so-called "$5 wrench attack." However strong the cryptography, once a key holder is identified, coercion becomes the shortest path. Jameson Lopp's compilation of publicly reported cases records more than 340 incidents since 2014, with 83 logged in 2025—the highest annual count to date—and 50 already logged in 2026 as of August. Countermeasures span both technique (multisig, timelocks, geographically distributed storage) and practice (not disclosing what you hold).

Custody Risk — Who Holds the Keys

The principle "not your keys, not your coins" identifies exactly where the risk sits. The moment you deposit with an exchange or custodian, the risk you carry is no longer Bitcoin's protocol risk but that institution's creditworthiness, internal controls, and legal jurisdiction.
Historically, most of the funds lost were lost at this layer. The assets that vanished in the Mt. Gox and FTX failures were not the result of Bitcoin's cryptography or consensus being broken. The individual cases are covered in detail in Incidents & Turning Points.
Self-custody carries a different set of risks: lost keys, holdings no heir can retrieve, and the physical coercion described above. Spot ETFs and custodial services substitute counterparty risk at a financial institution for the risks of self-custody—they relocate risk rather than eliminate it.
Which is appropriate depends on the amount involved, technical proficiency, jurisdiction of residence, and inheritance planning. This site does not recommend any particular custody method; it only sets out which risks each choice accepts.

How Bitcoin Defends Itself — Slow, but Thoroughly Reviewed

Bitcoin's handling of vulnerabilities is built on responsible disclosure. A finder reports privately to [email protected], the report is verified, a fix is released, and the details are then published. CVE-2018-17144 is a working example: an inflation vulnerability was closed before anyone exploited it.
Bitcoin Core formalized its disclosure policy in July 2024. Vulnerabilities are classified as Low, Medium, High, or Critical. Low severity issues are disclosed two weeks after the release of a major version containing the fix; Medium and High two weeks after the last affected release reaches end of life—roughly a year after the fix first shipped. Critical issues fall outside the standard policy and are handled ad hoc. A pre-announcement is issued two weeks before disclosure.
Structurally, the defense is that every full node independently validates every block. Compared with models where bribing a small set of validators suffices, the attack surface is widely distributed. But because most nodes run the same implementation, implementation bugs remain a correlated risk.
Changing consensus rules requires broad agreement, so even a well-known defect can take years to fix; the persistence of the time-warp flaw is one example. This is a genuine drawback—things cannot be fixed quickly—and the flip side of a genuine benefit: no single party can change the rules on its own.
And all of it stays in the public record: the code, the debates, and the post-mortems. That a document like BIP 50 still records the 2013 split in detail is the result of a practice of not hiding bugs.

Unresolved Structural Problems

The security budget is the longest-horizon question. The block subsidy fell to 3.125 BTC at the 2024 halving, halves roughly every four years, and reaches zero around 2140. Eventually, network security must be funded by transaction fees alone—yet in recent years fees have contributed only a few percent or less of miner revenue for extended stretches (dipping below 1% in quiet periods and spiking temporarily when demand for block space concentrates), and whether the transition proceeds smoothly is unproven.
Several views are offered in response: that demand for block space will grow, that the real value of BTC-denominated revenue will rise, or that hash rate naturally equilibrates with price and fees. Each is a hypothesis, not yet demonstrated. This site does not forecast future prices or how this question resolves.
The dispute over what block space is for continues. Bitcoin Core v30, released in October 2025, effectively removed the default standard-relay cap on OP_RETURN outputs (previously about 80 bytes), leaving the limit configurable per node. This changed relay policy rather than consensus rules, but it reignited a values conflict—whether Bitcoin is a ledger for financial transactions or may also serve as storage for arbitrary data—and prompted a number of node operators to move to alternative implementations such as Bitcoin Knots.
Concentration of development resources is another structural issue. The number of developers who continuously maintain Bitcoin Core is limited, and their funding depends on a small number of grant organizations and companies. The protocol is decentralized; the human resources that maintain it are not decentralized to the same degree.
The cost of running a node is a quieter concern. As the storage and bandwidth burden of validation rises, fewer people verify for themselves and more simply trust what others tell them. That is not a technical vulnerability but a social one.
Bitcoin's 17 years are not a history without bugs; they are a history in which bugs were found, published, and fixed. Several of the problems listed here remain open, and expert assessments differ. Reading with a clear separation between the strength of a claim and the strength of its evidence is, we believe, the surest way to understand Bitcoin without leaning toward either praise or dismissal.