Background that does not fit the schema or the README.
Deeper per-block history is documented elsewhere; see the observation provenance URLs in data/invalid-blocks.jsonl.
A .bin can be replayed with bitcoin-cli submitblock, but what comes back depends on where the violation is caught.
74638 fails the context-free CheckBlock checks before anything is stored, so every replay returns bad-txns-vout-toolarge on any node.
Its header alone is valid, though: submitheader accepts it (noted in bitcoin-data/stale-blocks#65), since every header-level check passes and the violation lives entirely in the body.
The transaction-ordering blocks, 474294, the two coinbase overpayments and the 2023 sigops blocks fail in ConnectBlock, which a node only runs when it is about to extend its active chain with the block.
Replayed today they sit on a branch with less work than the tip, so a node seeing them fresh stores them after the context-free checks and never connects them: submitblock returns inconclusive and the block becomes a valid-headers chain tip.
A node that already stores them returns duplicate, and only a node that attempted the connect at their original tip and marked them failed returns duplicate-invalid (the result reported in bitcoin-data/stale-blocks#11).
Most pool values are coinbase tags read from a body or a coinbase proof.
The records below attribute a pool another way; pool_basis says which and pool_provenance links the report or the mining-pools listing.
363731 (BTC Nuggets) and 363967 (Bitsolo) are attributed by payout address: 363967's coinbase, recovered from the AuxPoW record in Namecoin block 237930, carries no tag and pays 18zRehBcA2YkYvsC7dfQiFJNyjmWvXsvon, the address mining-pools lists for Bitsolo; 363731 is covered in its own note below.
The coinbases of 363967, 946213 and 957780 are authenticated by coinbase proofs built from the AuxPoW records in Namecoin blocks 237930, 821553 and 833329, so the Bitsolo address and the /F2Pool/ tags are read from transactions the headers commit to.
The two F2Pool coinbases pay 3.20191623 and 3.14128765 BTC in total, the 3.125 BTC subsidy plus fees, with all but a 546-satoshi output going to 1AfCc4F9c4VTYSE31PUe2kUEKs6ZxiDjxm.
474294 and 477115 are attributed to 1Hash from the BitcoinTalk thread of July 2017 that discussed both blocks; their coinbases carry /NYA/ and no pool tag.
226845, 226895 and 226912 are attributed to mmpool, Chris Double's Bitparking merged-mining pool at mmpool.bitparking.com, from his 20 March 2013 post in that thread reporting three invalidated blocks that day, and the bitcoin-dev log of the same day, where he reports the block height mismatch in coinbase rejection and names 226845; the later 367047 carries the mmpool tag itself.
Merge-mined recoveries supply a header and a coinbase extract, and until the coinbase is placed in the block that extract is only a claim.
Every record with coinbase_scriptsig_hex and no body now has a proof file except 649674: 37 coinbases with their merkle branches from the AuxPoW records in Namecoin blocks, read from a Namecoin Core node by the child block hash in each record's merge_mining observation, and 363731's coinbase reserialised from the pinned blockchain.info dump and placed by that dump's 99 txids.
CI reproduces each header's merkle root from the proof and requires the context scriptSig to equal the proved one, so every tag and address attribution in the dataset is read from bytes the header commits to.
389043 carried the 38th Namecoin proof until PR #26 supplied its complete block, kept by one of the long-running Chaincode Labs nodes whose stale blocks entered stale-blocks in PR #156; the body replaces the proof.
649674 has no Bitcoin merkle path.
Its Hathor block carries the coinbase and a twelve-hash path, and that path reproduces the header's merkle root only when the leaf is the double-SHA256 of the coinbase's full witness serialisation rather than its txid: the pool's merged-mining code built the tree from the wrong hash.
A Bitcoin node given the block would fail CheckBlock with bad-txnmrklroot before reaching the coinbase-height check the dataset records.
The scriptSig therefore stays an extract, bound to the header only through that non-standard tree, and the second failure is not registered as a rule.
A block built on an invalid block fails by ancestry and is recorded under prev_block_invalid from its header alone (see the schema).
The 27 recorded so far extend two incidents: five blocks on 363731 in July 2015, and 22 blocks on 14 of the P2SH blocks in April and May 2012, up to three deep.
The blocks built on 74638 in August 2010 were not preserved, and the Bitcoin Wiki lists two more blocks in the 5 July 2015 fork after reported 363997 that are known only by hash, so none of them can be recorded.
data/reported-blocks.jsonl keeps ten blocks that were reported as invalid but cannot be admitted.
Three Eligius blocks of September 2012 were reported as coinbase overpayments alongside the admitted 197438; 197883's header survives but its other transaction and fee do not, and 197701 and 197705 are known only by hash.
P2Pool's 212048 is known from a December 2012 InvalidChainFound report and a node-history dump, without a header or a rejection reason.
Five version-2 hashes from the BIP66 and BIP65 windows come from a March 2017 bitcoin-dev message and still lack headers.
Bitcoin Unlimited's 450529 has a recovered header and a reported size of 1000023 bytes, but no body bytes to establish it.
Issues labelled reported record what has already been searched for each incident and are the place to bring the missing header or body.
Each block includes non-coinbase transactions already confirmed in the canonical parent named by its header, so their inputs were already spent and ConnectBlock fails with bad-txns-inputs-missingorspent.
The dataset calls this already_confirmed_in_parent, separately from forward spends and missing unconfirmed parent transactions.
| Height | Date (UTC) | Transactions reused from parent | Non-coinbase transactions in candidate |
|---|---|---|---|
| 507514 | 2018-02-04 | 338 | 737 |
| 509557 | 2018-02-17 | 1253 | 2322 |
| 515319 | 2018-03-27 | 79 | 79 |
| 534339 | 2018-07-30 | 218 | 218 |
Block 515319 copies all 79 of its parent's non-coinbase transactions in order; 534339 carries a subset in a different order; the other two mix parent transactions with new ones.
All four coinbases carry Mined by AntPool, and the pattern suggests a template whose previous-block hash was refreshed while its transaction list was kept, an inference from the bodies rather than a recovered record.
It is the sibling of the 584802 incident, where the transactions were dropped while their fees stayed in the coinbase.
The pinned chainquery archive holds the hashes in orphans_chainquery.com.json and labels their tips invalid in tips.json; only the former is recorded as a scrape observation, the labels are background.
The bodies reached stale-blocks in abee96d without a recorded acquisition path, so they establish no further observation.
CI checks the named txid in each body against the parent's ordered txid list, authenticated by the parent header's merkle root, with a canonical-height lookup binding the parent to height minus one.
All four pass python-bitcoinlib's context-free CheckBlock and witness-commitment checks, which do not replay historical ConnectBlock.
On 17 September 2026 a Bitcoin Core v31.1.0 node, rewound to each parent with invalidateblock, returned bad-txns-inputs-missingorspent from submitblock for all four.
Core skips BIP30 checks below height 1983702 on the known mainnet chain after BIP34 (see the guard in validation.cpp), so the named failure is the reuse of spent inputs, not bad-txns-BIP30.
A 2026-09-15 sweep of all 1086 stale-blocks bodies at be1e859 found no other non-coinbase intersection among the 1073 bodies extending canonical parents; 13 extended noncanonical parents and were out of scope. A negative result does not establish that a block satisfies every consensus rule.
Each body includes the same 123-byte transaction, 4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2, which spends a pay-to-script-hash output funded at canonical 170054, b0539a45de13b3e0403909b8bd1a555b8cbe45fd4e3f3fda76f3a5f52835c29d:1, worth 400000 satoshis.
Its scriptSig pushes only the redeem script, a 1-of-1 OP_CHECKMULTISIG.
The pre-BIP16 template check hashes that push and compares it, and passes; executing the redeem script finds no signature on the stack and fails.
Nodes applying the 1 April 2012 rules rejected these blocks while older nodes accepted them, which is how the same transaction was included by many miners for months.
Core today reports block-script-verify-flag-failed (Operation not valid with the current stack size).
The four bodies are reconstructions: the coinbase from Namecoin's AuxPoW record, the other transactions from their later confirmations on the accepted chain, and the invalid spend itself; each reproduces its header's merkle root.
They hold 67, 64, 23 and 14 transactions in 31258, 41258, 7662 and 4855 bytes.
CI fetches the funding transaction, checks its txid, and evaluates the named input with and without P2SH.
The blockchain.info block pages archived by the Wayback Machine in April 2012 list each block's transactions.
The 2 April 2012 bitcoin-dev log records the first P2SH VerifySignature failed rejections and the 4 April log preserves the transaction.
The other 85 blocks carry the same spend without a complete body and are admitted from proof files holding the transaction and each block's ordered txids.
Among them are 173886, whose rejection a node log in the 7 April 2012 log records at 14:58:54 UTC on 1 April; 174772, which the 28 November 2012 log shows an unpatched node connecting as its best chain; and 189498, the last, reported in the 17 July 2012 log.
The txid lists come from the Wayback Machine's 2012 captures of the blockchain.info block pages (42 blocks) or from the Decker and Wattenhofer orphan archive preserved in mergedmonitor (43); the June 2012 capture of the transaction's own page lists 88 of the 89 blocks.
Blocks built on 14 of them fail by ancestry: the Decker and Wattenhofer archive holds 22 such headers, and the bitcoincharts node's May 2012 block index holds 21 of them.
Only three of the 89 are attributed, OzCoin at 173928 and 173957 and NMCbit at 173998, from tags in the reconstructed coinbases; the other 86 carry no pool because the search below found nothing, not because none was made.
The 43 archived block pages show the coinbase payout address as blockchain.info rendered it, which is not authenticated and stays out of context.
Each of those addresses was checked for reuse against every canonical coinbase from height 172000 to 190000 (18001 blocks, 3106 distinct payout addresses, read from a Bitcoin Core node with txindex) and against the mining-pools address and tag lists: 40 are single-use with no match, consistent with the reference client's new key per block, and the remaining 46 blocks have no archived page at all.
The same pages record the node that first relayed each block to blockchain.info, a pool's node for 24 of them; that says which nodes were still accepting P2SH-invalid blocks in April 2012, not who mined them, and is not part of this dataset.
bad-txns-vout-toolarge is the 2010 overflow incident (CVE-2010-5139).
A transaction created two outputs of about 92 billion BTC each.
The outputs were non-negative, so they passed the then-current per-output check; their sum overflowed a signed 64-bit integer and wrapped negative, so the input-versus-output check passed too.
Bitcoin 0.3.10 added a money-range check (there is no BIP).
Core now rejects any single output above MAX_MONEY with this string.
Both blocks exceed the sigop limit: accurate sigop cost 80003 against the 80000 maximum, counted in ConnectBlock.
The context-free legacy count is under the limit, which is why replay cannot reproduce bad-blk-sigops.
Documented in b10c observation 11.
CI reproduces the 80003 cost for each block using previous transactions authenticated against its inputs.
Block 783426 has 74520 legacy cost, 160 P2SH cost and 5323 witness cost; block 784121 has 72204, 908 and 6891 respectively.
The previous transactions are fetched from public APIs and cached; the block bodies and their witness commitments supply the remaining evidence.
Three of the block's 255 transactions spend an output of a transaction that appears later in the same block.
As with 809478, ConnectBlock encounters these inputs before their outputs are available: bad-txns-inputs-missingorspent.
This violation is re-derivable from the preserved full block.
145 of the block's 2528 transactions spend an output of a transaction that appears later in the same block.
ConnectBlock processes transactions in order, so the first such input fails the coins lookup: bad-txns-inputs-missingorspent.
This violation is re-derivable from the .bin alone.
Documented in b10c observation 07.
Transaction 110 spends b11a78c6c61af1cb37586f639050d74b95c2b0fd525623b6cb6a4bb4fba46a0e:1, and that parent transaction is not in the block.
The record names that outpoint in missing_prevout.
Both transactions confirmed in the competing block at the same height, 000000000000000000db2504327e272fe7658fac0dd0741f46b212256e500886.
The spent output did not exist at the tip of the previous block, so ConnectBlock fails with bad-txns-inputs-missingorspent.
This is not an in-block ordering error: unlike 477115 and 809478, no later transaction in the body creates the output.
The preserved full block, the parent transaction, its current confirmation and the canonical block hash at 474293 re-derive the violation.
Contemporaneous discussion is BitcoinTalk topic 2041607.
This version-2 header started the 4 July 2015 fork.
The fixture's other five headers, all version 3, chain from it through 363736; the network reorganized away from them, and the alert that followed asked lightweight-wallet users to wait for extra confirmations.
Those five descendants fail by ancestry and are recorded under prev_block_invalid; four of them are committed in Namecoin, Ixcoin or I0coin blocks, and both KIT monitoring nodes received all five on 16 July 2015.
Each holds only its coinbase, so the dump's coinbase fields rebuild the complete block, which reproduces the header's merkle root and the dump's recorded size; the four merge-mined coinbases are byte-identical to the parent coinbases in their Namecoin AuxPoW records.
Each pays exactly the 25 BTC subsidy, and the coinbase tags attribute 363734 to AntPool (Mined by AntPool) and the other four to F2Pool (七彩神仙鱼 and 🐟).
The 80-byte header comes from a blockchain.info block dump preserved in the BTC Relay test fixture for this fork, which also holds the six raw headers; the same field set survives independently in a TypeScript port of BTC Relay.
The dump's 99 transaction IDs reproduce the header's merkle root, and its coinbase fields reserialize to the first of those IDs, which ties the recorded scriptSig to the header.
The coinbase pays 1BwZeHJo7b7M2op7VDfYnsmcpXsUYEcVHm, the address mining-pools lists for BTC Nuggets; the scriptSig tags are /P2SH/ and /stratumPool/, so the attribution is by address.
A 16 March 2017 bitcoin-dev message lists this hash among blocks a node rejected with bad-version(0x00000002).
The 334-byte body contains only its coinbase, which pays 1326546691 satoshis against the 1250000000 subsidy: no fees, an excess of 76546691 satoshis (0.76546691 BTC).
Header hash, proof of work, merkle root, witness commitment and BIP34 height reproduce from the body, and the coinbase carries Mined by AntPool112.
Its parent is canonical 584801, 0000000000000000001b253b1fac766189e15d7f7078191002e5427ac7b8f9f1, which CI checks against the API's block hash at that height.
The header entered stale-blocks through the 2022 chainquery.com getchaintips import and the body in commit abee96d, which does not record how it was acquired, so no P2P observation is claimed.
The binary is preserved byte-for-byte, SHA-256 08e6fb81bc61db0836d8726f9fe40459fc5a9d3f3e64621a74b21b2af4d48df0.
Elastos child 419444 independently witnesses the parent; its Research provenance records acquisition, not the verdict.
The 1890-byte body holds the coinbase and one ordinary transaction.
The coinbase pays 5001000000 satoshis against the 5000000000 subsidy.
The transaction spends output 1 of 8d86cbc5bf98ae815b9f360d0ac208109a75ab7988fc33276fe1eebe46e7fd8f, confirmed at canonical 197333 and worth 503413843 satoshis, and pays out exactly that, so the fee is zero and the excess is 1000000 satoshis (0.01 BTC).
The block predates BIP34, so the height is bound by the canonical parent at 197437, 000000000000008cb385de6a68aaaaa6c3974b98cf8f544b8cce0db1855256c4, not by a coinbase prefix; the coinbase tag is Eligius.
The body is a reconstruction: header and coinbase from the AuxPoW record in Ixcoin block 91289, the transaction from its later confirmation at canonical 197523; the two txids reproduce the merkle root.
Luke-Jr's node log, pasted to bitcoin-dev IRC on 9 September 2012, reports InvalidChainFound for this block and three other Eligius blocks, 197701, 197705 and 197883, whose bodies remain missing.
Core's check then and now is the same subsidy-plus-fees comparison.
stale-blocks PR #139 added the header as a stale block; it is invalid, not stale, and is removed there once this record is published.
This version-1 header extends canonical 232390, 000000000000003d8e7a6b81bde8602277a2b4391df530f82cc13139f00ff3ce, 4460 blocks after the BIP34 activation height of 227931.
All 1000 canonical blocks from 231391 to 232390 carry version 2 or higher, so the 95% rule that nodes ran in April 2013 rejects it, as current Core's height check does.
blockchain.info listed it on its orphaned-blocks page and recorded receiving it at 08:24:51 UTC on 21 April 2013, 89 seconds after its header time.
The header comes from a Spanish-locale capture of its block page, which shows the version, previous hash, merkle root, time, bits and nonce; rebuilt, they hash to the recorded hash.
The page lists 158 transactions. Every one except the coinbase later confirmed on the canonical chain, and none spends an output that confirmed at or above this height outside the block, so the version is the only failure found; the body and coinbase are not available.
The block is not in stale-blocks.