Bitcoin addresses are designed to receive Bitcoin, but repeatedly publishing the same address can create privacy problems.

Advertise here

If you use one Bitcoin address for every payment, anyone who can identify that address may be able to look at its transaction history on the public blockchain.

This creates an interesting challenge.

You want people to have a reusable way to identify where they should send you Bitcoin, but you don’t necessarily want to give everyone one permanent address that can be easily linked to all of your payments.

BIP 47 was designed to address this problem.

BIP 47 introduces reusable payment codes for Bitcoin. Instead of giving someone a single Bitcoin address to reuse, a payment code can be publicly shared while the actual payments between users can be sent to different addresses.

The result is a system designed to make recurring Bitcoin payments more private without requiring the recipient to publish a new address manually for every transaction. The specification is an application-layer proposal and is currently listed as Deployed in the Bitcoin BIPs repository.

What Is BIP 47?

BIP 47 stands for Bitcoin Improvement Proposal 47.

Its full title is:

Reusable Payment Codes for Hierarchical Deterministic Wallets

The proposal was authored by Justus Ranvier and was assigned in 2015. Its goal is to create payment codes that can be publicly advertised and associated with an identity without creating the same privacy problems that come from repeatedly reusing a Bitcoin address.

The basic idea is:

Payment code → Private notification → Unique payment addresses

Instead of Alice publishing one Bitcoin address and asking everyone to send money there, Alice can publish a reusable payment code.

Bob obtains Alice’s payment code.

A notification process establishes the necessary information between their wallets.

After that, Bob can send payments to Alice using unique Bitcoin addresses derived for their interaction.

Alice can therefore have one reusable payment code while receiving payments through different addresses.

Why Was BIP 47 Created?

To understand BIP 47, first consider the problem with address reuse.

Imagine a freelancer publishes this Bitcoin address on their website:

1ExampleBitcoinAddress...

A customer sends 0.01 BTC.

Later, another customer sends 0.05 BTC to the same address.

Then another customer sends 0.02 BTC.

All of these transactions appear on the public blockchain.

Anyone who discovers that the address belongs to the freelancer can potentially see the transaction history associated with it.

They may be able to observe:

Incoming payments
Transaction amounts
Spending activity
Other addresses connected through transactions
Approximate payment patterns

Bitcoin’s blockchain is transparent by design.

That transparency is useful for verification, but it can create privacy concerns.

BIP 47 attempts to provide a reusable payment identifier without requiring the same address to be reused for every payment.

What Is Address Reuse?

Address reuse happens when the same Bitcoin address receives multiple payments.

For example:

Customer A → Address X

Customer B → Address X

Customer C → Address X

The problem is that all three payments are publicly associated with Address X.

This creates a common privacy weakness.

Bitcoin wallets generally encourage users to receive payments using fresh addresses whenever possible.

However, manually generating and sharing a new address every time isn’t always convenient.

Imagine a business that wants customers to have a permanent Bitcoin payment identity.

It could generate hundreds or thousands of addresses, but then it needs a practical way to distribute and manage them.

BIP 47 approaches the problem differently.

What Is a Reusable Payment Code?

A payment code is a special piece of information derived from a hierarchical deterministic wallet.

It can be shared publicly.

Unlike a normal Bitcoin address, it is not simply a destination where someone sends coins.

Instead, it allows compatible wallets to establish the information needed to derive unique payment addresses between participants.

Think of it as a reusable payment identity.

For example:

Alice publishes her payment code.

↓

Bob obtains Alice’s payment code.

↓

They perform a notification process.

↓

Bob can derive unique payment destinations for payments to Alice.

The payment code stays reusable while the underlying payment addresses can change.

This is the key idea behind BIP 47.

Payment Code vs Bitcoin Address

This distinction is extremely important.

A Bitcoin address is generally used to identify a destination for a particular payment.

A BIP 47 payment code is more like a reusable payment identifier.

Consider the difference:

Traditional Bitcoin payment

Alice gives Bob:

Bitcoin Address A

Bob sends Bitcoin to Address A.

If Alice gives the same address to everyone, payments become easier to link.

BIP 47

Alice gives Bob:

Payment Code A

Bob’s wallet uses the payment code to establish the necessary relationship.

Bob can then send payments to unique addresses associated with their interaction.

So:

Bitcoin address = payment destination

BIP 47 payment code = reusable payment identity

That difference is the foundation of the system.

Does a Payment Code Contain Bitcoin?

No.

This is another important distinction.

A payment code does not contain Bitcoin.

It is not a wallet balance.

It is not a private key.

It is not a Bitcoin transaction.

Instead, it contains information derived from an HD wallet that allows compatible wallets to establish payment addresses and shared secrets.

The actual Bitcoin still moves through ordinary Bitcoin transactions.

The payment code simply helps determine where those payments should go.

How Does BIP 47 Relate to HD Wallets?

BIP 47 is specifically designed to work with hierarchical deterministic (HD) wallets.

An HD wallet can derive many keys and addresses from a single master seed according to a defined derivation structure.

BIP 47 uses this capability to create payment-code-related keys and derive unique payment addresses.

The specification defines a derivation structure based on BIP32, BIP43, and BIP44 concepts.

The BIP 47 path begins with a purpose value of:

47′

A simplified version of the structure is:

m / 47' / coin_type' / identity'

The identity level corresponds to a particular payment-code identity within the wallet.

The important point for beginners is that BIP 47 isn’t creating random addresses independently.

