A live view of the newest Bitcoin blocks that trusts no server — every block is re-verified against the consensus rules in your own browser, then scored for how much arbitrary data it carries.
Most block explorers ask you to trust their database. This one doesn't. Block headers are
self-certifying — proof-of-work and the hash linking each block to its parent are checkable by
anyone — so a header stream needs no trusted host: you verify it on arrival. block·health
takes that stream from Nostr,
re-checks it, fetches the full blocks, re-validates them with a real Bitcoin consensus engine, and
reports what it found. If a relay or publisher lies, the checks fail and you see it.
NIP-333 is a small Nostr
convention for publishing Bitcoin headers: a parameterized-replaceable event of kind 33333
whose content is the newest 12 block headers (80 bytes each), concatenated as hex, tip last. The
d tag names the network (btc for mainnet). Relays keep only the latest event
per publisher, so subscribing gives you a self-updating window on the chain tip.
The publisher is a filter, not an authority. A NIP-333 key is a brand you choose to follow for convenience — it is never a security boundary. Every consumer re-checks proof-of-work and linkage, so following a dishonest publisher costs you nothing but a failed check. You can follow several and prefer the heaviest verified chain.
Nothing from the network is taken on faith. The page runs the bitcoin-kernel engine — a schema-driven Bitcoin consensus engine in pure JavaScript — inside a Web Worker:
bits, and each header must point at the previous one's hash.Why "without prevouts"? Fully checking that every input spends a real, unspent coin needs the whole UTXO set — gigabytes a browser tab won't hold. So this runs as a pruned window with an empty coin view: value, fee and script-signature rules honestly report unresolved rather than pretending. Everything that can be checked from the block alone — its structure, merkle commitment and witness commitment — is fully checked. It's an honest partial validation, and it says which parts it skipped.
Bitcoin's OP_RETURN outputs let a transaction embed arbitrary data — timestamps, protocol
messages, inscriptions, images. For years the default relay policy capped a data output at 80
bytes of payload, which is 83 bytes of scriptPubKey once you count the
OP_RETURN opcode and its push prefix. That limit has since been relaxed, and blocks now
routinely carry far larger payloads.
For every block, block·health counts the OP_RETURN outputs and flags those
over each historical line:
| threshold | what it measures |
|---|---|
> 80 B | the pushed data payload exceeds the classic datacarrier data limit |
> 83 B | the whole scriptPubKey exceeds the classic standardness limit |
A block with no oversize outputs shows healthy; one carrying larger data shows
bloated. The coinbase's own witness-commitment OP_RETURN is protocol
overhead, so it's counted separately and never flagged. This isn't a value judgement — it's a lens on
how the demand for on-chain data storage is showing up block by block.
Mining pools stamp a marker into the block's coinbase transaction — the scriptSig of its
single input, which carries no spending role and is free-form. Reading its printable ASCII usually
reveals the pool: /Foundry USA Pool/, Mined by AntPool,
SpiderPool/. The page matches that tag against a list of known pool markers — the same
primary signal mempool.space uses — and shows the raw tag alongside, derived entirely from the block
itself with no attribution service in the loop.
Not all datacarrier traffic is the same, so each OP_RETURN is classified straight from its
bytes:
OP_RETURN OP_13 (6a 5d),
the protocol's magic. That prefix alone identifies a Runes etch, mint, or transfer.16383) fields, each a
u128 holding 15 payload bytes. Reassembling those 15-byte chunks and reading the first
integer gives the protocol id — 1 is Alkanes. Runes indexers ignore that odd tag, so the
message is invisible to them but decodable here.OP_RETURN OP_8 (6a 58) is the marker for
OP_NET, a smart-contract metaprotocol whose
epoch-mining participants submit SHA-1 proof-of-work solutions on-chain. The payload carries the solver's
account key and the solution preimage.0x<hex>|depositor=bc1q…| — an EVM-style destination plus a
depositor/refund field. Flagged conservatively, so it may miss uncommon formats.OP_RETURN whose payload begins with one of the protocol's ASCII
ids (pwt1: credits, pwm1: mail/bonds, pwid1: identities, pwr1:) —
a social/token/mail system built on legacy Bitcoin transactions with 546-sat "proof" payments.OP_RETURN whose payload is entirely zero bytes: a reservation/padding
output that carries no information (Alkanes transactions often emit one). Split out so it doesn't inflate the data count.OP_RETURN (timestamps, protocol messages, raw bytes).The block faces show per-block counts (⚗ Alkanes, ᚱ Runes) and the detail panel
labels each oversize output by type. In practice Alkanes protostones dominate the oversize traffic —
which is precisely the demand for on-chain data that the relaxed datacarrier limit unlocked.
Three static files and a vendored engine — no framework, no build step, no backend. It runs anywhere that serves files: GitHub Pages, a static host, a personal data pod.
index.html — the app: Nostr subscription, header checks, UI.validator-worker.js — off the main thread: fetch a raw block, decode, validate, measure health, identify the pool.engine/ — the vendored bitcoin-kernel codec and JSON-LD consensus schemas.Raw blocks come from the mempool.space / blockstream.info esplora APIs (whichever answers first). Those are dumb byte sources — the bytes are validated on arrival, so a wrong answer is caught, not trusted.
Related explorers worth a look: mempool.guide (block/tx links open here) and mempool.kilombino.com — public mempool instances you can cross-check against.