BIP-47 (Reusable Payment Codes)

What Is BIP-47?

BIP-47, formally titled "Reusable Payment Codes for Hierarchical Deterministic Wallets," is a Bitcoin protocol proposed by Justus Ranvier in April 2015. It defines a technique for creating a payment code that can be publicly advertised and linked to a real-world identity without sacrificing the privacy of individual transactions. Each payment code is an 80-byte structure encoded in Base58Check with the prefix "PM8T" that looks like a long Bitcoin address.

The core problem BIP-47 solves is straightforward: if you publish a single Bitcoin address on your website or social profile, anyone who pays you reuses that address. On-chain observers can trivially link all incoming payments to the same recipient and estimate their total balance. BIP-47 payment codes give recipients a static identifier they can share freely while ensuring every sender derives a unique address for each payment, preserving privacy on the public blockchain.

The protocol builds on hierarchical deterministic (HD) wallets defined in BIP-32, using a dedicated derivation path (m/47'/0'/account') to generate keys specifically for the payment code scheme. Both sender and receiver can deterministically regenerate all shared addresses from their respective seed phrases, ensuring funds are recoverable even after a full wallet restore.

How It Works

BIP-47 uses a two-phase process: a one-time notification transaction to establish a communication channel, followed by an unlimited sequence of private payments.

Phase 1: Notification Transaction

Before Alice can pay Bob using his payment code, she must send a notification transaction. This is an on-chain Bitcoin transaction that tells Bob's wallet to start watching for payments from Alice:

1. Alice selects a UTXO and obtains its private key (a) and corresponding public key (A)
2. Alice extracts Bob's notification public key (B) from his payment code, derived at index 0
3. Alice computes a shared secret using ECDH: S = a * B (her private key multiplied by Bob's public key on the secp256k1 curve)
4. Alice derives a 64-byte blinding factor: s = HMAC-SHA512(x_coordinate_of_S, outpoint)
5. Alice XORs her payment code's public key and chain code with the blinding factor, encrypting her identity
6. Alice broadcasts a transaction with three outputs: an OP_RETURN containing the 80-byte blinded payload, a dust output (546 satoshis) to Bob's notification address, and a change output

Bob's wallet monitors his notification address. When it detects the incoming transaction, it extracts Alice's public key from the input, computes the same shared secret (S = b * A), derives the identical blinding factor, and decrypts Alice's payment code. The ECDH property guarantees both parties arrive at the same shared secret from their respective private keys.

Phase 2: Deriving Payment Addresses

After notification, Alice can generate unique addresses for Bob without further interaction:

1. For the nth payment, Alice computes a shared secret point using her notification private key and Bob's nth public key from his payment code
2. Alice derives a scalar from the x-coordinate of the shared secret point
3. The payment public key is Bob's nth public key offset by this scalar times the generator point
4. Alice sends funds to the resulting address

Bob independently derives the same addresses using his own private keys. No on-chain observer can link these payment addresses to Bob's payment code because the derivation depends on the shared secret, which only Alice and Bob can compute.

Payment Code Structure

A BIP-47 payment code is an 80-byte binary structure:

Byte 0:      Version (0x01 for v1)
Byte 1:      Feature flags
Bytes 2:     Sign byte (0x02 or 0x03, compressed pubkey prefix)
Bytes 3-34:  Public key x-coordinate (32 bytes)
Bytes 35-66: Chain code (32 bytes)
Bytes 67-79: Reserved (13 bytes, zero-filled)

Base58Check encoding uses version byte 0x47
Resulting prefix: "PM8T..."

Example:
PM8TJTLJbPRGxSbc8EJi42Wrber...

PayNym: The User-Facing Implementation

PayNym is the branded user experience built on top of BIP-47 payment codes, originally created by Samourai Wallet. Instead of sharing raw payment codes (which are long and unwieldy), PayNym assigns each payment code a human-readable identifier (like "+shrillsurf491") and a unique robot avatar generated from the code itself.

Wallets that have implemented BIP-47 payment codes include:

• Sparrow Wallet: the leading desktop implementation, with full BIP-47 support for creating and receiving via payment codes
• BlueWallet: added BIP-47 support in version 6.4.1 and made it generally available in v7.0.0
• Stack Wallet: cross-platform mobile wallet with BIP-47 support
• Ashigaru: a community fork of the Samourai Wallet codebase that maintains its own PayNym directory at paynym.rs

The original PayNym directory (paynym.is) was operated by Samourai Wallet and went offline when U.S. federal authorities seized the Samourai domain and servers in April 2024. The founders were arrested, later pled guilty to conspiracy charges related to operating an unlicensed money transmitting business, and were sentenced in late 2025. This event disrupted the centralized lookup service that many BIP-47 wallets relied upon and highlighted a tension in the protocol: a privacy-focused standard had become dependent on centralized infrastructure.

Use Cases

BIP-47 is most useful in scenarios where a recipient needs a persistent, public-facing payment identifier without sacrificing transaction privacy:

• Donations and tips: content creators, open-source developers, and nonprofits can post a single payment code that generates unique addresses per donor, preventing observers from tallying total donations
• Recurring payments: after the initial notification, a sender can make repeated payments to freshly derived addresses without any further coordination from the recipient
• Merchant payments: businesses can publish a payment code instead of generating fresh invoices for every customer, though the notification transaction adds friction for one-time purchases
• Privacy-conscious receiving: users who want to accept Bitcoin without revealing their transaction history to every sender

BIP-47 vs. Silent Payments and BOLT-12

BIP-47 was a pioneering approach to reusable payment identifiers, but newer protocols address its key shortcomings. Understanding the tradeoffs helps clarify where each fits.

Silent Payments (BIP-352)

Silent Payments, proposed by Josie Baker and Ruben Somsen, eliminate the notification transaction entirely. The sender derives a unique Taproot address directly from the recipient's public key and the sender's input keys. The resulting on-chain outputs look like ordinary Taproot transactions with no OP_RETURN, no dust output, and no linkable notification address.

Silent Payments were merged into Bitcoin Core 28.0 and are seen as the successor approach for on-chain payment privacy. For a deeper comparison, see the research on Silent Payments and Bitcoin privacy.

BOLT-12 Offers

BOLT-12 offers serve a similar conceptual role on the Lightning Network: a static, reusable identifier for receiving payments. Instead of on-chain notification transactions, BOLT-12 uses blinded paths and onion messages to negotiate invoices without revealing the recipient's node identity. There is no on-chain footprint at all. However, BOLT-12 operates on Layer 2 and requires Lightning Network connectivity, so it is complementary to rather than a direct replacement for on-chain approaches. For more detail, see the BOLT-12 offers deep dive.

Risks and Considerations

Notification Transaction Costs

Every new sender-recipient pair requires an on-chain notification transaction before any payment can occur. This means the first payment to a new recipient effectively costs two transactions worth of fees plus a 546-satoshi dust output. For one-time payments, this overhead makes BIP-47 significantly more expensive than simply generating a fresh address. The notification also permanently adds an 80-byte OP_RETURN output to the blockchain.

Privacy Limitations of the Notification Address

All senders transmit their notifications to the same notification address derived from the recipient's payment code. An observer who identifies this address can see that multiple parties have established BIP-47 channels with the same recipient, even though individual payment addresses remain unlinkable. The BIP specification itself warns that "incautious handling of change outputs from notification transactions may cause unintended loss of privacy."

Developer Community Reception

BIP-47 received a "Unanimously Discourage for implementation" assessment in the BIP wiki comments system, with prominent Bitcoin developers citing design concerns. Core criticisms included the notification transaction overhead, the notification address linkage issue, and concerns that practical implementations relied on centralized third-party servers for payment code lookups, undermining the protocol's privacy goals.

Ecosystem Fragility

The Samourai Wallet shutdown in 2024 demonstrated a practical risk: the PayNym directory that wallets depended on for resolving human-readable identifiers was a single point of failure. While the BIP-47 protocol itself is decentralized (notification transactions are on-chain), the user-facing ecosystem built around it was not. Community forks like Ashigaru have stood up replacement infrastructure, but the episode underscores the importance of self-custodial and decentralized designs at every layer of the stack.

Version Fragmentation

Although BIP-47 defines versions 1 and 2, and a separate RFC (OBPP-05) specifies versions 3 and 4 with improvements like reduced payload size and SegWit address support, only version 1 has seen real-world wallet adoption. This means the protocol's theoretical improvements (such as eliminating the reused notification address in v2's bloom-multisig approach) remain undeployed in practice.

Why It Matters

BIP-47 was one of the first serious attempts to solve the tension between usability and privacy in Bitcoin payments. The idea that a user could share a single, static code and receive to unique addresses was groundbreaking in 2015, even if the implementation involved tradeoffs that newer protocols have since improved upon.

For builders working on Bitcoin payment infrastructure today, BIP-47 is important context for understanding the design space. The problems it identified (address reuse, interactive address exchange, identity linkage) remain central challenges. Solutions like Silent Payments and BOLT-12 iterate on BIP-47's vision with fewer tradeoffs. Modern address formats and Layer 2 protocols like Spark continue to push Bitcoin privacy and usability forward.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.