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.
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.