For the complete documentation index, see llms.txt. This page is also available as Markdown.

Admin-reserved and Prohibited Key Derivation Protocols

Ty Everett (ty@projectbabbage.com)

Abstract

We define a set of reserved protocol namespaces that can be employed by clients utilizing the BRC-43 invoice numbering scheme to be set aside for administrative and internal use by the client software itself. This enables client software to manage its own internal state without the risk that application software will utilize the same internal protocols.

Motivation

BRC-431 defines an open-ended way to create protocols and systems of interaction within a BRC-422 key derivation architecture. However, client software implementing the BRC-431 invoice numbering scheme needs a way to manage its own internal state, encrypt data and perform administrative tasks like permissions management without interference from applications.

This specification distinguishes fully internal namespaces from payment namespaces with operation-specific restrictions. Public derivation can remain available while private-key operations remain internal.

Specification

The uppercase terms MUST, MUST NOT, SHOULD and MAY indicate normative requirements for implementations adopting this specification.

Fully internal namespaces

Any protocol ID that starts with admin is reserved for administrative and internal use, regardless of security level. Wallets MUST reject application requests involving these protocols.

BRC-29 payment namespace

For the exact normalized protocol name 3241645161d8, at every security level, wallets MUST reject application signing, encryption, decryption, HMAC and protocol-specific linkage requests. Public derivation and signature verification remain available under ordinary permissions. Wallets MUST also reject root-linkage disclosures that expose protected payment keys. Generic grants, privileged access and auxiliary methods MUST NOT bypass this boundary.

BRC-29 payment derivation is unchanged. Wallet-internal transaction signing and receipt remain available through authorized BRC-100 flows. Applications requiring non-payment data signatures must use a separate domain; BRC-207 defines the 1Color asset module. A policy or basket rename does not change existing on-chain keys.

References

  • 1: BRC-43: Security Levels, Protocol IDs, Key IDs and Counterparties

  • 2: BRC-42: BSV Key Derivation Scheme (BKDS)

Last updated