Limitations of BRC-69 Key Linkage Revelation

Ty Everett ([e-mail])

Abstract

This BRC identifies and summarizes the key limitations of BRC-69 key linkage revelation. The primary issues are centered around the inability of verifiers to independently verify the accuracy and correctness of the revealed key linkage information without access to private keys. Specifically, in Method 1, there is no way for the verifier to confirm the shared secret between the prover and their counterparty, and in Method 2, verifiers cannot ascertain the correctness of the specific key linkage (protocol ID and key ID). These issues present significant trust and security concerns, limiting the effectiveness of BRC-69 in its current form.

This BRC lays the groundwork for discussions on how these problems might be addressed to improve the security and verifiability of key linkage revelations.

Motivation

The goal of BRC-69 is to provide methods for proving associations between counterparties and their derived keys using BRC-42 and BRC-43 key derivation. However, BRC-69 suffers from verifiability issues that could undermine the trustworthiness of key linkage revelations:

1. Method 1: Revealing Counterparty Shared Secrets – Verifiers have no way of confirming that the shared secret is authentic without knowing the private keys of the prover or the counterparty. This defeats the purpose of revealing the secret, if it cannot be verified.

2. Method 2: Revealing Specific Key Associations – Verifiers cannot independently verify that the linkage is correctly computed for the claimed protocol ID and key ID. This leaves the verification process vulnerable to manipulation or incorrect linkage claims.

Without a way to verify the revelations, verifiers are forced to trust the prover or rely on possessing private keys, which severely limits the utility of BRC-69 for trustless systems or scenarios requiring independent auditing.

Method 1: Lack of Shared Secret Verifiability

In Method 1, the prover reveals the shared secret between their identity key and the counterparty’s key. However, verifiers cannot verify that the shared secret is correct without knowing either the prover's or counterparty’s private key. This reliance on private key access contradicts the purpose of the scheme, which aims to reveal linkages without exposing sensitive private keys.

For example, a verifier receiving a shared secret cannot confirm:

• That the shared secret truly corresponds to the prover and counterparty’s keypair.

• That the shared secret hasn’t been forged or manipulated.

In scenarios where verifiers lack access to private keys, they are forced to trust the prover's claim, making this method unsuitable for trustless verification environments.

Method 2: Unverifiable Specific Key Linkages

In Method 2, the prover reveals a specific linkage between their identity key and a child key derived for a specific protocol ID and key ID. However, the verifier cannot independently verify the correctness of the revealed linkage:

• The protocol ID and key ID used for deriving the child key are supplied by the prover, but the verifier has no way to check whether the linkage has been computed correctly for these values.

• Although the verifier can use the child public key derived from the revealed linkage, they cannot confirm that the correct protocol ID and key ID were used without further information or access to private keys.

This leads to a situation where the verifier must trust the prover to have provided the correct linkage information or possess the private key to verify the linkage, which again defeats the purpose of privacy-preserving derivation and verification.

Implications for Verifiability and Trust

The main implication of these issues is that BRC-69 currently lacks a mechanism for trustless verification. Without a method for the verifier to independently validate shared secrets and specific key linkages, the standard's utility is diminished in scenarios that require trustless interactions or where sensitive private keys cannot be shared.

Moreover, BRC-72 outlines measures for encrypting linkage revelations, but encryption alone cannot address the core issue of unverifiability. Even if the information is transmitted securely, the lack of a method for verifiable computation undermines confidence in the revelations.

Conclusion

The limitations of BRC-69's revelation methods significantly reduce its effectiveness in trustless environments or scenarios where independent auditing is required. Verifiers are forced to either trust the prover or possess sensitive private key information, which is contrary to the privacy-preserving goals of the standard.

Method 1 Issues:

• No way for the verifier to confirm shared secret accuracy without private key access.

• Trust-based verification undermines privacy and trustless interactions.

Method 2 Issues:

• Verifiers cannot independently confirm the correctness of key linkages for a given protocol ID and key ID.

• The method relies on the prover’s claims, again requiring trust.

To improve the practical application of BRC-69 in trustless systems, future discussions should focus on introducing a mechanism for independently verifying shared secrets and key linkages without the need for private key access. This will ensure that BRC-69 remains aligned with the privacy and security objectives of the BSV ecosystem.

Future Work

Discussions on potential solutions could explore:

1. Cryptographic proofs or zero-knowledge proofs (ZKPs) that enable verifiable shared secrets and key linkages without requiring private key disclosure.

2. Enhanced metadata structures or protocol-level mechanisms that allow for verifiable key derivation and linkage for both Method 1 and Method 2 revelations.

3. Additional layers of authentication or confirmation mechanisms to ensure that the linkage is accurate and corresponds to the correct protocol ID and key ID.

By addressing these limitations, future revisions of BRC-69 can enhance its suitability for privacy-preserving, auditable, and trustless applications in the ecosystem.