The risk a valid
signature can hide.

A BSV transaction can contain a valid signature even when the process that produced it has exposed the signing key. Verification answers a necessary question. A business still has to ask how the authority behind that signature was protected.

Imagine a supplier demonstrating a new signing service. The transaction verifies. The dashboard is green. The supplier adds more workers and the throughput rises. None of those observations tells the customer whether two workers can accidentally reuse a signing nonce across different messages after a restart, whether a diagnostic log contains that material, or whether the service signed what the customer actually approved.

This is a hypothetical procurement exercise, not an allegation about an existing BSV product. Its purpose is to locate a responsibility that a successful demonstration can conceal. Fixed transaction-validity rules give independently developed products a common target. They do not perform the engineering work inside each product.

The earlier article on hierarchical keys examined how a compromised child can affect a wider hierarchy. Here I want to move one step earlier: how can a signer lose a secret while producing an output that passes verification?

1. Keep the common contract clear

The BSV signature-hashing reference describes the transaction digest selected by the signature-hash flags. The signature check is tied to that digest and the relevant public key. It does not inspect the signer's random-number source, administrative permissions or incident procedure.

That boundary is useful. A small developer and a large supplier can build different products that satisfy the same applicable BSV rules. They can choose languages, hardware, internal controls and service arrangements without asking the existing wallet supplier to approve their architecture. Compatibility should be demonstrated against the stated rules and interfaces, rather than inferred from a familiar logo.

My published paper, Beyond ‘permissionless’: governance, commitment, and rule change in public blockchains, distinguishes open admission from authority over rule change. Its argument about commitment concerns the exposure created when participants invest under rules that others can later revise. Applying that distinction to BSV signing services gives a practical division of work: preserve the common validity contract while letting suppliers improve how they fulfil it. The paper is institutional research, not a cryptographic proof or a security audit of a signer.

A customer may require a particular interface or an independently assessed device as a condition of buying a service. That is a procurement choice. It does not make the chosen product, interface or assessment compulsory for every BSV application. The supplier should explain what its controls establish and what the customer pays for them.

2. The short-lived secret matters

ECDSA signing uses a private signing key and a secret per-signature value conventionally called k. The BSV TypeScript SDK's signing implementation exposes the underlying relation: s = k^-1(z + rd) mod n, where d is the private signing scalar, z is the message representative, and n is the curve-group order. The relation is shown before low-S normalisation, which may replace s with n - s. The signature supplies r and s; k must remain secret.

The equation explains why ordinary signature verification cannot certify the signer's secret handling. If an observer also learns k, the remaining private scalar is recoverable by rearranging that relation and accounting for any low-S normalisation. If the same secret k is used with the same private key for different message representatives, the two signature relations can likewise expose the key. This is elementary analysis of the signing equation, not a new attack or a claim that the cited SDK currently repeats nonces.

A transaction verifier can accept the resulting signatures throughout this failure. The equations still hold. The damage concerns who can now produce additional signatures. A system that tests only whether its own verifier accepts its own output can miss precisely the condition its customer is paying it to prevent.

Nor should an incident team treat every repeated signature as evidence of compromise. Repeating exactly the same deterministic signing operation can legitimately produce the same result. The relevant investigation distinguishes the key, the message representative and the signing procedure. A repeated r value alone is a reason to examine the evidence, not a complete account of what happened.

I would therefore keep request identifiers and public verification material available for authorised investigation, while excluding private scalars and nonce-generation state from routine logs. A diagnostic system that makes the service easier to debug by copying its signing secrets has changed the security boundary. Customers should not discover that boundary after an outage.

3. Determinism changes one engineering problem

Thomas Pornin's RFC 6979 specifies deterministic DSA and ECDSA signing. It derives the signing nonce from the private key and message hash using an HMAC-based procedure. Its signatures can be checked by an unchanged verifier. The document is Informational, not an Internet Standards Track specification.

This removes the need to obtain fresh high-quality randomness for each signing operation. It also makes fixed test vectors useful. It does not remove the need for securely generated private keys. Section 4 expressly discusses side-channel risks and defensive measures. Determinism is a particular control with a defined scope, not a general assurance that an implementation cannot leak.

The inspected BSV SDK revision constructs its internal deterministic nonce generator from fixed-size inputs. Its documentation limits that component to ECDSA nonce generation and warns against using it as a general random source or key generator. The signing API also accepts a custom nonce value or callback. Those are observations about a pinned source revision, not evidence that every deployed wallet uses the default path.

For a buyer, the next question is which path the actual product takes. Does the application invoke the normal signer? Can an integration override the nonce? Who can enable diagnostic options? Which configuration was used in the tests? A source-code feature and a deployed operating policy need to be connected before either supports a security promise.

I would keep nonce overrides out of ordinary application-facing requests unless a specific, reviewed design requires them. That is my engineering recommendation, not a new BSV rule. Developers remain free to implement a different sound construction and show why it meets their service's requirements.

4. Independent implementations need a stated comparison

Two sound ECDSA signers can produce different signatures for the same input. RFC 6979 explains why deterministic signatures remain compatible with ordinary verification; it does not require every signer to choose its nonce in the same way. Even deterministic comparison needs the same profile and output conventions.

