Bitcoin gives anyone the ability to receive payments without asking a bank for permission.

But there is a catch.

Bitcoin’s blockchain is public.

If you repeatedly receive Bitcoin at an address that everyone knows belongs to you, people may be able to connect your payments and build a picture of your financial activity.

That’s why Bitcoin developers have explored different ways to make receiving payments more private.

One of those ideas is BIP 351, known as Private Payments.

BIP 351 proposes a way for two people to transact using Bitcoin addresses that only the participants can calculate. It is designed to let recipients publicly share a reusable payment code while generating a unique set of payment addresses for each sender.

The proposal is particularly interesting because it attempts to improve on some of the limitations of earlier systems such as BIP 47 reusable payment codes.

So what exactly is BIP 351?

Let’s start with the problem it is trying to solve.

What Is BIP 351?

BIP 351 stands for Bitcoin Improvement Proposal 351.

Its title is:

Private Payments

The proposal was authored by Alfred Hodler and Clark Moody and is classified as an Informational BIP in the Applications layer. The current canonical BIP repository lists its status as Draft.

The basic idea is straightforward:

Allow someone to publish a reusable payment code while letting different senders derive different Bitcoin addresses for payments to that person.

In other words, BIP 351 tries to separate a person’s:

Public payment identity

from their:

Individual Bitcoin payment addresses

That is useful because publishing one permanent Bitcoin address can create privacy problems.

Why Does Bitcoin Need Private Payments?

To understand BIP 351, you first need to understand why receiving Bitcoin privately can be difficult.

Imagine that Alice runs a website.

She wants visitors to send her Bitcoin.

The easiest solution is to publish an address:

bc1qexample...

Now imagine that 100 different people send Bitcoin to that address.

The blockchain records all those payments.

Anyone who discovers that the address belongs to Alice may be able to see:

How much Bitcoin it received
When payments arrived
Which transactions spent those funds
Which other addresses may be connected
Patterns in Alice’s activity

The problem becomes even greater if Alice uses that same address repeatedly.

This is called address reuse.

Why Is Address Reuse a Privacy Problem?

Bitcoin addresses are not designed to be permanent identities.

Modern wallets generally generate fresh receiving addresses for different payments.

Why?

Because using the same address repeatedly makes it easier to connect transactions.

Consider this example:

Customer 1 → Address A

Customer 2 → Address A

Customer 3 → Address A

All three payments are visibly associated with Address A.

Now imagine:

Customer 1 → Address A

Customer 2 → Address B

Customer 3 → Address C

The relationship between those payments becomes less obvious from the receiving addresses alone.

This is one reason Bitcoin wallets commonly encourage address reuse avoidance.

However, constantly sending someone a new address isn’t always practical.

That’s where reusable payment systems become interesting.

The Problem With Giving Everyone a New Address

Suppose Alice wants to receive recurring Bitcoin payments.

She could simply generate a new address every time someone asks to pay her.

For example:

Bob asks for an address → Alice sends Address A

Charlie asks for an address → Alice sends Address B

David asks for an address → Alice sends Address C

This can work.

But it requires communication between Alice and each sender.

For some situations, that isn’t convenient.

Imagine Alice wants to put her Bitcoin payment information on a website.

She wants something that can remain there for months or years.

She doesn’t want to constantly replace the payment information.

A reusable payment identifier solves part of this problem.

What Is a Reusable Payment Code?

A reusable payment code is a piece of information that a recipient can share publicly.

Instead of publishing one Bitcoin address, the recipient publishes a payment code.

A compatible sender can use that code to derive payment information specific to their relationship with the recipient.

The important concept is:

One payment code → Different payment addresses for different senders

This means Alice can publish one payment code while Bob and Charlie can receive different derived addresses for payments to Alice.

BIP 351 calls this approach Private Payments.

BIP 351 and BIP 47

If you’ve already read our BIP 47 article, you’ll notice something familiar.

BIP 47 also introduced reusable payment codes.

Its basic model is:

Payment code → Notification → Unique payment addresses

BIP 351 was designed partly because BIP 47 has some limitations.

The BIP 351 specification specifically explains that BIP 47 addresses many problems associated with static addresses, but introduces its own notification mechanism and privacy considerations.

BIP 351 tries to keep the useful idea of reusable payment codes while changing how the sender and recipient establish their payment relationship.

That makes BIP 351 an important part of the evolution of Bitcoin payment privacy.

What Problem Does BIP 351 Try to Fix in BIP 47?

One major issue concerns the notification mechanism.

In BIP 47, a recipient has a notification address.

A sender uses that address to notify the recipient before making payments.

The problem is that the notification address is publicly associated with the recipient.

If the sender isn’t careful about which Bitcoin coins they use for the notification transaction, blockchain observers may be able to connect the sender with the recipient.

BIP 351 explicitly identifies this as a privacy concern with BIP 47.

BIP 351 therefore attempts to design a notification system that minimizes the blockchain footprint while reducing the information exposed by that process.

How Does BIP 351 Work at a High Level?

Don’t worry about the cryptography yet.

The basic process looks like this:

Step 1: Bob Creates a Payment Code

Bob’s compatible wallet creates a reusable payment code.

Step 2: Bob Publishes the Code

Bob can share it with anyone who wants to pay him.

Step 3: Alice Imports the Code

Alice’s wallet reads Bob’s payment code.

Step 4: Alice Sends a Notification

Alice’s wallet creates a small notification transaction containing information that allows Bob to identify their payment relationship.

Step 5: Bob Detects the Notification

Bob’s wallet scans the blockchain for the relevant notification.

Step 6: Both Wallets Derive Shared Information

Alice and Bob independently perform cryptographic calculations.

Step 7: Alice Derives a Payment Address

Alice’s wallet calculates a unique address for the payment.

Step 8: Bob Watches for the Payment

Bob’s wallet independently calculates the same address and monitors the blockchain.

The result is that Alice and Bob can arrive at the same payment destination without Bob publishing that address publicly.

Does BIP 351 Use a Notification Transaction?

Yes.

This is an important point.

BIP 351 does not completely eliminate notifications.

Instead, it attempts to make the notification mechanism more privacy-friendly and minimize its blockchain footprint.

