Bitcoin Vulnerabilities — Attack Vectors and Real Bugs

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.

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, the 21 million cap at the heart of Bitcoin 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).

The three cases show 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, which is part of the same record and should be read alongside it.

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 16, 2026, mempool.space puts total network hash rate at roughly 913 EH/s implied by difficulty, about 914 EH/s on a trailing seven-day average, and about 943 EH/s on a trailing three-day average. Hash rate is inferred rather than measured, and the shorter the averaging window the more it swings — instantaneous estimates from the most recent blocks sometimes exceed 1 ZH/s (1,000 EH/s), so figures across sources span roughly 910–1,040 EH/s. Either way, 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 16, 2026 (1,005 blocks), mempool.space shows the largest pool at about 23% of blocks found, the top two together at about 45%, the top three at about 61%, and the top five at about 78% — figures that move several points week to week, so read them with the date they were taken. Two counterweights belong in the same assessment: pools do not own their hash rate, since participants can leave at any time, and standards that return block construction authority to individual miners (such as Stratum V2) are seeing growing adoption.

Looking only at pool-level concentration, however, misses the concentration among the miners behind those pools. Makarov and Schoar (NBER Working Paper 29396, data through end-2020) estimated that the top 10% of miners controlled 90% of mining capacity, and the top 0.1%, roughly 50 miners, close to half. They further concluded that this concentration rises when the price falls sharply and after halvings, and that the risk of a 51% attack rises with it. The freedom to switch pools does not cancel that out.

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.

The same routing layer can also be used to split the network itself, the partition attack, 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.

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.

That lower bound of one quarter can fall further. As the fraction of nodes that adopt the attacker's block in a tie (the paper's γ) approaches 1, that is, as the propagation advantage becomes total, the threshold share required all but disappears. The threshold is not a fixed number but a function of where the attacker sits in the network.

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, which means broad agreement, so even well-known flaws can take a long time to address.

Given a sufficiently large fault-tolerant quantum computer, Shor's algorithm opens a path from a secp256k1 public key to its private key. That concerns both ECDSA and the BIP 340 Schnorr signature used by Taproot. No public demonstration can perform the attack today, and resource estimates depend strongly on hardware and error-correction assumptions.

On the mining side, Grover's algorithm reduces the idealized number of SHA-256 search queries by a square root. It does not mean that a quantum miner instantly acquires majority hash power. A real-system assessment must include error correction, reversible circuits, clock rate, power, parallelism, and competition with classical ASICs.

Exposure is not uniform. P2PK and P2MS contain public keys directly in the output, while P2TR places a BIP 341 tweaked x-only public key there, creating long exposure from output creation. P2PKH and P2WPKH normally hide a key behind a hash until spending; P2SH and P2WSH can do so depending on their scripts. The mempool spend, reuse of the same key, and leakage of an xpub or descriptor are additional exposure paths, so "never spent means safe" is not a general rule.

As of August 23, 2026, BIP 360 v0.12.1 remains Draft. Pay-to-Merkle-Root (P2MR) would mitigate long exposure by avoiding a long-lived public key in an output, but it is not itself a post-quantum signature. It does not solve the short-exposure window between an ordinary spend revealing a key in the mempool and confirmation.

NIST has finalized ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) as post-quantum signature standards, but Bitcoin has adopted no replacement signature in its consensus rules. Signature size, verification cost, wallets, existing UTXOs, and activation still require evaluation and agreement. This is a governance problem as well as a technical one, and this site does not assert a practical attack date. "Can Quantum Computers Break Bitcoin?" provides the primary sources and a fuller treatment of long and short exposure.

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. Crypto investor Michael Terpin lost roughly $24 million this way; 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 352 incidents since December 2014, with 85 logged in 2025, the highest annual count to date, and 54 logged in 2026 through early August (counts taken from the list on August 16, 2026). As Lopp himself notes, the list is not comprehensive and many attacks are never publicly reported, so the real total is higher. Countermeasures span both technique (multisig, timelocks, geographically distributed storage) and practice (not disclosing what you hold).

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.

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, in that 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.

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 long 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 83 bytes), leaving the limit configurable per node. This changed relay policy rather than consensus rules, but it reignited a conflict of values, over 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.