A modern, accurate roadmap for BlockchainInfo, reflecting the tool as it exists today.
BlockchainInfo has evolved into a Bitcoin telemetry instrument — a sovereign, real-time observatory revealing the living patterns of:
- hash power
- consensus health
- miner identity
- mempool energy
- node diversity
This roadmap is built on three principles:
All sections update independently with zero UI blocking.
Every dataset available instantly, shared across the entire app.
Prevents RPC overload during tx storms.
Instant search via RPC, paste detection, backspace-safe input.
Minimal, clean, self-documenting UX.
Live visualization of miner progress inside the 2016-block difficulty epoch.
Human-readable pool identification for every new block.
Active + stale branches shown in real time.
Popup triggers when any fork reaches length ≥ 2, warning the user of:
- potential reorg
- chain instability
- miner conflict
- consensus turbulence
Includes cooldown to prevent spam. This is a flagship BlockchainInfo innovation.
Pure mempool analytics, undistorted by spam, dust, or non-minable tx.
These are real ideas — not promises — designed to expand clarity without bloating the interface.
Show the last epoch’s hash rate at:
- 10%
- 25%
- 50%
- 75%
- 100%
A 5-point sparkline or micro-chart revealing miner momentum through the epoch.
miners.json expansion:
- pool name
- region/country
- wallet cluster
- optional anonymity flags
Allows small, optional region distribution displays.
Based on net totals:
- live inbound/outbound bytes
- optional toggle
- minimal footprint
Single key → exports:
- block height
- hash phase
- mempool state
- network stats
- fork status
- miner identity
A simple archival feature for node operators.
Implemented in 1.4.0-beta
A rolling 30 chain-day miner trend view based on actual blocks rewarded (144 blocks = 1 chain-day).
This feature reveals which miners and pools are gaining or losing momentum over time by tracking block distribution across consecutive chain-days.
Intent: Provide operators with a clean, manipulation-resistant signal of miner trend and network participation shifts — based purely on block reality, not hash-rate estimates or external metrics.
Design:
- Rolling 30 chain-day window
- Each chain-day = 144 blocks
- Miner counts aggregated per chain-day
- Trend deltas computed day-over-day and across full window
- Optional compact sparkline per miner
Insights Provided:
- Miner momentum (rising / falling participation)
- Pool dominance changes
- Emerging miner activity
- Structural network shifts
Philosophy: Blocks are the final truth layer of mining activity. This feature surfaces what the network actually rewarded, not what was advertised or estimated.
Status: Implemented in 1.3.0
Add a keybind to trigger a lightweight popup Popup displays: Current estimated hashrate (EH/s) Uses same logic: getnetworkhashps(144, current_height)
Intent: Provides an immediate comparison: Current state vs. sampled phase progression
Operator can quickly answer:
- Is hashrate rising since earlier phase samples?
- Is it dropping off mid-epoch?
- Is current value out of line with recent checkpoints?
- Add a keybind to trigger a lightweight popup
- Popup displays:
- Current estimated hashrate (EH/s)
Design:
- On-demand only (no constant polling)
- Uses same 144-block window for consistency
- Minimal UI:
- small popup
- no history, just “now”
Optional future extension (if it evolves):
- Color hint vs. last phase:
- ↑ higher than last sample
- ↓ lower than last sample
- Or simple delta:
- +32 EH/s from last phase
- Explore rolling BTC-value metrics within mempool windows
- Potential metrics:
- Total BTC awaiting confirmation
- BTC competing for next block
- Median BTC per transaction
- BTC distribution across fee-rate buckets
- Rolling BTC cleared per block
- Intended as observational/economic context rather than forensic analysis
- Could correlate with hashrate breathing, miner distribution, and fee urgency windows
- Potential metrics:
Observability Review (2026)
Status: Deferred / Likely Retired
Reason: While the concept is interesting from an economic-observability perspective, deriving meaningful BTC-value pressure metrics requires continuous inspection of the raw mempool.
For large mempools this effectively becomes:
Repeated getrawmempool retrievals Continuous transaction processing Ongoing value aggregation Frequent recomputation of bucket distributions
This workload is disproportionate to the value provided within a lightweight terminal observatory.
BCI's design philosophy favors:
Low RPC impact Fast refresh cycles Broad node compatibility Sustainable long-running observation
The proposed metrics are computationally expensive and derive from data that is not directly exposed through lightweight RPC summaries.
Lesson learned:
The question was not: "Can we calculate economic flow metrics?"
The answer is yes.
The question became: "Can we calculate them efficiently enough to justify their place in a real-time TUI observatory?"
Current answer: Probably not.
This concept may be better suited for a dedicated daemon, research tool, or offline analytics platform rather than BCI's live observatory model.
Instances mirroring each other over LAN. A sovereign “observer cluster.”
Let advanced users add custom RPC queries to display.
Flip-dot inspired graphics, or more cinematic toggles.
The original roadmap included explorations around:
- RBF manipulation logs
- mempool forensics
- miner censorship detection
- replacement storms
- priority fee comparisons
These are no longer aligned with the direction of BlockchainInfo.
The tool has matured into a clarity instrument, not a forensics engine.
Status: Implemented in v1.4.0 as UASF Signals.
Future BCI feature: runtime BIP/User-Agent monitoring. Allow operator to set or update a monitored token while BCI is running and display peer adoption count/percent in a new panel within the Client/Version Distribution area.
Status: Deferred / Likely Retired
Reason: Miner share already represents observed block attribution. Estimated pool hashrate would be derived from the same block-share data and therefore does not provide an independent signal.
Example: Network HR (On-Demand): 856 EH/s Foundry Share: 25%
Operator can already infer: 856 × 0.25 ≈ 214 EH/s
This adds arithmetic, not observability.
BCI favors new signals over transformed versions of existing signals.
Lesson learned: The question was not "How much estimated hashrate does a miner have?" The question was "Has the miner's underlying hashrate changed?"
Block attribution alone cannot answer that.
Every new toggle must earn its space.
RPC-only, trust-minimized.
If it distracts from the signal, it doesn’t ship.
The UI must remain alive — never waiting on RPC.
This roadmap represents a tool built with care, precision, and intention — designed to be the clearest window into Bitcoin’s heartbeat.