@@ -150,7 +150,7 @@ An overview and considerations for bitcoin wallets that are managed by multiple
-Explanations of various technical aspects of bitcoin and Lightning.
+Explanations of various technical aspects of bitcoin and lightning.
diff --git a/guide/daily-spending-wallet/activity.md b/guide/daily-spending-wallet/activity.md
index 7ed55f3b0..b1f013e45 100644
--- a/guide/daily-spending-wallet/activity.md
+++ b/guide/daily-spending-wallet/activity.md
@@ -26,7 +26,7 @@ imagesBasics:
- file: activity-ids
modalImage: activity-ids-big
alt: Smartphone screen showing a list of user transactions with minimal information and invoice IDs
- caption: If your users are likely to rely on addresses or Lightning invoice IDs to identify payments, you may decide to show them. Always consider your users.
+ caption: If your users are likely to rely on addresses or lightning invoice IDs to identify payments, you may decide to show them. Always consider your users.
imagesGrouping:
- file: micropayments
modalImage: micropayments-big
@@ -69,11 +69,11 @@ imagesReceive:
caption: Tapping list items can quickly bring up further details and options.
imagesSend:
- file: send-transaction
- alt: Smartphone screen showing a completed Lightning payment
- caption: On-chain and Lightning payments look structurally similar, but differ in subtle ways.
+ alt: Smartphone screen showing a completed lightning payment
+ caption: On-chain and lightning payments look structurally similar, but differ in subtle ways.
- file: send-transaction-expanded
- alt: Smartphone screen showing a completed Lightning payment with extended technical details
- caption: Expanded details of Lightning payment.
+ alt: Smartphone screen showing a completed lightning payment with extended technical details
+ caption: Expanded details of lightning payment.
---
{% include picture.html
@@ -138,7 +138,7 @@ Since we already offer users a chronological list of events, it is a small step
Events can include user activity related to unique wallet features. For example:
-- [Blixt](https://blixtwallet.github.io) allows for manual control over Lightning channels. The list can show when channels were opened and closed.
+- [Blixt](https://blixtwallet.github.io) allows for manual control over lightning channels. The list can show when channels were opened and closed.
- [Breez](https://breez.technology) includes a podcast player. New subscriptions and episodes could be listed.
- [Hexa](https://hexawallet.io) allows users to have multiple wallets. The list can show when new wallets were created.
- Authentication to third-party services via [sign in with bitcoin]({{ '/guide/how-it-works/sign-in-with-bitcoin/' | relative_url }}).
@@ -151,7 +151,7 @@ Wallets can also independently keep an eye on user funds, data traffic, and othe
### Smart organization
-The Lightning network makes micropayments economically and technically viable. For example, as a user listens to a podcast, they may stream 10 sats per minute to the host as a thank you. This can easily result in a cluttered activity list, which can be remedied via automatic grouping.
+The lightning network makes micropayments economically and technically viable. For example, as a user listens to a podcast, they may stream 10 sats per minute to the host as a thank you. This can easily result in a cluttered activity list, which can be remedied via automatic grouping.
{% include image-gallery.html pages = page.imagesGrouping %}
@@ -182,7 +182,7 @@ Alternative approaches to the basic list view can give users different perspecti
The example shown here uses traditional categories borrowed from [personal household finance]({{ '/guide/designing-products/personal-finance/' | relative_url }}). As users tag transactions, the categories update.
-It's recommended to approach this type of view based on the unique use case and feature set of the application. For example, a wallet that is focused on interaction with Lightning applications may instead group payments by the services they were made with.
+It's recommended to approach this type of view based on the unique use case and feature set of the application. For example, a wallet that is focused on interaction with lightning applications may instead group payments by the services they were made with.
@@ -190,7 +190,7 @@ It's recommended to approach this type of view based on the unique use case and
The activity list focuses on summarizing the top-level information, so users can quickly scan the screen to get an overview. If they identify a transaction they want to take a closer look at or interact with, the following screens become relevant.
-##### A payment made on Lightning
+##### A payment made on lightning
As with the activity list, transaction details screens should also only highlight relevant information and options, and make secondary details easily accessible.
@@ -198,7 +198,7 @@ As with the activity list, transaction details screens should also only highligh
##### A payment received on-chain
-While the details for Lightning and on-chain payments look very similar, there are subtle differences. Most noticeable for the user is the difference in fees and processing time.
+While the details for lightning and on-chain payments look very similar, there are subtle differences. Most noticeable for the user is the difference in fees and processing time.
{% include image-gallery.html pages = page.imagesReceive %}
@@ -240,7 +240,7 @@ This can be in the form of text labels, or even uniquely generated icons like [J
### Wrapping up
-As mentioned at the top of the page, there is a lot of nuance in the display of user activity. While this allows for many different small design decisions, users overall benefit if wallets take similar approaches. Particularly when it comes to the addition of metadata that is not stored on-chain or by Lightning nodes, it would be helpful if wallets can converge on standardized data formats to allow for [interoperability]({{ '/guide/getting-started/principles/#interoperability' | relative_url }}) and data portability.
+As mentioned at the top of the page, there is a lot of nuance in the display of user activity. While this allows for many different small design decisions, users overall benefit if wallets take similar approaches. Particularly when it comes to the addition of metadata that is not stored on-chain or by lightning nodes, it would be helpful if wallets can converge on standardized data formats to allow for [interoperability]({{ '/guide/getting-started/principles/#interoperability' | relative_url }}) and data portability.
---
diff --git a/guide/daily-spending-wallet/contacts.md b/guide/daily-spending-wallet/contacts.md
index 730bae353..5c9728bfb 100644
--- a/guide/daily-spending-wallet/contacts.md
+++ b/guide/daily-spending-wallet/contacts.md
@@ -27,11 +27,11 @@ imagesAddContact:
alt: Address entry screen with expanded information about supported addresses
caption: Information about supported address formats should be readily available.
- file: manual-add-contact-add-address-valid
- alt: Address entry screen with inline validation for a Lightning address
+ alt: Address entry screen with inline validation for a lightning address
caption: Inline validation lets users know about if addresses are accepted.
- file: manual-add-contact-with-address
- alt: A contact with a Lightning address assigned
- caption: A contact with a Lightning address associated.
+ alt: A contact with a lightning address assigned
+ caption: A contact with a lightning address associated.
imagesSupportedFormats:
- file: manual-add-contact-add-address-valid-on-chain
alt: Address entry screen with inline validation for an on-chain address
@@ -63,13 +63,13 @@ imagesMultiAddressContact:
caption: Address details and options can be available on tap.
imagesImportAddress:
- file: lightning-address-input
- alt: Modal showing that a Lightning address was detected on the clipboard
+ alt: Modal showing that a lightning address was detected on the clipboard
caption: A modal is shown when an address has been imported via the clipboard or other methods.
- file: lightning-address-input-add-contact
alt: Screen for selecting a contact
caption: The user has tapped "Add contact" and then taps "+" to add a new contact.
- file: lightning-address-input-new-contact
- alt: Contact screen with the Lightning address assigned
+ alt: Contact screen with the lightning address assigned
caption: The new contact is created with the address associated.
imagesPayInvoice:
- file: pay-invoice-with-details
@@ -165,7 +165,7 @@ https://www.figma.com/file/VB3GQdAnhl8yta44DY3PSV/Bitcoin-UI-Kit?node-id=3120%3A
Whether we’re sending emails, physical mail, or following someone on social media, we primarily think in terms of names and faces, and not the respective address or user ID.
-Invoices, node IDs and other transaction endpoints in bitcoin and Lightning are highly unintuitive. Abstracting them via a contact list can create a much smoother user experience. There are many [payment request formats]({{ '/guide/how-it-works/payment-request-formats/' | relative_url }}), each with unique properties and varying levels of maturity and adoption, requiring unique design solutions. This page uses the more approachable term "address", along with various UI techniques, to abstract these complexities for users.
+Invoices, node IDs and other transaction endpoints in bitcoin and lightning are highly unintuitive. Abstracting them via a contact list can create a much smoother user experience. There are many [payment request formats]({{ '/guide/how-it-works/payment-request-formats/' | relative_url }}), each with unique properties and varying levels of maturity and adoption, requiring unique design solutions. This page uses the more approachable term "address", along with various UI techniques, to abstract these complexities for users.
Let's go over common user interactions around managing contacts. This will illustrate how such a feature could work, and helps explain the underlying design problems and decisions.
@@ -194,7 +194,7 @@ The contacts screen should offer various features for editing and organization.
### Importing an address
-This scenario can be initiated by copying a Lightning address to the clipboard, scanning a QR code, or tapping a payment link (see [payment entry points]({{ '/guide/daily-spending-wallet/sending/#payment-entry-points' | relative_url }})). An address is passed into the application and, where it's recognized and appropriate options are shown to the user. In the example below, the user adds the address as a new contact.
+This scenario can be initiated by copying a lightning address to the clipboard, scanning a QR code, or tapping a payment link (see [payment entry points]({{ '/guide/daily-spending-wallet/sending/#payment-entry-points' | relative_url }})). An address is passed into the application and, where it's recognized and appropriate options are shown to the user. In the example below, the user adds the address as a new contact.
{% include image-gallery.html pages = page.imagesImportAddress %}
diff --git a/guide/daily-spending-wallet/security.md b/guide/daily-spending-wallet/security.md
index e3568297e..26949ce52 100644
--- a/guide/daily-spending-wallet/security.md
+++ b/guide/daily-spending-wallet/security.md
@@ -75,7 +75,7 @@ Editor's notes
This page narrowly focuses on user actions to set up and maintain good security
and privacy for their wallets. It does not cover key setup and management, or
-technical things like watch towers for Lightning wallets.
+technical things like watch towers for lightning wallets.
Illustration sources
diff --git a/guide/daily-spending-wallet/sending.md b/guide/daily-spending-wallet/sending.md
index 4188ad502..74aa9fb09 100644
--- a/guide/daily-spending-wallet/sending.md
+++ b/guide/daily-spending-wallet/sending.md
@@ -42,7 +42,7 @@ imagesEntryScreens:
caption: Invoices can also offer the user to withdraw bitcoin.
- file: error-invoice-expired
alt: A home screen with a modal explaining an invoice has expired
- caption: Basic Lightning invoices expire, typically after one hour.
+ caption: Basic lightning invoices expire, typically after one hour.
- file: error-incompatibility
alt: A home screen with an informational modal around invoice compatibility
caption: Compatibility problems are not uncommon due to the many formats.
@@ -81,7 +81,7 @@ imagesErrors:
caption: Access to error details for problem-solving.
- file: offline-error
alt: A screen showing error details
- caption: If the receiving Lightning wallet is offline, let the user know how to address this problem.
+ caption: If the receiving lightning wallet is offline, let the user know how to address this problem.
imagesReview:
- file: confirm
alt: Invoice approval screen
@@ -181,7 +181,7 @@ When responding to an invoice that contains all relevant information, the user c
**Recipient**
-The most convenient option for choosing a recipient is from a previously saved [contact]({{ '/guide/daily-spending-wallet/contacts/' | relative_url }}). Alternatively, users can enter Lightning addresses, Lightning node IDs, on-chain addresses, or other addresses that are supported by the wallet.
+The most convenient option for choosing a recipient is from a previously saved [contact]({{ '/guide/daily-spending-wallet/contacts/' | relative_url }}). Alternatively, users can enter lightning addresses, lightning node IDs, on-chain addresses, or other addresses that are supported by the wallet.
There are also static [payment requests]({{ '/guide/how-it-works/payment-request-formats/' | relative_url }}) that can receive payments repeatedly. These are less intuitive overall due to their appearance, but could also be considered payment endpoints.
@@ -202,7 +202,7 @@ Payment fees can drastically differ based on a few attributes:
{% include image.html
image = "/assets/images/guide/daily-spending-wallet/sending/fee-options.png"
retina = "/assets/images/guide/daily-spending-wallet/sending/fee-options@2x.png"
- alt-text = "Examples of on-chain, Lightning and Lightning routing fees"
+ alt-text = "Examples of on-chain, lightning and lightning routing fees"
width = 400
height = 417
layout = "float-right-desktop"
@@ -210,7 +210,7 @@ Payment fees can drastically differ based on a few attributes:
**Lightning routing fees**
-On the Lightning network, payments are passed between nodes to get from the sender to the receiver. Each of those nodes may charge a base fee and a second fee based on a percentage of the amount forwarded. Fees paid can vary, but are typically in the single-digit or double-digit Satoshi range (a small fraction of on-chain fees).
+On the lightning network, payments are passed between nodes to get from the sender to the receiver. Each of those nodes may charge a base fee and a second fee based on a percentage of the amount forwarded. Fees paid can vary, but are typically in the single-digit or double-digit Satoshi range (a small fraction of on-chain fees).
**Lightning service fees**
@@ -254,7 +254,7 @@ If using a security step here, it should come after the user has selected all ot
## Transaction processing
-Processing times may also differ between on-chain and Lightning network payments. On-chain, pending transactions are bundled into a [new block]({{ '/guide/getting-started/technology-primer/#what-is-a-blockchain' | relative_url }}) roughly every 10 minutes. On the Lightning network, [payment routing]({{ '/guide/getting-started/technology-primer/#how-are-payments-routed' | relative_url }}) happens instantly and is largely dependent on the number of nodes involved, as well as their liquidity and processing speeds.
+Processing times may also differ between on-chain and lightning network payments. On-chain, pending transactions are bundled into a [new block]({{ '/guide/getting-started/technology-primer/#what-is-a-blockchain' | relative_url }}) roughly every 10 minutes. On the lightning network, [payment routing]({{ '/guide/getting-started/technology-primer/#how-are-payments-routed' | relative_url }}) happens instantly and is largely dependent on the number of nodes involved, as well as their liquidity and processing speeds.
When transactions take longer than expected, users need to be clearly informed about the status. In scenarios like in-store payments, speedy confirmation is of the essence, as the user wants to move on, and the merchant may have other customers waiting. In-app status updates can be coupled with notifications to ensure that both parties are confident that everything is in order. For a framework on timing, see [this article on response time limits](https://www.nngroup.com/articles/response-times-3-important-limits/).
@@ -282,7 +282,7 @@ Completion of a payment should be clearly indicated to the user.
It should also be simple to share a proof that the payment was made. In-person, it may suffice to show the screen to the receiver. Additional options like sharing the confirmation via chat or email may also be useful.
-As on-chain transactions can be globally verified by anyone, a link to a [bitcoin explorer]({{ '/guide/getting-started/software/#explorers' | relative_url }}) can be shared as a payment confirmation. For Lightning transactions, the so-called `preimage` can be considered a proof of payment.
+As on-chain transactions can be globally verified by anyone, a link to a [bitcoin explorer]({{ '/guide/getting-started/software/#explorers' | relative_url }}) can be shared as a payment confirmation. For lightning transactions, the so-called `preimage` can be considered a proof of payment.
@@ -307,11 +307,11 @@ Effectively supporting users when problems occur can build trust and confidence,
### Encouraging lightning network
-Lightning is likely to be the best option for the majority of payments a user makes. It will be faster, more private, and cost less. An ideal scenario would be where the user does not spend time considering whether to pay on-chain or Lightning — it's all bitcoin to them.
+Lightning is likely to be the best option for the majority of payments a user makes. It will be faster, more private, and cost less. An ideal scenario would be where the user does not spend time considering whether to pay on-chain or lightning — it's all bitcoin to them.
-However, this can be challenging with the variety of different payment formats between on-chain and Lightning. What happens when the user is trying to pay somebody, but the receiving party has given them an on-chain address instead of a Lightning invoice?
+However, this can be challenging with the variety of different payment formats between on-chain and lightning. What happens when the user is trying to pay somebody, but the receiving party has given them an on-chain address instead of a lightning invoice?
-If your wallet is Lightning-only, the user will be unable to proceed with making payment. However, even if your wallet allows the user to send on-chain payments, this payment could still result in a higher transaction fee than they would have incurred over Lightning. If it's in the user's best interest to pay over Lightning, then let them know and help them determine what to do next.
+If your wallet is lightning-only, the user will be unable to proceed with making payment. However, even if your wallet allows the user to send on-chain payments, this payment could still result in a higher transaction fee than they would have incurred over lightning. If it's in the user's best interest to pay over lightning, then let them know and help them determine what to do next.
{% include image-gallery.html pages = page.imagesLightning %}
diff --git a/guide/designing-products/common-user-flows.md b/guide/designing-products/common-user-flows.md
index a68c76111..b91a28ddf 100644
--- a/guide/designing-products/common-user-flows.md
+++ b/guide/designing-products/common-user-flows.md
@@ -259,7 +259,7 @@ A good starting point today is an [HD wallet](/guide/glossary/wallet/#hd-wallet)
Some older software may create wallets with outdated technical formats, while others allow users to choose specific formats for their particular needs. Generally, this is difficult to understand for regular users and should either be automatically handled with good default settings, or explained in layman's terms. [Wallets Recovery](https://walletsrecovery.org) provides a great overview of different implementations and how nuanced some of the differences are.
-Most modern wallet applications should aim to support the Lightning network in addition to the base layer. While there are different options for how the applications interact with a Lightning network node, an HD wallet works fine for storing the required keys.
+Most modern wallet applications should aim to support the lightning network in addition to the base layer. While there are different options for how the applications interact with a lightning network node, an HD wallet works fine for storing the required keys.
Wallets can also be created with control shared between several other wallets, so called [multi-key wallets](/guide/private-key-management/multi-key/) (or multi-signature / multi-sig). This is typically done to increase security.
@@ -342,11 +342,11 @@ While we all prefer to receive bitcoin, there are times when we need to send the