The specification defines a notification transaction containing a 40-byte OP_RETURN output. The payload contains information that allows the recipient to identify a notification intended for them.

So the basic process remains:

Payment code → Notification → Derived payment addresses

But the notification design differs from BIP 47.

What Is OP_RETURN?

If you’ve read our article about Bitcoin OP_RETURN, you’ll recognize this part.

OP_RETURN allows a Bitcoin transaction to carry data that is not treated as spendable Bitcoin.

BIP 351 uses an OP_RETURN output for its notification mechanism.

The notification payload contains four main pieces of information:

A search key
A notification code
A sender-specific public key
An address-type value

The complete payload is 40 bytes.

You don’t need to memorize these fields.

Their purpose is what matters:

They allow the recipient’s wallet to recognize and process a notification without publicly revealing the recipient’s payment code.

Why Does BIP 351 Need a Notification?

You might wonder:

“If Bob publishes his payment code, why can’t Alice just calculate the payment address immediately?”

Because the system needs information that is specific to the relationship between Alice and Bob.

BIP 351 allows Alice to create a sender-specific key.

That key becomes part of the notification process.

Bob can then use his own private information to determine whether the notification belongs to him.

This creates a relationship between the two wallets without requiring Bob to publicly publish every future receiving address.

What Is the Payment Code in BIP 351?

BIP 351’s payment code contains:

Address-type information
A compressed public key

The payment code is encoded using Bech32m.

On Bitcoin mainnet, its human-readable prefix is:

pay

A BIP 351 payment code can therefore look something like:

pay1...

The exact string is much longer, but the important thing is that it is clearly different from a normal Bitcoin address.

Why Does BIP 351 Include Address-Type Information?

This is another important improvement.

A payment code doesn’t just need to tell the sender which key to use.

It also needs to communicate which types of Bitcoin addresses the recipient can actually use.

BIP 351 therefore includes address-type flags.

The current specification defines flags for:

P2PKH
P2WPKH
P2TR

In simpler terms:

Legacy Bitcoin addresses

SegWit addresses

Taproot addresses

The recipient’s payment code can indicate which types it supports.

This helps prevent a sender from generating a payment to a script that the recipient’s wallet cannot properly spend.

Why Is Address-Type Support Important?

Imagine Bob’s wallet can spend from a particular type of Bitcoin address.

Alice doesn’t know that.

If Bob simply gives Alice an extended public key, Alice might derive an address type that Bob’s wallet doesn’t support.

That could create a serious usability problem.

BIP 351 addresses this by including address-type information in the payment code.

So Alice’s wallet knows what kind of destination it should generate.

This is a major difference between simply sharing an extended public key and using a dedicated payment-code format.

How Does BIP 351 Use HD Wallets?

BIP 351 builds on hierarchical deterministic wallet technology.

Its derivation structure follows the general BIP44 path:

m / purpose' / coin_type' / account'

The purpose value for BIP 351 is:

351

So the system uses a dedicated branch of the HD wallet hierarchy for its payment functionality.

You don’t normally need to enter this path yourself.

A compatible wallet manages the derivation automatically.

The important concept is that BIP 351 isn’t generating unrelated random keys.

The payment information is derived systematically from the wallet’s key hierarchy.

How Do Alice and Bob Calculate the Same Address?

This is where elliptic-curve cryptography enters the picture.

Let’s keep it simple for now.

Alice has information associated with her payment relationship with Bob.

Bob has his own private key associated with his payment code.

Both sides can calculate a common cryptographic secret.

The specification calls the resulting secret point:

Alice calculates it using her private key and Bob’s public key.

Bob calculates it using the corresponding public information and his own private key.

Both sides arrive at the same result.

This is the foundation that allows them to independently calculate the same payment addresses.

What Is ECDH?

BIP 351 uses the same general cryptographic principle that appears in other Bitcoin privacy protocols:

Elliptic Curve Diffie-Hellman, commonly called ECDH.

ECDH allows two parties to calculate shared cryptographic information without simply publishing the resulting secret.

In simplified terms:

Alice’s private information + Bob’s public information

produces the same shared secret as:

Bob’s private information + Alice’s public information

The blockchain can contain the public information.

But an observer doesn’t automatically have the private keys required to reproduce the shared secret.

BIP 351 uses this property to derive payment addresses that are specific to the participants.

How Are Different Payment Addresses Created?

After establishing the shared secret, BIP 351 uses a transaction counter.

Think of the counter as:

Payment 0

Payment 1

Payment 2

Payment 3

and so on.

For each payment, the counter changes the derived secret.

That means the resulting payment key also changes.

Conceptually:

Shared secret + Payment #0 → Address A

Shared secret + Payment #1 → Address B

Shared secret + Payment #2 → Address C

The recipient’s wallet can calculate the same sequence independently.

This allows many payments to take place without reusing the same receiving address.

Does BIP 351 Create a New Address for Every Payment?

That’s the intended result.

The specification defines a transaction counter that increases for each payment made to a particular recipient relationship.

So instead of sending multiple payments to:

Address A

the sender can generate:

Address A

Address B

Address C

Address D

and so on.

This helps preserve the privacy benefits of fresh Bitcoin receiving addresses while maintaining a reusable payment identity.

What Does the Recipient See?

From the recipient’s perspective, the process can look surprisingly normal.

Bob publishes his payment code.

Alice uses it.

Alice’s wallet derives a payment address.

Alice sends Bitcoin.

Bob’s wallet scans the blockchain and discovers the transaction.

Bob doesn’t need to manually create a new address and send it to Alice before every payment.

The wallet performs the cryptographic work automatically.

That’s the main usability advantage of reusable payment systems.

What Makes BIP 351 Different From Simply Sharing an XPub?

An extended public key, or xpub, can allow another person to derive a sequence of addresses.

So why create a separate payment-code standard?

Because simply sharing an xpub has important limitations.

If Alice shares the same xpub with multiple people, those people may be able to identify the same chain of derived addresses.

That can destroy privacy between different senders.

BIP 351 instead creates a different relationship between each sender and recipient.

Each sender gets a separate set of payment addresses.

The BIP specifically identifies this distinction as one reason a dedicated payment-code mechanism is useful.

Can Multiple People Pay the Same Person Privately?

Yes.

This is one of the most important ideas behind BIP 351.

