BRC-97

Extensible Proof-Type Format for Specific Key Linkage Claims

Different proof systems will be used to back up key-linkage claims, and hard-coding one of them makes the format a dead end. This defines a container that names which proof type it carries, so new ones can be added later.

Ty Everett7 Nov 2024changed 4 Dec 20245 min read

Why: There was no standard way to attach a verifiable, upgradeable proof to a claim that a specific derived key was computed correctly from a shared secret.
What: BRC-97 is a binary format for attaching an optional, extensible proof to a BRC-69 Method 2 specific key linkage claim, using a one-byte proof-type identifier.
How: A wallet builds the specific key linkage payload as a proof-type byte followed by a proof payload whose format depends on that byte, then encrypts the whole thing together with the linkage offset using BRC-72 before handing it to a verifier.

What this lets you do

Attach a proof-type byte and proof payload to a specific key linkage reveal
Send proof-type zero when no proof is available and let the verifier trust the claim
Encrypt the proof payload with the linkage offset per BRC-72 before sending it
Add new proof schemes later by registering a new proof-type number
Parse an incoming proof-type field to decide how to handle the proof payload

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-97 accurately, including what it depends on.

The specification

Read the original

Abstract

This BRC proposes an extensible format for including zero-knowledge proofs (ZKPs) in specific key linkage revelations as per BRC-69 Method 2. While BRC-94 addresses limitations of BRC-69 Method 1 through a Schnorr-based ZKP, there is currently no standardized method for provable specific key linkage claims in Method 2. Given the rapid evolution of ZKP technologies, this specification introduces a proof-type enumeration scheme to accommodate future proof mechanisms. By defining a flexible proof-type field, we allow for the inclusion of various ZKP schemes as they become available, ensuring that wallets and applications can adopt and support them over time, eventually converging on standardized formats.

Motivation

We aim to provide a method for proving specific key linkage revelations under BRC-69 Method 2. However, current ZKP techniques may not fully support this requirement, as these technologies are still maturing. This proposal allows us to proceed with standardizing wallet interactions and linkage proofs while accommodating future advancements in ZKP capabilities. By introducing an extensible proof-type field, we create a flexible mechanism for integrating new proof schemes as they emerge, fostering innovation and facilitating eventual convergence on standard proofs.

Scope and Assumptions

This specification focuses on proofs of a specific computation: that a prover (Alice) has computed a shared secret between herself and a counterparty (Bob), and used it as a SHA-256-HMAC key over a defined invoice number to derive a specific linkage offset value. The approach is constrained to non-interactive proof schemes, as interactive proofs are impractical for our use case.

We make the following assumptions:

Non-Interactive Proofs: Only non-interactive proof schemes are considered, as per existing standards like STARKs.
External Verification: Proof verification is expected to be performed by external systems or verifiers, not within the wallet itself.
Encrypted Proof Payloads: Proof payloads are encrypted according to BRC-72 to ensure confidentiality during transmission.

Specification

Integration with Existing Standards

We build on the existing standards:

BRC-69: Defines methods for revealing key linkages.
BRC-72: Specifies encryption of linkage information in transit using BRC-2.
BRC-94: Provides a Schnorr-based ZKP for counterparty-level linkage revelation (Method 1).

This proposal extends these standards by defining an extensible proof-type format for specific key linkage claims (Method 2).

Proof Encryption with BRC-72

All proofs are encrypted using the mechanism defined in BRC-72.

Counterparty-Level Revelations: Encrypted according to BRC-72, including both the shared secret and the Schnorr proof as per BRC-94.
Specific Key Revelations: Encrypted according to BRC-72, including the linkage offset and the proof payload defined herein.

Proof Formats

Counterparty-Level Proof Format (BRC-94)

We define a binary format for the encrypted Schnorr proof payload for counterparty-level revelations:

Field	Bytes	Description
`R`	33	Nonce public key point `R` in compressed 33-byte DER format.
`S'`	33	Nonce shared secret point `S'` in compressed 33-byte DER format.
`z`	Variable	Response scalar `z` as a big-endian integer.

This binary data is concatenated in the above order, then encrypted as per BRC-72 alongside the shared secret, and returned by the wallet to the verifier.

Specific Key Proof Format (BRC-97)

We define a binary format for the encrypted payload for specific key linkage proofs:

Field	Bytes	Description
`Proof-Type`	1	One-byte unsigned integer (0-255), indicating the proof scheme used.
`Proof`	Variable	Proof payload, format depends on `Proof-Type`.

This binary data is assembled by first specifying the Proof-Type, followed by the Proof payload (if applicable), then encrypted as per BRC-72 alongside the specific linkage offset, and returned by the wallet to the verifier.

Proof-Type Enumeration

We introduce a proof-type numbering scheme:

Proof-Type 0: Indicates no proof is provided. Verifiers must trust the prover when the proof-type is zero. The Proof payload is empty.
Proof-Types 1-255: Reserved for future proof schemes. As new ZKP methods become available, they can be assigned unique proof-type identifiers within this range, along with their specific proof formats.

Example: Proof-Type Zero

When Proof-Type is zero:

The Proof payload is empty.
The verifier receives the encrypted linkage offset but must trust the prover's claim, as there's no way to independently verify the correctness without a proof.

Implementation Guidelines

Wallet and Application Behavior

Wallets: Should implement the ability to generate and include the Proof-Type and Proof payload in the encrypted data when performing specific key linkage revelations.
Verifiers: Should be able to parse the Proof-Type field and handle the Proof payload accordingly, based on supported proof schemes.

Future-Proofing

As new ZKP methods are developed and standardized, new BRCs can define additional proof-types (1-255) and their corresponding proof formats.
Wallets and verifiers should be designed to be extensible, allowing for the addition of new proof-types without significant changes to underlying architectures.

Security Considerations

Confidentiality: All proof payloads must be encrypted as per BRC-72 to ensure that sensitive linkage information is protected during transit.
Trust: When using Proof-Type 0 (no proof), verifiers must be aware that they are relying on the prover's honesty, as no independent verification is possible.

Future Work

Future specifications may define new proof-types (1-255) along with their proof formats and verification methods. Potential avenues include:

Proof-Type 1: Could be assigned to a specific ZKP scheme (e.g., Bulletproofs, STARKs, SNARKs) that is suitable for proving specific key linkage claims.
Standardization: As the ecosystem converges on preferred proof schemes, updates to this BRC can formalize these proofs, promoting interoperability.

References

Conclusion

This BRC provides a flexible and extensible framework for including proof schemes in specific key linkage revelations, accommodating future advancements in ZKP technology. By standardizing the proof-type field, we enable wallets and applications to adopt new proof mechanisms as they emerge, facilitating independent verification of specific key linkage claims while maintaining backward compatibility and fostering innovation in the BSV blockchain ecosystem.

Was this helpful?

Summary