Silent payments in the Guide

[yashrajd]

This is a draft pull request for silent payments content in the guide. It is ready for review but not ready to merge just yet even if feedback is fine. I was able to able to create server and preview all of the content on local.

Preview the silent payments page

Listing a few minor of to-do's below, apart from the any changes necessitated by feedback:

• add mobile images for most screens
• add alt-text, captions to some screens
• [optional] improve header image
• refine copy

Look forward to review and feedback by way of suggestions, corrections for screens and content keeping in mind the above to-dos, which I will complete in a few days. I would discourage inputs on approach unless they were really necessary. I wanted to put this out there so the wider community in general could preview & review it.

[netlify]

✅ Deploy Preview for bitcoin-design-site ready!

Name	Link
🔨 Latest commit	78c7f6c
🔍 Latest deploy log	https://app.netlify.com/sites/bitcoin-design-site/deploys/66ecedfda94b1f0008db126c
😎 Deploy Preview	https://deploy-preview-1109--bitcoin-design-site.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[GBKS]

Great start with this page. I know you're still working on things, so I didn't go into a ton of detail.

Generally, a lot of content here expands on stuff we already have dedicated pages for (contacts, backup...). As a reader, it can be tricky to piece it all together. Eventually, I think it would be good to have silent payments be covered in those pages, instead of having this addendum. For example, the contacts page should just include them by default. For now, I think it might be good to start paragraph by referencing those other pages, and then only describing what is different.

It's one of those tricky editorial things about the guide, having standalone content, but still having it all work together nicely with little duplication.

Anyhow, let my know if there's any other feedback you'd like (or not like).

[GBKS]

For backup and recovery, how about just link out to the backup and recovery section, with a small note about labels...?

Just feels like we're repeating some things here, and the point about wallet birthday is not specific to silent payments, and could be tackled on that page as well.

[yashrajd]

I have now linked to the user meta section on that page for a good explanation about the need to backup that in 30efc00

I am not able to find mention of wallet bitrthday in the content, though the backup print template does mention a creation date). Should I add content to that page mentioning birthday if something doesn't already exist?

[GBKS]

Everything below here seems like left-over from another page.

[yashrajd]

You mean the recovery carousel?

[yashrajd]

Great start with this page. I know you're still working on things, so I didn't go into a ton of detail.

It's one of those tricky editorial things about the guide, having standalone content, but still having it all work together nicely with little duplication.

Thanks for reading through @GBKS, I see some great feedback, which I intend to add on top a lot of changes I'm about to push (edit: shown above since they were committed yesterday). Agree re: editorial things, see below.

Generally, a lot of content here expands on stuff we already have dedicated pages for (contacts, backup...). As a reader, it can be tricky to piece it all together. Eventually, I think it would be good to have silent payments be covered in those pages, instead of having this addendum. For example, the contacts page should just include them by default. For now, I think it might be good to start paragraph by referencing those other pages, and then only describing what is different.