Imagine Bob publishes one payment code.

Alice wants to pay Bob.

Charlie also wants to pay Bob.

David wants to pay Bob too.

Instead of everyone receiving the same public Bitcoin address, each sender establishes their own relationship with Bob.

Conceptually:

Alice → Private payment relationship → Address A1, A2, A3…

Charlie → Private payment relationship → Address B1, B2, B3…

David → Private payment relationship → Address C1, C2, C3…

The payment addresses are therefore separated by sender.

This makes it harder for the different senders’ payment histories to be linked simply because they paid the same recipient.

What Is the Main Privacy Goal of BIP 351?

The goal is not to make Bitcoin invisible.

Instead, BIP 351 tries to prevent a reusable public payment identity from becoming a single blockchain address that everyone can monitor.

Its design allows:

One public payment code

to correspond to:

Many private payment relationships

which can produce:

Many unique payment addresses

That is the central privacy model.

Is BIP 351 Completely Anonymous?

No.

This is extremely important.

BIP 351 is a privacy-enhancing protocol, not an anonymity guarantee.

Bitcoin transactions remain public.

Blockchain observers can still analyze:

Transaction amounts
Transaction timing
Inputs
Outputs
Spending behavior
Address relationships
Exchange activity
Other publicly available information

BIP 351 mainly addresses the problem of reusable receiving identities and address reuse.

It doesn’t erase the Bitcoin blockchain’s transparency.

How Is BIP 351 Related to Silent Payments?

BIP 351 and BIP 352 Silent Payments are closely related in their goals.

Both attempt to let recipients publish a reusable payment identifier while avoiding the privacy problems of repeatedly publishing one static Bitcoin address.

But they use different designs.

BIP 351 uses a notification transaction.

Silent Payments are designed specifically to avoid on-chain notifications. The BIP 352 specification describes static payment addresses without on-chain linkability of payments or a need for on-chain notifications.

So, at a high level:

BIP 351

Payment code → Notification → Derived addresses

Silent Payments

Static payment identifier → Sender derives recipient-specific output

This difference becomes extremely important when comparing the two systems.

We’ll explore it in much more detail in Part 3.

Why Is BIP 351 Interesting?

BIP 351 is interesting because it tackles several problems at once.

It tries to provide:

A reusable payment identity
Unique payment addresses
Sender-specific payment relationships
Address-type compatibility
Minimal notification data
On-chain operation
No dependence on a centralized payment server

The proposal describes its goal as allowing two parties to transact using addresses that only they can calculate while minimizing the blockchain footprint.

That makes BIP 351 an interesting chapter in Bitcoin’s ongoing development of private payment systems.

BIP 351 in One Simple Example

Let’s make everything extremely simple.

Imagine Bob is a freelancer.

He wants clients to pay him Bitcoin.

Instead of publishing:

Bitcoin Address X

Bob publishes his:

BIP 351 Payment Code

Alice wants to pay Bob.

Her wallet imports Bob’s payment code.

Alice’s wallet sends the required notification.

Bob’s wallet detects it.

Both wallets calculate the necessary shared information.

Alice’s wallet derives:

Payment Address A

She sends Bitcoin there.

Later, Alice pays Bob again.

Her wallet derives:

Payment Address B

Charlie also pays Bob.

Charlie’s wallet derives a completely different payment relationship and address sequence.

Bob therefore doesn’t need to publish one permanent receiving address for all of his clients.

That is the core idea behind BIP 351.

How Does BIP 351 Work?

At a high level, BIP 351 follows this process:

Recipient creates payment code

↓

Recipient publishes payment code

↓

Sender imports payment code

↓

Sender creates notification transaction

↓

Recipient detects notification

↓

Both wallets calculate shared cryptographic information

↓

Sender derives a unique payment address

↓

Recipient derives the same address

↓

Bitcoin is sent

The blockchain sees the final Bitcoin transaction.

The important information needed to generate the destination isn’t simply published as a normal static Bitcoin address.

Step 1: The Recipient Creates a Payment Code

Suppose Bob wants people to be able to pay him privately.

His compatible wallet generates a BIP 351 payment code.

The code contains information that allows senders to calculate payment addresses for Bob.

It does not contain Bob’s private keys.

It also does not contain any Bitcoin.

Think of it as a public cryptographic payment identity.

Bob can therefore share it publicly without giving someone control over his funds.

What Does a BIP 351 Payment Code Look Like?

BIP 351 uses Bech32m encoding for its payment codes.

On Bitcoin mainnet, the payment code uses the human-readable prefix:

pay

A simplified example might look like:

pay1example...

The actual payment code is considerably longer.

The important distinction is that it is not supposed to look like a conventional Bitcoin address.

It represents a reusable payment identity rather than one specific receiving destination.

What Information Is Inside the Payment Code?

The payment code contains two important categories of information:

Address Type

This tells the sender which type of Bitcoin address the recipient supports.

Public Key

This provides the public cryptographic information needed to calculate the payment relationship.

The payment code does not contain the corresponding private key.

That distinction is critical.

Anyone can potentially know Bob’s payment code.

Only Bob’s wallet should possess the private information required to spend the Bitcoin eventually received through the derived addresses.

Why Does BIP 351 Specify Address Types?

Bitcoin has several address and output formats.

For example:

P2PKH
P2WPKH
P2TR

These correspond broadly to older Bitcoin addresses, SegWit addresses, and Taproot addresses.

BIP 351 allows the payment code to indicate which output types the recipient supports.

This prevents the sender from creating a payment using an address format the recipient cannot properly use.

The specification defines flags for these supported address types. (bitcoin.org)

What Is the BIP 351 Derivation Path?

BIP 351 uses hierarchical deterministic wallet derivation.

Its path follows the general structure:

m / 351' / coin_type' / account'

For Bitcoin mainnet, the coin type is:

0'

So a simplified Bitcoin path looks like:

m / 351' / 0' / 0'

The purpose value 351′ identifies the branch used for BIP 351 functionality.

A compatible wallet normally handles this automatically.

Users shouldn’t need to manually calculate these paths when using supported software.

Why Use HD Wallet Derivation?

HD wallets allow one seed to generate many related keys.

Instead of creating unrelated random keys, the wallet can derive keys according to a structured hierarchy.

This provides several advantages:

