Sealminer A4 Ultra Hydro
Bitcoin & Bitcoin Cash ASIC Miner
886TH
HASHRATE
9.45W/TH
EFFICIENCY
8373W
POWER
£853.81
EST. MONTHLY
NO PAYBACK
EST. ROI
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.
BIP 351 Private Payments in simple English
BIP 351 Private Payments: 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.
Simple example
A node operator is checking BIP 351 Private Payments. The notification code is truncated to four bytes, allowing roughly one false match in 2^32.
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 the main point of BIP 351 Private Payments?
BIP 351 Private Payments: 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.
For BIP 351 Private Payments, what should a beginner know about 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.
For BIP 351 Private Payments, what should a beginner know about 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.
For BIP 351 Private Payments, what should a beginner know about 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.
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.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.