Notification Transaction

Notification transaction is the one-time on-chain handshake that bootstraps a BIP47 payment-code relationship. Before a sender can derive private, one-time addresses for a recipient, the recipient's wallet must learn the sender's payment code — without that, the recipient cannot compute the shared secrets that make future payments detectable. The notification transaction conveys that code exactly once. After it confirms, the two parties can transact indefinitely, deriving a fresh address for every payment, with no further on-chain signalling and nothing visible linking the payments to each other.

How the blinding works

The sender directs a small output to the recipient's notification address, which is derived from the 0th public key of the recipient's payment code — it is, by design, publicly known. The payload is the sender's own payment code, but publishing it in cleartext would let any chain observer connect the two identities. So the sender blinds it: they compute an ECDH shared secret between one of their private keys and the recipient's notification public key, expand it into a 64-byte blinding factor via HMAC-SHA512, and XOR both the x-coordinate and the chain code of their payment code with that factor. The blinded result rides in an OP_RETURN output. Only the intended recipient, running the inverse ECDH with their notification private key, can unblind and validate the code. To everyone else, the transaction is a small payment to a reused address carrying 80 bytes of noise.

Privacy hygiene: the one hard rule

The notification transaction is the single place where sender and recipient appear together in public, which makes its change and outputs radioactive. BIP47 therefore mandates that funds received at a notification address must not be spent as inputs to later transactions: doing so would merge that tainted UTXO into the recipient's wallet cluster and re-link the two identities that the entire scheme works to keep separate. Careful sender wallets go further, funding the notification from an input that is not linkable to their main wallet. The lesson generalizes: in privacy protocols, the setup step is usually the weakest link, and discipline around it matters more than the elegance of the steady state.

The trade-off, and what came after

The notification design buys a real prize — after setup, the recipient knows exactly which keys to watch, so detection is instant and requires no heavy scanning. The cost is that the setup itself touches the chain: it costs a fee, it creates a small but permanent on-chain artifact, and the notification address is a fixed, reused point that a sophisticated observer can monitor for activity patterns even without reading any payment code. Newer designs accept the opposite trade. BIP352 silent payments eliminate the notification step entirely — no handshake, no OP_RETURN, no tainted output — in exchange for the recipient continuously scanning the chain for outputs derivable from their scan key. One-time setup cost versus perpetual scanning cost: two honest answers to the same problem of paying a static identifier without creating a public address-reuse trail. Wallets that implement BIP47 handle the blinding and hygiene automatically, but the on-chain footprint remains, and chain-analysis firms catalogue notification patterns for exactly this reason.

Where it fits

The reusable identifier this handshake unlocks is the payment code (BIP47), and the broader goal both generations of protocol pursue — making a recipient's payments mutually unlinkable on-chain — is covered under output linking resistance. For a sovereign Bitcoiner the takeaway is practical: static identifiers you can publish once and receive to forever are a genuine upgrade over address reuse, but every such scheme has a bootstrap story, and understanding yours is part of using it safely.