Invalid Bitcoin blocks: full PoW, consensus invalid

tl;dr

• A block can carry full proof-of-work and still be invalid. The invalid-blocks repository catalogues 143 such Bitcoin blocks from 2010 to 2026, each with the bytes and an offline check that establish which consensus rule it broke, plus 10 reported cases held apart until their evidence turns up.
• Two are very recent. F2Pool headers from April and July 2026 carry timestamps roughly 7 and 14 days below their parents' median time past. Neither has a known Bitcoin-side capture; both were found in merge-mined auxiliary chains, which is what prompted this post.
• 89 blocks contain the same P2SH-invalid transaction, mined between April and July 2012 by pools that had not upgraded. Archived explorer txid lists and preserved headers prove its inclusion in each, so the failure is established even though only four complete bodies could be rebuilt.
• 127 of the 143 have no complete body. A header, a coinbase bound to it by its Merkle branch, or an inclusion proof, plus chain context, is enough to establish the rule that was broken.
• Merge mining reveals both stale and invalid Bitcoin blocks. Auxiliary chains hold 49 of the 143 headers and provide the catalogue's only recorded observation for 35; the same research recovered roughly 1,400 stale headers new to the stale-blocks collection. Monitoring the chains that merge-mine with Bitcoin is essential to a holistic Bitcoin monitoring effort.

Introduction

Proof-of-work makes a Bitcoin block a candidate. The consensus rules in force at that height make it eligible to extend (or race). This post is about blocks that met the PoW requirements yet failed a consensus rule, thus becoming invalid blocks.

The catalogue, and this post, began with the two most recent cases. In April and July 2026, merge-mined auxiliary chains recorded two F2Pool headers whose timestamps sat a week and two weeks behind the chain, and no Bitcoin-side monitor reported either. I had assumed that consensus-invalid blocks with full proof of work belonged to earlier periods in Bitcoin's history, but two in three months from one of the largest pools suggested otherwise, and raised the question of how many there had been and how much of each survives.

Invalid blocks matter beyond the wasted work. Each is the public trace of a bug in mining software that is otherwise closed, and direct evidence of how a consensus rule was enforced when it changed. For example, as covered in this post, the 2012 cluster shows a pool advertising P2SH support in its coinbase while its node still accepted a spend the new rule forbade, and the 2015 forks show miners extending headers they had not validated.

Recent incidents are usually discussed individually. b10c documented F2Pool's two excessive-sigops blocks and MARA Pool's transaction-ordering failure from 2023, with enough data to reproduce the failures. Earlier incidents more often survive as a hash, a height and a contemporary report, without the bytes needed to check the claimed failure. Those are useful starting points, but not a substitute for the headers, coinbases or transactions that establish it.

I began with the record kept by chains that merge-mine with Bitcoin, because it had already proved the most productive source of stale blocks I know of: the merge-mining records of more than 25 auxiliary chains yielded about 2,160 unique stale Bitcoin headers, roughly 1,400 of them new to the stale-blocks collection (about 1,090 from Namecoin alone) and the rest corroborating headers that Bitcoin-side monitors had captured. The same records also keep headers of invalid Bitcoin blocks, since an auxiliary chain verifies its own rules and not Bitcoin's, and on AuxPoW chains the parent (Bitcoin) coinbase and its Merkle branch survive with them. The search then expanded into archived explorer pages, developer discussions, old node files and test fixtures, and the archives kept by earlier fork research. Combining those sources has made it possible to recover complete blocks in some cases, and in others to establish the failure without one.

The catalogue is bitcoin-data/invalid-blocks, which holds 143 established failures with their proofs and offline checks, and the tables and charts below are generated from its contents as of 22 September 2026. The 10 reported cases presented separately remain outside the catalogue because the surviving evidence does not yet establish their claimed failures. Many of these headers were already in the companion stale-blocks dataset, recorded as stales before their failures were established.

The next section sets out what the surviving evidence proves. The failure families then follow, from the 2010 overflow through the large 2012 P2SH cluster to the pool-template errors and MTP violations of 2017 to 2026, with the reported cases, the summary tables and source notes at the end.

Methodology

The scope of the catalogue

A catalogued header must hash to a value at or below the Bitcoin target required to extend its parent. It must also have enough surviving evidence to establish a specific consensus failure. A reported case has a claim of invalidity and usually a hash, sometimes a header, but not the bytes needed to run that check. Reported cases are therefore kept in the repository's separate ledger and are not fully admitted to the catalogue until the required evidence is available.