The addresses are derived systematically from the wallet’s hierarchical key structure.

What Is the BIP 47 Purpose Field?

You may have seen paths such as:

m/44'/0'/0'

in Bitcoin wallets.

These paths tell an HD wallet how a particular branch of keys should be used.

BIP 47 uses:

47′

as its purpose field.

So the beginning of a BIP 47 derivation path looks like:

m/47'

This tells a compatible wallet that the corresponding subtree is being used according to the BIP 47 payment-code specification.

The specification then defines additional levels for the Bitcoin coin type and payment-code identity.

You don’t normally need to manually type this path.

The wallet handles the derivation.

What Is the Notification Process?

This is one of the most important concepts in BIP 47.

Before Bob can begin making payments to Alice using the reusable payment-code system, Alice and Bob’s wallets need to establish the necessary information.

BIP 47 does this using a notification transaction.

The notification transaction allows the sender to securely communicate the information required for future payment-address derivation.

At a high level:

Alice publishes payment code

↓

Bob obtains payment code

↓

Bob sends notification transaction

↓

Alice detects and processes notification

↓

Bob can send payments using unique addresses

The notification transaction is therefore like an introduction between two compatible wallets.

What Is a Notification Transaction?

A notification transaction is a Bitcoin transaction used to communicate a payment code to the intended recipient in a form that other observers should not be able to interpret as the recipient’s payment code.

For BIP 47 version 1, the notification process involves sending a small amount of Bitcoin to the recipient’s notification address and embedding encrypted or blinded payment-code information in an OP_RETURN output.

This means the blockchain carries the notification information.

However, the payment code itself is not simply published in plain text for everyone to read.

The intended recipient can use information available to their wallet to recover it.

Why Is a Notification Transaction Necessary?

You might ask:

“If Alice already published her payment code, why does Bob need to send a notification transaction?”

The answer is that the wallets need a way to establish the information required for their future payment relationship.

BIP 47 uses elliptic-curve Diffie-Hellman (ECDH) to derive shared secrets.

The notification process allows Bob’s wallet to receive the information needed to recognize the payment-code relationship and derive future payment destinations.

The complicated cryptography happens behind the scenes.

For the user, the concept is simpler:

Notification = establish the private relationship needed for future payments.

What Is ECDH?

ECDH stands for Elliptic Curve Diffie-Hellman.

It is a cryptographic technique that allows two parties to independently calculate the same shared secret using their private and public keys.

Imagine:

Alice has a private key + Bob’s public key

and:

Bob has a private key + Alice’s public key

Both sides can calculate the same underlying secret.

BIP 47 uses this type of key agreement to derive information that allows payment addresses to be generated without simply publishing those addresses in advance.

You don’t need to manually perform ECDH when using BIP 47.

A compatible wallet handles the calculations.

How Are Unique Payment Addresses Created?

After the notification process, the sender can derive a unique payment address for each payment.

Suppose Bob wants to pay Alice three times.

Instead of:

Payment 1 → Address A

Payment 2 → Address A

Payment 3 → Address A

BIP 47 can produce something more like:

Payment 1 → Address A1

Payment 2 → Address A2

Payment 3 → Address A3

These addresses are derived using the payment codes and shared-secret calculations.

Alice’s wallet can derive the corresponding private keys and monitor the blockchain for payments to those addresses.

This reduces the need to reuse one publicly known Bitcoin address.

Why Is This Better for Privacy?

Imagine a business publishes one normal Bitcoin address.

Every customer sends money there.

Anyone looking at the blockchain can see the payments going into that address.

Now imagine the business publishes a BIP 47 payment code.

Customers can use that payment code to establish payment relationships.

The actual payments can then use unique addresses.

An outside observer doesn’t simply see:

Customer A → Same address

Customer B → Same address

Customer C → Same address

Instead, the payments can appear at different addresses.

This can make straightforward payment linking more difficult.

However, BIP 47 does not make Bitcoin transactions completely anonymous.

Blockchain analysis can still use transaction structure, timing, amounts, address relationships, and other information.

Privacy is therefore improved in certain ways, not guaranteed completely.

What Does BIP 47 Actually Hide?

BIP 47 primarily addresses the problem of publicly reusing one receiving address.

It can prevent a recipient from needing to publish the same Bitcoin address for everyone.

This can make it harder for a casual observer to associate multiple incoming payments simply because they all went to one known address.

However, the blockchain remains public.

Transactions still contain information such as:

Inputs
Outputs
Amounts
Transaction times
Script information
Transaction relationships

Therefore, BIP 47 should be understood as a privacy-enhancing payment mechanism, not an anonymity system.

What Is the BIP 47 Payment Flow?

Let’s simplify the complete process.

Step 1: Alice Creates a Payment Code

Her compatible HD wallet derives a BIP 47 payment code.

Step 2: Alice Shares the Payment Code

She can publish or communicate it to someone who wants to pay her.

Step 3: Bob Obtains the Code

Bob’s wallet imports or reads Alice’s payment code.

Step 4: Bob Sends a Notification

Bob’s wallet creates the required notification transaction.

Step 5: Alice’s Wallet Detects It

Alice’s wallet monitors the relevant notification address.

Step 6: The Wallet Establishes the Relationship

The wallets use the payment-code information and cryptographic calculations to derive shared secrets.

Step 7: Bob Sends Bitcoin

For each payment, Bob’s wallet derives a unique payment address.

Step 8: Alice Receives the Payment

