Core Lightning v26.06.7 with BLAKE2b block header support

Core Lightning v26.06.7 plus support for the 164-byte BLAKE2b block header (Knots PR 359). Seven files changed, nothing else.

Without it a node cannot parse the activation block: the 84 extra bytes are left over after the header, the block is rejected, and the chain backend treats that as fatal.

doc/blake2b-header.md: header layout, block id construction, limits.

Read first

The fork activated on mainnet at height 961640. This release lets Core Lightning follow the chain across that activation; it does not resolve what happens to Lightning itself. A hard fork does not change genesis, and BOLT identifies a network by its genesis hash, so nodes that have adopted the fork and nodes still on the old rules advertise the same chain_hash: they connect to each other and their gossip merges, while after the activation height they no longer agree on the chain. Channels funded before activation are valid under both rule sets, so their commitment transactions can be replayed against a node that did not adopt the fork. Both are open questions, not something header parsing settles.

Binaries

amd64 only: Ubuntu 22.04, 24.04, 26.04, Fedora 40, and a reproducible source zip. Upstream also ships arm64, built on arm64 hardware; that is not included here.

Built with CLN's own tooling (contrib/reprobuild, tools/repro-build.sh) from 1bcf3f8212163332896eeab1c60fa569686dd66f, with SOURCE_DATE_EPOCH=1672531200, --force-mtime=2026-08-28 and COPTFLAGS=-O3. Two notes for anyone reproducing these: tools/repro-build.sh calls a bare ./configure, which defaults to -Og, so without COPTFLAGS you get debug-optimized binaries; and the base images must come from debootstrap --variant=minbase, because repro-build.sh verifies pinned .deb files out of the apt cache and a fuller base leaves that cache empty.

Verified reproducible: an independent rebuild with different MAKEPAR produced byte-identical output, as did a second build of the source zip.

Verify

git verify-tag v26.06.7-blake2b.2
git diff --stat v26.06.7..v26.06.7-blake2b.2
sha256sum -c SHA256SUMS-v26.06.7-blake2b.2
gpg --verify SHA256SUMS-v26.06.7-blake2b.2.asc SHA256SUMS-v26.06.7-blake2b.2

Tested

Against Bitcoin Knots v29.4.1.knots20260508, the final release. The header format, block id and activation heights are unchanged from rc3 through the final tag, so the binaries below are unaffected by which of those you run.

• mainnet, live: the fork activated at height 961640. Core Lightning synced across it and computed the same block id as the node for all 254 blocks either side, including two carrying a non-null XOR key with 46 and 47 mask bits cleared, the partial-byte case. A further 25 blocks sampled up to height 965894 also match. An unmodified build on the same chain stopped at 961639 and segfaulted in bitcoin_block_from_hex().
• testnet4, live: the same across its activation at 150027, over 543 blocks.
• regtest: 54 checks, covering a channel opened before activation and force-closed after it, payments either side, a reorg within v2 blocks, a reorg across the activation boundary, restart on a v2 tip, mutual close, fee estimation and the bwatch chain backend.
• Cross-implementation vectors (all four mining layouts, XOR mask boundaries); parser clean under ASan/UBSan over 1M mutated headers.

Mining layouts 1 to 3 and the merge-mining field do not appear on mainnet or testnet4, so they are covered by the vectors only. fuzz-open_channel fails identically on unmodified v26.06.7.