Bitcoin Silent Payments let a recipient publish a reusable payment code while compatible senders derive separate onchain outputs. Receiving still requires scanning, and recovery depends on compatible key handling and relevant wallet metadata. Before relying on the feature, check three capabilities separately: sending, detecting incoming payments and restoring them after the original wallet is gone.
A reusable code is not an ordinary address-history lookup
With a conventional reused Bitcoin address, an observer can inspect activity associated with that address. Silent Payments use a different relationship between the published code and the transaction outputs. The BIP352 specification defines the protocol: the sender derives an output, and the recipient identifies it by performing the corresponding checks. Searching an explorer for the published code is not a substitute for those checks.
This creates a useful privacy distinction without making every part of the interaction private. A public page can still associate your identity with the code you posted. The sender knows whom they intended to pay. Your wallet’s network connections, information shared with services and later transactions remain separate considerations. Decide which exposure you are reducing rather than assuming a new receiving format resolves all of them.
For a fictional example, Noor publishes a payment code on a project page. That page still identifies Noor as the recipient. The improvement concerns how payments are represented and found, not whether the project page names her. Her backup plan must also account for the receiving feature; saving a screenshot of the public code does not give a replacement wallet the secrets it needs.
Keep receiving capability separate from spending authority
BIP352 separates scanning and spending roles. A scanner can use a private scan key together with the spend public key to identify payments, while spending requires the relevant private spending material. This is why an online scanner need not receive spending authority. It is also why the private scan key is still sensitive: the ability to identify receipts is an important disclosure even when it is not the ability to spend them.
| Material or capability | Purpose | Privacy or recovery concern | Question to answer |
|---|---|---|---|
| Published Silent Payments code | Allows compatible senders to construct payments | The place where it is published may identify its owner | Which public context have you attached to it? |
| Private scan key and required public material | Allows a compatible scanner to identify receipts | A third-party scanner can learn which outputs are yours | Who receives this material and why? |
| Private spending material | Authorizes spending with the required payment data | Disclosure concerns control of funds | Does the proposed restore preserve the complete required key material? |
| Labels used by the wallet | Distinguish receiving contexts and relevant outputs | A restore must search the labels that were used | Are these recorded or covered by the recovery procedure? |
| Wallet birthday or scan starting point | Defines the historical range to examine | Starting too late can omit earlier payments from the search | Does the chosen range cover the first possible receipt? |
| Cached discoveries and local descriptions | Make the current wallet convenient to use | They may not return with a seed-only restore | Which records must be backed up separately? |
Do not send private scan or spending material to a website just to check compatibility. Read the wallet’s own documentation first. When a scanner asks for information, understand whether it is downloading public preprocessing data or receiving a secret that lets it recognize your payments. A familiar label such as light wallet does not answer that trust question.
Find out who performs the scan
The project’s scanning overview distinguishes scanning locally, receiving public preprocessing data and delegating scanning to a server. These designs move different work and information between your device and the service. Ask where the matching calculation occurs and whether the service receives a private scan key. Downloading data from a server also leaves network-level questions distinct from identifying particular payments.
A concrete implementation makes that distinction easier to inspect. Frigate’s own repository describes server-side scanning and in-memory client keys. Its documented handling is useful information about that software, but using somebody else’s server still involves trusting how they operate it. A statement about memory storage is not a guarantee that an unknown operator cannot retain information.
Compare the trade-off against your actual needs. A phone that performs matching locally may take longer to catch up; delegating matching can disclose receipts to the scanner. Neither a fast balance display nor the absence of a conventional address query establishes the privacy of every connection. You need the architecture and the operator relationship, not a speed comparison presented as a security verdict.
Restore the receiving feature, not just the seed screen
BIP352’s recovery section discusses seed-based recovery, historical scanning and labels. It also distinguishes finding unspent outputs from recovering full history. A replacement application that imports your ordinary Bitcoin seed but does not implement Silent Payments receiving may show an incomplete picture. A successful import message only confirms the step that application actually performed.
Record the originating wallet, its recovery method and any wallet-specific information its instructions require. Keep a suitable historical scan starting point and preserve relevant labels or backup files through the wallet’s supported process. Do not interpret a suggestion to save metadata as permission to place secrets in an unprotected notes service. Public descriptions, scan secrets and spending secrets need appropriate treatment.
The Bitcoin Design recovery discussion explains why wallet birthday and metadata matter to recovery experience. If a restored balance is unexpectedly empty, first establish support, the scan range and progress. Do not delete the original installation or its only backup merely because another app accepted the seed. Keep access available while identifying what the replacement has and has not recovered.
Labels do not create unrelated public identities
A Silent Payments label helps the wallet distinguish receiving contexts, but it should not be treated as an identity-separation guarantee. The specification explains that published labeled codes share a scan public key. Someone comparing those published codes can associate them even though the outputs require the receiving process to identify. Keep that distinction in mind before placing different labels on unrelated public profiles.
- Confirm that both the sender and your receiving wallet support the required protocol.
- Identify whether matching happens locally or at a remote scanner.
- Keep private scanning material confidential even when it cannot alone spend funds.
- Follow the originating wallet’s backup instructions and record the relevant recovery context.
- Use a scan range that covers possible receipts and check progress before judging a restored balance.
- Keep the original wallet and backup available until recovery is understood; do not disclose secrets to a compatibility checker.
Ordinary local descriptions are different from BIP352 protocol labels. Follow appropriate seed-backup storage practices while preserving the additional recovery context. The Bitcoin page provides asset context. If you use a simple swap, confirm the service’s actual destination-format support before submitting an address: support for BTC does not establish support for every Bitcoin payment protocol, and this article does not claim KOT.CASH accepts Silent Payments destinations.
FAQ
Does every Bitcoin Silent Payments wallet support receiving?
Sending and receiving are separate capabilities. Verify receiving, scanning and recovery in the particular wallet instead of inferring them from a send feature.
Can I recover Silent Payments using a Bitcoin seed phrase?
BIP352 describes seed-based recovery with compatible scanning and attention to labels. A generic seed import into a wallet without Silent Payments receiving support is not the same operation.
What should I check in a Silent Payments wallet’s scanner?
Establish where matching happens and whether the scanner receives your private scan key. A remote service that can identify receipts creates a privacy relationship even when it cannot spend your coins with scanning material alone.