“Invalid” also needs a rule context. During a soft-fork transition, nodes enforcing the new rule reject blocks that older software can accept. The 2012 P2SH and 2015 version failures are the main historical examples. The 2010 overflow is a separate, explicitly retrospective case: the software initially accepted it, and the emergency fix made the block invalid. Admitting a block to the catalogue therefore does not claim that every implementation of the day rejected it.

The catalogue counts headers with an established failure in their own contents, rather than every descendant of an invalid block. That distinction matters for the July 2015 SPV-mining forks. That is, a descendant can have invalid ancestry without supplying another instance of a malformed coinbase or invalid transaction. One 2014 descendant is included because its own coinbase independently fails the height rule (so it was itself an invalid block).

The scope also excludes unmined invalid Stratum jobs and invalid relay encodings of otherwise accepted blocks, such as ViaBTC's witness-stripped messages. The March 2013 database fork is outside the catalogue: the triggering block was well-formed, and whether a node could process it depended on that node's Berkeley DB lock state. Two catalogued headers at that height, 225,430, are separate merge-mined candidates that fail the coinbase-height rule, not the block that triggered the fork.

Sources and commitments

Bitcoin P2P monitors can capture some invalid blocks. A failure visible earlier in validation has fewer opportunities to reach an observer, but high-bandwidth compact-block relay can still forward a block before validation against the UTXO set is complete. That window is the likely route by which the 2023 transaction-ordering and sigops failures documented by b10c reached observers. Historical peers that had not adopted a new rule also relayed blocks that upgraded peers rejected, and a monitor connected directly to a pool's node, or to a relay that does not validate, can receive blocks no validating peer would forward.

Merge mining provides a different record. An AuxPoW auxiliary chain verifies its own proof-of-work and commitment rules, and does not require the Bitcoin template to be consensus-valid. The header and coinbase can therefore survive in the auxiliary chain even when Bitcoin peers reject them. Those auxiliary chains also have easier targets, so a broken template can produce many child blocks whose parent headers never meet Bitcoin difficulty and are not catalogued. The initial sweep covered more than 25 auxiliary chains, building on Stifter et al.'s 2018 paper Echoes of the Past, which demonstrated the historical value of this material. The available evidence varies by chain: Rootstock, for example, preserves a truncated coinbase, and Hathor reconstructs the parent header from a split AuxPoW record.

Archives add a third route: explorer transaction lists, complete block responses, test fixtures and old node files. An archived explorer page proves the explorer saw the block, not that a peer relayed it, and a recovered block index can hold a header long after its body file is gone. The catalogue records which of the three routes, Bitcoin P2P observation, merge-mining record or archive, each header was recovered from, and Figure 1 colours the established headers by that combination.

Much of the recovery was done by AI agents working under my direction: chasing archive captures, trying transaction orderings until Merkle roots matched, and assembling bodies from parts. Every proof, body and coinbase they produced is checked by the repository's own verification code, so each case is in the catalogue on the strength of those checks rather than of the agents' output.

The 2012 P2SH cluster is almost entirely archival, while from 2013 merge-mined records dominate. A smaller set, including F2Pool's 2023 sigops blocks, survives in both a Bitcoin P2P record and an auxiliary chain.

Which rule can be checked depends on which bytes survive. A version or timestamp failure needs the header and chain context. A coinbase-height failure also needs the coinbase, tied to that header by its Merkle branch. A script failure can be established from the offending transaction, the output it spends and an inclusion proof: the sibling hashes that carry the transaction's txid up to the header's Merkle root. If hashing the txid together with those siblings, level by level, reproduces the root committed in the header, the header included that transaction, and the coinbase and every other transaction can stay missing.

Fee accounting has a different requirement: a coinbase above the subsidy may be valid if transaction fees cover the difference. The ordinary transactions and their funding values must be known before calling it an overpayment. The Eligius cases below show both sides of that distinction.

Table 1 separates established invalidity from complete-body availability. Every established row is proved. The rows differ only in which bytes are still missing.

Failed rule breakdown

Table 2 groups the established cases by failure mechanism. Several mechanisms produce the same Bitcoin Core reject reason, so a reject string alone does not explain what went wrong. Nor is the wording stable: a present-day node reports the 2012 P2SH failure with a different string from the one nodes logged at the time.

The timeline in Figure 2 shows how strongly the recovered record clusters around particular incidents and eras. The complete identities are in Table 4. Neither the chart nor the catalogue includes the reported cases.

The failures

