run a node — bitcoinxor

What you need

Disk: a full node stores the whole chain — roughly 750 GB and growing. With prune=550 that drops to under 10 GB (you keep full validation, you lose the ability to serve history).
Machine: anything reasonably modern works; even a small PC or mini-server. Initial sync takes hours-to-days depending on hardware and bandwidth.
Software: Bitcoin Knots — the node software of the enforcing chain. Since the proof-of-work change you need the fork-aware v29.4.1 series (release candidate rc4 at the time of writing) — the older 29.4.knots20260508 release cannot read post-fork blocks and stalls at height 961639.

Step 1 — install Bitcoin Knots

Download from bitcoinknots.org only — during a fork event, mirrors and lookalike sites are a real attack vector — and verify the release signatures before running anything. The official site warns, correctly, against downgrading or switching node software based on social-media advice.

Step 2 — configuration

In your bitcoin.conf:

# REQUIRED since the proof-of-work change: the node refuses to start
# without this line. Exact string, including spaces and capitalization.
blake2b_headline=8-30 NYPost Deride And Conquer

# optional: prune to ~550 MB of blocks if disk is tight
# prune=550

Why the node makes you type a headline It's a deliberate homage to the genesis block, which embedded a newspaper headline ("Chancellor on brink of second bailout for banks") as proof it wasn't mined in advance. The first BLAKE2b block — 961640 — was required by consensus to carry a headline from fork day in its coinbase, and every node operator types it in rather than shipping it in a default config. Your node checks the string byte-for-byte against that block. Get it wrong and the node either refuses to start (missing) or rejects block 961640 (mistyped).

The maxtipage=2592000 line recommended during the slow-block period between the split and the proof-of-work change is no longer needed — blocks arrive every few minutes again — but it is harmless if you still have it.

Step 3 — confirm which chain you're on

Once synced past height 961632, ask your node for that block's hash:

$ bitcoin-cli getblockhash 961632

If you get…	You are on…
0000000000000000000169eb6f811ddbd0daf343af7b62180cdb13e7c78dbc16	the enforcing chain (the one changing proof-of-work)
any other hash	the majority-hashrate chain

Both chains agree on everything through block 961631 (…9327ce8a) — that block is shared history.

And to confirm you're past the proof-of-work change, check the first BLAKE2b block:

$ bitcoin-cli getblockhash 961640
0000000000000050c1e5f69672f459293be14f46e5a494e7a8c8541396f18eeb

Notice the hash: far fewer leading zeros than the SHA256d blocks before it — the visible signature of the difficulty reset that came with the new algorithm.

What to expect day to day

Regular blocks again. Since the proof-of-work change activated at height 961640, the enforcing chain produces blocks every few minutes. (The hours-long gaps of the 8–30 August slow-block period are history.)
Fewer peers than you're used to. The enforcing-node network is smaller than the pre-split network. Patience during initial sync.
Your wallet still works. A node is also the most honest wallet backend there is — see wallet safety before spending anything on either chain.

Get the fork node from the source The proof-of-work change activated on 30 August 2026 and requires the v29.4.1 node series. Get it from bitcoinknots.org or build from the release tag at github.com/bitcoinknots/bitcoin, and verify signatures — fork week is peak season for lookalike binaries pushed through social media and DMs. Nothing else is "the fork node".

Checking status

Useful commands while you watch the split unfold:

# tip height, hash, and sync state
$ bitcoin-cli getblockchaininfo

# how long since the last block (a few minutes is normal post-fork)
$ bitcoin-cli getbestblockhash
$ bitcoin-cli getblockheader $(bitcoin-cli getbestblockhash) | grep time

# peer count
$ bitcoin-cli getconnectioncount