Skip to content

Latest commit

 

History

History
116 lines (70 loc) · 8.09 KB

0097.md

File metadata and controls

116 lines (70 loc) · 8.09 KB

BRC-97: Extensible Proof-Type Format for Specific Key Linkage Claims

Ty Everett ([email protected])

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:

  1. Non-Interactive Proofs: Only non-interactive proof schemes are considered, as per existing standards like STARKs.
  2. External Verification: Proof verification is expected to be performed by external systems or verifiers, not within the wallet itself.
  3. 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.