The sections below run in order of how many blocks each failure accounts for, from the 89-block P2SH cluster down to the single-block cases, with two exceptions: the 2010 value overflow comes first because it is the earliest and the origin of the retrospective caveat noted above, and the timestamp failures come last because the two 2026 F2Pool headers among them are what prompted this post. Each section states the rule, the blocks that broke it, what survives of them and where, and what can be said about the cause.

The value overflow (1 block, 2010)

At height 74,638, a transaction created two outputs of roughly 92.2 billion BTC each. Their sum overflowed the signed 64-bit value used in the check, so the software then in use accepted the transaction, as shown in Figure 3. The value-overflow incident prompted an emergency fix and a replacement chain. A present-day node rejects the retained body with bad-txns-vout-toolarge.

Figure 3: the value overflow, stage by stage

It is the retrospective case noted above, accepted when mined and invalid only after the fix. It also predates merge mining, so its survival depends on Bitcoin-side records.

One invalid P2SH transaction, many blocks (89 established cases, 2012)

BIP16 changed how pay-to-script-hash (P2SH) outputs were validated for blocks timestamped from 1 April 2012. Under the old rules, a spend could satisfy the outer hash comparison without executing the script that hash commits to. Under the new rules, the revealed redeem script also had to execute successfully. A transaction could therefore pass the old checks and fail P2SH validation.

That is what happened with transaction …ef2d5e3f78d2. The 4 April developer log preserves its 123-byte serialisation, pasted by twobitcoins. It spends a P2SH output confirmed at height 170,054. The input pushes a 1-of-1 OP_CHECKMULTISIG redeem script, with no signature and no dummy element, as shown in Figure 4. Under the old rules the redeem script's hash matches the output and the spend is valid. Under BIP16 the redeem script is then executed, OP_CHECKMULTISIG finds no signature and no dummy element on the stack, and the spend is invalid.

Figure 4: the P2SH spend's missing dummy and signature

Turning explorer records into proofs

A 15 June 2012 explorer capture lists the transaction in 88 blocks from 1 April through 6 June, each matched by height and timestamp to a header preserved in the stale-blocks collection. A separate July discussion identifies another case at height 189,498, bringing the identified population to 89. All 89 headers build on canonical parents, so these are not descendants of a few invalid openers.

Archived explorer block pages supplied complete txid lists for 46 cases. The Decker–Wattenhofer archive supplied lists for the remaining 43. These records do not consistently preserve the order used in the block's Merkle tree. I tested candidate orderings based on transaction dependencies and historical mining priorities until each ordered list reproduced its header's Merkle root. Hashing the recovered 123-byte transaction gives the invalid spend's txid, and its presence in each matching tree authenticates its inclusion in all 89 blocks. Together with the output it spends and the failed redeem script, that establishes the P2SH failure without recovering the complete block.

Height 174,057 is the smallest case: two transactions, a coinbase and the invalid spend. Hashing those two txids together in Bitcoin's byte order reproduces the header's Merkle root, as shown in Figure 5. The coinbase's txid is enough for that proof even though its bytes remain missing.

Figure 5: proving P2SH inclusion without the block body

For four blocks, Namecoin's AuxPoW record supplied the missing coinbase bytes as well. Their other transactions later confirmed on the accepted chain, so with those canonical bytes, the Namecoin coinbase and the invalid spend, complete bodies exist for heights 173,928, 173,957, 173,998 and 174,605. The four serialisations are among the block files, the inclusion proofs for the other 85 headers are in proofs/, and the dataset's checks evaluate the spend with and without P2SH against every one of them.

The other 85 P2SH cases are in the catalogue without their coinbase bytes, since the inclusion proof is sufficient on its own. That is, the header commits to the invalid spend through its Merkle root, and the spend fails BIP16 on its own bytes, so the other transactions in the block, the coinbase included, need be known only by their txids and not by their contents. The missing first transactions have authenticated txids, but their coinbase structure cannot be checked without their bytes.

What caused the repeated inclusions?

On 2 April, logs record nodes enforcing BIP16 rejecting the transaction with P2SH VerifySignature failed, and on 4 April Gregory Maxwell summarised that upgraded nodes reject transactions old nodes still accept. In that same discussion Maxwell said the spend was presumably intentional, then noted that a CHECKMULTISIG accident could look the same, and that an attacker could have used a simpler script. Miners still on the old checks could keep including it. The inclusions thinned as miners upgraded: of the 89 blocks, 73 are from April, 13 from May, two from June and one from July.

