Reusable Payment Address

A reusable payment address is a static identifier you can publish once — on a profile, a donation page, an invoice footer, or a printed card — that nonetheless directs each incoming payment to a different, unlinkable on-chain address. It resolves the oldest usability-versus-privacy tension in Bitcoin: a fixed address is wonderfully convenient and a privacy disaster, because every payment piles onto one visible balance and history, while fresh-address-per-payment is private but demands interaction with the payer every single time. A reusable payment address delivers both halves — one identifier, many unlinkable outputs — by moving the "fresh address" step into cryptography instead of conversation.

Why address reuse is the failure mode

Reused addresses are the cheapest target chain analysis has. One lookup reveals total received, spending patterns, and every counterparty who ever paid that address; those payments cluster instantly, no heuristics required, and the cluster feeds wallet clustering across the rest of the user's coins. Publishing a static address is functionally publishing a live, world-readable bank statement. The full pathology is covered under address reuse — a reusable payment address exists to give users the ergonomics they clearly want without that exposure.

Two families of design

Bitcoin has two principal approaches, and the difference is whether establishing the channel requires interaction.

BIP47 payment codes take the interactive route. The recipient publishes a payment code; a first-time sender broadcasts a one-time notification transaction that delivers their blinded code to the recipient. Thereafter both wallets derive a shared ECDH sequence of one-time addresses — the sender always knows the next address to pay, the recipient knows exactly which addresses to watch, and scanning stays cheap. This is the design that PayNyms wrapped in human-friendly handles. Its known wart is the notification transaction itself: an on-chain breadcrumb that a sophisticated observer can read as evidence that some channel between two codes was opened.

BIP352 silent payments remove interaction entirely. The recipient publishes a static sp1... address encoding two keys; a sender derives a unique Taproot output using ECDH between their input keys and the recipient's silent payment scan key, with no notification and no prior contact. On-chain, the payment is indistinguishable from any ordinary Taproot spend. The cost moves to the recipient, who must scan candidate transactions performing ECDH computations to find their money — heavier than BIP47's targeted watching, and the reason light-client support requires extra engineering. The two designs are different points on one curve: BIP47 pays a privacy tax at setup for cheap detection; BIP352 pays a compute tax at detection for a perfectly clean chain footprint.

What it means in practice

For a sovereign Bitcoiner the payoff is direct: accept recurring income, tips, or invoices under one published identifier without leaking a financial profile, without running a payment server, and without coordinating fresh addresses with every payer. A merchant can print one code on packaging; a project can pin one to a repository; a writer can put one in a footer — and none of those payments link to each other on-chain. Wallet support is the practical constraint to check first: BIP47 lives on in a handful of long-standing wallets, BIP352 support has grown steadily since the standard settled, and the two are not interoperable, so publisher and payer must share a standard. The underlying privacy goal both designs serve is output linking resistance: denying observers the ability to connect payments that share a recipient. This is defensive privacy in support of fungibility — every coin equal, every payment its own island — and it turns the most user-hostile rule in Bitcoin hygiene ("never reuse an address") into something the cryptography simply handles for you.