Payment Code (BIP47)

Payment code is the static identifier at the heart of BIP47, "Reusable Payment Codes for Hierarchical Deterministic Wallets." Technically it is an extended public key with associated metadata, bound to a wallet identity; practically, it is an address you can publish once — printed on a card, pinned to a profile, engraved on a tip jar — from which every payer's wallet derives a brand-new, unlinkable on-chain address for each payment. The code itself never appears on-chain in the clear, so a public observer cannot look up a payment code and tally a balance or scrape a payment history from it. It solves the oldest tension in Bitcoin privacy: addresses must not be reused, but real life keeps demanding one stable thing to publish.

Why address reuse is the enemy

A reused address is a gift to surveillance: every payment to it is trivially linked, its balance is public, and chain-analysis firms cluster it with everything it touches. Yet donation buttons, recurring invoices, and profile tips all want a fixed identifier. Before reusable payment codes, the workarounds were rotating addresses by hand or running a server to dispense fresh ones. BIP47's insight is that the published identifier and the on-chain addresses need not be the same thing — publish a key, derive addresses privately from it, and the linkage stays off-chain where observers cannot see it.

How the cryptography works

The first time Alice pays Bob, her wallet performs elliptic-curve Diffie–Hellman (ECDH) between her payment-code keys and his, producing a shared secret only the two of them can compute. From that secret, both wallets deterministically derive the same sequence of one-time addresses: Bob's public key B is tweaked as B' = B + sG, where s = SHA256(Sx) comes from the x-coordinate of the shared ECDH point — so Alice can compute where to pay, and Bob recovers the matching private key as b' = b + s to spend. Each subsequent payment uses the next index, yielding a fresh address every time. Neither the codes nor the shared secret ever touches the chain; an observer sees only unrelated-looking payments to never-reused addresses.

The notification transaction

The one wrinkle is bootstrapping: Bob's wallet cannot watch for payments from a secret it does not know exists. BIP47 solves this with a one-time notification transaction — Alice sends a small transaction to Bob's published notification address, embedding her payment code (blinded so only Bob can read it) in an OP_RETURN. From then on, both sides derive addresses silently forever. The notification is BIP47's main criticism: it costs a transaction, and payments to a known notification address are themselves visible metadata — an observer can see that someone opened a channel to Bob, though not who, if the sender is careful about the inputs funding it. The friendly identity layer built on top — human-readable names and avatars for payment codes — is covered under PayNym.

Payment codes versus Silent Payments

Silent Payments (BIP352) is the modern successor tackling the same problem with inverted trade-offs: it eliminates the notification transaction entirely — no on-chain bootstrap, no interaction — but requires the recipient to scan blocks doing ECDH against candidate transactions, real computational work that effectively wants a full node. BIP47 pays once on-chain and then detects payments cheaply by watching derived addresses, which suits lightweight wallets. Both descend from the older stealth-address idea, and both serve the same sovereign goal: a Bitcoiner should be able to be findable — payable by anyone, indefinitely — without handing the chain a ledger of everyone who has ever paid them. Publish the code; keep the graph to yourself.