From b8f8791211bb3fe1d682b50916d0f13f84edb342 Mon Sep 17 00:00:00 2001 From: Jakub Szwedo Date: Sun, 25 Sep 2022 17:57:00 +0200 Subject: [PATCH 1/3] Lowercase "lightning network" Changes "lightning network" to lowercase across the whole guide, except when it's the beginning of the sentence, a title for a section or subsection or when it's a part of a research/paper title. --- README.md | 2 +- calendar.md | 2 +- guide.md | 4 +-- guide/daily-spending-wallet/activity.md | 22 ++++++++-------- guide/daily-spending-wallet/contacts.md | 14 +++++----- guide/daily-spending-wallet/security.md | 2 +- guide/daily-spending-wallet/sending.md | 26 +++++++++---------- guide/designing-products/common-user-flows.md | 12 ++++----- guide/designing-products/interoperability.md | 14 +++++----- guide/designing-products/personal-finance.md | 4 +-- guide/designing-products/units-and-symbols.md | 4 +-- guide/designing-products/user-research.md | 4 +-- guide/getting-started/hardware.md | 10 +++---- guide/getting-started/open-design.md | 2 +- guide/getting-started/principles.md | 4 +-- guide/getting-started/software.md | 12 ++++----- guide/getting-started/technology-primer.md | 16 ++++++------ guide/getting-started/visual-language.md | 14 +++++----- .../getting-started/why-bitcoin-is-unique.md | 2 +- guide/glossary/index.md | 8 +++--- guide/how-it-works/coin-selection.md | 2 +- guide/how-it-works/introduction.md | 4 +-- guide/how-it-works/lightning-services.md | 20 +++++++------- .../private-key-management/cloud-backup.md | 6 ++--- .../external-signers.md | 2 +- .../private-key-management/multi-key.md | 6 ++--- .../private-key-management/overview.md | 6 ++--- guide/how-it-works/transactions.md | 22 ++++++++-------- guide/resources/design-challenges.md | 2 +- guide/resources/design-research.md | 12 ++++----- guide/shared-wallet.md | 2 +- projects.md | 4 +-- 32 files changed, 133 insertions(+), 133 deletions(-) diff --git a/README.md b/README.md index 4a800ec2e..c3eb4eb00 100644 --- a/README.md +++ b/README.md @@ -44,7 +44,7 @@ The process to create the guide started in the summer of 2020. The first draft o On June 2, 2021, the community [announced](https://bitcoindesign.medium.com/announcing-the-bitcoin-design-guide-c4955d859fda) the launch of the initial version of the Bitcoin Design Guide to the public. -On February 9, 2022, the community [announced](https://bitcoindesign.medium.com/design-better-lightning-wallets-with-the-bitcoin-design-guide-v2-2669f610ebc7) the completion of a major revision of the guide to include content about the Lightning network. +On February 9, 2022, the community [announced](https://bitcoindesign.medium.com/design-better-lightning-wallets-with-the-bitcoin-design-guide-v2-2669f610ebc7) the completion of a major revision of the guide to include content about the lightning network. See the [roadmap](https://github.com/orgs/BitcoinDesign/projects/2) for what we're currently working on. diff --git a/calendar.md b/calendar.md index fcf061620..32accb516 100644 --- a/calendar.md +++ b/calendar.md @@ -46,7 +46,7 @@ Join community calls, design reviews, project discussions and other events. Our {% include emoji-box.html emoji = "⚡️" title = "Bitcoin design sprints" - description = "Our collaborative design sessions with Lightning wallet projects." + description = "Our collaborative design sessions with lightning wallet projects." url = "https://github.com/BitcoinDesign/Meta/issues/244" %} diff --git a/guide.md b/guide.md index fcc7016b0..71b651a01 100644 --- a/guide.md +++ b/guide.md @@ -87,7 +87,7 @@ A closer look at the design process and frameworks, from [personal finance use c

[Daily spending wallet]({{ '/guide/daily-spending-wallet/' | relative_url }})

-An in-depth exploration of a mobile wallet for a Lightning-first, on-the-go use case. Covers primary user flows like [first use]({{ '/guide/onboarding/first-use/' | relative_url }}), [sending]({{ '/guide/payments/send/' | relative_url }}) and [requesting]({{ '/guide/payments/request/' | relative_url }}), features like [backup]({{ '/guide/onboarding/backing-up-a-wallet/' | relative_url }}) and [contacts]({{ '/guide/payments/contacts/' | relative_url }}), and more. +An in-depth exploration of a mobile wallet for a lightning-first, on-the-go use case. Covers primary user flows like [first use]({{ '/guide/onboarding/first-use/' | relative_url }}), [sending]({{ '/guide/payments/send/' | relative_url }}) and [requesting]({{ '/guide/payments/request/' | relative_url }}), features like [backup]({{ '/guide/onboarding/backing-up-a-wallet/' | relative_url }}) and [contacts]({{ '/guide/payments/contacts/' | relative_url }}), and more.
@@ -150,7 +150,7 @@ An overview and considerations for bitcoin wallets that are managed by multiple

[How it works]({{ '/guide/how-it-works/' | relative_url }})

-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..ccaac747e 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. @@ -59,7 +59,7 @@ imagesInfo: imagesProcessing: - file: processing alt: Payment screen showing the transaction is being sent - caption: Lightning transactions typically complete in seconds and don't require loaders. + caption: lightning transactions typically complete in seconds and don't require loaders. - file: processing-longer-wait alt: Payment screen showing that the transaction is taking longer than expected caption: If a transaction takes uncharacteristically long, users should be informed. @@ -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 @@ -92,7 +92,7 @@ imagesReview: - file: enter-pin-before-payment alt: Enter PIN screen caption: Optionally, this wallet is asking the user to enter their PIN as the final step before paying. -imagesLightning: +imageslightning: - file: home alt: Wallet home screen with amount input, pay and request options caption: The user taps the scan button on the home 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,13 +307,13 @@ 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 %} +{% include image-gallery.html pages = page.imageslightning %} In this example, the user scans a QR to make a payment. This wallet recognizes it as an on-chain address. It is capable of making the on-chain payment with submarine swaps. However, that would involve a longer confirmation time and a higher fee for such a small payment. It immediately pulls up a modal notification to warn the user that they will have to wait longer for the payment to settle and pay a higher fee. It informs them they can pay instantly if they can get a different type of QR code from the sender. 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
-Bitcoin can be sent two ways; on the primary base layer, or the secondary [Lightning network](/guide/glossary/#lightning-network) layer. +Bitcoin can be sent two ways; on the primary base layer, or the secondary [lightning network](/guide/glossary/#lightning-network) layer. On the base layer, once a transaction is broadcast from a wallet, the bitcoin network starts processing it. Users may want to stay informed about this progress, particularly when a transaction takes longer than expected. The average transaction time on the base layer is 10 minutes, but this can vary a lot depending on the fee the sender was willing to pay. In extreme cases, it is possible to retroactively increase the transaction fee to get validated faster with a [Replace-by-Fee](/guide/glossary/#replace-by-fee-rbf) technique. -On the Lightning network, transactions happen inside payment channels that are established on the base layer between two participants. The state of ownership of the bitcoin within the channel is maintained by the participant Lightning network nodes. Transactions on this layer are almost instant, and have negligible fees. However, there are fees to open and close channels, as this is recorded on the base layer. +On the lightning network, transactions happen inside payment channels that are established on the base layer between two participants. The state of ownership of the bitcoin within the channel is maintained by the participant lightning network nodes. Transactions on this layer are almost instant, and have negligible fees. However, there are fees to open and close channels, as this is recorded on the base layer. To find out more, visit the [Sending bitcoin](/guide/payments/send/) page. @@ -396,7 +396,7 @@ While it is possible to re-use the same receiving address repeatedly, this pract For more information-rich base layer requests, [BIP 21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) describes a URI scheme to turn requests into links that can be shared like any other link. On click, wallets that support this scheme can immediately show the send screen with the correct information pre-filled. Links can also be encoded and transmitted via QR code. Since the scheme also allows for the inclusion of an address label and transaction description, it allows both sender and recipient to stay organized. -For requests on the Lightning network, the receiver needs to create a lightning invoice that includes the amount, and then share the invoice with the sender. +For requests on the lightning network, the receiver needs to create a lightning invoice that includes the amount, and then share the invoice with the sender. ## Receiving bitcoin @@ -427,7 +427,7 @@ Once a user has requested payment, they are naturally interested in knowing when A user may also want to check in and see if any previous requests have not been completed yet. This is easily possible if the user has initiated all requests on the same wallet and used a new address for each one. In this case, a request can be considered fulfilled if at least one payment has been received with the total amount the user asked for. It is not as clear if addresses are getting re-used (how to tell which payment was for which purpose?) or the request has been made with another wallet (as this metadata is not stored and synced via the bitcoin network). -On the Lightning network, receiving bitcoin requires an invoice. This makes it easy to track if payments have been completed or not. +On the lightning network, receiving bitcoin requires an invoice. This makes it easy to track if payments have been completed or not.
@@ -472,7 +472,7 @@ The owner may want to increase the security of their wallet, either by using a s In the worst-case scenario, the wallet might have been compromised, and funds should be saved by sending them all to a different bitcoin wallet. -Whatever the reason, the import and backup of wallets is a vital function for users that applications should support. While it is easy to send all funds to a new address, additional meta and state data stored in wallet applications also need to be considered for full compatibility. It's not recommended to switch wallets that include funds on the Lightning network, as standards for backing up channel state have yet to emerge. See also, [Wallet interoperability](/guide/designing-products/interoperability/). +Whatever the reason, the import and backup of wallets is a vital function for users that applications should support. While it is easy to send all funds to a new address, additional meta and state data stored in wallet applications also need to be considered for full compatibility. It's not recommended to switch wallets that include funds on the lightning network, as standards for backing up channel state have yet to emerge. See also, [Wallet interoperability](/guide/designing-products/interoperability/). diff --git a/guide/designing-products/interoperability.md b/guide/designing-products/interoperability.md index 3665ada66..c1c92378b 100644 --- a/guide/designing-products/interoperability.md +++ b/guide/designing-products/interoperability.md @@ -88,9 +88,9 @@ Wallet backups generated in one wallet application should be able to be easily r Over the years, bitcoin wallets have implemented various features in different ways, partly because standards take time to evolve. Standards such as [BIP39 recovery phrases](/guide/glossary/#recovery-phrase) and [wallet descriptors](/guide/glossary/#output-script-descriptor) should be used to create wallet backups within your applications. -Backing up payment channels that are part of the Lightning network can be more difficult. Currently, no standards exist for this, nor is it possible to have a static backup method like you can with on-chain bitcoin. Payment channels states regularly change and thus need to be regularly updated. Some applications make use of static-channel-backup (SCB) files, though this is still an evolving standard. +Backing up payment channels that are part of the lightning network can be more difficult. Currently, no standards exist for this, nor is it possible to have a static backup method like you can with on-chain bitcoin. Payment channels states regularly change and thus need to be regularly updated. Some applications make use of static-channel-backup (SCB) files, though this is still an evolving standard. -It should be convenient for users to back up the relevant information they need for recovery with other applications. An example solution is to provide a [printable template or downloadable PDF](https://www.figma.com/file/sJYnyi2amehFJ2JpDgj978/Bitcoin-Wallet---Paper-Backup-Template?node-id=1%3A535) with the wallet name, software name and version, address type, wallet descriptors, and other non-standard information. If your application makes use of the Lightning network this could be done in conjunction with regular, encrypted SCB cloud backups. +It should be convenient for users to back up the relevant information they need for recovery with other applications. An example solution is to provide a [printable template or downloadable PDF](https://www.figma.com/file/sJYnyi2amehFJ2JpDgj978/Bitcoin-Wallet---Paper-Backup-Template?node-id=1%3A535) with the wallet name, software name and version, address type, wallet descriptors, and other non-standard information. If your application makes use of the lightning network this could be done in conjunction with regular, encrypted SCB cloud backups. @@ -109,7 +109,7 @@ It should be convenient for users to back up the relevant information they need Data that users create, such as [contacts]({{ '/guide/daily-spending-wallet/contacts/' | relative_url }}), payment descriptions, notes, etc., should be interoperable between different bitcoin applications. -Transaction data is stored on the bitcoin blockchain and available in any wallet a user has set up. However, transaction data does not contain any information about: the reasons why a transaction was made, who owns each address, which node a Lightning payment was made to, etc. +Transaction data is stored on the bitcoin blockchain and available in any wallet a user has set up. However, transaction data does not contain any information about: the reasons why a transaction was made, who owns each address, which node a lightning payment was made to, etc. To better understand and organize their finances, users typically enrich transaction data by assigning contacts, notes, labels, and other useful information. This data should be stored in standardized, open formats and easily synced between applications. This is especially useful for users who rely on multiple devices. @@ -153,7 +153,7 @@ Static QR codes can only contain small amounts of information. If you need to in layout = "float-right-desktop" %} -Most bitcoin applications rely on external data sources (like currency conversion data) and may also have integrations with third parties (like an external block or Lightning explorer). +Most bitcoin applications rely on external data sources (like currency conversion data) and may also have integrations with third parties (like an external block or lightning explorer). Whenever possible, it should be easy for users to learn about these dependencies and choose alternatives. @@ -189,13 +189,13 @@ Although every application will have its own unique interface, there are certain layout = "float-right-desktop" %} -Connecting to the bitcoin or Lightning network should be as trust-minimized and privacy preserving as possible. While it is convenient when applications provide their own node connection, it is beneficial to allow users to connect to a trusted node or their own self-hosted bitcoin or Lightning node. +Connecting to the bitcoin or lightning network should be as trust-minimized and privacy preserving as possible. While it is convenient when applications provide their own node connection, it is beneficial to allow users to connect to a trusted node or their own self-hosted bitcoin or lightning node. Having the option to choose how that data is queried, say using [Neutrino over SPV](https://bitcoin.design/guide/glossary/node/#light-nodes), should also be an option. This results in better network [decentralization](https://bitcoin.design/guide/getting-started/principles/#decentralization), and has privacy and [security](https://bitcoin.design/guide/getting-started/principles/#security) benefits for users. -If your application uses the Lightning network, users should be running their own Lightning node. However, there are certain aspects of a Lightning node that can be outsourced, such as creating inbound liquidity from an LSP or constructing payment paths. +If your application uses the lightning network, users should be running their own lightning node. However, there are certain aspects of a lightning node that can be outsourced, such as creating inbound liquidity from an LSP or constructing payment paths. -Your application should give users options as to which services (if any) they want to trust a third party to conduct. Your application should try to avoid having users locked into your application and give them various options for outsourcing Lightning services. +Your application should give users options as to which services (if any) they want to trust a third party to conduct. Your application should try to avoid having users locked into your application and give them various options for outsourcing lightning services. diff --git a/guide/designing-products/personal-finance.md b/guide/designing-products/personal-finance.md index 1ae8a5269..54e5c1f52 100644 --- a/guide/designing-products/personal-finance.md +++ b/guide/designing-products/personal-finance.md @@ -99,7 +99,7 @@ For small, frequent payments, we generally accept greater risk in exchange for c Most stores (online and offline) don’t currently accept bitcoin. When they do, users who already pay with smartphones or NFC-enabled credit cards can easily transition to bitcoin apps. -A typical scenario could be that users create dedicated mobile bitcoin wallets for on-the-go payments, in addition to having separate wallets for larger amounts. Similar to having a bank account and regularly taking out cash at an ATM, users could refill their mobile wallets. The mobile wallet is connected to the Lightning network, which allows the user to make very fast (almost instant) payments. This wallet may use [automatic cloud backup]({{ '/guide/how-it-works/private-key-management/cloud-backup/' | relative_url }}) for the private key as well as the lightning channel state. The user's primary wallet however, would be more strongly secured with a [hardware wallet]({% link guide/getting-started/hardware.md %}#hardware-wallets) or even a [multi-key]({{ '/guide/how-it-works/private-key-management/multi-key/' | relative_url }}) configuration. This would mirror the primary focus of convenience over security. Beyond key management, payment interactions could be identical to what users are already familiar with. +A typical scenario could be that users create dedicated mobile bitcoin wallets for on-the-go payments, in addition to having separate wallets for larger amounts. Similar to having a bank account and regularly taking out cash at an ATM, users could refill their mobile wallets. The mobile wallet is connected to the lightning network, which allows the user to make very fast (almost instant) payments. This wallet may use [automatic cloud backup]({{ '/guide/how-it-works/private-key-management/cloud-backup/' | relative_url }}) for the private key as well as the lightning channel state. The user's primary wallet however, would be more strongly secured with a [hardware wallet]({% link guide/getting-started/hardware.md %}#hardware-wallets) or even a [multi-key]({{ '/guide/how-it-works/private-key-management/multi-key/' | relative_url }}) configuration. This would mirror the primary focus of convenience over security. Beyond key management, payment interactions could be identical to what users are already familiar with. For more on this use case, see the [daily spending reference design]({{ '/guide/daily-spending-wallet' | relative_url }}). @@ -138,7 +138,7 @@ The higher-value of these payments necessitates a greater level of security than At the moment, a good solution is a desktop application which relies on a hardware device to sign transactions. This reduces the risk of keeping funds on a mobile wallet configuration but adds acceptable friction for transactions that occur less frequently. See the [savings wallet reference design]({{ '/guide/savings-wallet/' | relative_url }}) for an exploration of this user experience. -A disadvantage to this solution is that it does not use the Lightning network, meaning that the user will need to wait longer for their [transaction to confirm]({{'/guide/how-it-works/transactions/#7-confirmations' | relative_url}}) as well as pay an on-chain transaction fee. However, this will likely not always be the case: in the future, projects such as [Lightning Signer](https://gitlab.com/lightning-signer/docs) may solve this issue by allowing the private keys to be stored separately from the Lightning node on hardware that is security-hardened. +A disadvantage to this solution is that it does not use the lightning network, meaning that the user will need to wait longer for their [transaction to confirm]({{'/guide/how-it-works/transactions/#7-confirmations' | relative_url}}) as well as pay an on-chain transaction fee. However, this will likely not always be the case: in the future, projects such as [Lightning Signer](https://gitlab.com/lightning-signer/docs) may solve this issue by allowing the private keys to be stored separately from the lightning node on hardware that is security-hardened. ## Emergency funds diff --git a/guide/designing-products/units-and-symbols.md b/guide/designing-products/units-and-symbols.md index ca8bb43f5..2e5a8419d 100644 --- a/guide/designing-products/units-and-symbols.md +++ b/guide/designing-products/units-and-symbols.md @@ -73,7 +73,7 @@ Bitcoin, bits, sats. The format and presentation of bitcoin values are probably ## Current adoption -Bitcoin is most commonly expressed as BTC (bitcoin) or sat (satoshi), with 1 bitcoin being 100 million satoshi. The unicode symbol ₿, formalized in June 2017, is also used to represent BTC (bitcoin), but typeface support is still limited. While not as common, other denominations of BTC such as mBTC (millibitcoins), μBTC (bits), as well as msat (millisatoshi) in the Lightning network are sometimes used. The chart below illustrates how each unit relates to the bitcoin unit. +Bitcoin is most commonly expressed as BTC (bitcoin) or sat (satoshi), with 1 bitcoin being 100 million satoshi. The unicode symbol ₿, formalized in June 2017, is also used to represent BTC (bitcoin), but typeface support is still limited. While not as common, other denominations of BTC such as mBTC (millibitcoins), μBTC (bits), as well as msat (millisatoshi) in the lightning network are sometimes used. The chart below illustrates how each unit relates to the bitcoin unit. | Unit | Symbol | Bitcoin value | | ------------ | ------------ | ----------------- | @@ -90,7 +90,7 @@ For more information, see the Bitcoin Wiki: ## Recommended interaction -When displaying bitcoin values, the default unit for on-chain wallets should be bitcoin with 8 decimal places, and satoshi for Lightning wallets. Due to the challenging nature of scanning amounts with more than 2 decimal places, the user should be given the option to choose their preferred format across the application (for example, in the application's settings) as well as contextually, whenever the value is primarily displayed. +When displaying bitcoin values, the default unit for on-chain wallets should be bitcoin with 8 decimal places, and satoshi for lightning wallets. Due to the challenging nature of scanning amounts with more than 2 decimal places, the user should be given the option to choose their preferred format across the application (for example, in the application's settings) as well as contextually, whenever the value is primarily displayed. Product teams can choose an approach based on their audience and targeted use case. Lightning wallets for daily spending may be better served by defaulting to satoshi denomination due to the low amounts involved, while bitcoin can be used for savings-focused applications. diff --git a/guide/designing-products/user-research.md b/guide/designing-products/user-research.md index 0609f6b41..24c146682 100644 --- a/guide/designing-products/user-research.md +++ b/guide/designing-products/user-research.md @@ -125,9 +125,9 @@ Bitcoin only knows its users through pseudonymous addresses. We can analyze on-c Bitcoin is a protocol with [layers](https://bitcoin.design/guide/getting-started/technology-primer/#do-all-transactions-have-to-be-this-secure) built on top of it. -The base layer is a public record of transactions that can easily be analyzed. However, layers built on top, such as [Lightning network](/guide/getting-started/technology-primer/#the-lightning-payment-network) make analysis of specific transaction impossible, thanks to [payment channels](/guide/getting-started/technology-primer/#what-is-a-payment-channel). +The base layer is a public record of transactions that can easily be analyzed. However, layers built on top, such as [lightning network](/guide/getting-started/technology-primer/#the-lightning-payment-network) make analysis of specific transaction impossible, thanks to [payment channels](/guide/getting-started/technology-primer/#what-is-a-payment-channel). -While we often can’t know who is responsible for a specific transaction, on the Lightning network, we can attempt to analyze the overall network activity and look into metrics such as number of nodes, network capacity, payment channels changes. +While we often can’t know who is responsible for a specific transaction, on the lightning network, we can attempt to analyze the overall network activity and look into metrics such as number of nodes, network capacity, payment channels changes. No other currency in history has offered such a transparent way to analyze network activity. As designers, what can we learn from this data that allows us to improve the experience of our users. diff --git a/guide/getting-started/hardware.md b/guide/getting-started/hardware.md index 97cb1bffb..89cfa2861 100644 --- a/guide/getting-started/hardware.md +++ b/guide/getting-started/hardware.md @@ -79,11 +79,11 @@ You may already be familiar with physical security keys from your bank or work. Bitcoin hardware wallets, also called signers, act like bitcoin-centric security keys. They isolate the recovery phrase, private keys, and other sensitive data like output descriptors from the internet and other devices. -Hardware wallets only exchange non-sensitive information with external devices. Sensitive processes happen on the device, such as signing a transaction to open a Lightning network payment channel. Most interactions with hardware wallets happen via desktop [software, like wallets]({{ '/guide/getting-started/software/#wallets' | relative_url }}). +Hardware wallets only exchange non-sensitive information with external devices. Sensitive processes happen on the device, such as signing a transaction to open a lightning network payment channel. Most interactions with hardware wallets happen via desktop [software, like wallets]({{ '/guide/getting-started/software/#wallets' | relative_url }}). ## Nodes -A node is a device that participates in a network. There are two types of nodes to understand: A bitcoin node that participates in the bitcoin network and a Lightning node that participates in the Lightning network. For a deeper dive into what purpose these nodes serve check out the [technology primer]({{ '/guide/getting-started/technology-primer/' | relative_url }}). +A node is a device that participates in a network. There are two types of nodes to understand: A bitcoin node that participates in the bitcoin network and a lightning node that participates in the lightning network. For a deeper dive into what purpose these nodes serve check out the [technology primer]({{ '/guide/getting-started/technology-primer/' | relative_url }}). {% include picture.html image = "/assets/images/guide/getting-started/hardware/node-hardware.jpg" @@ -97,9 +97,9 @@ A node is a device that participates in a network. There are two types of nodes It is quite common to have dedicated hardware to run bitcoin [node software]({{ '/guide/getting-started/software/#nodes' | relative_url }}). This ensures your node stays in sync with the network and is regularly verifying the network rules, increasing bitcoin’s security. Some node software also comes packaged with other third-party applications, which may benefit from dedicated hardware and more regular uptime. -Lightning node software can be run on a smartphone. Though, this often comes with trusting a third-party for certain node functions such as payment path construction. For this reason, dedicated hardware Lightning nodes may be a better option for those who do not want a trust-minimized setup. +Lightning node software can be run on a smartphone. Though, this often comes with trusting a third-party for certain node functions such as payment path construction. For this reason, dedicated hardware lightning nodes may be a better option for those who do not want a trust-minimized setup. -Heavy users of the Lightning Network, such as routing node operators, often run Lightning nodes on dedicated hardware. Lightning nodes require 24/7 uptime, which is much easier to achieve with dedicated hardware. Lightning nodes also require the private keys to be stored on the same device. Dedicated hardware reduces the attack surface and makes it easier to secure private keys. +Heavy users of the lightning network, such as routing node operators, often run lightning nodes on dedicated hardware. Lightning nodes require 24/7 uptime, which is much easier to achieve with dedicated hardware. Lightning nodes also require the private keys to be stored on the same device. Dedicated hardware reduces the attack surface and makes it easier to secure private keys. [Plug-and-play hardware nodes](https://samouraiwallet.com/nodl) exist and make it simple to set up a dedicated hardware node. The most common way people run dedicated hardware nodes is installing a node OS, like [Umbrel](https://getumbrel.com/) or [MyNode](https://mynodebtc.com/), on a hardware device. @@ -139,7 +139,7 @@ Bitcoin Automated Teller Machines (ATM) are a convenient way to buy or sell bitc Much like traditional ATMs, bitcoin ATMs allow the deposit and withdrawal of money. Bitcoin ATMs, however allow someone to deposit fiat currencies in exchange for bitcoin. -Modern bitcoin ATMs take advantage of the bitcoin Lightning network. This enables almost instant withdrawals and cheaper fees, making the purchase experience more friendly and cost-effective. +Modern bitcoin ATMs take advantage of the bitcoin lightning network. This enables almost instant withdrawals and cheaper fees, making the purchase experience more friendly and cost-effective. Bitcoin ATMs are usually bound to local money transmission laws and regulations, such as Know Your Customer (KYC) and Anti-Money Laundering (AML) regulations. More on [Wikipedia](https://en.wikipedia.org/wiki/Bitcoin_ATM). diff --git a/guide/getting-started/open-design.md b/guide/getting-started/open-design.md index 8cf0e90b7..78318b186 100644 --- a/guide/getting-started/open-design.md +++ b/guide/getting-started/open-design.md @@ -140,7 +140,7 @@ Open-source software development has existed for decades. Public review and deba ### Test, redesign, and engage in feedback -- Experiment with bitcoin and Lightning. Download a wallet and test small amounts. You can also test network features without using real bitcoin on Testnet. It works with some wallets. +- Experiment with bitcoin and lightning. Download a wallet and test small amounts. You can also test network features without using real bitcoin on Testnet. It works with some wallets. - Redesign a bitcoin and/or lightning application or focus on a user experience issue that interests you. Even as a brief exercise, a redesign is a great way to develop understanding of how something works. - Join a [Design Review](https://github.com/BitcoinDesign/Meta/issues?q=is%3Aissue+is%3Aopen+Design+Review+Call+). A call focusing on giving feedback to improve a specific bitcoin product. Products vary by call. - Join the [Wallet Improvement Project](https://github.com/BitcoinDesign/Guide/issues/493). It tests a list of real world bitcoin projects and suggests redesigns to their makers. diff --git a/guide/getting-started/principles.md b/guide/getting-started/principles.md index ae8ea349c..d16d5da08 100644 --- a/guide/getting-started/principles.md +++ b/guide/getting-started/principles.md @@ -189,7 +189,7 @@ Bitcoin is an open-source protocol, operating in a decentralized manner. This ha **Do** - Support import and export of wallet data - For on-chain wallets, allow users to export and import wallets directly - - For Lightning wallets, offer a clear path for the user to move their Lightning funds to another wallet + - For lightning wallets, offer a clear path for the user to move their lightning funds to another wallet - Support as many relevant [BIPs]({{'/guide/glossary/#bip---bitcoin-improvement-proposal' | relative_url}}) and [BOLTs]({{'/guide/glossary/#bolt---basis-of-lightning-technology' | relative_url}}) as possible - Be transparent with which ones you do and don’t support - Maximize backwards compatibility @@ -255,7 +255,7 @@ The bitcoin network doesn’t need to know your name for you to use it. Strive t **Do** - Minimize the personal information you collect -- Encourage usage of the Lightning network for improved privacy +- Encourage usage of the lightning network for improved privacy - Avoid address reuse - Embrace privacy-preserving options when relevant (running a full node, compact block filters, Tor, coin selection, schnorr signatures, payjoin, coinswap, etc.) diff --git a/guide/getting-started/software.md b/guide/getting-started/software.md index 15f43e478..6f44c2acc 100644 --- a/guide/getting-started/software.md +++ b/guide/getting-started/software.md @@ -57,7 +57,7 @@ Wallets are perhaps the most important bitcoin applications. They provide easy-t Wallet features vary by application but always include [wallet setup]({{ '/guide/designing-products/common-user-flows/#software-onboarding' | relative_url }}), balance and transaction records, and the ability to [send]({{ '/guide/payments/send/' | relative_url }}) and [receive]({{ '/guide/payments/request/' | relative_url }}) bitcoin. The full range of features that wallets may support is broad and includes security and [privacy]({{ '/guide/payments/privacy/' | relative_url }}) options, currency exchange features, accounting tools, [interoperability]({{ '/guide/getting-started/principles/#interoperability' | relative_url }}), accessibility, and localization options. Few wallets support the full range of features. The reasons for this can vary from; standards not being available when the wallet was first developed (newer [address formats]({{ '/guide/glossary/address/' | relative_url }}) or [HD wallets]({{ '/guide/glossary/wallet/#hd-wallet' | relative_url }}) for example), the choice to not include anything that implies trusting a third party, or simply because it does not fit the intended use case for the software. -The features you include should be based on the needs of your users. Try to maximize interoperability with other bitcoin products by supporting modern standards and emerging technologies. For example, a wallet project started today should almost certainly support the Lightning network. +The features you include should be based on the needs of your users. Try to maximize interoperability with other bitcoin products by supporting modern standards and emerging technologies. For example, a wallet project started today should almost certainly support the lightning network. Due to bitcoin’s open-source nature, anyone with the technical skills can develop a bitcoin wallet. Many code libraries are available to simplify this task. @@ -67,7 +67,7 @@ Due to bitcoin’s open-source nature, anyone with the technical skills can deve
-Exchanges let users swap between currencies and networks (for example USD to bitcoin, or from the base layer to the Lightning network). They typically fall into three general categories. +Exchanges let users swap between currencies and networks (for example USD to bitcoin, or from the base layer to the lightning network). They typically fall into three general categories. {% include image.html @@ -94,13 +94,13 @@ If the blockchain is a public database, explorers are simply windows into that d For bitcoin, block explorers let users view transaction data, latest blocks, block height, etc. They also provide insight into bigger picture activity on the bitcoin network, such as daily transaction numbers. For example, there are typically fewer transactions on weekends, resulting in lower fees, ideal for low-priority transactions. -As transactions in Lightning payment channels are not recorded on the blockchain, there are also Lightning network explorers. These let you see public information about the nodes and the network, such as channel count, capacity and status. Only participant nodes can look up specific transaction information in a channel. +As transactions in lightning payment channels are not recorded on the blockchain, there are also lightning network explorers. These let you see public information about the nodes and the network, such as channel count, capacity and status. Only participant nodes can look up specific transaction information in a channel. {% include image.html image = "/assets/images/guide/getting-started/software/explorer-example.jpg" retina = "/assets/images/guide/getting-started/software/explorer-example@2x.jpg" alt-text = "Illustrative interface for block explorer software" - caption = 'Explorers offer insight into activity on the bitcoin and Lightning networks. Texture by [Mike van den Bos](https://unsplash.com/@mike_van_den_bos){:target="_blank" rel="nofollow"} on [Unsplash](https://unsplash.com){:target="_blank" rel="nofollow"}.' + caption = 'Explorers offer insight into activity on the bitcoin and lightning networks. Texture by [Mike van den Bos](https://unsplash.com/@mike_van_den_bos){:target="_blank" rel="nofollow"} on [Unsplash](https://unsplash.com){:target="_blank" rel="nofollow"}.' width = 800 height = 492 %} @@ -139,7 +139,7 @@ Payment processing applications offer easy-to-use online stores and point-of-sal Bitcoin [node]({{ '/guide/glossary/node/' | relative_url }}) software connects to and participates in the bitcoin network. Nodes typically download and broadcast user transactions, and optionally help verify blockchain data more broadly. Some wallet software comes with built-in node capabilities, such as [Bitcoin Core]({{ '/guide/glossary/#bitcoin-core-client' | relative_url }}), but most wallet software connects to external nodes. Learn more on the [Node page]({{ '/guide/glossary/node/' | relative_url }}) in the glossary. -Lightning node software connects to and participates in the Lightning network, extending bitcoin with payment channels to increase transaction speed and lower costs. It is becoming widely adopted and accepted as the preferred way to scale bitcoin. +Lightning node software connects to and participates in the lightning network, extending bitcoin with payment channels to increase transaction speed and lower costs. It is becoming widely adopted and accepted as the preferred way to scale bitcoin. It’s common to use node management software separate from the node software itself. This simplifies the setup, management and monitoring of nodes by providing graphical user interfaces to interact with the lower level node software instead of CLIs. @@ -176,7 +176,7 @@ Bitcoin [mining]({{ '/guide/getting-started/technology-primer/#how-is-the-blockc Mining has become primarily a professional undertaking with dedicated software to manage racks of [mining hardware]({{ '/guide/getting-started/hardware/#mining-hardware' | relative_url }}). However, some wallets still offer mining features, and there are also cloud mining providers that allow customers to rent mining capacity. -Mining does not exist for transactions on the Lightning network, so there is no equivalent software. However, opening and closing payment channels on Lightning involve transactions that need to be mined on the bitcoin network. +Mining does not exist for transactions on the lightning network, so there is no equivalent software. However, opening and closing payment channels on lightning involve transactions that need to be mined on the bitcoin network.
diff --git a/guide/getting-started/technology-primer.md b/guide/getting-started/technology-primer.md index b19221021..5c12af705 100644 --- a/guide/getting-started/technology-primer.md +++ b/guide/getting-started/technology-primer.md @@ -18,7 +18,7 @@ videos: Editor's notes -This is the second version of the tech primer that introduces the Lightning +This is the second version of the tech primer that introduces the lightning network to the reader. It's an introduction to bitcoin tech concepts based on simple questions readers might have, like "What is a bitcoin" and "How do I own bitcoin" but also sets up the foundations about @@ -182,7 +182,7 @@ Transactions get verified and stored by the entire network of nodes and miners w While creating a transaction to move your funds from one address to another is common, setting up more complex spending rules is also possible. Such rules could require multiple parties to agree before moving funds, how much each is entitled to, and even the amount of time that must pass before a transfer. These transaction features make bitcoin customizable so that it's possible to build other applications and even networks on top of the base layer. -There are multiple scaling solutions built on top of bitcoin's base layer, but we will be focusing on the Lightning Network in this guide. +There are multiple scaling solutions built on top of bitcoin's base layer, but we will be focusing on the lightning network in this guide. **More info** - [Transaction lifecycle](/guide/how-it-works/transactions/) @@ -210,20 +210,20 @@ A payment channel is a [joint account]({{'/guide/glossary/#multi-signature-walle -## The Lightning payment network +## The lightning payment network
{% include image.html image = "/assets/images/guide/getting-started/technology/lightning-network.jpg" retina = "/assets/images/guide/getting-started/technology/lightning-network@2x.jpg" - alt-text = "Lightning nodes connected to one another" + alt-text = "lightning nodes connected to one another" width = 400 height = 400 layout = "float-right-desktop" %} -The Lightning network is a network of payment channels. Lightning nodes allow you to have multiple channels with different parties to route payments through. This new network forms a second layer on top of bitcoin. This has some privacy benefits, too: payment information is only recorded to the blockchain when the payment channel is opened and closed. Every payment that happens in between the opening and closing is not stored “on-chain”. +The lightning network is a network of payment channels. Lightning nodes allow you to have multiple channels with different parties to route payments through. This new network forms a second layer on top of bitcoin. This has some privacy benefits, too: payment information is only recorded to the blockchain when the payment channel is opened and closed. Every payment that happens in between the opening and closing is not stored “on-chain”.
## What are ways to receive bitcoin? @@ -239,7 +239,7 @@ The Lightning network is a network of payment channels. Lightning nodes allow yo layout = "float-right-desktop" %} -To transfer bitcoin, the recipient needs to provide the sender with the destination for the payment. On the base layer, this is typically done in the recipient's wallet application by generating and sharing an address. For Lightning payments, an invoice is used. While base layer transactions update balances on the public ledger, Lightning invoices contain information for a payment to be routed through the network of payment channels. +To transfer bitcoin, the recipient needs to provide the sender with the destination for the payment. On the base layer, this is typically done in the recipient's wallet application by generating and sharing an address. For lightning payments, an invoice is used. While base layer transactions update balances on the public ledger, lightning invoices contain information for a payment to be routed through the network of payment channels. @@ -256,7 +256,7 @@ To transfer bitcoin, the recipient needs to provide the sender with the destinat layout = "float-right-desktop" %} -To make a Lightning payment, you don't need to open a channel with everyone you transact with. Lightning nodes talk to one another and declare their payment channels. It's typical for nodes to have multiple channels to access different parts of the network for better routing. With an invoice, the sender finds a path to the receiver, and the payment hops from channel to channel until it reaches the destination. +To make a lightning payment, you don't need to open a channel with everyone you transact with. Lightning nodes talk to one another and declare their payment channels. It's typical for nodes to have multiple channels to access different parts of the network for better routing. With an invoice, the sender finds a path to the receiver, and the payment hops from channel to channel until it reaches the destination.