Silent payments in the Guide

guide.md

@@ -170,7 +170,7 @@ How to design for use cases where it is important to manage multiple wallets in
 
 <h2 class="h3" markdown="1">[Inheritance wallet]({{ '/guide/inheritance-wallet/' | relative_url }})</h2>
 
-An in-depth exploration of a multi-key wallet designed for long-term savings and inheritance. It covers everything from wallet creation, backup, change management and succession. 
+An in-depth exploration of a multi-key wallet designed for long-term savings and inheritance. It covers everything from wallet creation, backup, change management and succession.
 
 ---
 
@@ -202,6 +202,7 @@ Explanations of various technical aspects of bitcoin and lightning.
 [Lightning liquidity]({{ '/guide/how-it-works/liquidity/' | relative_url }})<br />
 [Lightning services]({{ '/guide/how-it-works/lightning-services/' | relative_url }})<br />
 [Sign in with bitcoin]({{ '/guide/how-it-works/sign-in-with-bitcoin/' | relative_url }})<br />
+[Silent payments]({{ '/guide/how-it-works/silent-payments/' | relative_url }})<br />
 
 </div>
 </div>
@@ -236,4 +237,4 @@ Join our open community and help us improve the Bitcoin Design Guide. Here’s w
 {% include next-previous.html
    nextUrl = "/guide/getting-started/introduction/"
    nextName = "Get started"
-%}
+%}

guide/how-it-works/custom-spending-conditions.md

@@ -2,7 +2,7 @@
 layout: guide
 title: Custom spending conditions
 description: An overview about advanced capabilities that enable users to create more flexible bitcoin wallets.
-nav_order: 12
+nav_order: 13
 parent: How it works
 permalink: /guide/how-it-works/custom-spending-conditions/
 main_classes: -no-top-padding
@@ -46,13 +46,13 @@ In addition to these standard configurations it is also possible to create more
 
 #### Self-custody
 
-Custom spending conditions can be helpful to decrease the risk of losing funds in personal self-custody context. Let's say that you have a wallet that you use regularly on a weekly basis. You could unlock a recovery spending condition automatically if that wallet has not been used for more than six months, because it's likely that you have lost access to your primary key. The recovery condition could contain an additional key held in a different location. Such a setup does not decrease the wallet security, because the second key is locked under normal circumstances of using the wallet. 
+Custom spending conditions can be helpful to decrease the risk of losing funds in personal self-custody context. Let's say that you have a wallet that you use regularly on a weekly basis. You could unlock a recovery spending condition automatically if that wallet has not been used for more than six months, because it's likely that you have lost access to your primary key. The recovery condition could contain an additional key held in a different location. Such a setup does not decrease the wallet security, because the second key is locked under normal circumstances of using the wallet.
 
 In a multi-key context, the recovery condition could require only one instead of two keys to spend funds after 6 months of inactivity. This will help mitigate the risk of loss of funds in case one key holder loses a key.
 
 #### Company treasuries
 
-Custom spending conditions can also be useful in an organizational context. Companies need to make sure that they retain access to funds even if one or more employees lose their keys. Not only that, employees could also be compromised by a third party or try to obstruct the deployment of funds for their own benefit. Another use case is that a company needs to implement company-specific processes for corporate spending. For example, they would want to create a rule that the CFO must sign transactions for treasury management. 
+Custom spending conditions can also be useful in an organizational context. Companies need to make sure that they retain access to funds even if one or more employees lose their keys. Not only that, employees could also be compromised by a third party or try to obstruct the deployment of funds for their own benefit. Another use case is that a company needs to implement company-specific processes for corporate spending. For example, they would want to create a rule that the CFO must sign transactions for treasury management.
 
 
 ## Building blocks
@@ -114,11 +114,11 @@ After the wallet has been created, it needs to be registered on all of the invol
 
 ### Timelocks
 
-Timelocks can be relative (e.g. “1 year after the wallet has been last used”) or absolute (e.g. “on January 3rd, 2024”). 
+Timelocks can be relative (e.g. “1 year after the wallet has been last used”) or absolute (e.g. “on January 3rd, 2024”).
 
 ##### Relative timelocks
 