Alice’s wallet derives the corresponding private key and recognizes the payment.

The user doesn’t need to understand the underlying elliptic-curve calculations.

The wallet performs them automatically.

Does Alice Need a New Payment Code for Every Payment?

No.

That’s the main point.

The payment code is reusable.

Once the notification process has been completed between Alice and Bob, Bob can make additional payments without sending another notification transaction every time.

The BIP specification describes the ability to make a very large number of payments using the established payment-code relationship.

So instead of:

New address → Share → Pay

over and over again, the relationship can be established once and then reused.

What About Receiving Payments From Many People?

This is where the idea becomes particularly useful.

Imagine Alice is a content creator.

She wants to accept Bitcoin from:

Bob
Charlie
David
Emma

She could publish one BIP 47 payment code.

Each sender can establish the necessary relationship and derive unique payment destinations.

Alice therefore doesn’t need to publish one static Bitcoin address for everyone.

The payment code becomes a reusable public-facing identity, while the actual payment destinations can remain separate.

BIP 47 and Bitcoin Privacy

Bitcoin is often described as anonymous, but that isn’t quite accurate.

Bitcoin transactions are publicly visible.

Addresses do not directly contain your real name, but blockchain activity can sometimes be linked to individuals through exchanges, businesses, public statements, transaction patterns, and blockchain analysis.

This is why address reuse is considered an important privacy problem.

BIP 47 attempts to improve one part of that problem:

Don’t force users to repeatedly expose the same receiving address.

That makes BIP 47 part of the broader history of Bitcoin privacy technologies.

Other approaches include:

Fresh Bitcoin addresses
CoinJoin
Silent Payments
PayJoin
Other transaction privacy techniques

Each approach has different properties and trade-offs.

BIP 47 Is Not the Same as Silent Payments

This distinction will become particularly important when comparing modern Bitcoin privacy technologies.

BIP 47 uses reusable payment codes and notification transactions.

Silent Payments use a different mechanism that allows recipients to publish a reusable payment identifier without requiring the same kind of notification transaction.

In simplified terms:

BIP 47

Reusable payment code → Notification → Unique payment addresses

Silent Payments

Reusable payment identifier → Sender derives recipient-specific output → No traditional BIP 47 notification transaction

Both aim to improve receiving privacy, but they work differently.

We’ll compare them in much more detail in Part 3.

Why BIP 47 Is Important

BIP 47 represents an important idea in Bitcoin’s development:

A payment identity doesn’t have to be the same thing as a payment address.

That distinction is easy to overlook.

A payment identity can be reusable.

The actual payment destination can change.

This creates a better separation between:

How someone identifies you

and:

Where a particular Bitcoin payment is received

That concept remains important when understanding newer Bitcoin payment technologies.

How Does a BIP 47 Payment Actually Work?

Let’s use Alice and Bob to understand the process.

Suppose Bob wants to receive Bitcoin from Alice.

Bob has a BIP 47 payment code.

Alice obtains Bob’s payment code through some communication channel.

The process then looks roughly like this:

Bob publishes payment code

↓

Alice imports Bob’s payment code

↓

Alice sends notification transaction

↓

Bob’s wallet detects notification

↓

Both wallets derive shared information

↓

Alice sends Bitcoin to a unique derived address

↓

Bob’s wallet recognizes the payment

The notification happens before the first payment.

After that, the same relationship can support additional payments without requiring another notification transaction for every payment.

Step 1: The Payment Code Comes From an HD Wallet

BIP 47 builds on the same general hierarchical structure used by modern HD wallets.

The BIP defines the path:

m / purpose' / coin_type' / identity'

For BIP 47, the purpose field is:

47'

The identity level produces an extended public key and its corresponding private key. The extended public key, together with additional metadata, forms the payment code.

For Bitcoin, a simplified example is:

m / 47' / 0' / 0'

The important thing to understand is that the payment code isn’t an independently generated random string.

It is connected to a wallet’s hierarchical key structure.

That allows the wallet to derive additional keys and addresses in a predictable way.

What Does a Payment Code Contain?

A BIP 47 payment code contains an extended public key and associated metadata.

In version 1, its serialized structure includes:

A version byte
A feature bit field
A public-key prefix/sign byte
The public key’s x-coordinate
A 32-byte chain code
Reserved space for future expansion

When presented to users, the payment code is intended to use Base58Check encoding. The version byte specified by BIP 47 produces a payment code beginning with the letter P in its serialized form.

You normally don’t need to understand or manually decode these fields.

A compatible wallet handles them automatically.

What Is the Notification Address?

Before the first payment, the sender needs to notify the recipient.

BIP 47 uses a special notification address for this purpose.

The notification address is derived from the recipient’s payment code.

The sender creates a notification transaction that sends a small amount of Bitcoin to this address.

This transaction serves two purposes:

It alerts the recipient’s wallet that a payment-code interaction is being established.
It provides the information required for the recipient to recover and use the sender’s payment-code information.

The notification transaction is therefore not the normal payment itself.

Think of it as an introduction.

What Is an OP_RETURN Output?

You may have encountered OP_RETURN in our earlier Bitcoin article.

OP_RETURN allows a transaction to carry a small amount of data that isn’t intended to represent spendable Bitcoin.

BIP 47 uses an OP_RETURN output as part of its notification mechanism.

For version 1, the notification transaction includes an 80-byte OP_RETURN payload containing the payment-code information in a protected form.

This is important because the payment code isn’t simply placed on the blockchain as readable text.

