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.

If you tried v26.06.7-blake2b.2

Use this release instead. .2 was built from v26.06.6, not v26.06.7, because of a stale local tag, so it carried database version 282 and refused to open a database written by official v26.06.7:

Refusing to migrate down from version 284 to 282

Anyone who took the v26.06.7 security upgrade has database version 284, so .2 could not start for them, and going back to official v26.06.6 failed the same way. This release is built from the correct v26.06.7 commit 8684c68df and is database version 284. Nothing else about the fork support changed; the seven files are identical.

If you are coming from v26.06.6

Your database is at version 282 and this release is at 284, so it needs an upgrade. Because the version string here is not a plain vN.N.N, Core Lightning treats this build as non-final and will not upgrade a database irreversibly without being told to:

Refusing to irreversibly upgrade db from version 282 to 284 in non-final version ... (use --database-upgrade=true to override)

Start it once with --database-upgrade=true. That is a one-way door: afterwards the database is at 284 and v26.06.6 can no longer open it. Take a copy of lightningd.sqlite3, hsm_secret and emergency.recover first.

Coming from official v26.06.7 there is nothing to do, since that database is already at 284.

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/build-release.sh), with SOURCE_DATE_EPOCH=1672531200, --force-mtime=2026-09-13 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.

Verify

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

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.

• 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, over 543 blocks.
• regtest: 49 checks on this base, 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.

No warranty

This is an unofficial, unaudited build provided as is, with no warranty and no liability, under the same BSD-MIT license it inherits. It is not a Core Lightning release and is neither affiliated with nor supported by the Core Lightning project or Blockstream. Running it is entirely at your own risk, and you alone bear any loss of funds.