Skip to main content
£0.00 0

Basket

No products in the basket.

ASIC mining knowledge centre

BIP 351 Private Payments: Draft Reusable Code Guide

BIP 351 guide covering Draft payment codes, Bech32m encoding, OP_RETURN notifications, ECDH-derived addresses, scanning, collisions and recovery.

BIP 351 Private Payments guide cover

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.

BIP 351 Private Payments technical diagram
Notification: the fields, validation boundary and operational evidence that implementations need to agree.

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.

On this page

Search More Guides

Continue Reading

Explore more practical guidance on ASIC hardware, profitability, setup, hosting and maintenance.

Need Advice for Your Mining Setup?

Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.
Contact our team
Browse ASIC miners