Instead, the sender transforms the relevant information using a shared secret before placing it into the transaction.

Why Doesn’t Everyone See the Payment Code?

Bitcoin’s blockchain is public.

So if a notification transaction contains information related to a payment code, you might ask:

“Can’t everyone just read it?”

Not directly.

BIP 47 uses cryptographic blinding.

The sender and recipient independently calculate the same secret using ECDH.

That shared secret is then used to transform parts of the payment code before the information is placed into the OP_RETURN output.

The recipient can reverse the process because the recipient possesses the necessary private key.

Someone who doesn’t have the corresponding secret cannot simply interpret the protected payment-code information.

This is one of the central cryptographic ideas behind BIP 47.

What Is ECDH?

ECDH stands for:

Elliptic Curve Diffie-Hellman

It is a method for allowing two parties to calculate a shared secret using public and private keys.

Imagine Alice has:

Alice’s private key

and Bob has:

Bob’s public key

Alice can calculate a shared secret from them.

Bob can independently calculate the same shared secret using:

Bob’s private key

and:

Alice’s public key

The result is the same secret.

An observer watching the blockchain can see the public information, but doesn’t automatically have the private keys required to reproduce the secret.

BIP 47 uses this concept several times throughout its protocol.

How Does the Notification Transaction Protect the Payment Code?

The process can be simplified like this.

Suppose Alice wants to notify Bob.

Alice’s wallet:

Selects a private key associated with the notification transaction.
Uses Bob’s notification public key.
Calculates an ECDH shared secret.
Uses that secret to create a blinding factor.
Applies the blinding factor to parts of Bob’s payment code.
Places the resulting data into the OP_RETURN output.

Bob’s wallet then performs the corresponding calculation using Bob’s private key and Alice’s public key.

Because both sides arrive at the same shared secret, Bob can reverse the transformation and recover the payment code.

The technical specification describes this process in detail.

What Happens When Bob Detects the Notification?

Bob’s wallet monitors the blockchain for transactions sent to his notification address.

When it finds a potential notification transaction, the wallet examines the transaction.

For BIP 47 version 1, the specification describes looking for a standard OP_RETURN output with the expected payload structure.

The wallet then uses:

Bob’s notification private key
The designated public key from the sender’s transaction
The relevant transaction outpoint

to calculate the same shared secret.

It can then unblind the payment-code information.

If the recovered public-key information is valid, the wallet accepts the payment code.

Why Does the Transaction Need a Designated Public Key?

This is one of the more technical parts of BIP 47.

The sender’s notification transaction needs to expose a public key that can participate in the ECDH calculation.

BIP 47 calls this the designated public key.

The specification defines several standard transaction forms from which compatible wallets can identify this public key, including P2PK, P2PKH, bare multisig, and certain P2SH-spending scripts.

You don’t normally need to identify this key manually.

The wallet does it automatically.

What Is the Shared Secret Used For?

The shared secret isn’t simply used to decrypt a message.

BIP 47 uses it to derive information needed to generate unique payment addresses.

This is where the system becomes particularly interesting.

Once the sender knows the recipient’s payment code and the notification process has established the relationship, the sender can derive a new payment address for each payment.

The recipient can independently calculate the corresponding address.

Neither side needs to publish that address ahead of time.

How Does BIP 47 Create Unique Addresses?

Suppose Alice wants to send Bob Bitcoin.

Alice’s wallet selects:

A key from Alice’s payment-code identity
An unused public key derived from Bob’s payment code

The wallets then calculate a shared secret using ECDH.

That secret is converted into a scalar value.

The scalar is then used with Bob’s public key to derive a new public key.

Conceptually:

Bob’s payment-code key + shared secret → unique payment key

The resulting public key is then converted into a Bitcoin payment address.

The specification describes these calculations using elliptic-curve operations on secp256k1, the same elliptic curve used throughout Bitcoin’s key system.

Why Does Each Payment Get a Different Address?

The protocol uses a different key index for successive payments.

Imagine Alice pays Bob three times.

Her wallet can derive:

Payment 1 → Unique Address A

Payment 2 → Unique Address B

Payment 3 → Unique Address C

Bob’s wallet can independently calculate the same sequence.

As a result, Alice doesn’t need to ask Bob:

“What’s your Bitcoin address?”

before every payment.

The payment relationship already provides the information required to derive the next destination.

What Does Bob’s Wallet Do?

Bob’s wallet needs to watch for the addresses that Alice could generate.

After receiving the notification, Bob’s wallet calculates a range of possible payment addresses.

This is known as a lookahead window.

For example, the wallet might generate a number of possible addresses ahead of time and monitor the blockchain for activity.

If Alice sends Bitcoin to one of those addresses, Bob’s wallet recognizes it as belonging to the BIP 47 payment relationship.

This is similar to the way HD wallets can derive and monitor sequences of addresses.

What Is a Lookahead Window?

A lookahead window is simply a group of addresses that a wallet checks in advance.

Imagine Bob’s wallet calculates:

Address 0

Address 1

Address 2

…

Address 20

The wallet watches these addresses.

If Alice makes a payment to Address 5, Bob’s wallet discovers it.

The wallet can then continue deriving addresses beyond that point.

This lets the recipient detect payments without having to calculate every possible address in advance.

The exact implementation can vary between wallets.

What Happens When Bob Receives Bitcoin?

Bob’s wallet already knows how to derive the corresponding private key for each potential payment address.

When it detects an incoming transaction:

