Fulcrum 2.1.2:2 - BLAKE2b Support

Fulcrum with BLAKE2b hard fork support, packaged for StartOS. Recovers automatically from an index it cannot read.

What this fixes

This package and the marketplace build of Fulcrum write incompatible block header records, and neither can open the other's index: Fulcrum reports a magic bytes mismatch and stops, rather than misreading the data. Installing this package over a working stock Fulcrum therefore left the service crash-looping, with nothing a user could do from the interface to clear it:

FATAL: Caught exception: readOrInitMeta: Magic bytes mismatch for DB fulc2_db/headers, expected: 00f026a2, got: 00f026a1

The daemon now watches for that message, discards the unreadable index once, and lets Fulcrum restart and rebuild it.

It keys on the error rather than on the version being upgraded from, because this package's earlier releases and the marketplace build share the same version space, so no version range distinguishes an index this build can read from one it cannot. An index that opens normally is never touched, and an ordinary upgrade does not resync.

Where the index is discarded, the address index is rebuilt from scratch and takes as long as the original sync did. The Electrum port stays closed until that finishes.

Activation status

The fork is live on mainnet at height 961640, scheduled by Bitcoin Knots v29.4.1.knots20260508rc4, and on testnet4 at 150308. A node past its activation height serves 164 byte headers, which stock Fulcrum cannot parse and this build can.

Index compatibility

Header records are 164 bytes here rather than 80, and the headers table magic differs. Moving between this package and the marketplace build costs a full resync in either direction. Coming from the marketplace build that now happens automatically; going back to it does not, and has to be cleared by hand.

Verifying this download

gpg --import privkeyio-signing-key.asc
gpg --verify fulcrum_x86_64.s9pk.sha256.asc fulcrum_x86_64.s9pk.sha256
sha256sum -c fulcrum_x86_64.s9pk.sha256

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

Built from blake2b-pow at 3b66b77, with Fulcrum from privkeyio/Fulcrum at tag v2.1.2-blake2b (30138c7).

Fulcrum 2.1.2:1 - BLAKE2b Support

Superseded by v2.1.2_2. Installing this version over a stock Fulcrum leaves the service crash-looping on a magic bytes mismatch, with no way to clear it from the interface. The newer release detects that and rebuilds the index automatically.

---

Fulcrum with BLAKE2b hard fork support, packaged for StartOS, rebuilt on upstream Fulcrum 2.1.2.

Supersedes v2.1.1_19, which was built on Fulcrum 2.1.0 and carries a version that the marketplace release of Fulcrum outranks. Installing that one leads to it being replaced by the stock build, which then refuses to open the index and stops.

What this is

The BLAKE2b hard fork changes the proof of work at an activation height: from that block on, block headers are 164 bytes and hashed with BLAKE2b rather than 80 bytes and SHA256d. History is continuous, so blocks below that height keep their original headers and both forms coexist in one index. Stock Fulcrum cannot parse the new form and stops at the activation block rather than serving wrong data. This build reads both.

Activation 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 package 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.

Index compatibility

Header records are 164 bytes here rather than 80, and the headers table magic differs, so an index written by the marketplace build is not readable by this one and vice versa. Either direction fails with an explicit magic bytes mismatch rather than misreading data, and moving between them costs a full resync.

Note that the marketplace build will replace this package whenever its version sorts higher. Fulcrum then refuses to start until this package is installed again. Reinstalling this s9pk restores it without a resync, provided the index was written by this build.

Verifying this download

gpg --import privkeyio-signing-key.asc
gpg --verify fulcrum_x86_64.s9pk.sha256.asc fulcrum_x86_64.s9pk.sha256
sha256sum -c fulcrum_x86_64.s9pk.sha256

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

Built from blake2b-pow at f9e2c42, with Fulcrum from privkeyio/Fulcrum at tag v2.1.2-blake2b (30138c7).

Fulcrum 2.1.1:19 - BLAKE2b Support

Superseded by v2.1.2_1. This build predates rc3 and rc4. The notes below describe testnet4 activating at 149537 and mainnet having no schedule; both have since changed, and each move replaced the chain that followed the old height. Kept for reference.

Superseded by v2.1.2_1. This build is based on Fulcrum 2.1.0 and carries a version that the marketplace release of Fulcrum outranks, so installing it leads to it being replaced by the stock build, which then refuses to open the index and stops. Use the newer release.

---

Fulcrum with BLAKE2b block header support, packaged for StartOS.

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

This build reads both header forms, hashes each with the right algorithm, and serves them unchanged over the Electrum protocol, so it keeps indexing straight through the activation.

Verification

Tested against Bitcoin Knots v29.4.1.knots20260508rc2 on regtest with the activation forced to a low height, and against live testnet4 past its activation at height 149537:

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

Notes

• The index is rebuilt on first start. Header records grew from 80 to 164 bytes, so an index written by an earlier version cannot be read and is discarded on upgrade. This is a local rebuild forced by the storage layout, not a re-download of a different chain, but it costs a full resync.
• Wallets need their own support. This server returns headers at whatever size they actually are. A wallet that splits the concatenated blockchain.block.headers response at a fixed 80-byte stride, or that checks proof of work as SHA256d, will not follow the chain past the activation height regardless of what this server returns.
• Mainnet has no activation height scheduled. Below the activation height this build behaves identically to upstream Fulcrum.

Verifying this download

gpg --import privkeyio-signing-key.asc
gpg --verify fulcrum_x86_64.s9pk.sha256.asc fulcrum_x86_64.s9pk.sha256
sha256sum -c fulcrum_x86_64.s9pk.sha256

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

Built from blake2b-pow at 5609f3a, with Fulcrum from privkeyio/Fulcrum at 8167f96.