Fifteen years
to remove one message

§ 01 · The four attempts

Everybody pays. The question is who, and in what

Now scale it

One payment costs nothing worth arguing about. The argument only becomes visible when people actually pay you. Drag it.

§ 02 · The record

What happened, and when

1. 31 Oct 2008

   The problem is written down on page eight

   Section 10 of the bitcoin whitepaper, under the heading Privacy: “As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner.” Everything below is an attempt to do that without asking the payer for permission first.

   bitcoin.org/bitcoin.pdf

2. 25 Nov 2009

   Satoshi says it again, in plainer words

   “For greater privacy, it’s best to use bitcoin addresses only once.” Six months later he is on the forum promising to make the client rotate the displayed address automatically. Seventeen years on, address reuse is still near seventy percent.

3. 17 Apr 2011

   ByteCoin invents the trick, on a forum, in nine steps

   A post titled “Untraceable transactions which can contain a secure message are inevitable.” Step one: “The sender performs his side of a Diffie-Hellman key exchange by multiplying the recipient’s public key by his private key.” Step two: use the hash of that point to make a new address.

   It is not quite right yet. Step nine admits it: both the sender and the recipient know the key to that address. But the shape of every scheme that followed is already there, including the scanning loop.

   bitcointalk topic 5965

4. 17 Oct 2013

   CryptoNote makes the same idea mandatory

   One-time addresses, a view key and a spend key, and an ephemeral public key published inside every transaction. Monero launches on this in April 2014 and has never had an address reuse problem, because it was never optional. The whitepaper does not cite ByteCoin. Peter Todd, three months later, does.

5. 6 Jan 2014

   Peter Todd writes it up properly and calls it a stealth address

   He fixes the flaw by adding a nonce keypair, so only the payee can spend, and he is scrupulous about where it came from: “Credit goes to ByteCoin for the original idea.” The price is 40 bytes of OP_RETURN in every single transaction, carrying the nonce.

   Eight days later Gregory Maxwell breaks the bandwidth-saving variant by trial decryption, and Todd calls the whole optimisation “too risky without professional cryptographic review.”

6. 2014 → 2015

   BIP 63 gets a number and never gets a document

   To this day the bitcoin improvement proposal index lists number 63, Stealth Addresses, Peter Todd, status: BIP number allocated. There is no such file. The specification lived in a personal fork, the flagship implementation was Dark Wallet, and Dark Wallet died.

7. 3 Sep 2015

   BIP 47 tries the opposite trade: pay once, not every time

   Reusable payment codes. Instead of overhead on every transaction, one notification transaction per sender-and-receiver pair, carrying a blinded payment code in an 80 byte OP_RETURN. After that, both sides derive addresses privately forever. Samourai Wallet shipped it as PayNyms. Sparrow implemented it too.

   Luke Dashjr objected within weeks, and the objection was the notification address: it is a single static public identifier that every notification lands on, so chain analysis gets an edge from payer to payee permanently, before a single payment is made.

8. 11 Jun 2022

   The post-mortem, written after a conference in Prague

   “BIP47 requires a notification transaction prior to making payments. This transaction takes up on-chain space and can easily leak privacy if not handled with extreme caution. In practice this is quite hard.”

   Alfred Hodler, writing a competing proposal the same summer, was harsher and more specific: notification addresses leave a footprint that “makes it obvious that a particular recipient is going to receive private transactions”, and if the notifier uses coins tied to an identity, “it forever becomes visible that Alice connected with Bob” even though the code itself was blinded.

9. 28 Mar 2022

   Ruben Somsen posts three lines that make the overhead disappear

   To the bitcoin-dev mailing list, under the title “Silent Payments, non interactive private payments with no on-chain overhead”. The whole idea:

   The recipient publishes their silent payment address: X = x*G
   The sender picks an input containing a public key:    I = i*G
   The sender tweaks the address with that input key:    X' = hash(i*X)*G + X
   
   Since i*X == x*I, the recipient can detect the payment.

   There is no nonce to publish, because the sender’s transaction already contains a public key and it is already on the chain. That is the entire difference from 2014, and it is why there is nothing left to pay for.

   The gist went up on 13 March 2022; the mailing list post followed on 28 March.

