BSV Python SDK Merges Fix for Skipped BEEF V1 Proof Checks

Developer Tools / Payments Infrastructure

In Brief

The Python SDK for BSV Blockchain has merged a fix for a verification error: an application could receive a successful result for a BEEF version 1 payment bundle without the SDK checking its proof against a block header.

BSV TIMES reproduced the error in version 2.4.0, the latest package on PyPI as of November 3. The same test against the merged code rejected the bundle when the block-header check failed. The fix is available in source and has not yet appeared in a new PyPI release.

News Report

Pull request #232 merged on November 2, 2026, at 06:58 UTC. It changes how the SDK reads, checks and writes the first version of BEEF, the Background Evaluation Extended Format defined in BRC-62.

A BEEF bundle can carry a payment, earlier transactions it depends on and Merkle paths showing where transactions appear in blocks. A receiver uses a path to calculate a root, then asks a chain tracker whether that root matches the block header at the stated height. The proof can belong to an earlier transaction even when the incoming payment itself is still unconfirmed.

How the Check Was Skipped

The affected readers, new_beef_from_bytes() and parse_beef(), kept an entry for the transaction being examined but discarded the other transactions and the Merkle paths in a V1 bundle. The verifier then skipped entries that lacked parsed transaction data. As a result, Beef.verify() could report success without ever asking the chain tracker about the supplied proof.

The merged code preserves the transactions and paths. It also corrects a related error: a transaction ID appearing as a neighboring hash in someone else’s proof no longer counts, by itself, as proof of that transaction. The verifier follows the transaction’s own reference to a Merkle path and checks the root it computes.

The repair also corrects the write format. Previously, the SDK could put a V1 header on data encoded in the V2 layout. It now writes a V1 bundle in the format its header declares.

What the Published Package Returned

BSV TIMES tested the published package and the merged source with identical bytes: two synthetic transactions, one spending the other, and a Merkle path for the parent. A local tracker was set first to reject the claimed root and then to accept it. No live payment was involved.

Version 2.4.0 retained one transaction entry and no Merkle paths. It returned success in both runs and never called the tracker.

The merged version retained both transactions and the path. It called the tracker once per run, with the expected root and block height, and returned failure or success according to the answer. Repeating the comparison with the same bundle inside an Atomic BEEF wrapper produced the same results.

BSV TIMES Read

For a wallet developer, the revealing test is the rejection. A test that supplies only a root the tracker accepts would pass with both versions. Giving the tracker a reason to say no shows whether the wallet can rely on the result it receives.

For a payment receiver, the distinction is equally practical. Evidence that a parent transaction was included in a block can help assess a payment that spends it. That evidence is useful only if the software actually checks it.

Developer Context

Ken Sato submitted the repair under the GitHub account ALiberalVoluntarist. The SDK lists Ken Sato and Yosuke Sato of Yenpoint as maintainers. Ken Sato also contributed the Python Wallet Toolbox integration for broadcasting transactions and tracking their status that BSV TIMES covered in October.

Source Links

Posted on November 3, 2026 (UTC)