The coinbases say little about who mined them. The four recovered ones carry eco@ozco.in /P2SH/ twice and nmcbit.com once, so OzCoin mined at least two while carrying the /P2SH/ marker that signalled support for the rule its validation was not yet enforcing, and NMCbit at least one. The fourth is merge-mined and untagged. Of the 86 blocks without a pool tag, archived block pages preserve the coinbase's payout address for 43, and 40 of those are fresh addresses that no canonical coinbase between heights 172,000 and 190,000 reuses and no known pool used, which fits the new key per block that the reference client's own block template drew from its wallet. The same pages record which node relayed each block to the explorer, Deepbit's for 13 of them, and a node relays only a block it accepted, so that node was still on the old rules, but it does not identify the miner. The other 43 untagged blocks have no archived page and no coinbase information at all.

In November, a node still had an April invalid block from an old block file. A reorg disconnected that block, and its transactions entered that node's mempool, including the “invalid p2sh killer”. Despite the discussion, no invalid block resulted: the spend sat in that node's mempool but was never mined again, and the last block to contain it remains 189,498 on 17 July.

Coinbase-height mistakes (26 blocks, 2013 to 2023)

BIP34, whose height rule took effect for version-2 blocks at height 224,413 on 5 March 2013, requires the block height as the first item in the coinbase scriptSig, encoded as a minimally encoded script number. The header's previous-block hash fixes the parent and therefore the required height. A plausible-looking integer in the coinbase is insufficient if it names a different height or uses the wrong encoding. The catalogue contains four recurring issues, with their required and recovered height prefixes compared byte by byte in Figure 6.

Figure 6: required and recovered coinbase height prefixes

Difficulty in the height field: twelve blocks. Across March 2013, heights 225,013 to 226,912, the first coinbase item contains the header's compact difficulty instead of its height. Eight encode 0x1a03d74b; four later blocks encode the next epoch's 0x1a0375fa. The wrong field tracks the difficulty transition, and the pattern persists from 9 to 20 March.

The recovered coinbases are untagged, so the coinbases themselves do not identify the operator, though the report below attributes three of the twelve. Namecoin, Devcoin and Ixcoin supply the surviving observations, and the catalogue has no recorded Bitcoin P2P observation of these twelve headers.

On 20 March, the last day of the cluster, Chris Double (doublec), who ran the Bitparking merged-mining pool at mmpool.bitparking.com, reported version-2 blocks rejected for a coinbase height mismatch and named height 226,845. In the pool's thread the same day he wrote that his merge-mining code had been putting the wrong height data in the coinbase of his version-2 blocks, that it had cost him his last three, and that merge mining was disabled until he had a fix. Gavin Andresen asked whether he had put the wrong thing in the coinbase, and he said he had. His report covers three of the twelve heights. The other nine share the same coinbase layout, the difficulty then an extranonce then the 44-byte merge-mining commitment, the same three auxiliary chains, and all fall between the pool re-enabling merge mining on 9 March and disabling it on 20 March, which points to the same getwork server, though no report names them and the table leaves them unassigned.

An unchanged parent: six BTC Guild blocks. On 3 April 2013, six headers tagged BTC Guild 3 reference the same parent at height 229,387, requiring height 229,388. Their coinbases instead encode heights from 229,405 to 229,506, between 17 and 118 too high. The timestamps fit a template that kept writing the current height while remaining stuck on parent 229,387. Figure 7 shows the mismatch.

Figure 7: BTC Guild's six headers on an unchanged parent

Off by one: seven blocks. Six coinbases encode a height one too high; an Eligius block encodes one too low. Their similar errors do not establish a shared implementation or a single long-lived bug. Four build on stale or invalid parents. The 2016 blocks at 402,610 and 422,059 extend stale parents. The 2014 pair at heights 331,673 and 331,674 extends a stale block and then an invalid block, as shown in Figure 8. Both are counted because each coinbase encodes the wrong height on its own, and the second block's invalid parent is a separate defect.

Figure 8: the 2014 off-by-one fork

The right number, the wrong encoding: one Hathor recovery. At height 649,674 in September 2020, the coinbase starts with fe ca e9 09 00, Bitcoin's CompactSize encoding of 649,674. BIP34 requires a script push, 03 ca e9 09, as compared in Figure 9. The fe marker does not perform that push, so the coinbase violates BIP34 (bad-cb-height).

Figure 9: script push versus CompactSize at height 649,674

The height encoding is one of several defects in this block, compared in Figure 10. The coinbase carries witness data without an OP_RETURN witness-commitment output, the supplied branch reaches the header root through the wtxid rather than the txid, and the payout script omits the byte that should push the 20-byte public-key hash.