Easier backup
Predictable key generation
Large numbers of addresses
Organized wallet structure
Recovery from a seed

BIP 351 uses this capability to generate the keys needed for its payment-code system.

This is similar to the role HD wallets play in many other modern Bitcoin wallet systems.

What Happens After Bob Publishes His Payment Code?

Now suppose Alice wants to pay Bob.

Alice obtains Bob’s payment code.

Her wallet reads the information inside it.

However, Alice still needs to notify Bob that she wants to establish a payment relationship.

This is where the notification transaction comes in.

What Is the BIP 351 Notification Transaction?

The notification transaction is a small Bitcoin transaction that tells Bob’s wallet:

“Someone wants to establish a BIP 351 payment relationship with you.”

But it does more than simply send a message.

The transaction contains cryptographic information that Bob’s wallet can use to determine:

Who the notification is intended for
Which sender-specific key is being used
Which payment-code information should be processed
How the future payment relationship should be established

The notification is therefore an important part of the protocol.

How Is the Notification Different From BIP 47?

This is one of the most important differences.

BIP 47 uses a dedicated notification address.

The sender sends a small amount of Bitcoin to that notification address and includes protected payment-code information in an OP_RETURN output.

BIP 351 takes a different approach.

Its notification mechanism uses a 40-byte OP_RETURN payload and does not require the same dedicated notification-address model used by BIP 47. (bitcoin.org)

This change is intended to reduce the information exposed by the notification process.

What Is Inside the 40-Byte Payload?

The BIP 351 notification payload contains four main components:

Search key
Notification code
Sender’s public key
Address-type information

Together, these occupy 40 bytes.

The exact byte-level construction is primarily useful to wallet developers.

For ordinary users, the important concept is:

The notification transaction contains enough information for the recipient’s wallet to find and process it without simply publishing the recipient’s payment code.

What Is the Search Key?

The search key is designed to help the recipient determine whether a particular notification belongs to them.

Bob’s wallet can derive information from his own payment-code keys and compare it against the information found in transactions.

This means Bob doesn’t have to download every notification and assume it belongs to him.

The search mechanism helps narrow down which notifications are relevant.

Why Is a Search Key Useful?

Imagine thousands of BIP 351 users are making notification transactions.

Bob’s wallet needs some way to determine:

“Is this notification for me?”

A simple search mechanism makes that possible.

The notification contains a cryptographic value that can be checked against information derived from Bob’s payment code.

If the values match the required relationship, Bob’s wallet continues processing the notification.

If they don’t match, the wallet can ignore it.

What Is the Notification Code?

The notification code is another component of the OP_RETURN payload.

It contains information that Bob’s wallet can use after identifying the relevant notification.

The code is generated using cryptographic operations involving the sender’s information.

Its purpose is not to provide a normal Bitcoin address.

Instead, it helps establish the cryptographic relationship required for future payments.

What Is the Sender’s Public Key?

The notification transaction also contains a public key generated specifically for the notification.

This is important because Bob needs a public key from Alice that can participate in the cryptographic calculations.

Alice’s private key remains under her control.

The corresponding public key can safely appear in the notification transaction.

This gives Bob the public information he needs without exposing Alice’s private key.

Why Does the Sender Use a New Key?

Using a sender-specific or ephemeral key helps prevent unrelated payment relationships from becoming unnecessarily linked.

Instead of using one permanent public key for every payment relationship, the protocol can use fresh cryptographic material for different interactions.

This supports the privacy objective of BIP 351.

The goal is to avoid creating one obvious public identifier connecting all of Alice’s payments to different recipients.

How Does ECDH Enter the Picture?

Now we reach the cryptographic heart of the protocol.

BIP 351 uses an elliptic-curve shared-secret calculation.

The basic principle is similar to Elliptic Curve Diffie-Hellman, or ECDH.

Alice has a private key.

Bob has a private key.

They exchange the corresponding public information.

Both sides can then calculate the same shared secret without publicly revealing that secret.

Conceptually:

Alice’s private key + Bob’s public key

and:

Bob’s private key + Alice’s public key

produce the same underlying cryptographic result.

That shared information is then used to derive payment addresses.

Why Is the Shared Secret Important?

The shared secret creates something unique to the relationship between Alice and Bob.

An observer might know:

Bob’s public payment code
Alice’s public notification key
The Bitcoin transaction
The notification payload

But the observer does not automatically possess the private keys required to calculate the same shared secret.

That allows the sender and recipient to derive information that isn’t simply available to everyone watching the blockchain.

How Does the Sender Derive a Payment Address?

After the notification relationship has been established, Alice can derive a payment address for Bob.

The derivation uses:

Bob’s public key
Alice’s private information
The shared cryptographic result
A payment counter

The counter is important because it changes for subsequent payments.

Conceptually:

Shared information + Counter 0 → Payment Address 0

Shared information + Counter 1 → Payment Address 1

Shared information + Counter 2 → Payment Address 2

This allows the sender to generate different payment destinations.

Why Use a Payment Counter?

The payment counter prevents every payment from producing the same destination.

Imagine Alice pays Bob five times.

Without a changing counter, she could repeatedly derive the same address.

That would bring back the address-reuse problem.

Instead, the counter changes:

0 → 1 → 2 → 3 → 4

Each value produces a different derived payment address.

This is one of the mechanisms that allows BIP 351 to support repeated payments while maintaining address separation.

How Does Bob Find the Same Address?

This is where the protocol becomes clever.

Alice doesn’t need to send Bob the newly generated address.

Bob’s wallet can independently perform the corresponding derivation.

Both wallets have the information required to calculate the same result.

Alice calculates:

Payment Address 0

Bob independently calculates:

Payment Address 0

They arrive at the same destination.

Alice sends Bitcoin there.

Bob’s wallet recognizes the output as belonging to him.

The blockchain doesn’t need a special “BIP 351 address” format.

The derived destination can use the Bitcoin output type specified by the payment code.

Why Can’t Someone Else Calculate the Address?

An outside observer may see the public information involved in the transaction.

But they don’t have the private keys belonging to Alice or Bob.

The protocol’s cryptographic construction means that the relevant shared secret cannot simply be reconstructed from public blockchain data.

This is what gives the derived payment address its privacy properties.