It identifies the derived address.
It identifies the corresponding key index.
It derives the required private key.
It adds the received Bitcoin to the wallet’s available funds according to its normal wallet rules.

From the user’s perspective, it can look like a normal Bitcoin payment.

The complexity remains behind the scenes.

What About Refunds?

BIP 47 also considers the reverse direction.

Suppose Alice sends Bitcoin to Bob.

Bob wants to send Alice a refund.

Bob cannot simply assume that Alice’s payment code relationship works in the opposite direction.

The specification requires Bob to send a notification transaction to Alice before the first time Bob sends funds to Alice, even if Bob has previously received payments from her.

Once the notification relationship exists, Bob can use the same general payment mechanism in reverse.

This is important for businesses.

A merchant may receive a payment from a customer and later need to send a refund.

The protocol therefore has a defined method for handling that situation.

What Are BIP 47 Version 1 and Version 2?

BIP 47 defines two versions.

Version 1

Version 1 uses:

P2PKH payment addresses

and a notification method based on a dedicated notification address.

Version 2

Version 2 also uses:

P2PKH payment addresses

but changes the notification mechanism.

Instead of creating the notification-address output used by version 1, version 2 uses a special multisig notification change output and a payment-code identifier.

Wallets with bloom-filter capabilities are recommended by the specification to create version 2 payment codes rather than version 1.

The two versions are designed to remain interoperable under the conditions described by the specification.

For beginners, the key takeaway is simply:

BIP 47 has more than one notification mechanism.

Why Does Version 2 Matter?

The biggest difference isn’t the basic idea of payment codes.

The core concept remains the same:

Reusable payment identity → cryptographic relationship → unique payment addresses

The major difference is how wallets discover notification transactions.

Version 1 relies on a notification address.

Version 2 uses a payment-code identifier in a multisig output and allows wallets using bloom filtering to detect relevant transactions.

This changes how the notification information appears on-chain and how the recipient’s wallet searches for it.

Are BIP 47 Notification Transactions Private?

Not completely.

This is one of the most important limitations to understand.

The notification transaction is visible on Bitcoin’s public blockchain.

Even though the payment-code information is protected cryptographically, the existence and structure of the notification transaction can still create an on-chain footprint.

Observers may be able to identify that a particular transaction has characteristics associated with the protocol.

Therefore:

BIP 47 improves certain aspects of payment privacy, but it does not make the notification process invisible.

This becomes especially important when comparing BIP 47 with newer approaches such as Silent Payments.

What Happens to the Bitcoin Sent to the Notification Address?

The notification transaction sends a small quantity of Bitcoin to the notification address.

That Bitcoin creates an important privacy consideration.

The BIP specifies that funds received through notification addresses should not simply be treated like ordinary spendable balance.

For example, the specification says these outputs should not be displayed as part of the user’s spendable balance and should not be used as inputs for transactions involving ECDH calculations with the user’s payment codes.

Why?

Because spending those outputs carelessly could create blockchain links that weaken the privacy BIP 47 is trying to provide.

Some implementations may instead mix those funds or otherwise handle them separately.

What Is Change-Output Privacy?

Another subtle issue involves change from notification transactions.

Suppose a notification transaction contains:

Input → Notification output + Change

If the change is later spent carelessly, blockchain observers may be able to connect the notification transaction with another transaction.

That can reveal information about the relationship between participants.

The BIP specifically warns about this and recommends privacy-preserving handling of notification-transaction change.

This demonstrates an important lesson about Bitcoin privacy:

Using a privacy feature correctly matters just as much as using the feature itself.

What Happens If You Restore Your Wallet?

Wallet recovery is another complicated part of BIP 47.

A normal Bitcoin wallet can often be restored from a seed phrase by deriving its addresses again.

BIP 47 adds another layer.

The wallet also needs information about previous payment-code relationships and address indexes.

The specification explains that recovering a BIP 47 wallet may require scanning notification transactions and regenerating relevant derived addresses.

A fully indexed blockchain source may be required during recovery to reconstruct all of the necessary information.

This means a seed phrase alone may not be enough for a seamless BIP 47 recovery experience.

The wallet also needs to reconstruct the relevant payment-code metadata.

Why Is Metadata Important?

Suppose Alice has used BIP 47 to interact with ten different people.

Her wallet needs to know things such as:

Which payment codes she has interacted with
Which payment index comes next
Which addresses have already been derived
Which ephemeral payment codes have been used

This information helps the wallet continue the address sequence without accidentally reusing an address.

The BIP specifically identifies metadata that wallets need to maintain for proper operation.

This is one reason BIP 47 wallets need careful implementation.

Can You Use the Same BIP 47 Wallet on Multiple Devices?

You have to be careful.

The BIP specification warns that payment-code wallets generally should not be shared between multiple devices unless the necessary metadata is synchronized.

Why?

Imagine two devices independently believe the next payment address is:

Address #25

Both could potentially derive or use the same address.

That could create address reuse.

Therefore, a BIP 47 wallet needs to keep its payment-code metadata synchronized when operating across multiple devices.

This is a good example of how advanced Bitcoin features can introduce additional wallet-management requirements.

What About Cold Storage?

BIP 47 can also work with cold-storage setups, but the process becomes more complicated.

An offline wallet cannot continuously scan the blockchain.

A separate online component can monitor the blockchain for notification transactions and incoming payments.

The offline device can then generate the necessary public keys, which the online component uses for monitoring.

