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

Core Lightning is not yet safe to run across this activation. 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. For testnet4 and regtest.

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.1
git diff --stat v26.06.7..v26.06.7-blake2b.1
sha256sum -c SHA256SUMS-v26.06.7-blake2b.1
gpg --verify SHA256SUMS-v26.06.7-blake2b.1.asc SHA256SUMS-v26.06.7-blake2b.1

Tested

• testnet4, live: synced across the real activation at 150027; every block id matched the node, including blocks with a non-null XOR key and non-zero time offset. An unmodified build stopped at 150026 and aborted.
• regtest vs Knots v29.4.1.knots20260508rc3: channel opened pre-fork and force-closed post-fork, reorgs within v2 and across the boundary, restart on a v2 tip, mutual close, fee estimation, bwatch.
• Cross-implementation vectors (all four mining layouts, XOR mask boundaries); parser clean under ASan/UBSan over 1M mutated headers.

Layouts 1-3 and merge-mining fields occur on no chain yet, so they are vector-covered only. fuzz-open_channel fails identically on unmodified v26.06.7.