Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
Two parties can derive private keys between themselves, but neither can prove to an outsider that they did it correctly. This adds a way for a third party to check the derivation without being given the ability to spend.
Summary
- Why
- A verifying server needs to confirm that a derived key genuinely came from a specific sender, without breaking the privacy that key derivation between two parties is supposed to provide.
- What
- BRC-86 defines a key derivation scheme where the invoice number itself carries a signature, letting a third party verify both the sender's identity and the correctness of the derived key while limiting what else is revealed.
- How
- A sender builds an invoice number in the form "2-BAD Privacy-<key> <nonce> <sig> <keyID>", signing a fixed message containing the key, nonce and key ID with a BRC-3 signature over the "anyone" counterparty, and a verifier checks that signature and confirms the child key derives correctly from the invoice number.
What this lets you do
- Embed a signature inside a type-42 invoice number
- Let a third-party server verify who derived a child key
- Confirm a child key matches its claimed derivation without a private handshake
- Limit how much sender information leaks during verification
- Combine sender authentication with third-party linkage checks
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-86 accurately, including what it depends on.
The specification
Abstract
Sometimes, there's a need for a third party to validate the linkage and key derivation process between two transacting parties. Type-42 derivation enables the private use of child keys between the parties based on an invoice number, but doesn't allow for third-party servers to verify the linkage of the keys. Proposals like BRC-84 describe ways to enable third-party verification while keeping the sender's key linked to the derivation process, but lack a means of sender authentication. By their nature, privacy is lacking in all of thes proposals, but more can be done to preserve it. When Bitcoin is not exchanged in a peer-to-peer manner, this specification outlines the most robust approach to Bidirectionally Authenticated Derivation with Privacy Restrictions (BAD Privacy).
Specification
Senders use type-42 with the anyone key as counterparty and an invoice number in this format:
2-BAD Privacy-<key> <nonce> <sig> <keyID>
The format of the signed data is:
BRC-86 BAD Privacy
<key>
<nonce>
<key ID>
Verifiers (and servers) check:
- The signature
- The nonce
- The child key is derivable with the invoice number and the anyone key
The signature verification process for the signature embedded in the invoice number is:
- Extract the identity key of the sender from the message
- Invoice number is
2-BAD Signature-<nonce> - Verification counterparty is
anyone(see BRC-3 for signature verification on public signatures) - Message to verify is specified above