Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys

Ty Everett ([e-mail])

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:

1. Extract the identity key of the sender from the message

2. Invoice number is 2-BAD Signature-<nonce>

3. Verification counterparty is anyone (see BRC-3 for signature verification on public signatures)

4. Message to verify is specified above