A normal Bitcoin address can be copied forever, but reusing it creates a permanent public join: every direct payment to that script is trivially grouped. Generating a fresh address for every payer avoids the join, yet it is awkward for a profile, donation page, printed card, or contact who may pay you later. Silent Payments solve that tension with a surprising distinction: reuse the payment instruction, never the on-chain destination.
Aperture lets an eligible recovery-phrase wallet publish one reusable mainnet instruction beginning with sp1. A compatible sender combines that instruction with the final transaction inputs to create a new Taproot output that has never appeared before. The next compatible payment creates another output. The reusable string stays the same; the output script does not.
One public instruction. A different Taproot output for every payment. No repeated receive address on-chain.
Fresh capture from Aperture 2.40.12 in the iOS Simulator. Silent Payments is selected in an empty article-only wallet; the other receive formats remain available. Every app image in this article is a real Simulator capture containing public data only—no secrets, funds, signing, or transaction broadcast.
The address you share is not the output the blockchain sees
The phrase “reusable address” can sound like conventional address reuse, so precision matters. A version-zero Silent Payment address is a Bech32m-encoded payment instruction. On Bitcoin mainnet its human-readable prefix is sp, and its payload contains two compressed public keys: a scan public key and a spend public key. It is not a P2PKH, P2WPKH, or P2TR output script waiting to be copied into every transaction.
Instead, a supporting sender uses those public keys and information from its own final inputs to derive a unique x-only public key. The transaction pays a standard Taproot P2TR output built from that unique key. An observer sees an ordinary-looking Taproot output, not the published sp1 instruction and not a reusable script.
This is the central privacy win: two people can pay the same published instruction without creating two outputs to the same address. Their outputs are different, and the blockchain contains no direct reference to the reusable instruction that connects them.
Real Aperture 2.40.12 Simulator output. The QR and sp1 string are the reusable BIP352 payment instruction for this empty article-only wallet. The instruction is public; the scan and spend private keys are not shown.
What happens when a compatible sender pays
Silent Payments are interactive cryptography without an interactive conversation. The receiver publishes the instruction once. The sender can then construct a payment asynchronously, but it must do so only after its final transaction inputs are known. In simplified form:
Decode and validate the instruction. The sender reads the version-zero scan and spend public keys from the mainnet sp1 address. Aperture rejects unsupported testnet encodings and malformed payloads.
Finish coin selection. Eligible Bitcoin inputs are selected first. Their public keys and the lexicographically smallest input outpoint become part of the derivation context.
Create a shared secret. The sender combines its input-key material with the receiver’s scan public key. Elliptic-curve Diffie–Hellman lets the receiver reproduce the same secret with the scan private key, without anyone revealing a private key.
Derive a payment-specific tweak. BIP352 tagged hashes bind the shared secret to the transaction and output position. The tweak is added to the receiver’s spend public key.
Create the unique output. The tweaked x-only key becomes a Taproot output script. This script is the actual destination recorded in the transaction.
If coin selection changes, the sender must derive the Silent Payment outputs again. Adding or removing an input changes the shared input context and therefore changes the destination key. Aperture’s sender path performs Silent Payment derivation after final input selection and includes the exact 34-byte Taproot output in fee estimation and signing review.
That final-input rule is why an app cannot safely precompute a Silent Payment output too early, then casually add another UTXO without recalculating. The recipient instruction stays valid; the transaction-specific output must match the transaction actually signed.
Two receiver keys separate finding money from spending it
Aperture derives the BIP352 account at account index zero for recovery-phrase Bitcoin wallets. The two private branches have different jobs:
Scan key — m/352'/0'/0'/1'/0. This viewing key helps recognize candidate outputs and reconstruct the same payment tweak the sender created. It cannot authorize spending by itself.
Spend key — m/352'/0'/0'/0'/0. This key combines with each verified tweak to produce the one-time private output key that can spend the matching Taproot output.
The reusable address publishes only the two public keys. Aperture keeps both private keys in its this-device-only Keychain vault. The wallet database stores public account material, the reusable address, scan heights, discovered output metadata, and opaque Keychain references—not the recovery phrase, the base private keys, or a one-time output private key.
Real Simulator capture from Bitcoin Settings. The same wallet contains its conventional BIP44, BIP49, BIP84, and BIP86 accounts plus Silent Payments. Values shown are zero; the selected receive mode is Silent Payments.
The QR follows BIP321, not a private Aperture format
When Silent Payments is selected, Aperture saves that receive preference and displays the locally prepared instruction immediately. Its QR payload uses the Bitcoin payment URI form bitcoin:?sp=<address>, as defined by BIP321. That lets a supporting wallet recognize the sp parameter as a Silent Payment destination.
A BIP321 request can also carry an ordinary Bitcoin address as a fallback. When a sender understands Silent Payments, it can prefer the sp instruction; an older sender can use the conventional fallback if one was provided. A bare sp1 string still requires explicit BIP352 support.
Switching back to BIP86, BIP84, BIP49, or BIP44 clears the Silent Payments receive preference and publishes that account’s current fresh conventional child instead. It does not delete the Silent Payment account or make previously received outputs disappear.
Finding an output requires scanning, not address lookup
A conventional wallet can ask an indexer for activity on known scripts. A Silent Payment receiver does not know the final output scripts until it combines transaction input data with its scan key. The cost of eliminating the public notification is therefore scanning work.
Aperture’s current mainnet discovery path uses a TLS-protected BIP352 scan service. Before sending a request, the app verifies that the service reports the Bitcoin genesis hash and Silent Payments version zero. It provides the scan private key, spend public key, and a bounded starting height so the service can filter candidate transactions. This is an important privacy tradeoff: the scan service gains viewing capability for Silent Payment activity, but it does not receive the spend private key and cannot spend the funds.
Aperture does not accept a server candidate as money on trust. For each candidate it:
downloads the raw mainnet transaction through the same verified session;
parses the transaction locally and recomputes its transaction ID;
recomputes the BIP352 input hash, shared secret, tagged tweak, and expected Taproot script;
accepts only an exact script match at the reported output index; and
stores the exact decimal-text value, script, block metadata, and an opaque Keychain reference to the one-time output key.
This division is deliberate. The service can help narrow the search, but it cannot invent a spendable balance by returning a false candidate: local cryptographic verification must reproduce the output. It also cannot sign because it lacks the spend key. Nevertheless, anyone choosing Silent Payments should understand that the current discovery service can observe the activity it scans.
Real Aperture 2.40.12 Simulator capture. The dedicated account view exposes the reusable public instruction and wallet-owned scan status without revealing either private branch.
Incremental discovery, live updates, and reorg safety
The first recovery scan begins from a safe historical floor rather than Bitcoin block zero. Aperture currently uses block 709,632—the Taproot activation height—as the mainnet starting point for this account, unless a configured birth height narrows the range. Subsequent scans resume near the last verified height while overlapping the prior 100 blocks so a short reorganization can be reconciled.
A live scan subscription can trigger discovery again when a relevant mempool or block candidate appears. Once outputs are known, Aperture monitors their script hashes through its Bitcoin synchronization path, reconciles confirmations, detects spends, and removes orphaned state after a reorg. An unconfirmed verified Silent Payment can enter the spendable UTXO set; confirmation count still affects its status and ordering.
Fresh Simulator capture from the empty article-only wallet. It has zero discovered, unspent, and spent outputs. The visible scan range begins at block 709,632 and reached block 964,805 when captured; these are real runtime values, not a mockup.
Received outputs join the same Bitcoin balance
A Silent Payment does not create a separate kind of bitcoin. After an output is discovered and verified, Aperture represents it as a normal mainnet Taproot UTXO inside the same Bitcoin balance alongside outputs received through BIP44, BIP49, BIP84, and BIP86. Bitcoin Settings can show separate account details, but portfolio ownership remains unified.
For spending, Aperture retrieves the one-time output key through its opaque Keychain reference and proves that the key’s x-only public key matches the Taproot output script before signing. That output can then participate in ordinary coin selection. The sender does not need the original reusable instruction again, and the user does not have to “convert” the received funds.
Silent Payments do not remove miner fees. The outgoing transaction still occupies block space, and its fee is still the chosen satoshi-per-vbyte rate multiplied by actual virtual size. Receiving to a Silent Payment produces a 34-byte Taproot output script; spending it uses the Taproot key-path shape. Read Where Crypto Network Fees Actually Go for fee mechanics and Send Crypto Without Guesswork: From Recipient to Finality for Aperture’s transaction review path.
Silent Payments and fresh BIP84 addresses solve different moments
A fresh conventional address is still the simplest receive method when you can generate a new request for each payment and the sender may not support BIP352. Aperture defaults conventional receiving to BIP84 Native SegWit, whose addresses begin with bc1q. The wallet advances through its external address chain as use is discovered.
Real Aperture 2.40.12 Simulator capture from the same empty article-only wallet after returning to BIP84. The bc1q address is one conventional child destination; a later payment can use another child.
Use a fresh conventional address for an invoice, exchange withdrawal, or sender that does not explicitly support Silent Payments.
Use a Silent Payment instruction where one stable public contact point is valuable and the sender supports BIP352.
Do not confuse Silent Payments with reusing a bc1 address. Repeated conventional-address payments repeat a visible output script; compatible Silent Payments derive a different script each time.
For a deeper look at conventional HD receive and change chains, read Why Bitcoin Wallets Generate Fresh Receiving Addresses.
Compatibility: who can receive and who can send
Silent Payments require wallet support on the sending side. A legacy wallet, exchange withdrawal form, or payment processor that validates only conventional addresses may reject an sp1 string or fail to construct the required output. Aperture keeps all conventional formats available for exactly this reason.
Receiving in Aperture. The reusable BIP352 account is derived for Bitcoin wallets created from, or restored by, a recovery phrase. That full deterministic scope is necessary to reconstruct the scan and spend branches.
Sending from an Aperture recovery-phrase wallet. Aperture can build a version-zero mainnet Silent Payment output after final Bitcoin coin selection.
Sending from a supported imported single-key wallet. An eligible WIF wallet can pay an sp1 recipient because sender derivation can use the selected input key. The WIF import does not gain its own reusable receiver account.
Version handling. Aperture constructs version-zero payments. It can read forward-compatible versions 1 through 30 when the first 66 payload bytes provide the expected public keys, while version 31, malformed payloads, and testnet human-readable prefixes are rejected.
Before sending, confirm that both the source wallet and recipient instruction are on Bitcoin mainnet. If support is uncertain, ask the recipient for a conventional BIP84 or another mutually supported address and start with a small test payment.
Recovery reconstructs keys, then rediscovers outputs
Aperture can regenerate the same BIP352 scan and spend account from the same recovery phrase at account zero. Recovery is not an instant database snapshot: after deriving the keys, the wallet must scan from its historical floor or configured birth height, verify matching transactions, rebuild one-time output keys, and reconcile whether each output is unspent or spent.
That scan can take longer than restoring a short list of ordinary addresses because Silent Payment ownership must be derived from transaction data. Keep the app connected long enough for discovery to reach the current chain tip before concluding that funds are missing.
Aperture’s encrypted direct-device migration does not simply copy Silent Payment output rows as trusted state. The destination prepares the deterministic account and rediscovers outputs. The recovery phrase therefore remains the durable root of ownership; the local scan database is reconstructible index data. See Lose Your Phone, Not Your Wallet: Backup and Restore in Aperture and Recovery Phrase, Private Key, iCloud, or iPhone Transfer? Choose the Right Import before choosing a recovery route.
What Silent Payments protect—and what they cannot
Silent Payments remove one especially obvious relationship: repeated payments to the same published destination script. They also avoid an on-chain notification transaction and let the receiver publish a stable instruction without negotiating a new address. Those are meaningful improvements, not an anonymity guarantee.
The transaction graph remains public. Inputs, outputs, amounts, timing, fee rate, and later spends can still support analysis.
Input clustering can reveal sender relationships. Combining inputs can link coins even when the payment output itself is unique.
Later receiver spending can create clues. Consolidating multiple received outputs may reveal common control.
Off-chain records still matter. An exchange, merchant, contact, IP observer, or device telemetry source may know who initiated a payment.
The current scan service has viewing capability. It receives the scan private key and spend public key for filtering. It cannot spend, and Aperture verifies candidates locally, but this remains a disclosure to understand.
A published sp1 instruction is still public. Anyone who sees it can pay it and associate that instruction with the identity or page where it was published, even though they cannot search the chain for a repeated destination.
Good privacy comes from layers: avoid conventional address reuse, understand coin selection, avoid unnecessary UTXO consolidation, keep account descriptors private, limit off-chain identity leakage, and verify the software and services you choose. Silent Payments improve the receive layer; they do not erase every other layer.
A practical Silent Payments checklist
Open Bitcoin Receive, choose Types, then select Silent Payments.
Share the complete sp1 instruction or its QR; never share the recovery phrase, scan private key, spend private key, or extended private key.
Confirm the sender explicitly supports BIP352 Silent Payments on Bitcoin mainnet. If it does not, switch to a fresh conventional address.
For meaningful value, verify the instruction through a second channel and begin with a small supported test payment.
Allow discovery to reach the current block height after receiving or restoring. An empty result before the scan reaches tip is not final.
Keep the recovery phrase backup accurate and offline. The reusable instruction alone cannot restore or spend the wallet.
Remember that unique outputs improve linkability at receipt; later transaction behavior can still reconnect them.
Questions people ask before publishing an sp1 instruction
Can I keep using the same Silent Payment instruction? Yes. Its purpose is repeated publication and payment. With the same recovery phrase and account scope, Aperture reconstructs the same version-zero scan and spend public keys. Each compatible payment still derives a unique Taproot output.
Can any exchange send to it? Only if its withdrawal system supports BIP352. If the form rejects sp1 or does not explicitly document Silent Payments, use a conventional Aperture receive address instead.
Does the reusable instruction reveal my balance? It does not provide a simple address lookup that lists all received outputs. However, Silent Payments are not anonymous, and Aperture’s current scan-service model grants that service viewing capability as described above.
Can the scan key spend my bitcoin? No. Recognizing an output uses scan-key capability; spending requires the separate spend key and the verified per-output tweak. Protect the scan key anyway because it can reveal activity.
Are Silent Payments free? No. There is no special on-chain notification transaction, but the actual Bitcoin payment still pays an ordinary miner fee.
Do my old bc1 addresses stop working? No. Switching receive types changes what Aperture publishes now. Previously generated conventional addresses remain valid and monitored.
Why can restoration take time? The recovery phrase recreates the account keys, but ownership of one-time outputs must be rediscovered by scanning and locally verifying mainnet transactions.
Reusable should describe the instruction—not the output
Silent Payments change what a static Bitcoin contact point can mean. The reusable object is a pair of public keys encoded as an sp1 instruction. The blockchain output is a fresh Taproot key derived for one transaction. Aperture keeps those roles separate: public instruction for contact, scan key for discovery, spend key for ownership, local verification for trust, and the recovery phrase for reconstruction.
That separation is why the headline is not a contradiction. You can publish one stable way to be paid without asking compatible senders to reuse the same on-chain address. The instruction remains recognizable to people; the outputs remain distinct to the blockchain.
Publish once. Derive per payment. Verify locally. Recover from the phrase.
Technical standard: BIP352 Silent Payments. Payment URI interoperability: BIP321.
