LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • Abstract
  • Motivation
  • Specification
  • Key Derivation Scheme
  • Payment Message Construction (JSON)
  • The Outputs Extension
  • Sending Payments
  • Recipient Validation:
  • Implementations

Was this helpful?

Edit on GitHub
Export as PDF
  1. Payments

Simple Authenticated BSV P2PKH Payment Protocol

PreviousPaymail Payment DestinationsNextPacketPay HTTP Payment Mechanism

Last updated 1 year ago

Was this helpful?

Ty Everett (ty@projectbabbage.com)

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 key derivation to derive public and private keys between users, transaction envelopes to relay SPV-related information between the sender and the recipient, and a 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 key derivation to provide a privacy-enhanced approach to P2PKH transactions. The incorporation of 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 key derivation to derive related public and private keys with invoice numbers, transaction envelopes to relay SPV-related information, and SPV checks to enable the recipient to validate the transactions.

Key Derivation Scheme

As defined by , 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 key derivation by the sender from the identity key of the recipient. The invoice number is specified as follows:

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

Where:

  • 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

The Outputs Extension

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. 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:

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.

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

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

Within each of the 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:

For each output, use 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 .

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

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 SPV checks. If these checks pass, the payment is marked as accepted and acknowledged, and goods or services can be rendered to the payee.

BRC-42
BRC-8
BRC-9
BRC-42
BRC-9
BRC-42
BRC-8
BRC-9
BRC-42
BRC-42
BRC-43
BRC-8
BRC-8
BRC-42
BRC-16
BRC-8
BRC-9