Silent payments is a protocol the uses static addresses to simplify payment experience while preserving privacy. Receivers can share the static address once, but senders can use it to derive unique on-chain addresses with every payment. This prevents address reuse without repeated user interaction.
For eg: Alice can simply post a static address on her website, and receive a bitcoin donations from Bob at unique on-chain addresses. The static address itself never shows up on-chain.
Silent payments also allow users to customize their static address with labels that are detected when payments are received. This is a powerful tool that provides actionable information for coin selection with minimal manual effort.
Static addresses & labels enable robust contacts features. The result is a better interaction model centred around users.
Since the blockchain is public, reusing an on-chain address for payments informs the network that these payments are made to the same user. However, specifying a new address for each transaction usually requires user interaction. This is error-prone and requires time & manual effort.
Silent payments circumvent both these issues by using static addresses (starting with sp1).
For eg: the static address is only shared with senders who use it to make payments. It is not shared with nodes who only receive the scan key needed for identifying payments.
The above model introduces a scan key that is used for payment scanning and a static address which is used for deriving on-chain addresses. This is in contrast with the BIP-32 model where extended public keys are used for both purposes. Below is a summary of the differences between the two models:
Current model with BIP-32
Silent payments model
Benefit
Single-use on-chain address
Static address
Reusable & untraceable on-chain
Extended private key (xprv)
Spend (private) key
Extended public key (xpub)
Scan (public) key
Nodes & light clients can scan for payments but cannot derive addresses
Labels or tags (such as ‘business’ or ‘no-kyc’) are brief identifiers often associated with information such as payments, transactions and addresses. They’re used to organise, categorise or quickly spot items from a large set.
Silent payments allows users to add labels to their static addresses on a case-by-case basis before sharing or posting them. When a payment is received, these labels can be detected and used by the receiver (but no one else) to identify the static address used to make the payment.
For example, Alice can add can customise her static address with different labels before sharing them
with a certain client
on nostr and
on her website
When she receives payments from any of these sources, the respective label(s) will be detected in the on-chain address and used to infer the source of the payment.
This scheme improves labelling in general since these labels get auto-applied to all derived on-chain addresses. This eliminates the friction of manually adding labels to addresses or transactions while providing crucial information useful for automatic or manual coin selection.
Without using labels, receivers have no way of knowing who may have paid them since they do not interact with the sender to provide them a on-chain address.
Recommendation
Labels in silent payments are crucial where receivers such as businesses want to match payments with customers.
Here’s how businesses such as exchanges, merchants and vendors can use labels:
Invoices: merchant software like BTCPay must use labels to match incoming payments with invoices and/or provide static addresses to repeat customers.
Bitcoin exchange deposits: Customers looking to sell/deposit bitcoin at exchanges encounter friction when their deposit addresses change constantly. Labelled static addresses for users fix this without address reuse while retaining the ability to match deposits to customers.
Since senders can safely use the same static address for multiple payments, it is natural for them to want to store these for future use. Contacts are a great way to store them in terms that users can intuit: names and faces/images. The contacts page here provides good guidance about the topic.
Silent payments (along with bolt-12) present a great opportunity to centre payments UX in terms of people instead of addresses, something that was not advisable before due to issues with on-chain address reuse.
With labels and static addresses, the receiver can create contacts for parties they only receive bitcoin from, such as employers or customers. This is useful for invoicing, tracking payments, coin selection and further data analysis for businesses.
Applications can take a variety of approaches to set up and communicate silent payment wallets. Features such as reusable address or sender-id could be introduced and explained to users during the setup process. Some wallets may use unique or significant locations (mobile widget, custom app logos, watch faces) to house this static address for easy retrieval, and may highlight the same during setup.
Silent payment wallets may or may not be set up as BIP-39 and/or BIP-32 HD wallets, since the protocol does not require these. Since silent payments introduce a new model & primitives (such as spend key, scan key), the setup process might be a good opportunity to introduce some of these as needed without overloading the user.
With the improvements to Contacts, on-chain send flows may start from a number of entry points. When users start with obtaining a static address, every on-chain address derived from it will be visibly different from the static address the sender started with. This is likely to be confusing for users. Applications should take measures such as short explainers to avoid confusion on the users part. Test transactions are another good way to help users deal with this.
Recommendation
Applications that do not support static addresses should provide helpful, actionable, human readable errors.
As mentioned in the introduction, coin selection can be done much better due to auto-applied label information. Applications should encourage & assist users in performing coin selection by surfacing relevant or related labels or other methods. Automatic coin selection should be improved with all the label information available.
Tip
The coin(s) selected for a transaction determine the derived on-chain address due to the nature of silent payments protocol. The interface should avoid showing the on-chain address before the coin selection is done.
Receiving flows are likely to be used less often since static addresses can be safely reused. If the receiver has publicly posted their static address, they will receive payments without any interaction with the sender. Therefore, applications should encourage users to add labels or a contact whenever they actively share a static address with a sender.
Applications should also allow receivers to share an on-chain address itself in case the sender’s wallet cannot send to static addresses.
Some places where people can share static addresses (and add labels) include:
Social media pages
Fundraising websites
Exchanges
Email signatures
The tradeoff that silent payments offer for all their benefits is a higher blockchain scanning requirement. This scanning process is more computation-intensive and time-consuming than the currently-popular BIP-32 wallets. Mobile wallet users are likely to face a noticeable delay in the scanning process since they cannot be online all the time. While the scanning is takes place, applications should show progress and estimated time to complete the scanning process.
Like lightning wallets, on-chain bitcoin wallets supporting full-featured silent payments require file backups (cloud or offline) since the wallet has important user metadata besides key material. The following items are unique to silent payment wallets:
Allowing the user to manually note some of this information is helpful in case the user misplaces the backup file or recovery application does not support backup files.
Recommendation
Applications should display backup information such as recovery phrase or wallet birthday in the UI itself for partial manual backup.
Like regular wallets, silent payment wallets can also be backed up & recovered by simply backing up the seed. However, it may result in longer recovery times as well as loss of valuable metadata.
In addition to recovery methods mentioned here, applications may enable manual recovery with data unique to silent payments wallets, such as scan/spend key material.
Allowing users to enter the wallet creation date (wallet birthday) during recovery can help reduce recovery time substantially.
Applications should allow both backup & recovery through multiple methods. This is especially important during early stages of adoption when the backup & recovery processes are not standardised, and many wallets may not support silent payments.