-Relative timelocks can reach up to a maximum of 65535 blocks into the future, which is about 455 days. 
+Relative timelocks can reach up to a maximum of 65535 blocks into the future, which is about 455 days.
 
 An important aspect of timelocks is that they are applied to each [unspent transaction output (UTXO)](/guide/glossary/#unspent-transaction-output-utxo) in the wallet individually, not to the wallet as a whole. If a wallet uses relative timelocks, this means that the timelocks expire at different times for each UTXO, based on the time and date on which they were deposited into the wallet.
 
@@ -135,7 +135,7 @@ An important aspect of timelocks is that they are applied to each [unspent trans
    layout = "float-right-desktop"
 %}
 
-Let’s have a look at a concrete example. This image shows a wallet that contains three UTXOs with a total value of 0,40 BTC. The first UTXO of 0,10 BTC was received well ahead of the other two. And since it was not spent for six months, the recovery condition was unlocked. The emergency condition will unlock very soon, if the UTXO is not spent. 
+Let’s have a look at a concrete example. This image shows a wallet that contains three UTXOs with a total value of 0,40 BTC. The first UTXO of 0,10 BTC was received well ahead of the other two. And since it was not spent for six months, the recovery condition was unlocked. The emergency condition will unlock very soon, if the UTXO is not spent.
 
 As you can see, we are actually dealing with three timelocks, rather than one.
 
@@ -153,16 +153,16 @@ Note that an on-chain transaction is required to reset a timelock, along with th
 
 #### Absolute timelocks
 
-Absolute timelocks use a specific calendar date or block height as their reference point. In contrast to relative timelocks, absolute timelocks can go out as far as you want (the technical limit is 500 million blocks). 
+Absolute timelocks use a specific calendar date or block height as their reference point. In contrast to relative timelocks, absolute timelocks can go out as far as you want (the technical limit is 500 million blocks).
 
 Absolute timelocks apply the same timelock for each UTXO in the wallet. This has the advantage that they expire for all UTXOs in the wallet at the same time. This means that users only have to keep track of one deadline, which can make the management of the wallet easier and less demanding.
 
-**Resetting an absolute timelock requires sending the funds to a brand new wallet,** because a self-transfer to the same wallet would re-apply the same absolute timelock to the newly created UTXO. If your product uses absolute timelocks, it is therefore recommended to provide features that help streamline this process for your users. 
+**Resetting an absolute timelock requires sending the funds to a brand new wallet,** because a self-transfer to the same wallet would re-apply the same absolute timelock to the newly created UTXO. If your product uses absolute timelocks, it is therefore recommended to provide features that help streamline this process for your users.
 
 
 ### Flexibility vs. complexity
 
-Spending conditions based on Miniscript are composable. This means that you can create as many spending conditions as you like. You can even have one of the keys in one wallet be a multi-key wallet itself. Or you can combine time locked spending conditions with veto keys. It is also possible to combine relative and absolute timelocks. 
+Spending conditions based on Miniscript are composable. This means that you can create as many spending conditions as you like. You can even have one of the keys in one wallet be a multi-key wallet itself. Or you can combine time locked spending conditions with veto keys. It is also possible to combine relative and absolute timelocks.
 
 However, these kinds of setups can become complex very quickly and should not be used in most personal setups or by users who are new to bitcoin.
 

guide/how-it-works/introduction.md

@@ -86,6 +86,12 @@ How lightning wallets can support authentication and payments with external appl
 
 ---
 
+### [Silent payments]({{ '/guide/how-it-works/silent-payments/' | relative_url }})
+
+A simplified explanation of how silent payments work, along with its impact on bitcoin's interaction model and wallet flows.
+
+---
+
 ### [Wallet selector]({{ '/guide/how-it-works/wallet-selector/' | relative_url }})
 
 Documentation of an interface pattern for letting users choose which external wallet to use when withdrawing, sending, or receiving in a bitcoin application.

guide/how-it-works/sign-in-with-bitcoin.md

@@ -166,11 +166,9 @@ If a user loses their wallet, they also lose their access to your service. Ensur
 
 ---
 
-Next, view our [case studies]({{ '/guide/case-studies/' | relative_url }}) to see examples of design applied to real bitcoin software.
-
 {% include next-previous.html
    previousUrl = "/guide/how-it-works/wallet-privacy/"
    previousName = "Wallet privacy"
-   nextUrl = "/guide/how-it-works/wallet-selector"
-   nextName = "Wallet selector"
+   nextUrl = "/guide/how-it-works/silent-payments"
+   nextName = "Silent payments"
 %}