A current node fed the block as assembled would therefore report bad-txnmrklroot before reaching the BIP34 check, and unexpected-witness if the body did match the root, while the malformed payout alone does not invalidate a block. These findings concern the retained coinbase and proof, not a recovered complete Bitcoin body.

Figure 10: further defects in the Hathor coinbase

The height and payout encodings match bugs corrected in Hathor's reference coordinator in July 2020 (height fix, payout fix). Their later appearance points to older or derivative software, though the operator is unidentified.

Invalid block versions (11 blocks, 2015 to 2018)

BIP66, enforced from height 363,725 on 4 July 2015, and BIP65, enforced from 388,381 on 14 December 2015, introduced minimum block versions of 3 and 4 respectively. Six catalogued headers use version 2 after BIP66 enforcement; five fall below the BIP65 minimum. The version field and parent context are sufficient to establish these failures, without recovering transactions.

Version 2 after BIP66: six blocks. The July 2015 forks made this visible when miners built on headers without fully validating the blocks they extended. The first block of the 4 July fork, at height 363,731, fails the version rule itself. Its five version-3 descendants fail by ancestry and are excluded from the independent-failure count (not in the catalogue). The alert that followed told lightweight-wallet users and anyone on Bitcoin Core 0.9.4 or earlier to wait an additional 30 confirmations, and it remained in force for weeks. The first block's header was discovered in BTC Relay test fixtures. Figure 11 compares this six-block fork with the reported three-block fork on 5 July, whose first block's header has not yet been recovered.

Figure 11: the July 2015 forks

Two further version-2 headers on 4 July, at 363,726 and 363,847, sit on canonical parents and did not open forks, and 363,726 was mined two minutes after enforcement began. Three more failures followed, at 363,967, 364,341 and 367,047. The last (367,047), tagged mmpool, was mined on 26 July, three weeks after the initial fork, by the same Bitparking pool that produced the March 2013 coinbase-height cluster. Further reported version-2 cases that have not yet been recovered are listed in Table 5.

Version below BIP65: five blocks. Four days after BIP65 enforcement at height 388,381 on 14 December 2015, a version-3 header at 389,043 failed the new minimum of 4. The other four are BTC.COM headers from 2018, and they fail that same minimum by a different mechanism. Their versions are 0xa0000000 and 0xe0000000. As signed 32-bit integers, both are negative. Figure 12 shows the sign-bit effect.

Figure 12: BTC.COM's sign-bit versions

Miners use the version field as extra nonce space, a practice called version rolling: BIP320 sets aside bits 13 to 28 for it, and BIP310 lets a pool tell its miners which bits they may change. Both values keep bit 29 set, the base every version-signalling block carries; 0xa0000000 adds bit 31 and 0xe0000000 adds bits 30 and 31, all outside the permitted range. Bit 31 is the sign bit, which is what turns the value negative. The likeliest cause is mining hardware or firmware rolling a wider mask than it was given, though nothing in the surviving evidence identifies it. Namecoin and Rootstock each preserved all four headers, and their full PoW and invalid signed versions are directly checkable.

Inputs already spent (4 blocks, 2018)

A transaction cannot spend an output that has already been spent in an earlier block. This can produce the same bad-txns-inputs-missingorspent error as the missing or misordered dependencies described next, but the evidence must establish that the input was already consumed. At heights 507,514, 509,557, 515,319 and 534,339 in 2018, four AntPool blocks repeat non-coinbase transactions already confirmed in their canonical parents. Those transactions' inputs have already been consumed when validation reaches the copies. The surviving block bodies and their parents establish the conflict. Replaying each candidate against that parent on Bitcoin Core v31.1 returned bad-txns-inputs-missingorspent.

The simplest case is 515,319. Its header names parent 515,318 and its body contains a new coinbase followed by the same 79 ordinary transactions, in the same order, as shown in Figure 13. The other three repeat 218, 338 and 1,253 of their parents' transactions, the last two alongside 399 and 1,069 fresh transactions. All four were timestamped within about a minute of their parent. The pattern fits a template that took the new parent's hash without rebuilding the transaction list, so the body still carried the parent's transactions.

Figure 13: AntPool's repeated transactions at 515,319

These four bodies survived in archived chainquery.com responses and were originally contributed to the stale-blocks collection as stales, from which they were removed once the failure was established. A block can have valid PoW, a correct Merkle root and well-formed transactions, yet still fail when those transactions are applied to its parent state.

Transaction dependencies (3 blocks, 2017 and 2023)

When a transaction spends an output created by another transaction in the same block, the parent transaction must appear first. Validation applies transactions in order, making each new output available to subsequent transactions. So a parent included too late or omitted entirely leaves the child's input unavailable when validation reaches it, producing bad-txns-inputs-missingorspent. Figure 14 illustrates these two mechanisms.