This resembles the broader architecture used by watch-only wallets.

However, BIP 47 recovery and monitoring require additional metadata and address-generation logic.

Can BIP 47 Hide the Sender’s Identity?

BIP 47 primarily focuses on protecting the recipient’s payment identity.

However, the specification also describes a mechanism involving ephemeral payment codes for users who don’t want a particular payment to be associated with their normal payment-code identity.

An ephemeral payment code can be used for a single outgoing payment.

This provides another layer of privacy for certain use cases.

However, users should not assume that this makes the entire transaction anonymous.

Bitcoin transactions remain publicly observable.

BIP 47’s Biggest Strength

The strongest idea behind BIP 47 is its separation of:

Public payment identity

from:

Individual payment addresses

A business could theoretically publish one reusable payment code.

Customers could use that code repeatedly.

Yet the underlying Bitcoin payments can use different derived addresses.

That solves an important usability problem:

How can someone give you a permanent way to pay without permanently exposing one Bitcoin address?

BIP 47 provides one answer.

BIP 47’s Biggest Weakness

The major trade-off is complexity.

Compared with simply generating a new Bitcoin address, BIP 47 requires:

Payment codes
Notification transactions
ECDH calculations
Address derivation
Blockchain monitoring
Lookahead management
Metadata
Careful notification-transaction handling

There is also an on-chain notification footprint.

Therefore, BIP 47 isn’t simply:

“Use this new type of Bitcoin address.”

It is an entire payment protocol layered on top of Bitcoin.

BIP 47 vs Normal Bitcoin Addresses

Feature	Normal Bitcoin Address	BIP 47
Reusable identity	Limited	Yes
Unique payment addresses	Wallet-dependent	Yes
Notification process	No	Yes
HD wallet integration	Common	Required by design
Address reuse concerns	High if reused	Reduced
On-chain notification	No	Yes
Cryptographic relationship	No	Yes
Wallet complexity	Lower	Higher

The key difference is that a normal Bitcoin address is primarily a destination, while a BIP 47 payment code acts as a reusable payment identity.

BIP 47 vs Silent Payments

BIP 47 and Silent Payments are related in their goals, but they use different designs.

BIP 47:

Payment code → Notification → Derived payment address

Silent Payments:

Reusable payment identifier → Sender derives recipient-specific output

The major difference is that Silent Payments were designed to avoid the traditional BIP 47 notification transaction.

That can remove an important on-chain communication step.

However, Silent Payments also introduce their own technical requirements, including recipient scanning and different address-derivation rules.

So newer doesn’t necessarily mean simpler.

It means the trade-offs are different.

The Bigger Picture

BIP 47 is an interesting example of Bitcoin development moving beyond the simple idea of:

“Send Bitcoin to an address.”

Modern Bitcoin wallets can involve:

HD key derivation
Payment codes
Multisignature wallets
Output descriptors
PSBTs
Silent Payments
Miniscript
Script policies

BIP 47 fits into this larger evolution.

The goal isn’t to change Bitcoin’s basic transaction model.

Instead, it uses cryptographic techniques and wallet software to improve how users interact with that model.

What Are the Advantages of BIP 47?

BIP 47 offers several interesting benefits.

1. Reusable Payment Identity

The biggest advantage is right in the name.

A payment code can be reused.

You don’t have to publish a new Bitcoin address every time someone wants to pay you.

This makes the system more practical for people who want a permanent Bitcoin payment identity.

2. Reduces Address Reuse

Traditional Bitcoin address reuse can make payments easier to connect.

BIP 47 instead allows compatible wallets to derive different payment addresses.

For example:

Payment 1 → Address A

Payment 2 → Address B

Payment 3 → Address C

This reduces the simple blockchain link created when multiple payments go directly to the same address.

3. Useful for Recurring Payments

BIP 47 can make sense when two parties expect to transact repeatedly.

For example:

Customer and merchant
Donor and nonprofit
Freelancer and client
Business and supplier
Family members
Regular Bitcoin users

Instead of exchanging a new address every time, the payment-code relationship can be reused.

4. Works With HD Wallets

BIP 47 builds on hierarchical deterministic wallet technology.

This means compatible wallets can derive large numbers of payment keys from a structured wallet hierarchy.

Users don’t have to manually create and manage every address.

The wallet handles the derivation.

5. Can Be Shared Publicly

A payment code is designed to be reusable and publicly shareable.

This makes it possible to put a payment identity on:

A website
A business profile
A donation page
Printed material
A QR code
A payment request

The user doesn’t need to expose one permanently reused Bitcoin receiving address.

What Are the Disadvantages of BIP 47?

BIP 47 isn’t a perfect solution.

It introduces several trade-offs.

1. Notification Transactions Add On-Chain Activity

This is probably the most important limitation.

The sender needs to create a notification transaction before the payment relationship can be used.

That means additional blockchain activity.

Bitcoin Design describes this as one of the major downsides of payment codes: users need an additional on-chain transaction when establishing the relationship.

This can mean:

Additional transaction fees
Additional blockchain footprint
Additional waiting time
More wallet complexity

For someone making only one payment, this can feel inefficient.

2. The Notification Is Not Completely Invisible

BIP 47 protects the payment-code information cryptographically, but the notification transaction itself still appears on Bitcoin’s public blockchain.

Observers can see the transaction and its structure.

Therefore, BIP 47 shouldn’t be described as completely anonymous.

It is better understood as a privacy-enhancing payment system.

Bitcoin remains a transparent public ledger.

