Simple Authenticated BSV P2PKH Payment Protocol

Ty Everett ([e-mail])

Abstract

This BRC specifies a protocol for exchanging simple P2PKH payments between a sender and a recipient in a way that is SPV-compliant and cross-compatible. The protocol makes use of BRC-42 key derivation to derive public and private keys between users, BRC-8 transaction envelopes to relay SPV-related information between the sender and the recipient, and a BRC-9 SPV implementation to enable the recipient to obtain confidence that the transactions are valid and legitimate. This BRC specifies the JSON version of the payment message format used by the sender when exchanging the payment with the recipient, and the steps and processes involved in constructing and validating a payment message.

Motivation

The motivation for this BRC is to establish a simple, secure, and cross-compatible payment protocol that facilitates P2PKH payments across the BSV ecosystem. The protocol utilizes BRC-42 key derivation to provide a privacy-enhanced approach to P2PKH transactions. The incorporation of BRC-9 SPV checking ensures secure validation of transactions while maintaining efficient processing times. This standard aims to simplify the process of P2PKH payments for wallets and applications, providing a straightforward implementation path for developers.

Specification

We specify a protocol for exchanging simple P2PKH payments between a sender and a recipient. The protocol employs BRC-42 key derivation to derive related public and private keys with invoice numbers, BRC-8 transaction envelopes to relay SPV-related information, and BRC-9 SPV checks to enable the recipient to validate the transactions.

Key Derivation Scheme

As defined by BRC-42, the sender and the recipient each have a master private key and a master public key. The invoice number is used to derive related keys, which can be used to facilitate payments. A payment sender can derive a public key for the recipient, and with the same invoice number, the recipient can derive the corresponding private key.

We start with the need for a unique identifier for the payment, used for key derivation. To provide for the possibility that multiple outputs can be exchanged as part of the same payment, we also need a UTXO-specific number. We specify these two values as follows:

• Derivation Prefix: A unique value generated by the sender of a payment to distinguish keys used within this payment from keys used in other payments.

• Derivation Suffix: Each suffix is a unique value generated by the sender, so that each UTXO in the same payment has a different key, and so that the keys are not linkable by third parties.

The keys that protect the funds exchanged under this protocol are derived with BRC-42 key derivation by the sender from the identity key of the recipient. The invoice number is specified as follows:

“2-3241645161d8-<derivationPrefix> <derivationSuffix>”

Where:

• 2 is a protocol security level denoting the access restrictions applied under this protocol (see BRC-43 Security Levels)

• 3241645161d8 is a magic number that denotes compliance with this BRC

• <derivationPrefix> is the payment-specific prefix used to arrive at a common key universe for all outputs in this payment

• <derivationSuffix> is the UTXO-specific suffix used to arrive at a unique key for a specific P2PKH UTXO

Payment Message Construction (JSON)

The payment message format used by the sender when exchanging the payment with the recipient is a JSON object comprising:

• "protocol": This field denotes that the JSON object comprises a payment message according to this protocol. Its value should be set to 3241645161d8.

• "senderIdentityKey": The recipient will need to know the public identity key of the sender in order to validate the incoming payment. This field's value should be the 33-byte, compressed, hex-encoded secp256k1 public key of the sender

• "derivationPrefix": This field denotes the payment-wide derivation prefix used by the sender when the keys for the payment UTXOs were derived

• "transactions": This field comprises an array of one or more extended BRC-8 transaction envelopes. Each of the envelopes is extended with an additional "outputs" field, which is specified below

The Outputs Extension

Within each of the BRC-8 transaction envelopes, there is an additional field called outputs. This field is an object whose keys are integers that correspond to the output numbers in the specific transaction, all of which are intended by the sender to be redeemable by the recipient as part of this payment. The object values are objects that contain the suffix property, which is the derivation suffix for the specific UTXO being referenced. Here is an example of the outputs field:

outputs: {
  3: { suffix: 'abcdefg' },
  4: { suffix: 'hijklmnop' },
  7: { suffix: 'qrstuvwxyz' }
}

This example would be affixed onto an envelope that contained a transaction where the fourth, fifth, and eighth outputs (zero-indexing) are intended by the sender to be redeemable by the recipient as part of a payment.

Sending Payments

The steps for a sender to send a payment under this protocol are as follows:

1. Learn the identity key of the recipient, determine the total amount of the payment and generate a derivation prefix.

2. Decide on the number of outputs (across one or multiple transactions) that will comprise the payment.

3. For each output, generate a derivation suffix for the output and decide on the number of satoshis in the output.

4. For each output, use BRC-42 key derivation to derive a public key for the recipient for the output, and use the public key to construct a P2PKH Bitcoin output script as per BRC-16.

5. Use any wallet capable of creating BRC-8 Transaction Envelopes to construct and sign transactions that contain the output scripts derived for the recipient from the previous step.

6. With all of the transactions, the derivation prefix, the derivation suffixes, and your sender identity key in hand, construct a payment message for the recipient that contains this information.

Recipient Validation:

When the recipient processes their incoming transactions, they check that the public key hashes in the output scripts are properly derived. The recipient should also perform the standard BRC-9 SPV checks. If these checks pass, the payment is marked as accepted and acknowledged, and goods or services can be rendered to the payee.

Implementations

Implementations of this protocol should adhere to the key derivation scheme and the payment message format specified in this BRC. The transaction submission system within any wallet can implement this protocol and validate that incoming transactions submitted under this protocol contain UTXOs that are properly derivable by the recipient. The protocol is intended to be cross-compatible and SPV-compliant.