However, remember that Bitcoin transaction privacy is not the same as complete anonymity.

The transaction itself remains visible.

What Happens When Bob’s Wallet Scans the Blockchain?

Bob’s wallet needs to monitor the blockchain.

It looks for notification transactions that might belong to his payment code.

The search-key mechanism helps it identify relevant notifications.

Once Bob’s wallet recognizes one:

It processes the notification.
It obtains the sender-specific public information.
It performs the required cryptographic calculations.
It derives possible payment addresses.
It watches those addresses for incoming transactions.

The process happens automatically in compatible wallet software.

What Is a Watchlist?

A wallet can maintain a list of addresses that it expects to receive payments through.

For BIP 351, the wallet can derive a sequence of possible payment addresses.

For example:

Address 0

Address 1

Address 2

Address 3

and so on.

The wallet monitors these destinations.

If Bitcoin appears at one of them, the wallet can recognize the payment.

This is similar to the address-derivation process used by HD wallets, although BIP 351 introduces additional cryptographic relationships.

Why Does the Recipient Need to Scan?

A normal Bitcoin address is easy to monitor.

The wallet knows exactly which address to watch.

BIP 351 is different because the actual payment address isn’t publicly announced.

The recipient therefore needs to calculate possible addresses and monitor the blockchain.

This is one of the trade-offs of private receiving systems.

More privacy can require more wallet-side work.

That same trade-off also appears in Silent Payments.

What Happens After the First Payment?

Once the payment relationship exists, Alice can make additional payments.

She doesn’t necessarily need to repeat the entire notification process for every payment.

Instead, the payment counter advances.

For example:

First payment → Counter 0

Second payment → Counter 1

Third payment → Counter 2

Fourth payment → Counter 3

Each payment can therefore use a different derived address.

This is what makes the payment code reusable.

What If Alice Sends Bob Another Payment Months Later?

The payment-code relationship can remain available.

Alice’s wallet keeps track of the relevant payment index.

When she wants to pay Bob again, it can derive the next payment destination.

Bob’s wallet independently knows how to derive the corresponding destination.

The wallets therefore don’t need to exchange a fresh Bitcoin address through a separate communication channel for every payment.

What Happens If the Sender Loses Wallet Data?

This is an important practical issue.

A BIP 351 implementation needs to preserve the information required to continue the payment-code relationship.

That includes relevant derivation state and payment indexes.

If the wallet doesn’t correctly restore that information, it may not know which payment addresses have already been used.

This is why advanced Bitcoin wallet protocols require careful backup and recovery design.

A seed phrase protects the underlying wallet keys, but software may also need to reconstruct protocol-specific state.

Why Is Wallet Recovery More Complicated?

Imagine Alice has paid Bob 50 times.

Her wallet has reached:

Payment index 50

If Alice restores her wallet and starts again at:

Payment index 0

she could derive addresses that were already used.

That would be undesirable.

A compatible implementation therefore needs to recover enough information to determine where the payment sequence should continue.

This is one reason protocol-specific wallet metadata matters.

What Happens If the Same Payment Code Is Used on Two Devices?

This is another potential implementation challenge.

Suppose Alice uses BIP 351 on her phone and desktop.

Both devices need to maintain consistent payment-code state.

If one device thinks the next payment is:

Index 25

while the other also thinks the next payment is:

Index 25

they could potentially derive the same destination.

Proper wallet synchronization is therefore important.

This is not unique to BIP 351; many deterministic wallet systems need careful handling of address-generation state.

Does BIP 351 Require a New Blockchain?

No.

This is an important point.

BIP 351 doesn’t create a new cryptocurrency.

It doesn’t require a separate blockchain.

It doesn’t change Bitcoin’s fundamental consensus rules.

Instead, it defines a payment mechanism that can operate using standard Bitcoin transactions and cryptographic key derivation.

That means the protocol works at the application and wallet level.

Does BIP 351 Change Bitcoin Transactions?

Not fundamentally.

A normal Bitcoin transaction still contains inputs and outputs.

Bitcoin nodes still validate it according to Bitcoin’s consensus rules.

The difference is in how compatible wallets calculate the destination addresses and communicate the information needed to establish the payment relationship.

This is similar to many other Bitcoin wallet protocols.

The blockchain remains Bitcoin.

The wallet software becomes smarter.

What Are the Main Technical Trade-Offs?

BIP 351 attempts to improve privacy, but that comes with additional complexity.

Privacy

The payment relationship can avoid exposing one static receiving address.

Complexity

Wallet software must perform additional calculations and scanning.

Blockchain Footprint

The notification process still creates an on-chain transaction.

Compatibility

Both sides need compatible software.

Recovery

Wallets need to preserve enough state to continue deriving payment addresses correctly.

These trade-offs become especially important when comparing BIP 351 with Silent Payments.

BIP 351 vs BIP 47: The Key Technical Difference

The two proposals share the concept of reusable payment codes.

But their notification mechanisms differ.

BIP 47

The sender uses a dedicated notification address and a notification transaction.

BIP 351

The notification mechanism uses a compact OP_RETURN payload and a search-key-based identification system.

BIP 351 was designed to address some of the privacy concerns associated with the BIP 47 notification model. (bitcoin.org)

This makes BIP 351 an interesting evolution of the reusable-payment-code concept.

BIP 351 vs Silent Payments: The Important Difference

BIP 351 still uses a notification mechanism.

Silent Payments take a fundamentally different approach.

Silent Payments allow a recipient to publish a static payment identifier and allow senders to derive recipient-specific outputs without first creating a separate notification transaction.

That removes an important on-chain step.

However, Silent Payments require the recipient to scan blockchain transactions to identify payments.

So the trade-off becomes:

BIP 351

Notification transaction + payment derivation

versus:

Silent Payments

No traditional notification transaction + more recipient-side scanning

Neither approach is completely free of trade-offs.

Why Was BIP 351 Proposed?

The broader motivation is privacy.

Bitcoin addresses are not intended to function as permanent public identities.

But real-world users often want exactly that.

A business may want one payment identity.

A creator may want one donation identifier.

A freelancer may want one payment page.

A nonprofit may want one permanent donation reference.

BIP 351 tries to provide this convenience without forcing every payment to use the same blockchain address.

The Core Idea in One Diagram