Figure 14: parent-before-child ordering

Parent included too late: two blocks. At height 477,115 on 23 July 2017, three transactions in a 255-transaction block spend outputs from transactions that appear later in the body (this was attributed to 1Hash in a BitcoinTalk thread). Namecoin kept its header and chainquery.com kept its body, from which the ordering failure can be checked. Six years later, MARA's block at 809,478 failed after sorting transactions by fee rather than respecting dependencies. Its retained evidence comes from Bitcoin's compact-block relay window.

Parent omitted: one block. At height 474,294 on 5 July 2017, another block attributed to 1Hash (the same BitcoinTalk thread as above) contains a transaction whose unconfirmed parent is absent. The parent is neither elsewhere in the body nor anywhere in the canonical chain. The spending transaction and its parent were later confirmed together in the competing block at that height.

Coinbase overpayment (2 established blocks, 2012 and 2019)

The coinbase may claim the block subsidy plus the fees of the transactions actually included. A coinbase computed from another template can claim fees for transactions the mined block body does not contain. For the two established cases below, the fees are known and the overpayment is exact.

Eligius: one established overpayment, three unresolved reports. A 9 September 2012 developer report identifies four Eligius blocks as coinbase overpayments: 197,438, 197,701, 197,705 and 197,883. Only 197,438 has enough surviving evidence to establish the overpayment, and the other three remain outside the catalogue.

At 197,438, an Ixcoin AuxPoW record preserves the coinbase and the hash of the other transaction. That transaction later confirmed at height 197,523, allowing its exact bytes to be recovered and the complete two-transaction block to be reconstructed.

The ordinary transaction's authenticated input is worth 503,413,843 satoshis, and its outputs total exactly the same amount. Its fee is therefore zero. The coinbase pays 5,001,000,000 satoshis against the 5,000,000,000-satoshi subsidy: an excess of 1,000,000 satoshis, or 0.01 BTC. The reconstructed block is among the dataset's block files, and its check recomputes those amounts from the authenticated funding transaction, independently of the contemporary report.

At 197,883, the authenticated coinbase pays 50.0005 BTC, and four auxiliary chains preserve the same header, coinbase and Merkle sibling. The other transaction's hash is known, but its bytes remain missing. Unlike the ordinary transaction at 197,438, it has not been found confirmed under that hash. If it paid a 0.0005 BTC fee, that coinbase amount would be permissible. A coinbase above the subsidy alone cannot settle the question.

A reproduction using the historical Eloipool trimming code can drop a transaction from the template while keeping its fee in the coinbase total, which is the reported kind of failure. The same code can also produce a template in which the one retained transaction genuinely pays a 0.0005 BTC fee, giving an identical coinbase amount legitimately, so the amount alone cannot tell the two apart. The code shows a possible mechanism, but does not establish the missing transaction's fee or which configuration Eligius ran.

For the remaining two Eligius reports, an archived September block list supplies full hashes for 197,701 and 197,705, but their headers and bodies remain missing and none of the auxiliary chains that preserved 197,438 or 197,883 holds them.

AntPool 584,802: no ordinary transactions. In July 2019, AntPool's 334-byte block contained only a coinbase paying 13.26546691 BTC against a 12.5 BTC subsidy. With no ordinary transactions, there were no fees to justify the extra 0.76546691 BTC. The rejection was widely reported, including ForkMonitor's check across eight implementations. Elastos also preserved the header and coinbase.

A stale fee total is a plausible explanation and resembles later invalid mining jobs documented by b10c. Unlike the 2018 spent-input blocks, which kept parent transactions they should have dropped, this one claimed fees with no ordinary transactions at all.

Excessive signature operations (2 blocks, 2023)

F2Pool blocks at heights 783,426 and 784,121 each reached a sigops cost of 80,003 against the 80,000 limit. b10c's account has both complete bodies and explains the off-by-three result. Five auxiliary chains also retained the headers, which on their own cannot establish a sigops count.

A coinbase greeting three bytes too long (1 block, 2013)

On 31 December 2013, GHash.IO's block at height 277,975 included the greeting Happy New Year! Yours GHash.IO.. The preceding fields already occupied 72 bytes, including a 45-byte push carrying the 44-byte merge-mining commitment, leaving only 28 bytes for the 31-byte greeting, as shown in Figure 15. The coinbase scriptSig reached 103 bytes, exceeding the 100-byte consensus maximum and producing bad-cb-length. Unlike the other 2013 coinbase failures, its BIP34 height prefix was correct, and the length alone is the fault.

