Research into Bitcoin merge mining and what it reveals about the network.
Auxiliary proof of work (AuxPoW) is a common merge-mining construction that lets a sibling chain reuse Bitcoin's hashing work. A Bitcoin miner commits the sibling chain's block in a Bitcoin coinbase, and the sibling chain accepts the associated Bitcoin header as proof of work. The sibling ledger can therefore preserve what Bitcoin parent a miner was building on and when. Namecoin-family proofs also preserve the parent coinbase and related proof material; other designs, notably RSK, expose less. Pool identity is a later inference where the available evidence supports it, not a field recorded directly by every chain. As of 2026, almost 30 chains have merge-mined with Bitcoin since Namecoin activated AuxPoW in 2011, leaving a large, independently hosted corpus of mining evidence.
This repository collects tooling, datasets, and methodology that mine that
corpus for questions about Bitcoin mining generally: mining pools, block
propagation, and the canonical-versus-stale record. Currently, its most
developed work recovers stale Bitcoin blocks from evidence preserved by
merge-mined sibling chains. It also includes a tested registry and decoders for
recognising AuxPoW and chain-specific commitment patterns in Bitcoin coinbase
scripts. A canonical-chain scanner and generated commitment census are not
part of this release. Further directions (mining-proxy and aggregator analysis,
selfish-mining analysis, and mining-pool operations analysis) may follow. See
docs/research-directions.md.
This repository is the public successor to earlier private work on stale blocks. Private and bulky artifact boundaries are documented below. The Merge Mining Monitor combines live tracking of merge-mined chains with the historical datasets produced here (source code). This repository remains the research and data side: methodology, reproducible tooling, and published datasets.
A stale block is a valid Bitcoin block that lost a propagation race and did not
remain in the canonical chain. The merge-mining evidence recovered here
contains a competing Bitcoin header and, where the proof exposes it, coinbase
evidence, not the complete Bitcoin block. The repository therefore publishes
direct-stale header candidates and states which necessary validity checks
they passed. Unless a complete block has been independently validated, the
combination of classification=stale and either exact accepted direct-stale
token in validation_status does not assert full Bitcoin block validity. See the
data validity contract.
Bitcoin nodes that received a stale block may retain it as an alternative chain tip, but historical recovery requires access to a node that was running when the block propagated and still holds that data. Few such nodes remain available, most are private, and relatively few have been searched for stales. Merge-mined sibling chains provide another source: they can preserve the losing Bitcoin header in their own block history long after the original event.
A merge-mined child chain can preserve a competing Bitcoin header before the Bitcoin race resolves, allowing the stale header to be extracted and validated later. Editable diagram source.
The recovery method used here builds directly on work by Nicholas Stifter, Philipp Schindler, Aljosha Judmayer, Alexei Zamyatin, Andreas Kern, and Edgar Weippl. Their 2018 paper, "Echoes of the Past: Recovering Blockchain Metrics From Merged Mining", introduced the technique of reconstructing Bitcoin forks and stale blocks from cryptographic evidence in merge-mined child chains, and showed why it complements live network monitoring. This project extends that foundation across additional chains with reproducible acquisition, extraction, validation, evidence preservation, and analysis pipelines.
Obtaining that sibling-chain history was a substantial part of the
recovery. This repository includes reproducible Docker workspaces for the
vintage or otherwise awkward daemons that had to be built, patched, connected,
synced, and operated, along with recovered peer and bootstrap configuration.
See node-infra/README.md and its per-chain READMEs;
recoveries based on snapshots, public archives, JSON dumps, or APIs are
documented in the corresponding notes under docs/chains/.
The node workspaces support preserved datadir adoption, explicit historical
start/stop commands and offline profiles. Host-specific settings and native
build inputs remain in the private archive.
Qbit archival acquisition is complete through child height 80,986, with a pinned node workspace and tested proof adapter. Its publication contains 2,536 canonical observations and four accepted direct-stale witnesses. All 24 unknown parents fail the Bitcoin epoch-target relevance gate.
The recovery pipeline runs per sibling chain:
- Extract (
scripts/extract/): parse each sibling block's merge-mining proof and pull out the 80-byte Bitcoin parent header plus coinbase evidence where the source exposes it. Depending on the source, this reads rawblk*.datfiles offline, queries a sibling-chain node over RPC, or parses a recovered dump or API response. - Classify (
scripts/classify/): check each unique parent header against Bitcoin Core. A header absent from the active chain whose prev-hash is active becomes a direct-stale candidate; one whose prev-hash is also unknown stays in theunknownbucket. - Gate (
btc_stale_validation): apply the declared header-context profile, including self-target proof of work, active-parent linkage, canonical-heightnBits, median-time-past, historical minimum block versions, coinbase scriptSig length, and BIP34 coinbase height where the evidence permits. The verdict is persisted per row. RSK lacks the coinbase evidence needed for the final two coinbase-dependent checks. - Integrate: the rows that pass that profile become the committed
data/validated-stales/<chain>_validated_stales.csvloader input, deduplicated by(height, hash)so competing same-height hashes are both preserved.
The committed chain inputs hold 3,863 accepted direct observations covering
2,155 unique (height, hash) Bitcoin events; the per-chain and cross-chain
accounting, with its caveats, is in
docs/process-data-outcomes.md. Current upstream
overlap and chronological allocation live in the novelty report;
run just novelty to regenerate it or just novelty-check to verify it.
The table below summarizes child chains for which the project recovered and
classified Bitcoin-parent evidence. Rows follow the documented merge-mining
evidence chronology. Accepted direct-stale candidates are headers in the
committed loader inputs that passed the published header-context profile; they
are not claims that a complete Bitcoin block was fully consensus-valid.
Strict BTC orphans and weak BTC orphans are separate relevance buckets
for parent headers whose primary classification remains unknown: strict
observations have block-height evidence and matching Bitcoin nBits, while
weak observations have timestamp-selected nBits consistency within one
retarget epoch. Counts are per-chain observations, and zero means none in the
recovered scope, not necessarily none over the chain's lifetime. Not
assessed means the required unknown-parent inventory was not available to the
public relevance pass.
The final column is limited to the most important coverage qualification or
evidentiary significance. Detailed provenance, stage counts, validation
rejections, and artifact availability are in the linked chain notes, or in
the docs/process-data-outcomes.md cross-chain accounting snapshot linked
above.
| Child chain | Source and recovered scope | Accepted direct-stale candidates | Strict BTC orphans | Weak BTC orphans | Coverage limit or significance |
|---|---|---|---|---|---|
| Namecoin | Offline blk*.dat parse; AuxPoW recovery window from BTC height 148,553 |
1,641 | 8 | 10 | Earliest production recovery window and the largest accepted direct-stale contribution. |
| Geistgeld | Complete Nicholas Stifter getblock JSON dump; 7.3M records |
0 | 0 | 0 | Most parent headers use targets easier than Bitcoin's and do not link to Bitcoin mainnet, so no direct stales are accepted. |
| i0coin | Complete March 2026 snapshot; 87 blk*.dat files parsed offline |
191 | 0 | 0 | Accepted Bitcoin stales end in August 2020; the later child snapshot contains no further accepted direct stale. |
| ixcoin | Local IXCore node; full AuxPoW range scanned to the recovered tip | 464 | 0 | 0 | One of the largest early-chain direct-stale contributions; accepted observations end in July 2016. |
| CoiledCoin | Recovered archival node; January to July 2012 BTC-parent window | 27 | 0 | 0 | The window includes the January 2012 Eligius attack; all 27 accepted candidates cross-confirm earlier sources. |
| Devcoin | Local node; AuxPoW range scanned to the recovered tip | 467 | 1 | 0 | One of the largest early-chain accepted sets, spanning January 2012 to December 2020. |
| Groupcoin | Nicholas Stifter getblock JSON dump through child height 235,751 |
30 | 0 | 0 | The network is dead, and no source is known beyond the dump's July 2018 endpoint. |
| Huntercoin | Kraft native dump through stored height 3,937,953; all retained Arweave anchors match | 78 | 0 | 0 | Observed endpoint July 2021; two invalid-fork witnesses are catalogued separately. Native active-chain membership and full consensus were not replayed. |
| Unobtanium | Local node; continuous AuxPoW scan to the recovered chain tip | 43 | 0 | 0 | Accepted direct stales end in August 2020 despite the roughly 11-year scan. |
| Crown | Local node; complete SHA-256d proof-of-work era | 23 | 0 | 0 | Coverage ends at the full proof-of-stake transition; most stales overlap other sources. |
| Myriadcoin | Local multi-algo node; SHA-256d branch scanned to the recovered tip | 40 | 0 | 0 | Other proof-of-work algorithms do not carry Bitcoin-parent evidence. |
| SixEleven | Local 611d node; complete legacy chain through child height 999,406 |
0 | 0 | 0 | Complete recovered range with no accepted stale or strict/weak evidence. |
| Argentum | Local multi-algo node; SHA-256d branch scanned to the recovered tip | 2 | 0 | 0 | Bitcoin-confirmed parent observations are sparse beside the unresolved population; this ratio is not a hashrate estimate. |
| Terracoin | Local node; full AuxPoW-era scan to the recovered tip | 35 | 0 | 0 | Accepted observations span May 2017 to August 2020. |
| Emercoin | Local hybrid PoW/PoS node; scanned to the recovered tip | 96 | 0 | 0 | Most post-activation blocks are PoS and cannot preserve this Bitcoin-parent evidence. |
| RSK / Rootstock | RSKj 9.0.1 archive node, child heights 0 through 9,220,904; canonical blocks plus every advertised uncle | 351 | 3 | 0 | The early acquisition gap is accounted for; no pre-139,999 parent passes its own PoW target. The full coinbase cannot be reconstructed, and the 3 strict verdicts come from cross-chain matches. |
| Doichain | Local node; block-file survey through the active-chain tip observed at child height 430,684 | 0 | 0 | 0 | Observed-window negative result with no accepted stale or strict/weak evidence. |
| Bitmark | Synced multi-algo node; SHA-256d branch scanned to the recovered tip | 1 | 0 | 0 | The single accepted candidate cross-confirms an event already seen by other chains. |
| Xaya | Kraft native dump; stored ancestry reaches height 7,312,209 | 42 | 0 | 0 | Extends past the migration height; ten unlinked stored side headers remain explicit coverage limitations. |
| Elastos | Local ELA node plus public API tail; accepted evidence through April 2026 | 174 | 3 | 0 | One of the largest post-2018 direct-stale contributions. |
| Syscoin | Local node; fresh-genesis chain launched in 2019 | 96 | 1 | 0 | The retired 2016 to 2019 Syscoin chain was not extracted. |
| Hathor | Public REST API; retained corpus through child height 6,593,796 | 6 | 0 | 0 | The unified result covers 6,532,372 version-3 observations and publishes 3,658 canonical parents plus the 6 accepted direct stales. |
| Bitcoin Vault | Trezor Blockbook raw-block API; nearly complete AuxPoW lifetime | 9 | 0 | 0 | No node was available, and no later accepted direct stale was found after 2021. |
| Electric Cash | Self-synced local node; standard Namecoin-style AuxPoW | 3 | 0 | 0 | The three accepted stales from June to September 2021 all cross-confirm Bitcoin Vault observations. |
| SpaceXpanse ROD | Fully synchronized archival node; every active-chain block through height 4,127,689 | 0 | 0 | 0 | The complete scan found one fully reviewed canonical Bitcoin parent; lower-work and unresolved templates remain private evidence. |
| Lyncoin | Live-peer P2P header stream; complete pre-Flex merge-mined era | 0 | 0 | 0 | Complete recovered era with no accepted stale or strict/weak evidence. |
| Fractal Bitcoin | Archival node; point-in-time scan through child height 1,807,154 | 40 | 0 | 0 | Only the Cadence merge-mined block class carries Bitcoin-parent evidence. |
| Qbit | Fully validating native archive; genesis through child height 80,986 | 4 | 0 | 0 | Publishes 2,536 canonical parents; all four stales cross-confirm upstream and RSK, while 24 synthetic-parent proofs fail Bitcoin epoch targets. |
VCash is kept outside the direct-stale table because no VCash blockchain was recovered and its stale and strict/weak totals cannot be measured. Its partial canonical evidence is still useful to the Merge Mining Monitor.
| Child chain | Recovered evidence | Material limitation |
|---|---|---|
| VCash | 68 Bitcoin Core-confirmed canonical mappings from a 767-row explorer archive | The remaining 699 mappings are unresolved, and the subset cannot measure VCash-witnessed Bitcoin stales. |
The remaining surveyed candidates did not yield chain evidence. Keeping these blocked and source-only outcomes separate avoids confusing "zero stales" with "no data".
| Child chain or candidate | Data recovered | Status and main hole |
|---|---|---|
| BLAST | Build and network diagnostics only | No peer completed a handshake and no chain data was recovered. |
| Bitcoin Stash | Source and protocol research only | No reachable peer or block archive. |
| Fusioncoin | Private source archive only | No canonical node run, extraction, classifier output, or block archive. |
| Jax.Network | Official source and container material only | Seeds, explorer, and public data routes were unavailable. |
| Jincoin | Buildable source and node scaffold | No reachable peers or private block archive. |
Two kinds of gap in the tables above are worth surfacing, because closing either one is exactly the sort of contribution this project wants.
No recovered data. Five surveyed candidates (BLAST, Bitcoin Stash, Fusioncoin, Jax.Network, and Jincoin) yielded no block data at all, as the status table above records, so any reachable peer, block archive, or working sync path for them would be a first.
Partial or bounded coverage. VCash, i0coin, Huntercoin, Xaya, Syscoin, and Bitcoin Vault carry the coverage limits stated in their table rows, and more history would extend or firm up each result. Two limits are worth stating precisely: the Kraft dump closes Xaya's former snapshot tail gap in stored ancestry, while ten unlinked side headers and no native active-chain replay remain explicit limits. Huntercoin's observed dump endpoint is July 2021. Bitcoin Vault's post-2021 era is weak-share only, so it yields no further accepted candidates.
Raw block data, snapshots, node datadirs, peer addresses, or archive locations
for any of these are welcome even without running the pipeline. See
CONTRIBUTING.md and the per-chain notes under
docs/chains/.
The recovered coinbase evidence is retained for mining-pool attribution.
Attribution supports analysis of pool size, stale incidence, and block
propagation, but stays outside the acquisition and recovery pipeline. The pool-attribution layer itself, including its dual
tag-owner/template-producer attribution design, is implemented in this
repository and documented in
docs/pool-attribution.md. The
observed-versus-expected stale-rate analysis, its methodology and threats to
validity, and the propagation-era definitions live in the companion
stale_rate_analysis repo (not yet published).
The reusable logic lives in the core modules under src/stale_blocks_analysis/
(auxpow_parse, auxpow_chainid, btc_rpc, btc_classify,
btc_nbits_validation, and the CHAIN_SPECS registry in config.py). The
unknown-ancestry analysis entry point is
scripts/analysis/reconcile_unknown_stale_ancestry.py. See
docs/auxpow-recovery.md for the cross-chain recovery
model and validation caveats, and the per-chain provenance docs under
docs/chains/ for source-specific methodology.
src/stale_blocks_analysis/coinbase_markers.py provides a data-only registry
and decoders for recognised coinbase patterns, including AuxPoW magic,
chain-specific OP_RETURN tags, pool tags, SegWit commitments, and BIP34
height pushes. Focused pinned-fixture coverage is available through
just test-markers.
These helpers classify coinbase data supplied by a caller. This release does not include a scanner that fetches canonical Bitcoin blocks or a generated SQLite, Parquet, or other census dataset. Such a census remains future work and is not an input to stale-block recovery or the committed loader datasets.
.
├── src/stale_blocks_analysis/ # importable recovery package:
│ # loaders, native framing/ancestry, AuxPoW commitments,
│ # validation, CHAIN_SPECS
├── scripts/ # extraction, classification, and analysis tooling
│ ├── extract/ classify/ analysis/ reports/ prep/
│ └── fetch-data.sh # clones pinned public datasets into data/
├── data/ # committed stale and error-block loader inputs
│ ├── validated-stales/ # per-chain accepted direct-stale loader inputs
│ ├── bitcoin-epoch-reference/# public nBits/time reference for relevance gates
│ ├── child-identity/ # verified child hash and time records per chain
│ ├── error-blocks/ # error catalogue, witness ledger, and context
│ ├── stale_descendants.csv # accepted stale-fork parent verdicts
│ ├── stale_descendant_observations.csv # authenticated witnesses
│ ├── new_stale_blocks_for_upstream.csv # pending bitcoin-data sidecar rows
│ └── upstream_header_fills.csv # headers for hash-only upstream rows
├── results/ # committed reference CSVs and final exports
│ ├── monitor-evidence/ # Git LFS-backed per-chain payloads + metadata
│ ├── analysis/ # regenerable diagnostics grouped by question
│ ├── novelty.md # generated upstream and chronological novelty report
│ ├── strict-weak-orphans/ # strict/weak BTC-orphan relevance outputs
│ ├── child-header-coverage.csv # authenticated historical refresh coverage
│ └── rsk_pool_registry.csv # historical RSK miner-address label snapshot
├── docs/ # methodology, research directions, per-chain
│ # provenance, pipeline contracts, node operations,
│ # investigations and visual artefacts
├── node-infra/ # Chain nodes and the one-off research worker
├── tests/ # pytest suite
├── justfile # common commands (just test / full-evidence / ...)
├── AGENTS.md # concise entry point (CLAUDE.md links to it)
├── pyproject.toml
├── LICENSE # MIT: project-authored software and documentation
└── LICENSE-DATA # CC BY 4.0: datasets and visual artefacts
Huntercoin and Xaya use the Kraft native dumps as their foundation inputs. Earlier Arweave/CDN recoveries are historical provenance, not fallback workflows.
Documentation for contributors and agents lives in docs/, including the
pipeline reference,
research contracts and
node operations. AGENTS.md is the concise agent
entry point and links to that same documentation.
Requires Python 3.10 or newer. The documented task recipes also require the
just command runner and Git LFS for the
published monitor-evidence payloads.
git lfs install --local
git lfs pull --include="results/monitor-evidence/*_monitor_evidence.csv"
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
./scripts/fetch-data.shpip install -e ".[dev]" installs the runtime dependencies plus pytest and
Ruff for the documented checks. Use pip install -e . when only the runtime
pipeline is needed.
The per-chain results/monitor-evidence/*_monitor_evidence.csv payloads are
stored in Git LFS. The counts CSV and JSON manifest remain ordinary Git files
so publication changes retain a compact, directly reviewable summary. Without
Git LFS, a checkout contains pointer files instead of the evidence payloads.
just test-unit excludes the dataset-marked publication invariants and can
run from that pointer-only checkout. just test-dataset, and therefore
just test, requires the payloads to be materialized first.
The node-infra Compose policy tests (tests/test_node_infra_compose.py, part
of the default pytest suite) require the Docker Compose CLI. They only render
the committed Terracoin/Fractal profiles with docker compose config. They
never start containers, build or pull images, or contact a node, and fail
loudly when the renderer is unavailable. Run them alone with
just test-node-infra.
fetch-data.sh checks out bitcoin-data/stale-blocks at the exact commit
pinned in data-sources.tsv, so stale-block membership and
novelty results are reproducible. Run just upstream-check to compare the pin
with current upstream, or just upstream-update stale-blocks to update the pin
and checked-out dataset deliberately. The fetch script will not disturb a
clone that is on a branch or has local edits. Override its location with
STALE_BLOCKS_DIR.
Body-invalid catalogue validation also reads the pinned bitcoin-data/invalid-blocks
clone under data/invalid-blocks/, fetched by scripts/fetch-data.sh.
Set INVALID_BLOCKS_DIR to select another checkout. Bodies are authenticated
locally; their named consensus failures are independently established upstream.
just format-check
just lint
just test
just test-unit
just test-dataset
just test-node-infra
just upstream-check
just refresh-bitcoin-epoch-reference
just full-evidence
just strict-weak-orphans
just monitor-evidence
just validate-error-blocks
just reconcile-stale-ancestry --rpc-source-label core-reference
just build-rod-canonical --extraction-root <private-rod-extraction> \
--audit-root <private-final-audit> <remaining-pinned-input-options>
just attribute
just child-header-coverage --input-dir <staged-evidence-dir> \
--output <staged-results-dir>/child-header-coverage.csv
just check-leaksjust monitor-evidence is a release rebuild, not a clean-clone regeneration
recipe. A complete rebuild requires the private canonical/classifier archives
plus the relevance evidence described by the command's help. VCash uses the
same canonical-source convention as other chains: stage its hydrated source as
vcash_canonical_blocks.csv under data/ or a supplied archive root.
It includes every available canonical row for every chain and fails closed
when required inputs are incomplete. --skip-canonical is a diagnostic option
and is accepted only with --allow-partial and an explicit, disposable
--output-dir; partial builds must not replace the committed release
artifacts. The command stages the complete generated set before replacing the
publication transactionally, and preserves unrelated files in the output
directory if the build succeeds or fails. Complete exports may have an
external final destination. When output is staged for later installation
elsewhere, pass --reported-output-dir with that final destination so every
generated metadata path names it. Without that option, the output directory
itself is the reported destination. The same completeness gates apply to
repository and external destinations.
just build-rod-canonical validates the complete audited private ROD
extraction and the independently reviewed canonical child and Bitcoin bodies.
It writes rod_canonical_blocks.csv plus a digest receipt to a required fresh
private output directory. Activate the project virtual environment first and
pass every required source path and digest shown by --help; the repository
does not contain those private inputs.
just validate-error-blocks validates the reviewed canonical error-block
catalogue, its median-time-past sidecar, and the exact child-observation
ledger that covers it. just reconcile-stale-ancestry requires the complete
staged ancestry inventories. The --data-dir option selects a complete staged
tree, including its error catalogue, epoch reference and pinned invalid-block
bodies, while runtime classifier bindings remain intact. It validates the
canonical error module first,
excludes its known parent hashes, evaluates the complete candidate population
against trusted stale roots, and publishes accepted parent verdicts in
data/stale_descendants.csv with their authenticated witnesses in
data/stale_descendant_observations.csv. Any consensus-invalid candidate not
already admitted to the canonical error catalogue fails the workflow before
either stale-ancestry artifact is installed.
The command also requires a stable, non-secret --rpc-source-label for the
Bitcoin Core node that performs the exact active-hash-at-height comparisons.
That label is committed as bitcoin-core-rpc:<label>; configured-node is
reserved for disposable partial diagnostics.
Per-chain extraction and classification entry points are documented in the
corresponding notes under docs/chains/. Run an individual
script with --help before using it against a node, archive, or API source.
Historical Namecoin-family extractors emit an authenticated child-header
bundle (child_block_hash, child_header_hex, child_block_time, and
child_nbits) from the original block source. Classifiers preserve that
bundle in every split output, and the evidence exporters recheck its internal
consistency. Existing raw or classified CSVs that predate these columns are
not valid hydration inputs. Re-run the normal extraction and classification
path instead. The source status and safe refresh contract are documented in
docs/child-header-hydration.md.
just refresh-bitcoin-epoch-reference incrementally refreshes the compact
Bitcoin retarget-boundary and confirmed-horizon dataset from mempool.space's
public Esplora-compatible API. A scheduled GitHub Actions workflow runs the
same command weekly, opens a reviewable pull request when the reference
changes, and merges that pull request once CI passes. Auto-merge needs an
AUTOMATION_PAT repository secret, because a pull request opened with the
default GITHUB_TOKEN never triggers CI; without the secret the refresh still
opens a pull request and leaves it for manual review. The strict/weak relevance
tools consume this committed public input; cache/ remains reserved for
transient local lookups.
The committed data/validated-stales/*_validated_stales.csv files are the
canonical stale loader inputs. Every available canonical-parent row is
published alongside the other final monitor-facing rows under
results/monitor-evidence/; full classifier inventories remain outside the
repository. Other reference outputs live under results/, and regenerable
diagnostics are grouped by research question under results/analysis/.
Schemas for committed datasets are documented in the
dataset reference.
Namecoin's accepted loader now includes complete coinbase output script vectors recovered from its private classified inventory. The normal blkdat extractor and classifier retain the full vector and emit its final rendering directly; classification rejects partial output claims before RPC or writes. See the Namecoin recovery receipt for counts, fingerprints, attribution impact and the verified Monitor rebuild. Full-evidence exports retain the selected classifier inventories' source-level output claims.
Bulky fetched data (the upstream bitcoin-data/stale-blocks clone) and large
derived artifacts (full per-chain evidence exports,
unknown-origin inventories, and any locally generated Bitcoin coinbase census)
are not committed. The largest consolidated datasets are candidates for future
separate publication rather than tracked in git; this release does not claim an
unlinked external dataset publication. See docs/ for the
committed-versus-external boundary.
A final monitor-facing projection of the evidence is committed under
results/monitor-evidence/ (built by just monitor-evidence): per-chain CSVs
holding only the final categories the merge-mining-monitor ingests - canonical
rows, publication-gate-accepted direct stales and stale descendants, and
strict/weak BTC orphans -
with the classification vocabulary both projects share. See the
dataset reference for the schema and value
vocabularies.
The breadth of this project would not have been possible without extensive use of modern AI and large language model (LLM) tools. Most code, tests, infrastructure, chain-recovery scaffolding, and supporting technical documentation were generated or substantially developed with LLM assistance under human direction and review. Key user-facing documents, methodological decisions, interpretation of results, and published claims remain subject to direct human authorship, editing, and approval.
LLM output is treated as working material rather than research evidence. Technical claims and generated code are checked against source implementations, node behaviour, primary sources, chain data, and reproducible pipeline outputs. Responsibility for the published work and any remaining errors rests with the maintainer.
Project-authored software and associated documentation are licensed under the
MIT License, see LICENSE. This includes the code under src/,
scripts/, and tests/, together with project-authored build configuration
and node-infrastructure tooling. Files carrying their own copyright or license
notices remain subject to those notices.
Project-generated dataset files under data/ and results/, together with
visual artefacts under figures/ and docs/img/, are licensed under Creative
Commons Attribution 4.0 International (CC BY 4.0), see
LICENSE-DATA.
These licenses apply only to rights held by this project. Fetched, cached, or
vendored third-party material retains its original license. In particular, the
pinned bitcoin-data/stale-blocks dataset is CC0. Gitignored upstream datasets
and caches under data/ are not relicensed by this repository.