You can think about BIP 351 like this:

Public

Reusable Payment Code

↓

Private Relationship

Cryptographic Derivation

↓

Unique Payment Destination

↓

Bitcoin Payment

The public payment code is reusable.

The actual payment destinations can change.

That’s the key privacy advantage.

Why BIP 351 Is Technically Interesting

BIP 351 demonstrates how much can be accomplished without changing Bitcoin’s basic consensus rules.

It combines existing cryptographic concepts with wallet software to create a new payment experience.

The protocol doesn’t need:

A new coin
A centralized payment server
A new blockchain
A new mining algorithm

Instead, it uses Bitcoin’s existing transaction system, public-key cryptography, and deterministic key derivation.

What Are the Main Advantages of BIP 351?

BIP 351 is designed around a simple goal:

Let someone publish a reusable payment identity without forcing every payment to use the same Bitcoin address.

That creates several potential advantages.

1. Reusable Payment Identity

A normal Bitcoin address is generally designed for receiving a particular payment.

If you publish the same address everywhere, anyone can potentially observe the transactions associated with that address.

A BIP 351 payment code works differently.

You can share one reusable payment identifier while compatible wallets derive different payment destinations.

This makes the payment experience more convenient without relying on one permanently reused address.

2. Better Address Privacy

Address reuse can make blockchain activity easier to associate.

For example, imagine a creator publishes one Bitcoin address on their website.

They receive:

A $20 donation.
A $50 donation.
A $100 donation.
A $200 donation.

If all four payments use the same address, an observer can easily see that those transactions belong to the same destination.

BIP 351 aims to avoid that pattern.

Each payment can use a different derived destination.

Therefore, someone viewing one payment cannot simply look at the recipient’s publicly advertised payment code and assume that every future payment will use the same address.

3. No Central Payment Server

BIP 351 doesn’t require a company to operate a payment server.

The payment relationship is established using Bitcoin transactions and cryptographic key derivation.

That means the system can remain decentralized.

Users don’t need to trust a centralized payment processor simply to generate receiving addresses.

4. Supports Multiple Address Types

Another useful feature is its ability to communicate supported Bitcoin address types through the payment code.

The specification includes support for address types such as:

P2PKH
P2WPKH
P2TR

This allows wallets to coordinate the type of destination they derive.

That is important because Bitcoin’s address ecosystem has evolved significantly over time.

5. Useful for Repeated Payments

BIP 351 is especially interesting when someone expects to receive Bitcoin repeatedly.

Consider:

Freelancers
Content creators
Donation campaigns
Businesses
Bitcoin services
Organizations
Individuals receiving recurring payments

Instead of manually creating and publishing a new address every time, a reusable payment code can provide a more convenient receiving experience.

The wallet handles the address generation in the background.

What Are the Disadvantages of BIP 351?

Privacy protocols always involve trade-offs.

BIP 351 is no exception.

1. Notification Transactions Are Required

One of the biggest limitations is the notification process.

The sender needs to establish the payment relationship through an on-chain notification.

That creates a blockchain footprint.

This is important because one of the attractions of Bitcoin Silent Payments is that they eliminate the need for this traditional notification step.

2. Wallets Need More Work

A normal Bitcoin wallet can simply monitor a list of addresses.

BIP 351 requires more sophisticated wallet logic.

A compatible wallet needs to:

Understand payment codes.
Process notifications.
Perform cryptographic calculations.
Derive payment addresses.
Track payment counters.
Monitor derived destinations.
Recover protocol state correctly.

This makes implementation more complicated than ordinary Bitcoin receiving.

3. Both Sides Need Compatible Software

The sender needs a wallet that understands the payment code.

The recipient also needs compatible software capable of processing notifications and deriving the corresponding destinations.

Without compatible wallet support, a BIP 351 payment workflow cannot simply be assumed to work.

This is one reason advanced Bitcoin payment protocols can take time to become widely used.

4. Blockchain Scanning Is Necessary

The recipient’s wallet needs to monitor the blockchain for relevant notifications and derived payment outputs.

That means the wallet has additional scanning responsibilities.

For desktop wallets connected directly to a Bitcoin node, this can be manageable.

For lightweight wallets, however, efficient scanning can become a significant engineering challenge.

5. Recovery Requires Care

Advanced deterministic payment systems need to preserve more than just private keys.

Wallet software needs to remember enough information to reconstruct the payment relationships and determine which derived addresses should be monitored.

If that state isn’t handled correctly during recovery, the wallet could have difficulty finding previously received payments or continuing a payment sequence.

This is one reason users should prefer mature wallet implementations over experimental software when dealing with real funds.

Is BIP 351 Completely Anonymous?

No.

This distinction is extremely important.

BIP 351 is a privacy-enhancing protocol, not an anonymity guarantee.

Bitcoin transactions remain visible on the public blockchain.

Observers can still analyze:

Transaction amounts
Transaction timing
Inputs
Outputs
Transaction relationships
Spending patterns
Network information

BIP 351 mainly attempts to prevent the recipient from having one publicly reused address that directly links all incoming payments.

It does not make the Bitcoin blockchain invisible.

Can BIP 351 Prevent Blockchain Analysis?

Not completely.

Blockchain analysis companies can use many different clues.

For example, they can examine transaction structures, timing, spending behavior, known addresses, exchange deposits, withdrawals, and other information.

Therefore, users should not assume that using a private-payment protocol automatically makes every transaction anonymous.

A better way to describe BIP 351 is:

It reduces certain forms of address-based linkability.

That is valuable, but it is not the same thing as complete financial anonymity.

BIP 351 vs BIP 47

BIP 351 is closely related to BIP 47 because both use the idea of reusable payment codes.

However, the protocols aren’t identical.

BIP 47

BIP 47 introduced reusable payment codes that allow senders to establish private payment relationships with recipients.

However, the original design uses a notification transaction involving a dedicated notification address.

That creates a recognizable on-chain process and introduces additional considerations around notification addresses and address types.

BIP 351

BIP 351 attempts to improve this model.

Its notification mechanism uses an OP_RETURN payload containing information that allows the recipient to identify and process the notification.

It also expands the address-type model to support newer Bitcoin output types.

The goal is to provide reusable payment identities while improving some of the limitations associated with earlier payment-code designs.

