Chain status

Ready to start

—

Blocks / second—

Block index memory—

Session uptime00:00

NETWORK

Peers

0 connected

ENDPOINTUSER AGENTTRANSPORTCONNECTION

———Disconnected

Latest blocks

Last block—

HEIGHT	TIMESTAMP · UTC	BLOCK TIME	TX	SIZE	MINER
The browser node has not started yet.Start the node from the overview. Go to overview →

Mempool

Not started

Transactions0Observed locally

Total size0 BTransaction data

Average size—Per transaction

Oldest transaction—Time since first seen

Transaction sizes

BYTES / TRANSACTION

TRANSACTION	FIRST SEEN	SIZE

Start the node to receive transactions.

1 / 1

YOUR BROWSER. YOUR NODE.

Knuth Web Node

A Bitcoin Cash node running in your browser. The application is a static website: HTML, CSS, JavaScript and the Knuth C++ engine compiled to WebAssembly. The node runs locally in a background worker, and its saved chain lives in your browser’s storage.

A direct connection to the network

Chain data comes from Bitcoin Cash peers, not from Fulcrum, an address indexer or a block-explorer API. Knuth nodes implement a WebSocket transport for the peer-to-peer protocol, allowing the browser to speak P2P directly to compatible nodes. The website host delivers the application files; the peers deliver the network data.

WebSocket changes the transport, not the nature of that connection. The browser node can connect to multiple peers, discover compatible peers and receive block and transaction announcements.

What this node verifies

Knuth validates the block-header chain locally, including proof of work and difficulty rules. It can download recent block bodies, check that they match their headers and Merkle commitments, and perform structural checks before releasing the full bodies. A bounded cache retains useful recent-block information.

The current node does not keep the full blockchain or a UTXO set, so it does not perform full transaction validation against unspent outputs. Its observed transaction pool is not a fully validated mempool.

Why run it in a browser?

No node installation is required. You inspect the chain and consensus state using the actual Knuth engine on your device, with local header verification and multiple peer connections, without depending on a hosted indexer’s view of the chain.

The limited storage budget is a practical design choice, not a fundamental restriction of WebAssembly. More browser storage could make a full-node implementation more practical, alongside the necessary work on validation, performance, bandwidth and reliable background execution.

A path to a browser-native SPV wallet

Yes: this provides a foundation for a real Simplified Payment Verification wallet. It could maintain a locally validated header chain, obtain wallet transactions and verify their Merkle inclusion in that chain, then broadcast signed transactions directly to peers.

That wallet is a future capability. It still needs key management, transaction discovery, inclusion-proof retrieval and verification, and wallet transaction handling. SPV verifies inclusion under proof-of-work assumptions; it does not provide the same independent transaction validation as a full node. Direct P2P access also does not automatically make wallet activity private.

Read Satoshi’s description of SPV · Bitcoin whitepaper, section 8 ↗

BEHIND THE NAMES

The path to Satoshi

Starting with the May 2018 edition, I chose to name Knuth’s network upgrades after mathematicians, giving each upgrade an identity of its own. These names belong to Knuth; they are not official Bitcoin Cash upgrade names.

They are a tribute, but also a way of tracing the path to Satoshi. Across centuries, these mathematicians devoted their lives to discovering mathematical truths and developing ideas that became part of the foundations on which Bitcoin rests.

Work on prime numbers and other abstract questions could once seem to have no practical purpose. Yet, over thousands of years, those discoveries helped make Bitcoin possible. Their value was not limited to what anyone could imagine using them for at the time.

For me, that path culminates in Satoshi. Bitcoin needed the work of those who came before; those of us who continue developing it carry that legacy forward.

— Fernando Pelliccioni

CONSENSUS EXPLAINED

DAA · Difficulty Adjustment Algorithm

Mining power changes as miners join, leave or switch chains. The DAA changes how hard it is to find a valid block, keeping the average block interval near the network’s target. It sets a probability, not a deadline: individual blocks can arrive much sooner or later.

2009-Jan · Original Bitcoin retarget
Satoshi’s algorithm adjusts difficulty every 2'016 blocks, aiming for roughly two weeks per period at a ten-minute average. It compares elapsed time with the expected duration and limits each adjustment to a factor of four. This simple design works well with gradual changes in mining power, but can respond slowly to a sudden loss of miners.
2017-Aug-01 · EDA
The Emergency Difficulty Adjustment supplemented the original rule when Bitcoin Cash launched. If median chain time advanced by at least twelve hours across six blocks, it raised the proof-of-work target by 25%, making difficulty 20% lower. This helped the new chain keep moving with less mining power, but sharp reductions encouraged cycles of slow blocks followed by bursts of fast ones.
2017-Nov-13 · CW-144
Chainwork over 144 blocks replaced EDA with an adjustment for every block. It estimates mining power from accumulated work and elapsed time over a rolling window of about one day. This responded faster to miners arriving or leaving, but the window could produce recurring difficulty swings and reward miners who switched chains at favourable moments.
2020-Nov-15 · ASERT
Absolutely Scheduled Exponentially Rising Targets compares the chain’s progress with an ideal schedule relative to an anchor block. Running ahead raises difficulty; falling behind lowers it. Its exponential response avoids the old rolling-window cycle and reduces the incentive to switch mining power opportunistically.
The mainnet version, aserti3-2d, uses a two-day half-life: two days behind schedule halves difficulty; two days ahead doubles it. This balances responsiveness with resistance to random timing noise.

These dates describe Bitcoin Cash mainnet history. Test networks can activate rules earlier and use different intervals or half-lives. The live values in this panel come from the selected network’s native chain state.

Chain status

Peers

Latest blocks

Settings

Runtime settings

Library configuration

Browser

Network

Chain & storage

Runtime & reconnection

Mempool

Transaction sizes

Chain state

Knuth Web Node

A direct connection to the network

What this node verifies

Why run it in a browser?

A path to a browser-native SPV wallet

Node logs

Reset local chain?

Chain status

Peers

Latest blocks

Settings

Runtime settings

Library configuration

Browser

Network

Chain & storage

Runtime & reconnection

Mempool

Transaction sizes

Live transactions

Chain state

Knuth Web Node

A direct connection to the network

What this node verifies

Why run it in a browser?

A path to a browser-native SPV wallet

Node logs