Bitcoin Knots BLAKE2b fork: node and miner guide

[jasonsopko]

The BLAKE2b fork is live: getting a node or miner onto the chain

Edit (Aug 30, evening): rewritten top to bottom now that the fork is behind us; this began as the fork-night plan and the old text is in the edit history. What changed: the steps are now for joining a running chain, not for the night itself.

Where things stand

• The proof-of-work change activated at height 961640, mined Aug 30 06:14 UTC. The chain is past 961860, finding blocks every few minutes at difficulty 3.0e7, and mempool.guide follows it.
• The first difficulty retarget lands at 963648. Expect a drop whatever the block pace, because the retarget window includes the eight BIP110 blocks that took Aug 8 through Aug 30, then roughly ten-minute pacing as it finds its level.
• BIP110's reduced-data rules are consensus on this chain until September 1, 2027; among other things blocks are capped at 800,000 weight units until then.

Upgrading a node that ran 29.x (was on the BIP110 chain)

1. Install 29.4.1 (tag v29.4.1.knots20260508rc5), verify signatures as usual.
2. Nothing to configure on rc5: the headline is hardcoded (PR #385) and a leftover blake2b_headline= line in bitcoin.conf is ignored. On rc4 only, add blake2b_headline=8-30 NYPost Deride And Conquer — exact bytes, no quotes. The config parser keeps quotation marks, and a value that does not match byte-for-byte makes an rc4 node reject the real fork block; rc4 refuses to start without the key.
3. Start it. It syncs like any other upgrade; getblockchaininfo should move past 961640.

Fresh installs and nodes that were on Core
Same steps. 29.4.1 ships checkpoints at 961632 and 961639 (00000000000000000001bbc439e13f749dca850d32c7a2834165338713027e65), and rc5 adds one for the fork block 961640 itself (0000000000000050c1e5f69672f459293be14f46e5a494e7a8c8541396f18eeb), so it rejects Core's branch at those heights on its own. It still needs at least one peer that has the BLAKE2b chain; if yours only serve Core's, add a known Knots node with addnode=. A pruned node that came from Core may be told to reindex at startup; that is the migration check being careful, not a fault.

Mining

• Hardware is Sia-family BLAKE2b ASICs. Solo mining works today through the DATUM gateway at innerhat-dev/datum_gateway (2fea7e5 or later); leave pow_algorithm at auto and the gateway follows the node's template. A setup guide is open as PR #10 and readable here until it merges.
• The headline was a consensus requirement for block 961640 only. From here your coinbase tag is yours; it is how the explorer names your blocks.
• Pooled mining through OCEAN has produced blocks on this chain (961687, for one). Their public gateway repo has not updated, so I cannot describe that setup; solo is the documented path today.
• SHA256d hardware has no role on this chain; blocks on the old algorithm are invalid past 961639.

Electrum server and explorer, for self-hosters

• An unpatched electrs crash-loops at the first v2 header. A romanz electrs with header support is maintained at jasonsopko/electrs (branch blake2b; the README has build steps and a check script). For pruned nodes see paulscode/electrs-pruned.
• A mempool explorer set up for this chain is at jasonsopko/mempool (branch knots-blake2b; KNOTS-BLAKE2B.md covers the 800k block weight, the miner list, and two backend fixes, which are also open against the Retropex fork it builds on).

Packaged nodes (Start9, Umbrel, and the like)
No package ships 29.4.1 yet. paulscode's StartOS packages (knots-blake2b, datum-blake2b) are testnet4/regtest by design so far and refuse mainnet. As of rc5 there is no headline setting to carry, so the Start9 config-form limitation noted in earlier editions no longer matters; a package only needs the new binary. Until one lands, a plain 29.4.1 on any machine is the way in; there is no penalty for joining late beyond missed blocks.

Wallets
Balances, addresses, transactions and history are unchanged; nothing from before the fork moved. A wallet that trusts a backend (most of them) follows whatever its backend follows. A wallet that verifies headers itself cannot follow the chain until it understands the v2 header; the client-side work for that exists as paulscode's Electrum protocol 1.8 proposal.

---

Earlier edits (Aug 29 on Start9, Aug 30 on rc4 facts) are folded into the text above; the originals are in the edit history.

Edit (Aug 31): added the note about #385 to the upgrade steps; nothing else changed.

Edit (Aug 31, later): rc5 is tagged, with #385 in it: the headline is hardcoded and the fork block has a checkpoint. Updated the install tag, the headline step (now rc4-only), the fresh-install checkpoint list, and the packaged-nodes note.

[PprTwls]

You can add to the bitcoin.conf file on Start9 by ssh command line

[emilydarryl]

Where do we look for the headline from Luke?

[emilydarryl]

The copy and paste version. Thanks

[emilydarryl]

got it. never mind. Lets go!!!

[jasonsopko]

It is in the Edit (rc4, Aug 30) paragraph at the end of the post above: 8-30 NYPost Deride And Conquer, 30 bytes, unquoted in bitcoin.conf and the exact bytes in the gateway's coinbase_tag_secondary. I took it from the Knots Discord where Luke posted it; I have not seen it on the website yet.

[jasonsopko]

Good to know. I have not run StartOS, so I did not want to claim it. Does a hand edit to bitcoin.conf survive the package regenerating the file from its config form on the next restart? If it does, that is the path for Start9 users once a build with the fork ships, and I will say so in the Start9 note.