Beersy
BRC-44

Admin-reserved and Prohibited Key Derivation Protocols

If applications and the wallet itself draw keys from the same pool, an application can trample on the wallet's own records. This sets aside a range of names for the wallet's internal use and puts them beyond application reach.

Ty Everettchanged 9 Sept 20241 min read
protocol idstarts with adallowed

Summary

Why
Wallet client software needs a private space to manage its own internal state and permissions without an application accidentally or deliberately deriving keys in that same space.
What
BRC-44 reserves any starting with "admin" for exclusive use by wallet client software, off limits to applications, within the BRC-43 key derivation scheme.
How
A compliant wallet checks every incoming key derivation request from an application and rejects any where the protocol ID starts with "admin", regardless of the requested .

What this lets you do

  • Reserve an admin namespace for internal wallet use
  • Refuse application requests that use a protocol ID starting with admin
  • Manage internal state and permissions without collision risk
  • Rely on a fixed rule instead of coordinating namespaces app by app

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

Reference for an AI

Everything an assistant needs to answer questions about BRC-44 accurately, including what it depends on.

The specification

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-43<sup>1</sup> defines an open-ended way to create protocols and systems of interaction within a BRC-42<sup>2</sup> key derivation architecture. However, client software implementing the BRC-43<sup>1</sup> 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.

With this specification, we define a list of namespaces in which applications are never allowed to derive keys, and any client that follows this specification will refuse requests made by applications to perform these operations.

Specification

We reserve the following for the administrative and internal use of clients, no matter the :

  • Any protocol ID that starts with admin

References

  • <a name="footnote-1">1</a>: BRC-43: Security Levels, Protocol IDs, and Counterparties
  • <a name="footnote-2">2</a>: BRC-42: (BKDS)
Was this helpful?

Search Beersy

Search standards by number, title, author or topic