Silent Payments: current status

You might have seen mentions of Silent Payments in different threads around here. It’s a method that allows folks to send Bitcoin to a unique static address, but every payment goes to a distinct one-time address. Unlike PayNyms, which requires both parties to chat beforehand, this tech lets users independently create the same one-time address using the Elliptic Curve Diffie-Hellman algorithm. I wanted to break down what Silent Payments looks like now, so here’s the rundown. 1) BIP352 is the main protocol (covers ECDH, addresses, scanning, etc.). The authors are Josiah Baker, Ruben Somsen, and Sebastian Falbesoner. Current status of the BIP: version 1.1.1, last updated on May 31, 2026. Key points about BIP352: - ECDH-based key derivation for both sender and receiver - The sp1 address encoding - Rules for input eligibility - Input_hash computation to help prevent attacks - Scanning algorithm that receivers need to run - Test vectors to verify implementation 2) BIP374 deals with Discrete Log Equality Proofs (DLEQ). Authors are Andrew Toth, Ruben Somsen, and Sebastian Falbesoner. This one is still in Draft status, with last updates on April 28, 2026. Key highlights of BIP374: - A standard 64-byte zero-knowledge proof format that demonstrates the same discrete logarithm holds true across two different elliptic curve bases, without giving away the private key - Tagged hashing scheme for proof challenges to avoid cross-protocol reuse - GenerateProof algorithms - Test vectors for both proof generation and verification 3) BIP375, which is about sending Silent Payments.

Sparrow Wallet implementing it is nice, but we are going to need some kind of CLI daemon for scanning for counterparty Silent Payment addresses. That way, silent payments will be able to be used for a variety of use cases without people having to be stuck with specific wallets.

For me the most essential thing will be SP support from Foundation. I use Sparrow + Passport Core setup to store my main stash, so as soon as Foundation implements that support, I will try to disconnect this stash from its prior history by sending it to SP address under my control. There are a few ways to implement this scheme using one or two SP addresses, but the main outcome will be the same.