Prise en charge des Silent Payments par les portefeuilles
Réponse rapide
Les Silent Payments (BIP-352) vous donnent une adresse réutilisable unique (sp1…) que n'importe qui peut payer sans réutiliser d'adresse ni vous en demander une nouvelle — un vrai gain de confidentialité. Mais il y a une asymétrie qui piège les gens : ENVOYER à une adresse sp1 est facile et largement pris en charge (Sparrow, Cake, BlueWallet, Wasabi, Nunchuk, même le BitBox02 comme signataire), tandis que RECEVOIR en privé est difficile et rare. Recevoir signifie scanner chaque sortie taproot éligible dans chaque bloc pour trouver celles qui vous sont destinées — trivial pour un nœud complet, prohibitif pour un téléphone — si bien que les portefeuilles mobiles récupèrent les données de tweak auprès d'un serveur d'indexation qui, même s'il n'apprend jamais quelles pièces sont les vôtres, voit bien votre IP et vos requêtes. À la mi-2026, la réponse honnête est : Sparrow sur ordinateur (pointé vers votre propre serveur) est la seule configuration avec un véritable envoi ET une réception privée, Cake et Nunchuk fonctionnent sur mobile via les indexeurs de leurs opérateurs, et Bitcoin Core ne livre toujours rien.
L'envoi est résolu ; la réception est la frontière. Si vous voulez réellement RECEVOIR des Silent Payments en privé aujourd'hui, exécutez Sparrow 2.5.0+ contre votre propre serveur Electrum compatible SP, ou auto-hébergez un oracle BlindBit pour un client mobile — sinon vous faites confiance à un tiers avec votre IP et votre schéma de requêtes (jamais avec vos clés ni avec le fait de savoir quelles pièces sont les vôtres). Ne mettez pas de fonds importants dans les portefeuilles de démonstration.
yes pris en charge partial bibliothèque/expérimental no non pris en charge · la confidentialité de réception dépend de la colonne méthode de scan
| Portefeuille / bibliothèque | Type | Envoi | Réception | Méthode de scan (réception) | Depuis |
|---|---|---|---|---|---|
| Cake Wallet | mobile | yes | yes | third-party indexer (Cake default)Client-side derivation, but the default Cake-run Electrum servers see your IP and query pattern | send + receive since 2024 (first major mobile SP wallet) |
| Receive is a catch-up scan from wallet birth height. A documented edge case (issue #2395) can miss funds — verify received SP funds carefully. (A) | |||||
| Nunchuk | mobile | yes | yes | third-party indexer (Nunchuk default)Receive relies on a specialized SP-index server, Nunchuk-operated by default; self-host option unverified | 2026 (send + receive) |
| One of the few multisig-oriented wallets with SP receive; public implementation detail is thinner than Sparrow's. (B) | |||||
| Silentium | mobile | yes | yes | third-party indexer (silentiumd)PWA light client backed by silentiumd; the server serves tweak data and never learns which UTXOs are yours, but sees block-level queries | 2024 proof of concept |
| 🔴 Explicitly a proof-of-concept reference, 'use at your own risk' — NOT for meaningful funds. (A) | |||||
| sp-client | library | yes | yes | third-party indexer (BlindBit-style)Wallet-layer Rust lib designed around tweak-oracle backends; privacy depends on the oracle you point it at | 2024 (cygnet3) |
| Handles incoming-tx parsing, owned-output management and signing; powers Dana Wallet. (A) | |||||
| Sparrow Wallet | desktop | yes | yes | third-party indexer (self-hostable)Receive needs an SP-capable Electrum server serving per-block tweak data; detection runs client-side, but the server sees your IP/queries unless you run your own or use Tor | send v2.3.0 (Oct 2025); receive v2.5.0 (May 2026, incl. air-gapped signer) |
| The most complete mainstream implementation as of mid-2026. Pair with your OWN SP-capable server for best privacy — the recommended setup. (A) | |||||
| Dana Wallet | mobile | partial | yes | third-party indexer (BlindBit oracle)BlindBit Oracle backend serves tweak data per the BIP-352 light-client spec; server learns block-level queries but not which outputs are yours | v0.1.0-alpha (2024, built on sp-client) |
| Purpose-built for RECEIVING donations (receive is the point). General spend features limited; still experimental. (B) | |||||
| BlindBit | library | no | yes | IS the indexer (self-hostable, Go)BlindBit Oracle serves per-block tweak data + BIP158-style filters per the light-client spec so clients detect payments locally without revealing which UTXOs are theirs | 2024 (setavenger) |
| The reference architecture for SP light clients. Self-hostable — the way to get private mobile receive. (A) | |||||
| go-bip352 | library | yes | partial | n/aCrypto/derivation library; scanning infra lives in the companion BlindBit Oracle project | 2024 (setavenger) |
| The Go BIP-352 implementation underpinning BlindBit. (B) | |||||
| python-bip352 (reference) | library | yes | partial | n/aReference crypto only; no chain-scanning infrastructure | shipped with the BIP (bip-0352/reference.py, 2024) |
| The canonical Python code is the in-repo reference implementation with test vectors; a separately packaged 'python-bip352' is unverified. (B) | |||||
| rust-silentpayments | library | yes | partial | n/aProvides send and receive/scan cryptography; chain access and scan strategy are the integrator's problem | active 2023-2024 (crates.io: silentpayments) |
| The de facto Rust BIP-352 crypto crate; basis for sp-client and bdk-sp. (A) | |||||
| BitBox02 | hardware | yes | no | n/aSigning device only — cannot scan; verifies SP send outputs on-device | unverified firmware version |
| Hardware wallets can only ever do the send side (BIP-375 PSBT fields) or act as an air-gapped signer for a host wallet that scans (Sparrow 2.5.0 supports this). (C) | |||||
| BlueWallet | mobile | yes | no | n/aNo receive scanning shipped, so no scan-privacy question arises | send in v6.6.8 (with full BIP-47) |
| Maintains its own TypeScript SP library with receive code, but the app has receive only as an open feature request (issue #7432). (A) | |||||
| Wasabi Wallet | desktop | yes | no | n/aSend-only; docs state Wasabi cannot generate an SP address or recognize payments to one | send in v2.4.0 |
| Community-maintained since the zkSNACKs coordinator shutdown; receive announced as planned but not shipped as of mid-2026. (A) | |||||
| Bitcoin Core | node | no | no | n/aWould be the gold standard — full-node local scanning, zero leak — once merged. Nothing shipped yet | not shipped (libsecp256k1 SP module merged; wallet PRs #28201 send / #32966 receive / #28241 index all OPEN) |
| 🔴 No released Core version has SP wallet support. The zero-leak full-node receive option does not exist in any shipped general wallet yet. (A) | |||||
| Breez | mobile | no | no | n/a | n/a |
| Lightning/Liquid (Nodeless SDK); no BIP-352 support found. (B) | |||||
| Electrum | desktop | no | no | n/a | n/a |
| Send support is still an open feature request (issue #8847); no SP in any release. (B) | |||||
| Phoenix | mobile | no | no | n/a | n/a |
| Lightning wallet (ACINQ); no on-chain SP support announced. (B) | |||||
| Zeus | mobile | no | no | n/a | n/a |
| Lightning-focused (embedded LND); no BIP-352 support found as of mid-2026. (B) | |||||
Pourquoi la réception est la partie difficile. A receiver cannot recognize their own payments by watching addresses — each incoming output is a fresh P2TR script derived via ECDH between the sender's input keys and the receiver's scan key, so detection requires computing a tweak for essentially every eligible taproot transaction in every block. That is trivial for a full node with an index but prohibitive for a phone, so light clients fetch precomputed per-block tweak data (~100 kB/block) from an indexing server (BlindBit Oracle, silentiumd, an SP-capable Electrum server) and often combine it with BIP158 filters. The final ownership check stays client-side. The crux: the tweak server never learns which outputs are yours, but it DOES see your IP and query pattern — so the practical privacy question for every mobile SP wallet is who runs the indexer and whether you can self-host it.
Statut du BIP-352. BIP-352 was merged into the bitcoin/bips repo in May 2024 (authors Josie Baker and Ruben Somsen) and is stable, with a minor spec revision (~v1.1.0) in March 2026. The libsecp256k1 bundled with Bitcoin Core has a merged silentpayments module, but no RELEASED Core version ships SP wallet functionality — the wallet-level PRs remain open. Adoption is asymmetric: many wallets can SEND to an sp1 address; full private RECEIVE is limited to Sparrow, Cake, Nunchuk and the experimental SP-native wallets.
Données ouvertes (CC BY 4.0) : CSV · JSON · API : /wp-json/dc/v1/silent-payments
Produits, réparations et guides connexes
- comment D-Central diagnostique les réparations ASIC
- bibliothèque de dépannage ASIC
- manuels ASIC et guides de réparation
- hashboards de remplacement
- cartes de contrôle ASIC
- blocs d’alimentation ASIC
- hashboard de remplacement pour la famille S19
- carte de contrôle de remplacement C52
- bloc d’alimentation APW12 pour S19
- comparer les specs dans la base de mineurs ASIC
- comparer les specs des mineurs ASIC
- base de mineurs ASIC
- services de réparation ASIC
- specs et rentabilité de l’Antminer S19
- acheter un Antminer S19 testé
- guide d’entretien Antminer S19
- service de réparation Antminer S19
- specs de l’Antminer S21
- Bitmain Antminer S21
- guide d’entretien Antminer S21
- puce BM1370BC pour S21 Pro
Dernière révision: 27 juillet 2026.