Teranode v0.16.1 Beta 5 Fixes Mining and Policy Validation

Scaling & Teranode / Node Software

In Brief

Teranode has published v0.16.1-beta-5, correcting mining submission failures, transaction-rejection classifications and conflict-recovery behavior.

The pre-release also enforces an existing transaction-finality rule on block reward transactions. Because earlier Teranode builds can accept blocks that this version rejects, the project calls for coordinated node upgrades.

News Report

The Teranode project published v0.16.1-beta-5 on November 1, 2026, at 23:30 UTC. GitHub marks it as a pre-release, continuing the beta series covered by BSV TIMES in October.

The changes concentrate on mining, validation and recovery, with specific deployment instructions for operators.

Keeping the Same Coinbase Throughout Mining

One repair concerns miners using getminingcandidate and submitminingsolution.

Previously, when a miner submitted a solution without supplying its own coinbase—the transaction that pays the block reward—Teranode rebuilt that transaction with new random data. The resulting transaction differed from the one used in the miner’s calculation, causing the solution to fail its proof-of-work check.

Beta 5 keeps the candidate’s original coinbase and uses those same bytes when the submitted solution omits it. The mining interface also returns that retained transaction when requested.

Operators using this interface must upgrade Block Assembly no later than the RPC service. Miners that supply their own coinbase are unaffected by this particular repair.

Other changes address stale mining candidates and unnecessary mining interruptions while a slow block is being validated.

Distinguishing Policy Rejections From Invalid Transactions

A node can decline a transaction under its local operating policy even when the transaction complies with the rules used to validate blocks. Software consuming rejection messages needs to distinguish those outcomes.

Beta 5 repairs a known classification problem in betas 2 through 4. For specified script errors encountered during policy validation, Teranode now checks the scripts again under consensus rules. A successful recheck produces a policy rejection; a failed check produces an invalid-transaction verdict.

The recheck has limits on processing time, memory and concurrent work. When it cannot complete within those limits, the transaction remains classified as policy-rejected, with downstream validation still required. That fallback should not be interpreted as proof that the transaction satisfies consensus rules.

Finality Checks Require Upgrade Coordination

The release also applies existing transaction-finality rules to the coinbase. A block is rejected when its coinbase has a non-final input sequence and a lock time that has not yet been reached, matching SV Node’s behavior.

The mining submission path has been corrected so that a solution’s timestamp and nonce belong in the block header rather than being copied into the coinbase’s lock-time and sequence fields.

The release notes instruct operators to upgrade all nodes together because older and newer Teranode builds can otherwise disagree about whether an affected block is valid.

Recovering From Conflicting Transactions

Conflict recovery now retains records of the original transaction flags and ownership of spent outputs before changing state. These records support recovery when an operation or its rollback fails.

The update addresses a failure that could leave Block Assembly unable to advance. It also changes the recovery-record format and the interface used by transaction-output stores.

Operators are instructed to upgrade Block Assembly together with its store implementation and avoid reverting to beta 4 while recovery remains pending. Unresolved records can prevent startup, and older records may require manual repair. The recovery guide instructs operators to preserve those records rather than delete them to bypass the check.

BSV TIMES Read

The practical significance of this release lies in consistent behavior across the mining and validation process. A mining candidate must retain the transaction the miner actually worked on, rejection messages must describe the applicable checks, and recovery must preserve enough information to restore a coherent state.

The coordinated-upgrade instruction is particularly relevant: an implementation correction can affect which blocks different software versions accept. Beta 5 therefore warrants attention as an operational release, while its pre-release status remains part of the assessment.

Developer Context

The release was published by GitHub contributor oskarszoon in the bsv-blockchain Teranode repository.

The contribution records credit icellan with the policy-validation recheck, freemans13 with the coinbase mining and finality repairs, and ordishs with the conflict-recovery work. These are the contributors’ public GitHub handles.

Source Links

Posted on November 2, 2026 (UTC)