3. Wallets Must Scan the Blockchain

The recipient’s wallet needs to detect notification transactions and later identify payments to derived addresses.

That requires additional scanning and wallet logic.

This can be more demanding than monitoring a conventional Bitcoin address.

The complexity becomes particularly important for lightweight wallets and mobile devices.

4. Wallet Metadata Matters

BIP 47 isn’t simply a matter of restoring a seed phrase and forgetting everything else.

The wallet needs information about payment-code relationships, address indexes, and related state.

If that information isn’t properly preserved or reconstructed, wallet recovery can become more complicated.

This is one reason implementations need to handle BIP 47 carefully.

5. Not Every Wallet Supports It

A payment code only works if the sender and recipient use compatible software.

A normal Bitcoin wallet may not understand BIP 47 payment codes.

That creates an adoption problem.

A Bitcoin address is widely understood.

A BIP 47 payment code requires specific wallet support.

6. The System Is More Complicated Than Normal Addresses

Compare:

Normal payment

Receive address → Send Bitcoin

with:

BIP 47

Payment code → Notification → Shared secret → Address derivation → Blockchain scanning → Payment

The second system provides additional functionality, but it also requires more moving parts.

For beginners, that complexity can be a barrier.

Is BIP 47 Anonymous?

No.

This is an important distinction.

BIP 47 can improve privacy, but it does not make Bitcoin anonymous.

The Bitcoin blockchain remains public.

Transactions can still potentially be analyzed using:

Transaction amounts
Timing
Inputs
Outputs
Address relationships
Spending patterns
Exchange records
Publicly known identities
Blockchain-analysis techniques

BIP 47 mainly addresses the problem of repeatedly exposing one receiving address.

It should therefore be described as a privacy-enhancing technology, not an anonymity guarantee.

BIP 47 vs Bitcoin Address

The simplest comparison looks like this:

Feature	Bitcoin Address	BIP 47 Payment Code
Main purpose	Receive Bitcoin	Establish reusable payment identity
Reusable	Technically possible, but not recommended for privacy	Yes
Unique addresses	Depends on wallet usage	Derived for payments
Notification	No	Yes
Additional transaction	No	Yes
Wallet complexity	Low	Higher
Privacy from address reuse	Limited if reused	Improved
Blockchain remains public	Yes	Yes

The fundamental difference is:

A Bitcoin address is a destination.

A BIP 47 payment code is a reusable payment identity.

BIP 47 vs CoinJoin

BIP 47 and CoinJoin solve different privacy problems.

BIP 47 focuses on receiving Bitcoin without repeatedly exposing the same payment address.

CoinJoin combines transactions from multiple users to make transaction relationships harder to determine.

For example:

BIP 47:

How can someone pay me without repeatedly using my public address?

CoinJoin:

How can transaction history become harder to associate with specific ownership?

They are therefore not direct competitors.

They can address different parts of Bitcoin transaction privacy.

BIP 47 vs Silent Payments

This is probably the most important comparison for modern Bitcoin users.

Both systems allow a recipient to publish a reusable payment identifier while avoiding simple address reuse.

However, their designs are different.

BIP 47

Payment code

↓

Notification transaction

↓

Shared secret

↓

Unique payment addresses

Silent Payments

Static payment identifier

↓

Sender derives recipient-specific output

↓

Unique on-chain payment output

Silent Payments were specifically designed to avoid the need for a BIP 47-style notification transaction. Current documentation describes them as a way to receive privately through a static identifier without requiring additional on-chain notification.

However, Silent Payments introduce their own trade-offs.

The recipient needs to scan blockchain data to identify payments.

That can require more work from the receiving wallet and supporting infrastructure. Current Silent Payments tooling is actively focused on improving scanning and indexing for lightweight wallets.

So the trade-off can be summarized as:

BIP 47: notification transaction, then efficient ongoing payment derivation.

Silent Payments: no traditional notification transaction, but more demanding recipient-side scanning.

Is Silent Payments Better Than BIP 47?

For many modern privacy-focused receiving scenarios, Silent Payments offer an attractive design because they remove the separate notification transaction.

But that doesn’t automatically make BIP 47 useless.

BIP 47 remains historically important because it established the idea of separating a reusable payment identity from individual payment addresses.

It also demonstrates an important Bitcoin design trade-off:

Moving communication off-chain can reduce blockchain overhead, but it can increase wallet-side computation and scanning requirements.

Silent Payments take a different approach to this problem.

BIP 47 vs BIP 353

BIP 353 addresses another part of the payment experience.

BIP 47 gives users a reusable payment code.

BIP 353 allows users to associate a human-readable Bitcoin payment name with payment instructions using DNS and DNSSEC.

For example, a human-readable name can be much easier to communicate than a long cryptographic identifier.

They can therefore be thought of as solving different problems:

BIP 47 → Reusable payment privacy

BIP 353 → Human-readable payment identification

These technologies can conceptually complement one another rather than directly compete.

Can BIP 47 Be Used for Donations?

Yes.

Donations are one of the situations where reusable payment identifiers can be useful.

Imagine a nonprofit publishes a payment code on its website.

A donor can use a compatible wallet to establish the payment relationship.

Future donations can then use derived payment addresses rather than sending every donation to one publicly reused address.

This can improve the organization’s receiving privacy.

However, compatibility remains important.

If the donor’s wallet doesn’t support the payment-code format, the organization may need to provide another payment option.

Can Businesses Use BIP 47?

