Fulcrum 2.1.2 - BLAKE2b Support

Fulcrum 2.1.2 with support for the BLAKE2b proof-of-work hard fork.

Upstream Fulcrum assumes every block header is 80 bytes and hashes it with SHA256d. The hard fork changes the proof of work at an activation height: from that block on, headers are 164 bytes and hashed with BLAKE2b, signalled by the top bit of the version field. History is continuous, so every block below that height keeps its original header and both forms coexist in one index. Upstream cannot parse the new form and stops at the activation block rather than serving wrong data.

This build reads both forms, hashes each with the right algorithm, and serves them unchanged over the Electrum protocol.

Current status

The fork is live on both networks. Bitcoin Knots v29.4.1.knots20260508rc4 schedules it at height 961640 on mainnet and 150308 on testnet4, and both have crossed it. Nothing here carries an activation height: header size is read from the version word of each header, so this follows whatever schedule the node it indexes is built with.

The testnet4 schedule has moved three times, 149460 to 149537 to 150027 to 150308, and the chain that activated at each earlier height was abandoned when the next release replaced it. Expect a node that follows a moved schedule to reorganise away from the chain it was on, and this index to follow it there.

Verification

Tested against a Bitcoin Knots release that did schedule the fork, both on regtest with the activation forced to a low height and on live testnet4 while its activation stood:

• Syncs across the activation boundary and serves every header byte-exact against getblockheader, in both the 80-byte and 164-byte forms, over blockchain.block.header and both forms of blockchain.block.headers.
• Unwinds reorgs spanning the boundary, including undoing a pre-activation header.
• Keeps pace through the sustained one-block reorgs that follow a post-activation difficulty reset.
• Verified interoperating with a wallet over the Electrum protocol on the live forked chain.

Upgrading an existing index

Header records grew from 80 to 164 bytes and the headers table magic was bumped, so an index written by upstream Fulcrum is not readable by this build and vice versa. Either direction fails with an explicit magic bytes mismatch rather than misreading the data. Moving between the two costs a full resync.

Notes on this build

The Linux tarball is built with upstream's own release tooling, contrib/build/build.sh, so it links Qt, libstdc++ and OpenSSL statically and carries no shared Qt dependency. It runs on a stock system with nothing installed, the same as the upstream Linux release, and ships the same files: the binary, FulcrumAdmin, a help2man generated man page, both sample configs and the licence.

x86_64 Linux, arm64 Linux and Windows are all built with that script, from the tag, so each carries the same files as the corresponding upstream archive.

The x86_64 binary was run from the published tarball to confirm it works. The arm64 and Windows binaries cannot be executed on the machine that built them, so they are verified by architecture and archive layout rather than by running.

Verifying this download

gpg --verify Fulcrum-2.1.2-blake2b-shasums.txt.asc Fulcrum-2.1.2-blake2b-shasums.txt
sha256sum -c Fulcrum-2.1.2-blake2b-shasums.txt

Signed by Kyle Santiago kyle@privkey.io, key A47D99B6DB0D715D40C59A2023AE8A8EA7E24E38.

Built from tag v2.1.2-blake2b at 30138c7, which is upstream v2.1.2 with two commits applied on top.