The inspected SDK provides a concrete reminder. Its higher-level PrivateKey.sign method hashes its message with SHA-256 and defaults to low-S output. The low-level ECDSA function expects a message representative and has a different low-S default. Comparing these calls without accounting for those choices would test the caller's assumptions as much as the implementations.

For a BSV transaction, the evaluation must additionally use the correct transaction digest and applicable signature-encoding and validation rules. A generic message-signing call does not, by itself, assemble the transaction's signing preimage. I would record the transaction context, digest, public key, interface version and output encoding before interpreting a mismatch.

A useful evaluation has three parts. First, use public test keys and fixed inputs to compare the precise deterministic profile a supplier claims to implement. Second, have an independently implemented verifier check the resulting signatures and relevant BSV transactions. Third, examine the operational controls that neither of those functional checks establishes.

The third part is where advertising often becomes vague. A test-vector pass says something definite about those inputs. It does not demonstrate resistance to timing leakage, memory disclosure, unauthorised requests or faulty recovery. A second brand using the same underlying signing library also supplies less implementation diversity than two genuinely separate implementations. Shared dependencies belong in the report.

These are proposed evaluation steps, not results from an audit conducted for this article. Independence is valuable when it can expose a mistake. It loses much of that value if every disagreement is resolved by telling the other developer to adopt the incumbent's code.

5. Follow a leak through the key hierarchy

Nonce handling and hierarchical derivation solve different problems. Good nonce generation does not strengthen a weak root secret or change the algebra of a derivation scheme. A well-organised key hierarchy does not repair a signer that reveals one of its private signing scalars.

BRC-42 explicitly describes its additive relationship, childPrivate = (masterPrivate + tweak) mod N. Someone holding both a child private key and its tweak can recover the master. For the public anyone counterparty, the tweak is publicly derivable. Private-counterparty shared material alone does not disclose a child private key.

The consequence for this article is specific. If a nonce failure reveals a signing child, the incident analysis must follow the derivation relationship rather than stop at the label on that child. In the public-counterparty case, creating a different child for the next invoice does not restore the old root's secrecy. The hierarchy can turn one signing failure into a wider authority problem.

A customer might respond by separating high-value functions into independently generated roots, with separately administered signers and recovery arrangements. That can reduce the scope of some compromises, while adding enrolment, continuity and operating costs. If all those roots share one exportable backup or one unrestricted administrator, the common exposure remains.

The appropriate choice depends on the authority being protected. BRC-42 is a voluntary application scheme. Its containment requirements apply to implementations claiming that scheme; they are not instructions for every conceivable BSV wallet. Customers deserve the tradeoff in plain language, including the cost of losing access when recovery is deliberately restricted.

6. Scale the service without copying the failure

Return to the supplier adding signing workers. Copying an operational image may also copy state the designer expected to be unique. Where a signer relies on a stateful random source, the review should examine cloning, initialisation, concurrent access and restart behaviour. A deterministic design changes that part of the analysis, but still requires correct inputs, protected keys and authorised requests on every worker.

The question is what the added capacity actually completes safely. A faster primitive may leave the approval queue unchanged. A protected signing device may become the bottleneck. An additional service replica may improve availability while leaving every request dependent on the same key store and administrator. Count completed authorised operations under the promised workload, not just successful arithmetic calls.

For the hypothetical procurement exercise, I would ask each supplier to replay a non-production workload containing repeated requests, different messages, restarts and concurrent submissions. Record accepted operations, explicit refusals, unresolved outcomes and end-to-end latency. Separately commission the security work appropriate to its threat model. Never use live customer secrets to make a demonstration more convincing.

When a response is lost, the service also needs to distinguish repeating a cryptographic computation from authorising a second business action. Identical signature bytes do not supply an application's complete retry policy. A caller may have changed the request, a permission may have expired, or the downstream operation may already have completed. Those conditions need their own recorded decisions.

Suppliers can compete on these arrangements. One may sell a narrowly scoped local signer; another may sell a managed approval and submission service. Their promises differ, so the comparison should state what is included. The BSV distinction between local policy and consensus helps keep the boundary honest: a provider's refusal or operational limit should not be presented as transaction invalidity.

7. Responsibility continues after verification

If a signing service fails, the operator should identify the affected keys and operations, contain further exposure, preserve appropriate evidence and give customers a usable account of the recovery. Replacing the faulty software does not make a previously disclosed key secret again. Nor does it settle which earlier actions were authorised.

Contractual remedies, customer migration and any legal obligations need their own treatment. The technical statement should remain exact: what failed, what is known to be exposed, what remains uncertain and what the proposed repair can achieve. Invoking decentralisation does none of that work.

Fixed base rules make room for independent implementations precisely because they give those implementations a stable common obligation. Voluntary standards can reduce the cost of connecting them. Competition then has something concrete to reward: better protection, clearer evidence, usable recovery and capacity that survives the conditions under which it is sold.

A valid signature is an essential result. The quality of the signing service is a larger promise. The business making that promise remains responsible for the difference.