In theory, yes.

A business could publish a reusable payment code on:

Its website
Invoices
Payment pages
Printed material
QR codes
Customer documentation

Customers with compatible wallets could then use the payment-code system.

However, businesses need to consider wallet compatibility and user experience.

A payment system is only useful if customers can actually use it.

For this reason, businesses may want to support multiple payment methods instead of relying on BIP 47 alone.

What About Bitcoin Donations and Public Figures?

A public Bitcoin address can create significant privacy issues for individuals who receive many payments.

A reusable payment mechanism can help separate the public-facing payment identity from individual payment destinations.

For example, someone could publish a payment identifier on a website rather than repeatedly publishing the same Bitcoin address.

However, public payment identities still need careful security management.

A compromised website or social account could potentially redirect users to a fraudulent payment destination.

Users should always verify payment information before sending Bitcoin.

Is BIP 47 Still Relevant Today?

Yes, but its role has changed.

BIP 47 introduced an important concept for reusable private payment identities.

However, Bitcoin’s payment ecosystem has continued to evolve.

Newer technologies such as Silent Payments address similar receiving-privacy goals without using the traditional BIP 47 notification mechanism.

Bitcoin Design currently describes payment codes as a static payment-request format based on BIP 47 and notes that they have been used in wallets such as Sparrow and historically Samourai.

At the same time, Silent Payments development continues to focus on improving wallet scanning and infrastructure.

So BIP 47 is best understood as part of the evolution of Bitcoin payment privacy rather than the final answer to the problem.

What Can We Learn From BIP 47?

BIP 47 teaches an important lesson:

A reusable payment identity does not have to be the same thing as a reusable Bitcoin address.

That’s a surprisingly powerful idea.

A user might want people to know:

“This is where you can pay me.”

But they don’t necessarily want everyone to know:

“This exact blockchain address belongs to me forever.”

BIP 47 separates those two concepts.

That idea has influenced the broader development of privacy-focused Bitcoin payment systems.

Common BIP 47 Questions

What does BIP 47 stand for?

BIP 47 stands for Bitcoin Improvement Proposal 47. Its title is Reusable Payment Codes for Hierarchical Deterministic Wallets.

What is a BIP 47 payment code?

It is a reusable payment identifier derived from an HD wallet that allows compatible wallets to establish a relationship and derive unique payment addresses.

Is a BIP 47 payment code a Bitcoin address?

No.

A payment code is not itself the destination for ordinary Bitcoin payments.

It is used to establish the information needed to derive payment destinations.

Does BIP 47 prevent address reuse?

It can greatly reduce the need to reuse one publicly known receiving address.

However, correct wallet implementation and usage still matter.

Does BIP 47 make Bitcoin anonymous?

No.

It improves certain aspects of receiving privacy but does not make Bitcoin transactions completely anonymous.

What is a BIP 47 notification transaction?

It is a Bitcoin transaction used to establish the payment-code relationship between compatible wallets.

Does BIP 47 require an on-chain notification?

Yes. This is one of the major differences between BIP 47 and Silent Payments.

Does BIP 47 use OP_RETURN?

Yes. BIP 47 notification transactions use OP_RETURN as part of the notification mechanism.

Does BIP 47 use ECDH?

Yes.

Elliptic Curve Diffie-Hellman is used to establish shared cryptographic information between the participants.

Can BIP 47 be used for recurring payments?

Yes.

Once the relationship has been established, compatible wallets can derive multiple payment addresses for subsequent payments.

Can BIP 47 be used for donations?

Yes.

A public payment identity can be useful for organizations, creators, and individuals receiving recurring Bitcoin payments.

Does BIP 47 work with every Bitcoin wallet?

No.

The wallet needs to support the payment-code protocol.

Always check wallet compatibility before sending funds.

What happens if I lose my wallet?

Recovery depends on the wallet implementation and preserved payment-code metadata.

A BIP 47 wallet may need to reconstruct previous payment relationships and scan for relevant transactions.

Is BIP 47 better than a normal Bitcoin address?

It depends on the goal.

For a simple one-time payment, a normal Bitcoin address is much simpler.

For a reusable payment identity with improved receiving privacy, BIP 47 provides additional functionality.

Is BIP 47 better than Silent Payments?

Not necessarily.

They use different designs.

BIP 47 relies on notification transactions, while Silent Payments remove that traditional notification step but require more recipient-side scanning.

The Bottom Line

What is BIP 47?

BIP 47 is a Bitcoin payment protocol that introduces reusable payment codes.

Instead of publishing one Bitcoin address and repeatedly receiving payments there, a user can publish a payment code that compatible wallets use to derive unique payment addresses.

The process uses HD wallet derivation, cryptographic shared secrets, and a notification transaction to establish the relationship.

Its biggest advantage is straightforward:

One reusable payment identity can support many payments without requiring the same Bitcoin address to be reused.

However, BIP 47 also has important limitations.

The notification transaction adds blockchain activity and cost. Wallets need additional scanning and metadata. Compatibility isn’t universal. And the protocol does not make Bitcoin anonymous.

That’s why newer technologies such as Silent Payments are important.

Silent Payments pursue a similar goal while eliminating the traditional BIP 47 notification transaction, although they introduce their own scanning and implementation challenges.

The broader lesson is more important than any individual protocol:

Bitcoin privacy isn’t just about hiding transactions. It’s also about avoiding unnecessary links between a person’s identity and their payment history.

BIP 47 was an important step toward that goal.