BIP 351 vs Silent Payments

This is arguably the most important comparison.

Bitcoin Silent Payments, specified by BIP 352, pursue a similar high-level goal:

Allow someone to publish a reusable receiving identifier while generating unique on-chain payment destinations.

However, Silent Payments take a different approach.

BIP 351 Uses Notifications

BIP 351 establishes the payment relationship using a notification transaction.

The sender and recipient therefore have an on-chain interaction that helps establish the relationship.

This can make implementation conceptually easier in some respects because the recipient has a notification to identify.

However, the notification itself creates additional blockchain activity.

Silent Payments Avoid Traditional Notifications

Silent Payments were designed so that the sender can derive the recipient’s unique payment output without first sending a separate notification transaction.

That is a major architectural difference.

Instead of:

Payment code → Notification → Payment address

Silent Payments work more like:

Silent Payment address → Transaction-specific output

The recipient then scans the blockchain to discover payments intended for them.

So Which Is More Private?

There isn’t a simple “one is private and the other isn’t” answer.

Both are designed to improve privacy compared with repeatedly publishing and reusing a normal Bitcoin address.

The difference is primarily how they achieve it.

BIP 351 uses a notification mechanism.

Silent Payments remove that traditional notification step but require more recipient-side scanning.

So the trade-off looks roughly like this:

Feature	BIP 351	Silent Payments
Reusable receiving identifier	Yes	Yes
Unique payment destinations	Yes	Yes
Traditional notification	Yes	No
Recipient blockchain scanning	Required	Required
Address reuse avoidance	Yes	Yes
Wallet complexity	Higher	Higher
On-chain notification footprint	Yes	No
Designed for modern Bitcoin privacy	Yes	Yes

The important point is that Silent Payments don’t simply make BIP 351 obsolete because the two protocols represent different design approaches.

Is BIP 351 Better Than BIP 47?

For some goals, BIP 351 can be viewed as an evolution of the reusable payment-code concept.

It was designed with lessons from BIP 47 in mind, including the notification mechanism and support for different Bitcoin address types.

However, “better” depends on what you are optimizing for.

If you want to understand the history of reusable payment codes, BIP 47 is extremely important.

If you’re interested in a later design that tries to improve some of those limitations, BIP 351 becomes more interesting.

And if you want a notification-free approach, Silent Payments are particularly important.

Is BIP 351 Better Than Silent Payments?

Not necessarily.

Silent Payments have a major architectural advantage:

They don’t require a separate notification transaction.

That reduces the additional on-chain footprint associated with establishing a payment relationship.

However, Silent Payments introduce their own challenges.

The recipient’s wallet must scan transactions to determine which outputs belong to the wallet.

That can be computationally demanding.

It also creates challenges for lightweight wallets and infrastructure.

Current work around Silent Payments includes indexing and scanning services intended to make this process more efficient for wallet implementations.

Therefore, the comparison isn’t simply:

BIP 351 = old

Silent Payments = new

Instead, it is:

Different privacy architectures with different engineering trade-offs.

Is BIP 351 Still Relevant?

Yes, at least as a technical proposal and part of Bitcoin’s evolution toward better private receiving mechanisms.

However, there is an important status distinction.

The current BIP documentation lists BIP 351 as Draft. It should therefore not be presented as a finalized Bitcoin standard that every wallet supports today.

That distinction matters.

A BIP can describe a technically interesting proposal without becoming universally implemented.

Why Isn’t BIP 351 Used Everywhere?

Bitcoin wallet development is conservative for good reason.

Wallets handle real money.

Developers therefore need to consider:

Security
Recovery
Compatibility
Testing
Interoperability
Backup behavior
Scanning performance
User experience
Long-term maintenance

A protocol can be technically impressive and still take years to gain meaningful adoption.

Users also need wallets that actually implement the same specification.

Without broad wallet support, even a well-designed payment protocol can remain niche.

Could Businesses Use BIP 351?

Potentially, yes.

The concept is particularly interesting for businesses that want a reusable Bitcoin payment identity.

Imagine an online business publishing one payment identifier:

Pay us in Bitcoin

The customer doesn’t need to be given a permanent Bitcoin address.

Instead, compatible wallet software can derive a destination for that particular payment.

This could reduce address-management problems while improving privacy between customers.

However, businesses should not adopt an experimental or insufficiently supported payment protocol simply because it sounds more private.

Compatibility and wallet support matter.

What About Bitcoin Donations?

Donations are another natural use case.

Imagine a nonprofit publishing one Bitcoin payment identity on:

Its website
Social media
Printed materials
Email newsletters
Donation pages

With ordinary address reuse, all donations could become associated with one public address.

A reusable private-payment system attempts to solve that problem.

Each donor can potentially end up paying a different derived destination.

That makes the public payment identity much more convenient.

What About Freelancers?

A freelancer could also benefit from reusable private payment identifiers.

Instead of sending a new Bitcoin address to every client, the freelancer could provide one payment identity.

Compatible wallets can derive unique destinations for different payments.

This can make Bitcoin invoicing easier while reducing unnecessary address reuse.

However, accounting software would need to properly track the underlying transactions.

Privacy improvements should never come at the cost of losing financial records.

Does BIP 351 Make Bitcoin Payments Private From the Recipient?

No.

This is another subtle point.

BIP 351 primarily protects the recipient from having to expose one reusable address publicly.

It doesn’t mean that the sender doesn’t know where their own payment went.

If Alice pays Bob, Alice knows that she paid Bob.

The privacy benefit is more relevant to outside observers who are watching the blockchain.

What About Payment Amounts?

BIP 351 does not hide Bitcoin transaction amounts.

Bitcoin transactions remain publicly visible.

Therefore, someone who discovers the relevant transaction can still see the amount transferred.

This is another reason not to confuse private receiving mechanisms with confidential transactions.

BIP 351 changes how payment destinations are derived.

It doesn’t encrypt Bitcoin’s public ledger.

Can BIP 351 Be Combined With Other Privacy Techniques?

Potentially, yes.

Bitcoin privacy is not usually based on one magic feature.

Users may combine different techniques depending on their needs.

For example:

New receiving addresses
CoinJoin
Silent Payments
PayJoin
Careful UTXO management
Full-node usage
Network privacy tools

