Mining attribution

A block does not say who mined it. What it carries is a coinbase transaction: a scriptSig with bytes the miner chose, and outputs paying somebody. btcintel records that as an observation, matches it against published pool catalogs, and serves every match with its method and its source. Where the catalogs disagree, the answer says so.

The observation

The extractor coinbase-v1 reads the raw block and stores a pure function of it: the printable runs of the coinbase scriptSig after the BIP34 height push (tag_runs, joined as tag_text), the full scriptSig, each output with its script hash, rendered address and value, the reward, and the fees as reward minus the subsidy of the claimed height. No author, no interpretation; a re-extraction produces the same row. Blocks that were later orphaned keep their observation, because they did exist.

The catalogs

Pool signatures come only from catalogs published by others — today the mempool.space and bitcoin-data lists — imported with licence and attribution (sources). A signature is a coinbase tag to look for, or a payout address. btcintel never learns a signature from a block it matched: the tables of what pools look like are data, not inference.

Attributions, plural

The matcher pool-matcher-v1 evaluates every current signature against the observation and writes one attribution per match: entity, method (coinbase_tag or coinbase_address), the catalog it came from, the evidence (the run or the output), a confidence class from the GraphSense vocabulary, and a citation with a content hash. Nothing is merged and nothing is deleted when a catalog changes its mind: the attribution expires with a date and stays addressable at its version.

The read policy

GET /v1/blocks/{id}/attribution returns the attributions ordered by policy v1: method rank first (prev_template, then coinbase_address, then coinbase_tag, then coinbase_script, then manual), then confidence level, then the source's editorial prior. pool is the first row — an answer with its method, never a verdict — and disputed is true when the two best rows name different entities. The block page and the block list carry the same pool.

curl -s https://api.btcintel.io/v1/blocks/840000/attribution \
  | jq '{pool, disputed, policy_version, attributions: [.attributions[] | {entity: .entity.id, method, source: .source.id, citation}]}'

When a tag and an address disagree

A coinbase can carry one pool's tag and pay another pool's address (a proxy, a rebrand, a catalog that has not caught up). btcintel writes both attributions and one event, tag_address_mismatch, that cites them and names the two entities. When a later catalog update removes the disagreement, the event is retracted with that reason. The event is listed on both entities' pages.

Absent and empty

Before the extractor has run for a block, observation and pool are absent from the answer: not computed. After it ran and no catalog matched, attributions is an empty list and pool stays absent: computed, nothing found. The difference is the contract; see the semantics page.