Extensible Proof-Type Format for Specific Key Linkage Claims
Last updated
Was this helpful?
Last updated
Was this helpful?
Ty Everett (ty@projectbabbage.com)
This BRC proposes an extensible format for including zero-knowledge proofs (ZKPs) in specific key linkage revelations as per Method 2. While addresses limitations of 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.
We aim to provide a method for proving specific key linkage revelations under 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.
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 .
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 to ensure confidentiality during transmission.
We build on the existing standards:
This proposal extends these standards by defining an extensible proof-type format for specific key linkage claims (Method 2).
Specific Key Revelations: Encrypted according to BRC-72, including the linkage offset and the proof payload defined herein.
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.
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
.
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.
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.
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.
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.
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 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.
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.
: Defines methods for revealing key linkages.
: Specifies encryption of linkage information in transit using .
: Provides a Schnorr-based ZKP for counterparty-level linkage revelation (Method 1).
All proofs are encrypted using the mechanism defined in .
Counterparty-Level Revelations: Encrypted according to BRC-72, including both the shared secret and the Schnorr proof as per .
This binary data is concatenated in the above order, then encrypted as per alongside the shared secret, and returned by the wallet to the verifier.
This binary data is assembled by first specifying the Proof-Type
, followed by the Proof
payload (if applicable), then encrypted as per alongside the specific linkage offset, and returned by the wallet to the verifier.
Confidentiality: All proof payloads must be encrypted as per to ensure that sensitive linkage information is protected during transit.