Figure 15: GHash.IO's 103-byte coinbase scriptSig

A missed difficulty retarget (1 block, 2022)

Height 717,696 is a difficulty-retarget boundary. ViaBTC's header carries the previous epoch's nBits, 170b98ab, instead of the required 170b8c8b, producing bad-diffbits. The old target was easier, but the header's hash happens to clear the correct, harder target as well. That is why it meets this catalogue's full-PoW requirement despite encoding the wrong difficulty. Emercoin, Syscoin and Namecoin preserved the header.

Timestamps below median time past (3 blocks, 2015 to 2026)

A block's timestamp must be strictly greater than its parent's median time past. The header at height 380,992 in 2015 falls about 4.6 hours below that bound. Two F2Pool cases in 2026 miss it by days, as shown in Figure 16.

On 22 April 2026, auxiliary chains recorded a header at height 946,213 whose nTime was 15 April, 634,618 seconds (7.35 days) below the parent MTP. On 13 July 2026, another header at 957,780 used an nTime of 29 June, 1,206,929 seconds (13.97 days) below the parent MTP. Both fail time-too-old.

Figure 16: F2Pool's 2026 timestamps against median time past

Namecoin, Syscoin and Elastos recorded both whereas Fractal Bitcoin recorded only 957,780. The merge-mining monitor captured 957,780 live, while 946,213 was recovered retrospectively. No Bitcoin-side capture of either header is known.

Both headers build on the canonical parent at their height, and their coinbases, preserved in Namecoin's AuxPoW records, carry the /F2Pool/ tag and claim 3.20191623 BTC and 3.14128765 BTC, the 3.125 BTC subsidy plus fees, all of it forfeited. A mining template that updated its parent while retaining an old timestamp could explain these headers, but the available evidence does not establish how the fault arose. Whatever the cause, the violation is directly checkable from each header and its parent's median time past.

Reported cases and missing evidence

The 10 additional reports in Table 5 are grouped in Table 3 by what remains missing. They do not contribute to the 143 established failures or the rule totals, but they are useful recovery targets.

P2Pool 212,048: identified report, missing rejection reason. On 13 December 2012, gmaxwell reported an invalid P2Pool block at height 212,048 and supplied its hash prefix, but said his node had not logged the rejection reason. The full hash appears in Syke's historical node dump, linked from his 2016 forum post, with status invalid and branch length one. No header or body has been recovered, so neither the proof of work nor a named consensus failure can be independently checked. The ledger entry records the report, the node dump and its archived copy.

Version failures: reported hashes, missing headers. The five version reports include the first block of MegaBigPower's 5 July fork at 363,997 and four later blocks at 364,261, 367,195, 386,682 and 387,396. A 2017 bitcoin-dev message lists their full hashes alongside bad-version(0x00000002). Without the headers, neither the version field nor the PoW can be independently rechecked. The message lists every hash as a .bin filename, which suggests the block files existed on disk in March 2017. Outreach to the original author has not yet elicited a response.

Bitcoin Unlimited 450,529: header recovered, size violation unverified. The January 2017 incident statement reports a 1,000,023-byte block from Bitcoin.com's pool, exceeding the 1 MB limit after incorrect coinbase-size accounting. Archived BlockCypher fields reconstruct its exact 80-byte header, and its hash meets the expected target. The body is still incomplete, so the reported 23-byte excess has not been verified from the serialised block itself.

Conclusions

The early P2SH, coinbase-height and version clusters coincide with newly enforced rules. SegWit and Taproot have no comparable activation clusters, as Figure 2 shows. Later cases show failures against long-standing rules, including AntPool's already-spent inputs in 2018 and F2Pool's timestamps in 2026. The catalogue brings these incidents and their surviving evidence together, making each established failure independently checkable.

The recoveries show how complementary records can establish failures that no single source could prove. For the P2SH cases, archived txid lists and preserved headers establish inclusion of a spend whose script failure can be checked without a complete block body. For a suspected coinbase overpayment, however, one missing transaction can leave the decisive fee unknown. Preserving those records and their provenance allows old reports to become independently checkable cases as missing evidence emerges.

Merge mining has proved to be an unusually productive side channel into Bitcoin mining. Auxiliary-chain records yielded roughly 1,400 stale headers new to the stale-blocks collection, and provide this catalogue's only recorded observation for 35 established invalid headers. Stales reveal mining competition outside the accepted chain; invalid blocks reveal failures in constructing candidates that satisfy Bitcoin's rules. An auxiliary chain checks its own rules, so it can preserve evidence of both outcomes even when Bitcoin peers never relay the candidate.