Each technique addresses different parts of the privacy problem.

However, combining privacy tools doesn’t automatically make a user anonymous.

Poor operational practices can still reveal information.

BIP 351 and Wallet Security

Privacy doesn’t replace basic wallet security.

A sophisticated payment protocol cannot protect you if someone steals your seed phrase.

Users should still:

Keep recovery phrases offline.
Never share private keys.
Verify wallet software.
Avoid suspicious websites.
Check transactions before signing.
Keep backups secure.
Use reputable wallet implementations.

Remember:

Privacy protects information.

Security protects funds.

You need both.

Common BIP 351 Questions

What is BIP 351?

BIP 351 is a Bitcoin proposal for Private Payments that uses reusable payment codes and cryptographic derivation to allow unique payment destinations.

Is BIP 351 a Bitcoin address?

No.

A BIP 351 payment code is a reusable payment identifier.

It is different from a normal Bitcoin receiving address.

Can I send Bitcoin directly to a BIP 351 payment code?

Not in the same way you send Bitcoin to an ordinary Bitcoin address.

Compatible wallet software must process the payment code and derive the appropriate Bitcoin destination.

Does BIP 351 require a notification transaction?

Yes.

The protocol uses a notification mechanism to establish the payment relationship.

Does BIP 351 prevent address reuse?

Its design aims to avoid repeatedly using one static receiving address by deriving unique payment destinations.

Is BIP 351 anonymous?

No.

It is a privacy-enhancing protocol, not a complete anonymity system.

Does BIP 351 hide Bitcoin transaction amounts?

No.

Bitcoin transaction amounts remain visible on the blockchain.

Does BIP 351 require a new blockchain?

No.

It is designed as a Bitcoin application-layer payment protocol.

Is BIP 351 the same as BIP 47?

No.

They both use reusable payment-code concepts, but their notification mechanisms and technical designs differ.

Is BIP 351 the same as Silent Payments?

No.

Silent Payments use a different architecture and avoid the traditional notification transaction.

Which is better: BIP 351 or Silent Payments?

There isn’t one universal answer.

BIP 351 uses notifications, while Silent Payments avoid them but require more recipient-side scanning.

The better approach depends on wallet design, infrastructure, privacy requirements, and compatibility.

Is BIP 351 finalized?

The current BIP documentation lists BIP 351 as Draft, so it should not be described as a finalized universal Bitcoin standard.

Should beginners use BIP 351?

Beginners should prioritize mature, well-supported wallet features.

If a wallet doesn’t clearly support BIP 351, users should not attempt to manually construct payment-code transactions.

BIP 351 in Simple Terms

If all the technical details feel overwhelming, remember this:

A normal Bitcoin address is like giving someone a specific mailbox.

Anyone who knows that mailbox can see the Bitcoin transactions going into it.

A reusable payment code is more like giving someone a private payment instruction.

They can use that instruction to generate a new destination for each payment.

So instead of:

One public identity → One public Bitcoin address

the goal becomes:

One public payment identity → Many unique Bitcoin destinations

That is the central idea behind BIP 351.

Why BIP 351 Matters

Bitcoin has always had an interesting contradiction.

It gives users control over their money, but its public blockchain makes transaction history highly transparent.

Address reuse makes that transparency even easier to exploit.

If one address becomes publicly associated with a person or business, anyone can potentially monitor its activity.

Privacy-oriented payment protocols attempt to reduce that problem.

BIP 351 is one example of that broader effort.

The Bigger Bitcoin Privacy Picture

BIP 351 shouldn’t be viewed in isolation.

Bitcoin’s privacy ecosystem has developed through several different ideas.

BIP 47 explored reusable payment codes.

BIP 351 explored a later private-payment design using a different notification mechanism.

BIP 352 introduced Silent Payments, which remove the need for traditional notification transactions.

Other techniques, such as CoinJoin and PayJoin, approach transaction privacy from different directions.

Each solves a different part of the puzzle.

Final Verdict: What Is BIP 351?

BIP 351 is a Bitcoin proposal designed to make reusable payments more private.

Instead of publishing one Bitcoin address and repeatedly receiving funds there, users can share a reusable payment code.

Compatible wallets can then use cryptographic techniques to derive unique payment destinations.

The result can reduce address reuse and make blockchain-based payment relationships harder to link simply by looking at one publicly shared address.

However, BIP 351 isn’t perfect.

Its notification mechanism creates additional on-chain activity.

Wallets must perform more complicated calculations and scanning.

Recovery and synchronization require careful implementation.

And, most importantly, BIP 351 should currently be understood as a Draft proposal, not a universally adopted Bitcoin standard.

BIP 351 vs BIP 47 vs Silent Payments: The Bottom Line

If you remember only one comparison, remember this:

BIP 47

Reusable payment codes + notification transaction

An important early approach to private reusable Bitcoin payments.

BIP 351

Reusable payment codes + redesigned notification mechanism

An attempt to improve the payment-code model and address some limitations of BIP 47.

BIP 352 Silent Payments

Reusable payment identifier + no traditional notification transaction

A different approach that shifts more work toward recipient-side blockchain scanning.

All three are part of the same broader effort:

Make Bitcoin easier to receive repeatedly without publicly reusing the same address.

Final Thoughts

Bitcoin was designed to make payments possible without requiring a centralized financial intermediary.

But Bitcoin’s transparency creates a privacy challenge.

If you publish the same receiving address everywhere, your transactions can become much easier to associate.

BIP 351 offers an interesting solution to that problem.

It separates the idea of a public payment identity from the actual Bitcoin destinations used for individual payments.

That distinction is powerful.

At the same time, privacy comes with engineering costs.

Wallets need more sophisticated scanning, cryptographic derivation, recovery logic, and compatibility.

And because BIP 351 remains a Draft proposal, users should treat it as an advanced Bitcoin payment concept rather than assuming every wallet supports it.

The most important lesson is broader than BIP 351 itself:

Bitcoin privacy isn’t about hiding everything. It’s about reducing unnecessary information leakage.

Reusable private-payment protocols are one way Bitcoin developers are trying to achieve that goal.

And as Bitcoin wallets continue to evolve, the ability to receive payments privately without manually generating and publishing a new address every time could become an increasingly important part of the Bitcoin user experience.