This guide explains BIP 351 Private Payments in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 351 is a Draft private-payment-code scheme. A recipient publishes a static Bech32m payment code containing accepted address types and one compressed public key.
- Why it matters: BIP 351 reduces recurring-address reuse but adds notification, scanning and state burdens. Until interoperability matures, wallets should label it Draft, preserve counters and notification history and test privacy assumptions under realistic coin selection.
- Current position: BIP 351 is a Draft private-payment-code scheme.
What this means in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of the transaction as a form passed between several authorised signers. Each person or device checks the same payment details before adding approval. Passing the form around does not make the payment safe unless every signer checks what it contains.
Key terms in plain English
- BIP
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Node
- A computer running Bitcoin software that checks data and communicates with other peers.
Status
BIP 351 remains Draft and Informational. It is incompatible with earlier static payment-code standards such as BIP 47, so support and backup semantics must be negotiated explicitly.
Payment code
The code uses purpose 351, carries two address-type flag bytes plus a 33-byte compressed public key, and uses Bech32m HRP pay on mainnet or payt on testnet.
Notification
A 40-byte OP_RETURN begins with PP, followed by a four-byte ECDH-derived notification code, the sender’s 33-byte per-recipient public key and one address-type ordinal.
Collision trade-off
The notification code is truncated to four bytes, allowing roughly one false match in 2^32. A recipient must tolerate spurious watch entries without treating them as payments.
Payment derivation
Sender and recipient compute the same ECDH point, hash it with a big-endian 64-bit counter and add the scalar to the recipient key to derive each ephemeral payment key.
Scanning
Recipients must scan full block OP_RETURN data; BIP 158 filters do not cover those payloads. Out-of-band notifications need separate durable backup because chain restoration cannot rediscover them.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is BIP 351 Private Payments?
BIP 351 is a Draft private-payment-code scheme. A recipient publishes a static Bech32m payment code containing accepted address types and one compressed public key.
Is BIP 351 Private Payments active or supported today?
BIP 351 is a Draft private-payment-code scheme.
Why does BIP 351 Private Payments matter?
BIP 351 reduces recurring-address reuse but adds notification, scanning and state burdens. Until interoperability matures, wallets should label it Draft, preserve counters and notification history and test privacy assumptions under realistic coin selection.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
BIP 351 reduces recurring-address reuse but adds notification, scanning and state burdens. Until interoperability matures, wallets should label it Draft, preserve counters and notification history and test privacy assumptions under realistic coin selection.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