The two F2Pool headers that prompted this catalogue make the case for ongoing monitoring particularly clear. The July F2Pool header was captured live by the merge-mining monitor, while the April header was recovered retrospectively. Neither has a known Bitcoin-side capture; auxiliary chains preserved the evidence that establishes their failures. These records cover only participating miners, and uneven monitoring and archive coverage mean the catalogue cannot establish how often invalid blocks occur across Bitcoin mining as a whole. They nevertheless reveal mining activity that would otherwise be missing from the collected record. Monitoring the chains that merge-mine with Bitcoin is essential to a holistic Bitcoin monitoring effort.

Contributions and corrections

If you have evidence of an invalid block, additional information about any of these cases, or a correction to this post, contributions to invalid-blocks are welcome. Old node files, pool logs and archived discussions could help resolve a reported case or identify one that is missing entirely. You do not need a complete block or a finished proof to suggest a lead: include whatever hashes, dates and source material you have.

Summary tables and sources

The first table summarises the catalogue's 143 established failures, and the second lists the 10 reported cases that do not yet meet its evidence requirements. Heights can repeat because different headers were mined at the same height. “Unknown” means this catalogue does not assign a pool, rather than asserting that a recovered coinbase has no identifying bytes. A bare pool name comes from a tag in the recovered coinbase, “(reported)” from a report of the time, and “(address)” from the coinbase's payout address matched against the mining-pools dataset. Dates, full hashes, source links and observation channels for all established cases are in the post catalogue; the reported ledger covers the rest.

References

Datasets, research and related posts

• bitcoin-data/invalid-blocks: the catalogue, its proofs and bodies, verification code and evidence notes
• bitcoin-data/stale-blocks: historical stale-block collection
• bitcoin-data/mining-pools: coinbase tags and payout addresses
• Stifter, Schindler, Judmayer, Zamyatin, Kern & Weippl. Echoes of the Past: Recovering Blockchain Metrics From Merged Mining (FC 2019)
• NStifter/mergedmonitor: research archives
• BTC Relay: July 2015 fork-header fixtures
• Eloipool: historical transaction-trimming code
• Hathor: coinbase-height encoding fix
• Hathor: coinbase payout-script fix
• Merge-mining research
• Live merge-mining monitor
• Merge mining and AuxPoW: how it works

Incident reports and historical records

• Value overflow incident (Bitcoin Wiki)
• P2SH-invalid transaction discussion (bitcoin-dev IRC, 4 April 2012)
• P2SH transaction inclusion list (Blockchain.info, 15 June 2012 archive)
• P2SH case at height 189,498 (bitcoin-dev IRC, 17 July 2012)
• Eligius coinbase-overpayment reports (bitcoin-dev IRC, 9 September 2012)
• Eligius block list (18 September 2012 archive)
• P2SH-invalid transaction after a reorganisation (bitcoin-dev IRC, 28 November 2012)
• Chris Double: coinbase-height mismatch discussion (bitcoin-dev IRC, 20 March 2013)
• Chris Double: three lost blocks (BitcoinTalk, 20 March 2013)
• Chris Double: Bitparking pool thread, merge mining disabled after three invalidated blocks (BitcoinTalk, 20 March 2013)
• July 2015 chain forks (Bitcoin Wiki)
• Some Miners Generating Invalid Blocks (Bitcoin.org, 4 July 2015)
• bfd: Reported version-2 block hashes (bitcoin-dev, 16 March 2017)
• Bitcoin Unlimited oversized-block incident statement (29 January 2017)
• piotr_n: 1hash pool just mined an invalid block again (BitcoinTalk, July 2017)
• AntPool's coinbase overpayment at 584,802 (The Next Web, July 2019)
• b10c: Invalid MARAPool block 809478
• b10c: Invalid F2Pool blocks 783426 and 784121
• b10c: ViaBTC's mutated blocks without witness data
• b10c: Invalid mining jobs by AntPool & friends during forks

Specifications

• BIP 16: Pay to Script Hash
• BIP 34: Block v2, Height in Coinbase
• BIP 50: March 2013 Chain Fork Post-Mortem
• BIP 65: OP_CHECKLOCKTIMEVERIFY
• BIP 66: Strict DER signatures
• BIP 141: Segregated Witness (Consensus layer)
• BIP 152: Compact Block Relay
• BIP 310: Stratum protocol extensions
• BIP 320: nVersion bits for general purpose use
• BIP 341: Taproot: SegWit version 1 spending rules