A thousand keys,
one point of failure.

A wallet can generate a thousand different signing keys and still leave a business with one point of failure. Counting keys tells us very little until we know what happens when one of them escapes.

Hierarchical key derivation is useful. It lets an application distinguish relationships and purposes without asking a person to manage a filing cabinet full of unrelated secrets. In BSV, it can support signatures, payments and private interactions across independently operated services. The mistake is to turn that convenience into a security claim the mathematics does not make.

A new label can identify a new operation. A new derived key can serve that operation. Neither statement establishes a new compartment that will survive compromise elsewhere in the same hierarchy. If a supplier sells those three statements as though they were interchangeable, the customer should ask for the missing explanation before asking for the price.

This is the next practical question in the BSV decentralisation series. The previous article considered disagreements between implementations. Here I want to examine a boundary inside the implementation: the difference between organising authority and containing the damage when authority is stolen.

1. Choose the boundary, then choose the product

The BSV protocol reference distinguishes transaction and block validity from wallets, application interfaces and operating choices. A fixed validity contract can support competing products precisely because it does not prescribe every internal arrangement of those products.

A business can choose a signing appliance, a local wallet, a managed service or an arrangement combining several components. It can adopt a voluntary interface to reduce integration costs. Another business can choose differently. Compatibility with a particular application may depend on that choice; participation in every possible application does not follow merely from creating valid BSV transactions.

I favour stable base rules and vigorous competition above them. That position allows strong engineering recommendations. It does not require pretending that every design is safe, cheap or adequate for every workload. A recommendation should explain the failure it addresses and the cost it introduces, rather than borrowing the authority of the underlying system.

The useful procurement question is therefore quite specific: which event is this design supposed to contain? Loss of a device, compromise of an application, disclosure of a signing key and disappearance of a supplier are different events. A product that handles one may handle another badly.

2. Separate derivation, signing and approval

BRC-3 describes ECDSA signatures using derived keys. Its status note directs current wallet operations to BRC-100 rather than treating its historical message framing as the current interface. ECDSA performs the signing operation. ECDH, used in the derivation arrangement, establishes shared key material; it is not a signature algorithm.

That distinction matters commercially. A supplier may demonstrate that two components derive corresponding keys. The customer may need evidence that a named employee approved a specified purchase. The demonstration does not answer the customer's question until the application connects the cryptographic operation to the person, their authority and the exact purchase presented for approval.

I would make that connection explicit in a signing-service design. Specify the bytes representing the approved document, its revision, the purpose of the signature and the transaction context. Define how attachments are included and how competing representations are resolved. Then test what happens when the application changes one of those elements after the user has reviewed it.

These are proposed design requirements for a service claiming to capture that approval, not additional BSV validity rules. A different service can make a narrower promise. It should describe that narrower promise accurately.

Nor does a transaction signature automatically cover an accompanying business document. The BSV signature-hashing reference specifies a digest determined by the transaction and its signature-hash flags, rather than a signature over everything a user happened to see. A business-document commitment needs an explicit construction. The application cannot supply the missing connection with a green tick.

3. Read the consequence of the addition

BRC-42 specifies an additive derivation. In simplified notation, a child private scalar c, master private scalar m and derivation tweak t satisfy c = (m + t) mod N, where N is the curve-group order. Consequently, possession of both c and t reveals m = (c - t) mod N.

The specification expressly warns about this consequence. With the public anyone counterparty, the tweak is publicly derivable. One exposed child private key therefore compromises the master private key. Using a different child for every operation does not eliminate that consequence. A private-counterparty shared secret alone, by contrast, does not disclose a child private key.

Here is a deliberately small arithmetic illustration: with a toy modulus of 101, a master value of 80 and a tweak of 30 produce a child value of 9. Subtracting 30 from 9 modulo 101 recovers 80. These values are not BSV keys, a cryptographic implementation or a security test. They simply make the reversibility of an additive relation visible.

The practical recommendation is containment: keep private scalars inside the protected signer and return the authorised operation's result, not its secret. BRC-42 states private-key containment requirements for implementations of its scheme. Adopting that scheme remains an application choice; its requirements should not be recast as instructions for every possible BSV application.

Consider the sales presentation that promises a separate key for every invoice. That may be useful organisation. Ask the presenter what their incident procedure does if the invoicing application obtains one private child and the corresponding tweak. If the answer begins with the number of remaining invoice labels, the presentation has changed the subject.

4. Labels organise; compartments limit loss

BRC-43 organises derivation using security levels, protocol identifiers, key identifiers and counterparties. Its permission model distinguishes protocol-wide grants from counterparty-specific grants. These conventions help a wallet decide which application operation to allow; they do not turn an additive child into a separately generated root.

