BRC-84

Linked Key Derivation Scheme

Deriving a shared key normally needs one party's private key, which rules out cases where neither side can act. This extends the derivation so a key can be worked out from both parties' public keys alone.

Damian Orzepowski24 May 2024changed 7 Jun 20242 min read

Why: Non-custodial wallets need a way to derive fresh, unlinkable-looking public keys per transaction using only public keys, while still being able to prove afterward which master key each derived key traces back to.
What: BRC-84 is a key derivation scheme that lets two parties compute a new linked public key from their master public keys alone, while only the master private key holder can compute the matching private key.
How: A developer HMACs an invoice number using the counterparty's serialized public key as the HMAC key, turns the result into a number, multiplies it by the generator point, and adds that point to the master public key to get the derived public key, with the private key side done the same way but adding the number…

What this lets you do

Derive a new public key per invoice without touching any private key
Derive the matching private key only if you hold the master private key
Prove a derived key traces back to a specific master key
Give a non-custodial wallet unlimited one-off addresses
Skip generating or storing a shared secret between parties

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

The specification

Read the original

Abstract

The Linked Key Derivation Scheme builds on and extends the "type 42" key derivation method. This scheme allows public key derivation using only the public keys of both parties, maintaining the flexibility and unlimited key derivation of type 42. It aims to enable non-custodial wallets to derive public keys from a master public key without private key access, while only the master private key owner can derive the corresponding private key.

Motivation

The primary goal of this scheme is to enhance privacy and scalability in key derivation processes, enabling public key derivation based solely on the public keys of involved parties. Additionally, it ensures that the derived keys are linked back to their master keys, providing a mechanism for auditing and confirming the parties involved in transactions. This supports applications such as non-custodial wallets, ensuring secure and verifiable transactions without the need for private key access during the derivation process.

Identity Keys

The assumptions regarding identity keys remain unchanged from type 42. Each party has a master key pair, where the master public key is used to derive linked public keys. This ensures that the derived keys are linked back to the master key without requiring the master private key during the public key derivation process.

Security Considerations

The Linked Key Derivation Scheme maintains similar security properties to type 42, with the notable exception that no shared secret is generated or utilized. The scheme ensures that only the owner of the master private key can derive the corresponding linked private key, while public key derivation remains secure and private.

Key Derivation Process

Public Key Derivation:

flowchart
    A["Master Public Key (masterPubKey)"] --> B["HMAC(message = InvoiceNumber, key = Serialized Counterparty Public Key)"]
    B --> C[h = HMAC as big number]
    C --> D["H = h * G (Elliptic Curve Point)"]
    D --> E["LPK = masterPubKey + H (Derived Linked Public Key)"]

Generate HMAC from the invoice number using the serialized public key as the key.
Convert the HMAC to a scalar using big-endian encoding.
Multiply the generator point ( G ) by this scalar to obtain a point on the elliptic curve.
Add this point to the master public key (also expressed as a point) to get a new point on the elliptic curve.
This new point represents the derived linked child public key.

Private Key Derivation:

flowchart
    A["Master Private Key (masterPrivKey)"] --> B["HMAC(message = InvoiceNumber, key = Serialized Counterparty Public Key)"]
    B --> C[h = HMAC as big number]
    C --> D["lpriv = masterPrivKey + h (Derived Linked Private Key)"]

Generate HMAC from the invoice number using the serialized public key as the key.
Convert the HMAC to a scalar using big-endian encoding.
Add this scalar to the master private key (expressed as a number).
This resulting number is the derived linked child private key.

Conclusion

The Linked Key Derivation Scheme provides a robust method for public key derivation, suitable for applications like non-custodial wallets, ensuring privacy, auditability, and secure key management without compromising security.

Was this helpful?