P Protocols: Allowing future wallet protocol permission schemes

Ty Everett ([e-mail])

Abstract

The BRC-43 architecture for wallet protocol permissions enables a wide range of use cases. By reserving protocol identifiers and preventing their use by applications, we ensure compatibility with future standards, supporting the future development of new protocol permission schemes.

Motivation

The motivation for this proposal is to future-proof the BRC-43 architecture by enabling the seamless integration of new protocol permission schemes. By specifying reserved identifiers, we can ensure that new security and permission paradigms can be implemented without conflicts or unintended behavior.

Specification

To accommodate future protocol permission schemes, wallets must reject operation requests using protocol IDs beginning with p (a lowercase “p” followed by a space), regardless of security level.

Future Scheme Identifiers

Future permission schemes must define their ID formats as follows:

• Scheme IDs cannot contain spaces.

• Protocol IDs must start with p , followed by the scheme ID, a space, and the rest of the protocol identifier.

Example Format

A protocol ID like p 222 xxxxx could represent a specific invoice number (e.g., 2-p 222 xxxxx-kkkkk), where:

• 2 indicates the BRC-43 security level.
• p designates an alternative permission scheme.

• 222 identifies the permission scheme.

• xxxxx forms the remainder of the protocol ID under the alternative scheme.

• kkkkk denotes the key ID.

Protocol Parsing and Rules

Wallets must differentiate between standard and alternative permission schemes by recognizing the p prefix followed by a distinct, space-free scheme ID. To ensure unambiguous parsing.

Upon recognizing a protocol ID structured as p <scheme ID> <rest of the ID>, wallets may apply the specific rules defined by the scheme associated with the scheme ID. These rules could define:

• Permitted protocols and key IDs.

• Conditions for operation execution.

• Counterparty requirements and customizable permission attributes.

Reserved Structure

To maintain clarity and prevent conflicts:

• Protocol IDs beginning with p must be reserved for future use.

• Wallets must reject operations involving such IDs unless they explicitly support the scheme ID.

• A space must immediately follow the scheme ID to separate it from other elements.

Extensibility Beyond Current Paradigms

This specification allows future permission schemes to extend beyond current BRC-43 models (e.g., security levels or BRC-73 paradigms), enabling flexible and innovative wallet permissions that evolve with user and application needs.

Conclusion

By reserving protocol IDs starting with p and specifying rules for future permission schemes, this specification ensures forward compatibility and robust wallet permission functionalities. It enables seamless integration of new schemes without disrupting existing applications or introducing parsing ambiguities.