10. 17 Apr 2022

    Three weeks later there is code

    w0xlt opens a proof of concept against Bitcoin Core. Over the next six months the same developer publishes three more versions, and the fourth one, in October 2022, makes the change that matters for real transactions: tweak with the sum of all input keys rather than one of them, which halves the receiver’s work and opens the door to collaborative transactions.

    Worth correcting, because it is misreported constantly: versions two, three and four were announced by w0xlt, not by Somsen. They are versions of the implementation.

11. 4 Aug 2023

    Peter Todd, back again, with the sharpest objection anyone has made

    He argued silent payment addresses should expire, because “wallets don’t last forever… funds sent to those addresses can be easily lost forever. All Bitcoin addresses have this problem. But at least existing Bitcoin addresses aren’t supposed to be reused. Silent Payments are.”

    The proposal was rejected on the grounds that an attacker could just renew, that recovered keys would miss years of payments, and that heirs would miss an inheritance. There is no expiry field in the standard today. Decide for yourself whether that was right.

12. 10 Feb 2024

    BIP 353 gets its number

    Matt Corallo and Bastien Teinturier, DNS payment instructions. Written for lightning offers first, but the record format takes a bitcoin: URI, so it carries a silent payment address just as happily. The two standards were designed by different people for different reasons and fit together exactly.

13. 8 May 2024

    BIP 352 is merged

    Two years and six weeks after the mailing list post. Authors: josibake, Ruben Somsen, and later Sebastian Falbesoner. Status moves from Draft to Proposed in the same session, on the argument that an implementation already existed.

    The header today reads Assigned: 2023-03-09. That is the old Created field, renamed by a process change in October 2025. It is not the date the number was handed out.

14. 11 Jul 2024

    Payment names ship first, in lightning

    Phoenix 2.3.3 both resolves payment names and hands them out to its users. Zeus follows the next day. On-chain wallets take another fifteen months to catch up.

15. 3 Oct 2025

    Sparrow 2.3.0 makes both standards usable together

    One release adds sending to silent payment addresses, resolving payment names, validating the DNSSEC chain itself, and attaching the proof to the unsigned transaction so a hardware wallet could check it. Receiving arrives in version 2.5.0 on 21 May 2026, with airgapped signers supported.

16. 2 Mar 2026

    The denial of service hole is closed

    Version 1.1.0 caps recipients per group at 2,323, after a measurement showed a single hostile transaction with 23,230 outputs took 165 seconds to scan. Afterwards, 17 seconds. The number is not arbitrary: a transaction with 2,323 taproot outputs is 99,959 vbytes, and one more output breaks the standard relay limit.

17. 3 Aug 2026

    The cryptography reaches a tagged release

    libsecp256k1 0.8.0 ships a silent payments module. Four years and four months after the proposal. Light client scanning is explicitly not included.

18. Today

    Bitcoin Core still ships nothing to users

    Three wallet-level pull requests are open. Two earlier ones were closed unmerged in May 2026. BTCPay Server has no support, no plugin and one unanswered request. No exchange publishes a payment name. No hardware wallet has claimed the thousand dollar bounty for supporting one.

    Craig Raw, who wrote most of the wallet-side implementation that does exist, put the case for carrying on in one line: “address reuse is currently near 70% because it’s difficult to share/validate a new address for every payment.”

§ 03 · The lesson

Nobody found new mathematics

Diffie-Hellman key exchange is from 1976. The elliptic curve is the one bitcoin has always used. Every scheme on this page uses the same primitive, discovered in the same forum post in 2011.

What took fifteen years was working out where to put one piece of data. In the chain, in an OP_RETURN, cost forty bytes a transaction. In a separate notification transaction, cost a permanent public link. The answer in the end was not to put it anywhere, and to derive it from something the transaction was already obliged to contain.

This proposal aims to address the limitations of these current approaches by presenting a solution that eliminates the need for interaction, eliminates the need for notifications, and protects both sender and receiver privacy. These benefits come at the cost of requiring wallets to scan the blockchain in order to detect payments.

That last sentence is the deal. It is a good deal, and it is the only honest way to describe it.