SmartLedger-BSV Corrects Chronicle Signature Hashing in New Library Releases

Developer Infrastructure Watch / Developer Tools

In Brief

SmartLedger-BSV has published three npm updates, versions 9.37.0 through 9.39.0, addressing signature-hash compatibility and two behaviors that application developers could otherwise misunderstand.

The main correction, introduced in 9.37.0, changes how the library calculates transaction signature hashes for certain incomplete script encodings under Bitcoin’s original transaction digest algorithm, including its use through Chronicle.

The subsequent releases add an optional stricter check for signed messages and a warning when a developer changes an output’s script object without updating the bytes that will actually be serialized.

News Report

The npm registry records all three releases on October 15 UTC. Version 9.39.0, published at 21:33 UTC—October 16 in Thailand—was the latest available package at this edition’s check.

The package is @smartledger/bsv, SmartLedger’s JavaScript Bitcoin library. It is distinct from the BSV Association’s @bsv/sdk.

The most consequential change concerns agreement between application software and node software over the exact bytes covered by a transaction signature.

Matching the Node’s Signature Hash

Before a transaction signature can be created or verified, software must construct the data being signed and calculate its hash.

For certain scripts containing an incomplete data-push encoding, SmartLedger-BSV previously included bytes that SV Node’s original-algorithm serializer does not include.

That difference can produce a different signature hash even when both implementations begin with the same transaction and script.

Version 9.37.0 changes the library’s handling to follow the node’s byte-level processing, including where script decoding stops and how the script length is represented in the signing data.

This remains relevant after Chronicle because the Chronicle signature flag selects the original transaction digest algorithm.

The scope is specific. The project says the correction leaves the BIP-143 hashing path unchanged and does not change signatures over scripts whose data pushes all decode normally.

It is a library compatibility correction against existing node behavior; it does not change BSV Blockchain’s consensus rules.

Validation Results—and a Corrected Earlier Claim

The release notes report a comparison against a compiled SV Node v1.2.3 across 55 reference cases. Before the correction, 45 matched; afterward, all 55 matched for both the signing data and the resulting digest.

The project also withdraws an earlier claim that all 55 already matched, explaining that the previous comparison did not establish that result.

That correction matters when assessing the evidence. The reported results concern a defined test corpus, rather than proof that every possible application or transaction path has been checked.

BSV TIMES inspected the published 9.39.0 package and the relevant SV Node source. The numerical test results above are the project’s reported results; they were not independently rerun for this article.

An Optional Check for Signed Messages

Version 9.38.0 adds a lowS option to message-signature verification.

An ECDSA message signature can have an alternative encoding that verifies for the same key and message. Applications can make incorrect assumptions if they treat the signature’s bytes as a unique identifier for the statement being signed.

The new option rejects the high-S alternative when explicitly enabled. It remains optional because other implementations may legitimately produce high-S signatures.

This check does not provide complete replay protection or guarantee one possible signature per statement. The project’s follow-up documentation makes that limitation explicit: application identity and replay controls must rely on the signed statement and its identifiers, rather than signature bytes alone.

A Warning About the Bytes That Will Be Sent

Version 9.39.0 addresses a separate transaction-construction hazard.

An application can modify the script object returned by an output while the output retains its previously stored serialization bytes. The application may then calculate a size using the modified object but serialize the earlier bytes.

The update adds a warning when the output’s size calculation detects that difference.

It does not automatically synchronize the two representations. The warning also does not cover every path: serialization without a size calculation can remain silent, and the equivalent input-script behavior is outside this check.

Developers must explicitly set the modified script on the output—or finish constructing it before assigning it. Changing signed transaction data also requires reviewing and recreating the affected signatures.

BSV TIMES Read

These releases address the boundary between what application code appears to do and what its underlying cryptographic operations actually establish.

A signature depends on exact byte construction. A valid message signature does not automatically provide a unique statement identifier. Changing an object in memory does not necessarily change the transaction bytes sent to the network.

For developers using SmartLedger-BSV, those distinctions have practical consequences for signing, verification and transaction construction.

The strongest news element is the published signature-hash correction. The accompanying verification option and warning are useful additions whose limits need to remain clear.

Developer Context

SmartLedger-BSV is developed publicly in the codenlighten/smartledger-bsv repository.

The npm package identifies SmartLedger Technology as its author and smartledger as its maintainer account. The inspected October 15 release commits are credited to the public GitHub account codenlighten.

Source Links

Posted on October 16, 2026