Knots 29.4.3 extends reward locks on its BLAKE2b chain: check which network pays you
Source report: 2026-10-28 · Editorial analysis published: 2026-10-29
The October 28 release sets 25,920-block maturity from height 979,919 while its temporary regime applies. These are rules of the BLAKE2b branch, not a change to Bitcoin Core’s 100-block SHA256d rule.
A new release with a network-specific reward rule
Bitcoin Knots published 29.4.3.knots20260508 on October 28 at 05:59 UTC. The update extends the waiting rule for newly mined rewards on the BLAKE2b branch it supports: from height 979,919, the release specifies 25,920 blocks, described as about 180 days, while its temporary regime applies. For a miner, this changes when a block reward can become spendable, so the chain named by a pool or wallet matters as much as the software version.
This is not a new 180-day lock for all Bitcoin SHA-256 mining. Knots’ own chain guide says its proof of work changed from SHA256d to BLAKE2b, with the first BLAKE2b block at 961,640 on August 30, 2026. Bitcoin Core’s checked source still defines the SHA256d chain’s coinbase maturity as 100 blocks. Similar names and related software history do not make these reward rules interchangeable.
What the block numbers actually mean
Coinbase is the special transaction that creates a block reward; here it is not the Coinbase exchange. Maturity is the wait before that reward’s output can be spent. The new Knots release retains the earlier treatment for the preceding epoch and adds the rolling 25,920-block rule from 979,919. The release-tagged chain parameters set that start height and calculate the new duration as 180 times 144 blocks.
The phrase “about 180 days” assumes the target average of 144 blocks per day. It is a block count, not a promise that a wallet becomes spendable on a particular calendar date. The guide says the temporary data-limit regime expires on September 1, 2027 at 00:00 UTC, using median time past, while the BLAKE2b algorithm itself remains afterward. The release links its longer maturity rule to that regime; it should not be presented as a permanent rule for every future block.
Why operators need to read the upgrade boundary
The release asks its node operators and miners to upgrade before height 979,919. It explains that 29.4.2 can disagree with the new release about rewards created from that point: an older node may accept blocks the update rejects, and an older miner can later produce such blocks. This is a compatibility warning about accepted blocks, rather than a cosmetic wallet-label change or an instruction for every SHA256d Bitcoin node to install Knots.
A 29.4.2 node upgrading late rechecks from 979,919, according to the notes; a node coming from 29.4.1 or another implementation rechecks from 973,440. A pruned node, which has removed older block files to save storage, may have to synchronize again from scratch. These are meaningful time and storage considerations for an operator. They are not evidence that the update has already been installed on a reader’s pool or that a reported balance has been paid.
The release also stops sending newer headers and blocks to peers that do not advertise BLAKE2b support above its stated boundary. That reinforces why this should be understood as a particular chain’s node release. Following a download link with the word Bitcoin in it does not establish which network a wallet or exchange credits. The issuer’s own guide tells businesses to follow the BLAKE2b chain they intend to credit and list.
A warning about DATUM is not a universal Bitcoin rule
The release contains a strong warning from its maintainers about participants not running their own DATUM Gateway, including the expectation that they may never be paid going forward. DATUM is mining gateway software through which an operator can build work using its own node. The warning belongs to this project’s position and future plans; it is not proof that every ordinary Bitcoin pool has stopped paying or that all existing pool balances are invalid.
The concrete implemented change documented here is the longer maturity rule. Statements about extending waits further or making rewards conditional on how work is assembled must be distinguished from that shipped rule. The release uses accusatory language about other miners and chains; those political descriptions are the authors’ claims, not technical findings we adopt. For the reader, the practical task is identifying the actual chain, accepted block rules and payout terms.
Check the asset before estimating cash flow
A block reward waiting to mature is different from a pool account balance and different again from a normal wallet transfer. A pool can have its own payment schedule and terms; a consensus wait on newly created coins does not, by itself, specify when every customer withdrawal is processed. Read the pool’s terms for the network actually being mined, rather than apply one number to all three records.
Before treating mining income as available cash, check the algorithm, chain, software version used by the operator and the asset credited by the receiving service. A SHA256d ASIC does not become a BLAKE2b miner because node software has a familiar name. This October release is useful news about compatibility and liquidity on the Knots-supported branch; it does not change Bitcoin Core’s 100-block rule or establish a universal calendar deadline for Bitcoin miners. We reviewed documentation and source, without installing the node or moving coins.
Source: Bitcoin Knots ↗ · Knots explanation of its BLAKE2b chain ↗ · Release-tagged chain parameters ↗ · Bitcoin Core coinbase maturity constant ↗
Mining calculator ↗
