BIP47 payment codes crossed my radar again recently because someone built a very nice website for the concept (#1462400), and if you recall Samourai Wallet had created an address book of sorts for BIP 47 payment codes that they called PayNyms.
This whitepaper proposes BIP47DB: an open protocol for permanently inscribing BIP47 payment codes onto the Bitcoin blockchain itself, creating a decentralised directory that cannot be seized, censored, or lost. The protocol leverages Ordinals inscriptions to store compressed binary batches of payment codes at minimal cost, with full client-side verifiability.
So, why would we need such a thing?
Incoming connections to a BIP47 payment code are recoverable from the blockchain alone. A user who restores their wallet from seed can derive their notification address and scan the blockchain for notification transactions sent to it. Each notification transaction contains the sender’s payment code (encrypted with ECDH), allowing the wallet to reconstruct all incoming payment channels.
Outgoing connections present the problem. When a user sends a notification transaction to a peer, they record which notification address they sent to. However, a notification address alone does not reveal the corresponding payment code. To recover outgoing connections, the wallet must query a directory that maps notification addresses to payment codes. If no such directory is available, the user loses visibility of all outgoing BIP47 payment channels.
If you recall, BIP 47 proposes a two-part construction where a sender broadcasts a notification transaction before actually sending the transaction with the funds. This allows the receiver to easily identify the addresses where their coins are stored. This is especially helpful in the case of a restoring a wallet with BIP 47 payments from a seed backup.
It remains possible to send to a BIP47 payment code in Sparrow without a notification transaction being created under certain circumstances. [14] While this saves the cost of an additional on-chain transaction, it means there is no outgoing notification transaction recorded on the blockchain for the wallet to discover during recovery. If the user subsequently restores their wallet from seed, there is no on-chain evidence that they ever sent payments to that peer’s payment code. The funds are not lost — they remain spendable by the recipient — but the sender’s transaction history becomes incomplete and the outgoing payment channel is invisible to the restored wallet.
The Samourai Wallet solution to this was the PayNyms system operated off a central server they controlled:
This server stored the mapping between payment codes, notification addresses, and PayNym identities. It also tracked “following” relationships between PayNyms, which wallet clients used to recover outgoing BIP47 connections during wallet restoration.
If the server goes down, all the mappings disappear. So, the solution proposed here is to use ordinals, particularly inscriptions, to create an append only, client-side verified database to which anyone can write and use this database for storing payment codes in inscriptions:
This document proposes BIP47DB, an open protocol for inscribing BIP47 reusable payment codes onto the Bitcoin blockchain using Ordinals inscriptions with compressed binary encoding. The protocol creates a decentralised, censorship-resistant, and publicly verifiable directory of payment codes that eliminates single points of failure in the PayNym ecosystem. Anyone may write to the directory, and all entries are client-side verifiable against the secp256k1 curve. We describe the binary encoding format, the inscription structure, cost analysis, a comparison with the Runes protocol, indexer architecture, and integration paths for existing wallets including Ashigaru and Sparrow.
The outgoing channel recovery problem is the real killer and most people miss it. You lose your phone, restore from seed, and suddenly half your transaction history is gone because there's no on-chain breadcrumb pointing back to who you paid.
Using ordinals inscriptions for this is clever but I'm curious about the cost tradeoffs. A single OP_RETURN is 80 bytes, which fits one compressed payment code. But batching multiple codes into an inscription amortizes the overhead across entries. Has anyone run the numbers on what this looks like at scale? If you're indexing say 50,000 payment codes, the inscription approach should be dramatically cheaper per-code than individual notification transactions, especially with witness discount pricing.
The part that concerns me is the append-only nature combined with no revocation mechanism. BIP47 payment codes are derived from your seed, so they don't rotate the way stealth addresses do. But what happens when a wallet gets compromised? The old payment code is permanently inscribed and anyone scanning the directory will still find it. You'd need some kind of tombstone inscription that marks a code as deprecated, signed by the original key, which adds complexity to the indexer.
Samourai's PayNym directory had one accidental advantage here. Being centralized meant they could actually remove compromised entries. The decentralized version trades that for censorship resistance, which is the right call, but the revocation UX needs to be solved before wallets ship this.