Overall, I agree with you but view this effort as silent payments-focused for people who want to read about silent payments and their UX impact. My view (related to #1101 ) is that reference designs should outline established UX patterns and best practices, which IMO doesn't apply to silent payments currently since it is nascent at this point. That said, I've tried to link to existing pages where I could (do let me know if I missed someplace).

[mouxdesign]

Just had a read through Yashraj, thanks for putting this together. You approach the topic from a high level and then it gets more granular. Some suggestions and ideas:

Overall structure

It would be an idea to revisit the overall headings. In general it seems that there is a double introduction and that might be able to be revised by breaking the introduction into two parts. Also would suggest moving the contacts and labels to lower down in the copy.

1. Introduction
2. Advantages to users and user experience
3. Setup
4. Sending
5. Receiving and scanning
6. Contacts and labels
7. Backup
8. Recovery

Images

I would suggest to remove the static address and onchain address in all diagrams. It could be:

• Static address
• Bitcoin address
  For each of these a symbol or a color indicating that its moving from a static to an onchain address. People seeing the diagram would easily understand this if you also include a key at the top.

Suggested introduction with the help of AI

Introduction
On-chain addresses are only meant to be used once. Therefore, users have to interact with others to specify unique address(es) to be used every time they want to pay or get paid. This takes time and effort, along with the possibility of mistakes while handling on-chain addresses. Silent payments is a protocol involving static addresses that are used to derive unique on-chain address during every transaction. This not only prevents address reuse, but also removes the need for repeated interaction.
For example: Alice, who runs an NGO, can simply post a static address on her website, and receive bitcoin donations at unique on-chain addresses that only she can identify. The static address itself never shows up on-chain.

A silent payment transaction happens in 4 broad steps:

• The receiver shares/publishes a static payment address
• The sender obtains & uses it to derive a unique on-chain address
• The sender broadcasts a transaction that pays this derived address
• The receiver identifies the payment as theirs by verifying that they control this address

Advantages to users and user experience

• Removes the need for repeated interaction to specify unique addresses for each transaction
• Prevents address reuse, enhancing privacy and security
• Allows users to customize their static address with labels, which are detected when payments are received
• Improves features such as coin selection and contacts, making them more powerful and easier to use
• Enables a simpler and safer payment experience centered around people
• Reduces the possibility of mistakes while handling on-chain addresses
• Provides a more convenient way for individuals and organizations to receive payments (e.g., donations for an NGO)
• Offers a powerful yet user-friendly approach to bitcoin transactions

Overall, silent payments enable a more intuitive, secure, and user-centric payment experience in the bitcoin ecosystem.

[yashrajd]

Just had a read through Yashraj, thanks for putting this together. You approach the topic from a high level and then it gets more granular. Some suggestions and ideas:

Thanks a lot for this!!

Overall structure

It would be an idea to revisit the overall headings. In general it seems that there is a double introduction and that might be able to be revised by breaking the introduction into two parts. Also would suggest moving the contacts and labels to lower down in the copy.

• re intro: I see your overall point about this content being still too long. I'll try to move some content around and also shorten the text.
• re: contacts and labels - I mentioned them first since they are the most direct benefits of silent payments, and also set the foundation for the changes/benefits to general user flows. They also line up nicely with the content above them.

1. Introduction
2. Advantages to users and user experience
   I have briefly addressed in the intro already but will use them to distill it further. Will also add some of these to the pros and cons.

3. Setup
4. Sending
5. Receiving and scanning
6. Contacts and labels
7. Backup
8. Recovery

Images

I would suggest to remove the static address and onchain address in all diagrams. It could be:

• Static address
• Bitcoin address

I used on-chain address because it seemed specific enough and helpful in explaining the mechanism of silent payments as converting static address to the on-chain version that's in the blockchain.

For each of these a symbol or a color indicating that its moving from a static to an onchain address. People seeing the diagram would easily understand this if you also include a key at the top.

I'll add key to both diagrams, was kinda hoping it wouldn't be necessary if I did a good enough visual...

Suggested introduction with the help of AI

Introduction On-chain addresses are only meant to be used once. Therefore, users have to interact with others to specify unique address(es) to be used every time they want to pay or get paid. This takes time and effort, along with the possibility of mistakes while handling on-chain addresses. Silent payments is a protocol involving static addresses that are used to derive unique on-chain address during every transaction. This not only prevents address reuse, but also removes the need for repeated interaction. For example: Alice, who runs an NGO, can simply post a static address on her website, and receive bitcoin donations at unique on-chain addresses that only she can identify. The static address itself never shows up on-chain.

Thanks! Will use this in crafting a better intro section.

Advantages to users and user experience

• Removes the need for repeated interaction to specify unique addresses for each transaction
• Prevents address reuse, enhancing privacy and security
• Allows users to customize their static address with labels, which are detected when payments are received
• Improves features such as coin selection and contacts, making them more powerful and easier to use
• Enables a simpler and safer payment experience centered around people
• Reduces the possibility of mistakes while handling on-chain addresses
• Provides a more convenient way for individuals and organizations to receive payments (e.g., donations for an NGO)
• Offers a powerful yet user-friendly approach to bitcoin transactions

Overall, silent payments enable a more intuitive, secure, and user-centric payment experience in the bitcoin ecosystem

Incorporating these into pros and cons, adding a couple to intro section.

[yashrajd]

Hey @rabbitholiness here's an update to the updates based on your feedback (see recent commits for details):

• Illustrations have been updated with inspiration & the mobile versions are now pretty close to your suggestions
• I've added a conceptual model section
• Backup and Recovery sections are now combined
• Have simplified and trimmed content where I could spot it

Hope it makes the page better...

[yashrajd]

Just updated header images...if those are fine I think this one is ready for final reviews.

[rabbitholiness]

Great progress! The page reads much better already. I made some more suggestions.

It could also be a good idea to add a little bit more structure to the content by framing the bottom half of the content as UX implications. Like so:

• Rationale
• How it works
• New conceptual model
• Labels
• User experience implications
  -- Contacts
  -- Sending
  -- Receiving
  -- Setup
  -- Backup
  -- Recovery
• Pro's and cons

[rabbitholiness]

Suggested change

	For eg: Alice can simply post a static address on her website, and receive bitcoin donations at unique on-chain addresses. The static address itself never shows up on-chain.
	For instance, Alice can simply post a static address on her website, and receive bitcoin donations at unique on-chain addresses. The static address itself never shows up on-chain.

[rabbitholiness]

I'd either use "for instance" or "for example". If you want to go with the current model, it should be spelled e.g.

[rabbitholiness]

Suggested change

	Silent payments are made in 4 broad steps:
	Silent payments involve 4 broad steps:
	1. The receiver shares a static payment address with the sender or publishes it publicly (manual)
	2. The sender uses the static address to initiate a payment (manual)
	3. The sender's wallet uses the the static address to derive a unique on-chain address (automated)
	4. The sender broadcasts the transaction, which pays this derived address (manual)
	5. The receiver's wallet scans the bitcoin blockchain to identify payments (automated)

[rabbitholiness]

Suggested change

[Silent payments](https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki) is a protocol the uses static addresses to simplify payment experience while preserving privacy. Once the receiver shares a static address, senders derive a new unique on-chain address with it they make a payment. This prevents [address reuse](/guide/glossary/address/#address-reuse) without repeated user interaction.

[Silent payments](https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki) is a protocol the uses static addresses to simplify the payment experience while preserving privacy. Once the receiver shares a static address, the sender's wallet derives a new unique on-chain address for each payment to the static address. This prevents [address reuse](/guide/glossary/address/#address-reuse) and eliminates the need for repeated user interaction at the same time.

[rabbitholiness]

Suggested change

	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, takes time and requires manual effort.
	Since the bitcoin blockchain is public, reusing an on-chain address 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, takes time and requires manual effort.

[rabbitholiness]

Suggested change

	| Silent payments' concept | Shared with | for: |
	| Component |Used by | Purpose |

[rabbitholiness]

Suggested change

	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.
	As mentioned in the introduction, coin selection can be significantly improved due to auto-applied label information. Applications should encourage and assist users during coin selection by surfacing relevant or related labels. Automatic coin selection should be improved with all the label information available.

[rabbitholiness]

Suggested change

	Applications should also allow receivers to share an on-chain address itself in case the sender's wallet cannot send to static addresses.
	Applications should also allow receivers to generate and share conventional on-chain addresses in case the sender's wallet cannot send to static addresses.

[rabbitholiness]

Suggested change

	Some places where people can share static addresses (and add labels) include:
	Some practical examples for where users might want to share (labelled) static addresses include:

[rabbitholiness]

Suggested change

The tradeoff with silent payments for all their benefits is a higher blockchain scanning requirement. This scanning process is more computation-intensive and time-consuming than popular BIP-32 wallets/addresses. Mobile wallet users are likely to face a noticeable delay in the detecting payments once they come online. While the scanning is takes place, applications should show progress and estimated time to complete the scanning process.

The tradeoff with silent payments, for all their benefits, is a higher blockchain scanning requirement. This scanning process is more computation-intensive and time-consuming than for popular BIP-32 wallets and addresses. Mobile wallet users are likely to face a noticeable delay in the detecting payments once they come online. While the scanning is takes place, applications should show progress and estimated time to complete the scanning process.

[rabbitholiness]

Suggested change

	Allowing the user to manually note some backup information in case the user misplaces the backup file or recovery application does not support backup files. Like regular wallets, silent payment wallets can also be backed up & restored with the recovery phrase. However, it may result in longer recovery times as well as loss of valuable metadata.
	Applications should allow users to manually note backup information in case they misplace the backup file or the recovery application does not support backup files at all. Like regular wallets, silent payment wallets can also be backed up with restored using a recovery phrase. However, this method may result in longer recovery times as well as loss of valuable metadata.