The distinction gives a buyer a useful way to compare proposals. One supplier may offer a convenient common root with strong signer isolation. Another may use independently generated roots for separately administered business functions. The second arrangement can reduce the scope of a particular key compromise, but creates more enrolment, recovery, continuity and operational work.

There is no honest reason to conceal either side of that tradeoff. Independent roots are not free protection. If every root is exported into the same backup account controlled by the same administrator, the common compromise has simply moved. If the recovery procedure is too difficult to use, staff may invent a shortcut that defeats the intended separation.

For a hypothetical manufacturer, I would compare the authority to approve supplier payments with the authority to acknowledge warehouse deliveries. The business might accept a shared operational dependency, or decide that the potential loss justifies separate signers and recovery arrangements. That is an explicit risk and cost decision, not a contest over which team can display more key identifiers.

A wallet's approval to use a protocol also needs to be distinguished from a person's approval of an individual business action. A standing application permission may be entirely appropriate for some automated work. It should not quietly be described as evidence that a person reviewed every later document.

5. Decide who can verify, and what that reveals

BRC-43's public-counterparty arrangement allows a verifier to derive the corresponding public child key from public inputs. Its private-counterparty arrangement uses the relationship's shared secret instead. This creates a choice about how readily outsiders can discover the verification key and its relationship to the root.

For an application, that choice should follow the evidence it expects to provide. A public announcement and a confidential bilateral order need not use the same disclosure model. Where a third party will later need to verify a private-counterparty signature, design the permitted disclosure and the evidence linking the verification key to the asserted identity. Do not promise effortless independent verification while retaining indispensable information in one supplier's database.

It is also important not to confuse restricted discovery of a public key with an absolute prohibition on verification. An ECDSA signature can be checked by someone who has the signature, the signed message and the correct public verification key. Establishing whose key it is and what authority it represented is a separate evidential question. An application should state what it discloses, to whom, and with what consequences for linkage.

My preference is for an exportable evidence package with a documented verification procedure. That is a recommendation about the service being purchased. It does not mean publishing private documents or relationship secrets on BSV. Portability for an authorised recipient and indiscriminate public disclosure are very different objectives.

6. Make the signer replaceable without exporting its secrets

BRC-100 offers a vendor-neutral application boundary with signature creation and verification operations. A common interface can make alternative implementations easier to integrate. It does not establish that two products have equivalent custody, recovery, availability or evidence-retention arrangements.

A meaningful exit exercise would ask a second implementation to verify retained signatures and interpret the documented evidence. It would separately examine how future authority is transferred or re-established. Verifying an old approval, continuing an identity and taking possession of an old private key are three different jobs.

A business may choose a controlled migration into a compatible protected signer. It may instead re-enrol users and establish new credentials while preserving the evidence for old signatures. Neither route should be improvised during an outage. The chosen route needs to explain who can authorise it, how fraudulent replacement is prevented and how relying parties distinguish the old authority from the new one.

Recovery can itself become the central authority that the architecture claimed to avoid. If one support employee can silently replace a customer's signer, the front-end description of client control is incomplete. If nobody can recover anything, the consequences of device loss belong in the product description as well.

I would test the exit before making it a contractual selling point. Disconnect the original provider from the exercise. Use retained, non-production evidence. Record which steps the replacement can complete and which require an unavailable dependency. A successful demonstration should survive the absence of the person who knows how the original demonstration was arranged.

7. Scale the whole service, and own the failure

A fast signature primitive does not establish a fast signing service. The service may still wait for user review, identity checks, a protected device, storage or an external submission service. I would measure completed business operations under a stated workload, including refusals, retries and recovery, rather than multiply a laboratory primitive rate by the number of machines in a slide.

The hypothetical manufacturer might care most about a concentrated end-of-shift burst. The operator could add capacity, change its queueing policy or sell a narrower service level. Another operator could compete with a different architecture. There is no reason to convert the first operator's bottleneck into a mandatory limit on everyone else's ambitions.

The policy-versus-consensus distinction is relevant here too: an operator's admission or relay decision is not the same thing as transaction invalidity. A service that declines work should describe its own boundary, rather than claim that the underlying system forbids what its implementation cannot presently handle.

Responsibility remains with the business that made the promise. If its application exposes signing material, misrepresents approval or loses required evidence, invoking decentralisation is not a repair. Explain the affected authority, contain further damage, preserve the incident evidence and give customers a usable recovery path. Where a dependency caused the failure, identify it without making the customer manage the dependency dispute.

That is the discipline I want from competition in BSV. Stable base rules leave room for different choices. Voluntary standards help those choices communicate. Clear claims let customers compare them. The party making a poor choice carries responsibility for its consequences; it does not acquire the right to prohibit better choices by everyone else.

Generate as many keys as the application needs. Then explain the boundary that remains when one is lost. That explanation is worth more than a thousand reassuring labels.