From 9c8f0bbe2abaa3b4d68020331291c376879eb0ad Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Fri, 12 Mar 2021 03:16:26 +0100 Subject: [PATCH 01/20] docs(payments): import sending bitcoin page --- guide/payments/introduction.md | 6 +- guide/payments/send.md | 271 +++++++++++++++++++++++++++++++++ 2 files changed, 274 insertions(+), 3 deletions(-) create mode 100644 guide/payments/send.md diff --git a/guide/payments/introduction.md b/guide/payments/introduction.md index 62d597c9e..a73ebf8ff 100644 --- a/guide/payments/introduction.md +++ b/guide/payments/introduction.md @@ -3,7 +3,7 @@ layout: guide title: Payments description: Diving into the user experience of moving Bitcoin nav_order: 5 -has_children: false +has_children: true permalink: /guide/payments/ main_classes: -no-top-padding --- @@ -27,13 +27,13 @@ We have already established that [Bitcoin is money](https://bitcoin.design/guide --- -**Transactions overview (coming soon)** +**[Transactions overview](/guide/payments/overview/)** An overview of Bitcoin payments, common concepts and the transaction lifecycle. --- -**Sending bitcoin (coming soon)** +**[Sending bitcoin](/guide/payments/send/)** An introduction to how sending bitcoin works. diff --git a/guide/payments/send.md b/guide/payments/send.md new file mode 100644 index 000000000..843ecc245 --- /dev/null +++ b/guide/payments/send.md @@ -0,0 +1,271 @@ +--- +layout: guide +title: Sending bitcoin +description: An introduction to how sending bitcoin works. +nav_order: 2 +parent: Payments +permalink: /guide/payments/send/ +main_classes: -no-top-padding +image: /assets/images/guide/payments/overview/page-overview.svg +--- + +# Sending bitcoin + +Sending bitcoin can be a very straight forward or complex flow in a bitcoin application. Users may be sending bitcoin to a known contact, moving it between their own wallets on different devices, or making a purchase through a [payment processor](https://bitcoin.design/guide/getting-started/software/#payment-processors). + +Regardless of where the bitcoin is being sent, there are some basic configurations that an application needs to help the user with when creating a transaction: + +- Recipient address — Where to send the bitcoin +- Amount — How much to send +- Coin selection — Which coins/inputs to use (optional) +- Fee settings — Prioritize fast confirmation or low cost (optional) + +The order of configuration for the payment can be tailored to your use case. For example, you may make users set the amount before the address is entered. + +## Get the recipient address +To send a payment on the Bitcoin blockchain we need the recipient's address. Since Bitcoin [addresses](https://bitcoin.design/guide/glossary/#address) are long and seemingly random, they are best shared by copying and pasting in plain text, as a [payment link](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links), or as a scannable [QR Code](https://bitcoin.design/guide/foundations/wallet-interoperability/#qr-codes). + +This is easily accomplished by generating a new address in the receiving wallet application, then sharing it with the sender. If the sender and receiver are together at the time, scanning the receivers address as a QR code will be easy, but if you are not they can send the address as text in any regular communication tool like email, sms etc. + +{% include tip-open.html %} +There are different types of Bitcoin addresses. This can have implications for compatability when sending bitcoin. A modern wallet application is likely to use native SegWit addresses. SegWit enables cheaper transactions and other functionality. Find more information on [address types](https://bitcoin.design/guide/glossary/#address) in the glossary. +{% include tip-close.html %} + +## Input an address + +Once you have gotten the address, it needs to be inputed on the create transaction interface. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. + +Upon address input, the user should be clearly informed if the address is valid or not. If the address is not valid, or incompatible with the current application, sending should be disabled. + +![](https://i.imgur.com/M9ajQz9.png) + + +### Input options + +
+{% include image.html + image = "https://i.imgur.com/B5MlGKt.png" + retina = "https://i.imgur.com/B5MlGKt.png" + alt-text = "Example image" + width = 100 + height = 100 + layout = "float-left" +%} + +**QR Code**
+Once the camera detects a valid address in the QR Code, it can be automatically inputted. The user will need to grant access your application to be able to scan QR Codes. + +--- +
+ +
+{% include image.html + image = "https://i.imgur.com/gnMTFpb.png" + retina = "https://i.imgur.com/gnMTFpb.png" + alt-text = "Example image" + width = 100 + height = 100 + layout = "float-left" +%} + +**Copy Paste**
+When the sender receives the address in text format they would need to paste in the address. Your application can detect a valid address in the clipboard and prompt the user to press a button to paste. +
+ +{% include tip-open.html %} +Most platforms allow applications to read the contents of the device's clipboard to enable convenient copy/paste. While some users find this helpful, some may perceive it as a privacy infringment. You may want to consider giving them an option to disable automatic reading of the clipboard. +{% include tip-close.html %} + +### Do's + +- Indicate clearly if the address is valid or not +- Show the whole address if possible to help the user visually verify it is correct +- If space is a constraint, truncate the address in the middle so that both the beginning and end are visible + +### Don'ts + +- Don't allow a transaction to be sent if the address is invalid + +## Inputing an amount + +Depending on their familiarity with bitcoin, your users may have a preference to which denomination the amount should be specified in. Common options include: + +- **bitcoin** — most common *(i.e. 0.00019376 btc)* +- **local currency** — more familiar *(i.e. $10)* +- **sats / satoshis** — more knowledgable *(i.e. 19376 sats)* + +Allowing the amount to be inputed in different denominations should be readily available. Read more about why and changing units contextually in [Units, symbols and amount display](https://deploy-preview-63--sad-borg-390916.netlify.app/guide/payments/units-and-symbols/). + +Since an amount specified in bitcoin or sats often involve many digits, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example). Applications can let the sender select fractions of the total available balance. Most common is *max*, which also makes it easy for the user to sweep all of the available coins to another wallet. + +{% include tip-open.html %} +Payment links and QR codes can contain an amount — when they do, the amount should be populated automatically. +{% include tip-close.html %} + +![](https://i.imgur.com/vSYVVLu.png) + +### Do's + +- Allow different denominations to be used for the amount +- Show the total balance available to send +- Allow selecting max amount (subtracting the required fee) + +### Don'ts + +- Don't allow entering more than the available balance + + + +## Transaction fee + +The application can automatically estimate a fee and set it for the sender. This would normally prioritise the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they choose to optimize for faster confirmation, or lower fees. + +#### Variations +- Automatically set fee rate +- Allow user to choose from presets +- Allow user to enter a custom fee rate (advanced) + +#### How are transaction fees calculated? + +The total fee is dependent upon the data size of the transaction multiplied by the fee rate, not the amount being sent. The fee rate is expressed as satoshi's per vByte (sat/vB). Be mindful that not all bitcoin users are familiar with terms such as sat/vB, so it may be necessary to also express the value in their local currencies. + +{% include tip-open.html %} +#### Fee Estimation +Fee estimations are largly inaccurate — this is because the fee rate is impacted by everyone else who are trying to get their transactions into a block. The rate is constantly changing so it is difficult to make an accurate prediction of. + +The fee recomendation in your application can cause senders to end up over paying in fees, or waiting long periods of time to get their transactions confirmed. +{% include tip-close.html %} + +### Setting the transaction fee manually + +![](https://i.imgur.com/LcEGYjG.png) + +When allowing users to set their own fee, it is important to clearly communicate the estimated cost and confirmation time, along with some details on how the fee gets calculated ([see below](#How-are-transaction-fees-calculated)). + +Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses). Someone can set a fee rate that's way too high, overpaying in fees or having transactions stuck for long periods of time if the fee is too low. For these reasons you should carefully consider if and how to expose transaction fees to users depending on the usecase. + +### Do's + +- Clearly communicate infomation related to the fee rate options +- Display the fee rate and estimated transaction confirmation time +- Display bitcoin and local currency denominations for cost reference +- Include an option to adjust this rate with either: + - Select from priority pre-set options (high, medium, low priority) + - Manually entering a fee rate for their transaction +- Display a warning if the user enters an amount far beyond the recommened rate +- Consider offering a [replace by fee]() option to speed up stuck transactions + +### Don'ts + +- Allow for confusion between total fee and fee rate +- Allow users to overpay in transaction fees + +## Reviewing and Approving the Payment + +A valid transaction that is broadcast to the network cannot be reversed, so it is critical that the sender is given a chance to double check the payment details (amount, recipient address, total fee, etc) before submitting the transaction. + +![](https://i.imgur.com/mk3pJHa.png) + +{% include tip-open.html %} +If the wallet allows users to set a spending limit and the current transaction exceeds it, make sure users go through some security check (biometric, enter PIN, 2FA password, etc). This can also be used if the 100% of the funds are being sent. +{% include tip-close.html %} + +### Do's + +- Allow users to review payment details and adjust if necessary, before submitting the transaction +- Show amount and fee in both bitcoin and local currency denominations + +### Don'ts + +- Assume the user has got all the details correct, give them the chance to look over the information before broadcasting the transaction + +## Transaction processing and confirmation + +Once a transaction has been signed by the sender and submitted by the application, the transaction goes through the following steps before being confirmed by miners on the network: + +
+{% include image.html + image = "https://i.imgur.com/t8WHLp6.png" + retina = "https://i.imgur.com/t8WHLp6.png" + alt-text = "Example image" + width = 100 + height = 100 + layout = "float-left" +%} + +**Broadcasting**
+The transaction is broadcast to a node, usually the one the wallet is connected to. + +--- +
+ +
+{% include image.html + image = "https://i.imgur.com/Ey6hMoA.png" + retina = "https://i.imgur.com/Ey6hMoA.png" + alt-text = "Example image" + width = 100 + height = 100 + layout = "float-left" +%} + +**Validation**
+The node checks to see if the transaction is valid. If **Yes**, the node propagates the transaction to other nodes in the network. If **No**, the transaction is rejected. + +--- +
+ +
+{% include image.html + image = "https://i.imgur.com/DEsVUFj.png" + retina = "https://i.imgur.com/DEsVUFj.png" + alt-text = "Example image" + width = 100 + height = 100 + layout = "float-left" +%} + +**Propagation**
+Once the transaction is valid it is now in the *memory pool*, and is available for including in a block by miners. When in the *memory pool*, the sender can see the transaction in their wallet as unconfirmed. +
+ +{% include image.html + image = "https://i.imgur.com/idV0Mt7.png" + retina = "https://i.imgur.com/idV0Mt7.png" + alt-text = "Example image" + width = 1600 + height = 800 +%} + +### Do's +// Maybe these can be combined, they say almost the same thing +- Notify the user which stage of the process their transaction is in: + - Awaiting broadcast + - Broadcast, awaiting validation + - Validated, awaiting propagation + - Awaiting confirmation +- Or, simply show the transaction as pending, perhaps with a time estimate if applicable + +### Don'ts +- Show a the transaction as confirmed until it has received ***at least*** one confirmation, but preferably six + +## Transaction confirmation +At some point the transaction is included in a block that is added to the blockchain. This counts as a first confirmation. The recipient can be confident that they will receive the bitcoin, and may even receive a pre-emptive notification from their wallet. How long the first confirmation takes is dependent on many factors, principally - how many other transactions are waiting to be confirmed and how big a fee the transaction will pay. A new block is confirmed roughly every ten minutes. + +Each additional block that is accepted by the network counts as an extra confirmation. When a block (and therefore the transaction within) has 6 confirmations, it is considered final. + +![](https://i.imgur.com/BxvSAzE.png) + +### Error States + +// Maybe write some explanatory text here? + +### Do's +- Notify users of confirmed outgoing/incoming payments +- Show the amount of confirmations a transaction has received +- Provide information on transaction/block ID for receipt purposes + +### Don'ts +// This is doubling up with the ones in Transaction processing (maybe they can be cut and moved here?) + +- \ No newline at end of file From 31b1d83904b4beeb0839fa320a7a09aa189024cc Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Fri, 12 Mar 2021 03:31:44 +0100 Subject: [PATCH 02/20] docs(payments/send): make less wordy --- guide/payments/send.md | 77 ++++-------------------------------------- 1 file changed, 6 insertions(+), 71 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index 843ecc245..c1175eace 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -181,53 +181,7 @@ If the wallet allows users to set a spending limit and the current transaction e ## Transaction processing and confirmation -Once a transaction has been signed by the sender and submitted by the application, the transaction goes through the following steps before being confirmed by miners on the network: - -
-{% include image.html - image = "https://i.imgur.com/t8WHLp6.png" - retina = "https://i.imgur.com/t8WHLp6.png" - alt-text = "Example image" - width = 100 - height = 100 - layout = "float-left" -%} - -**Broadcasting**
-The transaction is broadcast to a node, usually the one the wallet is connected to. - ---- -
- -
-{% include image.html - image = "https://i.imgur.com/Ey6hMoA.png" - retina = "https://i.imgur.com/Ey6hMoA.png" - alt-text = "Example image" - width = 100 - height = 100 - layout = "float-left" -%} - -**Validation**
-The node checks to see if the transaction is valid. If **Yes**, the node propagates the transaction to other nodes in the network. If **No**, the transaction is rejected. - ---- -
- -
-{% include image.html - image = "https://i.imgur.com/DEsVUFj.png" - retina = "https://i.imgur.com/DEsVUFj.png" - alt-text = "Example image" - width = 100 - height = 100 - layout = "float-left" -%} - -**Propagation**
-Once the transaction is valid it is now in the *memory pool*, and is available for including in a block by miners. When in the *memory pool*, the sender can see the transaction in their wallet as unconfirmed. -
+Once a transaction has the correct signatures, authorised by the senders wallet, and it's broadcasted to a node, it will be in an unconfirmed state. {% include image.html image = "https://i.imgur.com/idV0Mt7.png" @@ -238,34 +192,15 @@ Once the transaction is valid it is now in the *memory pool*, and is available f %} ### Do's -// Maybe these can be combined, they say almost the same thing +- Notify users of confirmed outgoing/incoming payments +- Show the amount of confirmations a transaction has received +- Provide information on transaction/block ID for receipt purposes - Notify the user which stage of the process their transaction is in: - Awaiting broadcast - Broadcast, awaiting validation - Validated, awaiting propagation - Awaiting confirmation -- Or, simply show the transaction as pending, perhaps with a time estimate if applicable +- Or, simply show the transaction as pending, perhaps with a time estimate if possible ### Don'ts -- Show a the transaction as confirmed until it has received ***at least*** one confirmation, but preferably six - -## Transaction confirmation -At some point the transaction is included in a block that is added to the blockchain. This counts as a first confirmation. The recipient can be confident that they will receive the bitcoin, and may even receive a pre-emptive notification from their wallet. How long the first confirmation takes is dependent on many factors, principally - how many other transactions are waiting to be confirmed and how big a fee the transaction will pay. A new block is confirmed roughly every ten minutes. - -Each additional block that is accepted by the network counts as an extra confirmation. When a block (and therefore the transaction within) has 6 confirmations, it is considered final. - -![](https://i.imgur.com/BxvSAzE.png) - -### Error States - -// Maybe write some explanatory text here? - -### Do's -- Notify users of confirmed outgoing/incoming payments -- Show the amount of confirmations a transaction has received -- Provide information on transaction/block ID for receipt purposes - -### Don'ts -// This is doubling up with the ones in Transaction processing (maybe they can be cut and moved here?) - -- \ No newline at end of file +- Show a the transaction as confirmed until it has received ***at least*** one confirmation, but preferably six \ No newline at end of file From 81c6bcb766c2f7207163df41d6bdeaf1c710f21f Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Fri, 12 Mar 2021 04:02:38 +0100 Subject: [PATCH 03/20] chore(payments/send): remove fee estimation heading from tip --- guide/payments/send.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index c1175eace..0ca5efcec 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -27,10 +27,6 @@ To send a payment on the Bitcoin blockchain we need the recipient's address. Sin This is easily accomplished by generating a new address in the receiving wallet application, then sharing it with the sender. If the sender and receiver are together at the time, scanning the receivers address as a QR code will be easy, but if you are not they can send the address as text in any regular communication tool like email, sms etc. -{% include tip-open.html %} -There are different types of Bitcoin addresses. This can have implications for compatability when sending bitcoin. A modern wallet application is likely to use native SegWit addresses. SegWit enables cheaper transactions and other functionality. Find more information on [address types](https://bitcoin.design/guide/glossary/#address) in the glossary. -{% include tip-close.html %} - ## Input an address Once you have gotten the address, it needs to be inputed on the create transaction interface. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. @@ -130,7 +126,6 @@ The application can automatically estimate a fee and set it for the sender. This The total fee is dependent upon the data size of the transaction multiplied by the fee rate, not the amount being sent. The fee rate is expressed as satoshi's per vByte (sat/vB). Be mindful that not all bitcoin users are familiar with terms such as sat/vB, so it may be necessary to also express the value in their local currencies. {% include tip-open.html %} -#### Fee Estimation Fee estimations are largly inaccurate — this is because the fee rate is impacted by everyone else who are trying to get their transactions into a block. The rate is constantly changing so it is difficult to make an accurate prediction of. The fee recomendation in your application can cause senders to end up over paying in fees, or waiting long periods of time to get their transactions confirmed. @@ -162,7 +157,7 @@ Human error with fee selection can lead to [costly mistakes](https://www.coindes ## Reviewing and Approving the Payment -A valid transaction that is broadcast to the network cannot be reversed, so it is critical that the sender is given a chance to double check the payment details (amount, recipient address, total fee, etc) before submitting the transaction. +A valid transaction that is broadcasted to the network cannot be reversed, so it is critical that the sender is given a chance to double check the payment details (amount, recipient address, total fee, etc) before submitting the transaction. ![](https://i.imgur.com/mk3pJHa.png) @@ -181,7 +176,7 @@ If the wallet allows users to set a spending limit and the current transaction e ## Transaction processing and confirmation -Once a transaction has the correct signatures, authorised by the senders wallet, and it's broadcasted to a node, it will be in an unconfirmed state. +Once the transaction is valid it is now in the *memory pool*, and is available for including in a block by miners. When in the *memory pool*, the sender can see the transaction in their wallet as unconfirmed. {% include image.html image = "https://i.imgur.com/idV0Mt7.png" From 49031dcea87457d3b0240a7389bce6a17bbdb7cb Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Fri, 12 Mar 2021 11:56:43 +0100 Subject: [PATCH 04/20] docs(payments/send): fix typos and grammar --- guide/payments/send.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index 0ca5efcec..c299d329c 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -25,11 +25,11 @@ The order of configuration for the payment can be tailored to your use case. For ## Get the recipient address To send a payment on the Bitcoin blockchain we need the recipient's address. Since Bitcoin [addresses](https://bitcoin.design/guide/glossary/#address) are long and seemingly random, they are best shared by copying and pasting in plain text, as a [payment link](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links), or as a scannable [QR Code](https://bitcoin.design/guide/foundations/wallet-interoperability/#qr-codes). -This is easily accomplished by generating a new address in the receiving wallet application, then sharing it with the sender. If the sender and receiver are together at the time, scanning the receivers address as a QR code will be easy, but if you are not they can send the address as text in any regular communication tool like email, sms etc. +This is easily accomplished by generating a new address in the receiving wallet application, then sharing it with the sender. If the sender and receiver are together at the time, scanning the receivers address as a QR code will be easy, but if they are not, they can send the address as text in any regular communication tool like email, sms etc. ## Input an address -Once you have gotten the address, it needs to be inputed on the create transaction interface. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. +Once you have gotten the address, it needs to be inputted on the "create transaction" interface. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. Upon address input, the user should be clearly informed if the address is valid or not. If the address is not valid, or incompatible with the current application, sending should be disabled. @@ -92,7 +92,7 @@ Depending on their familiarity with bitcoin, your users may have a preference to Allowing the amount to be inputed in different denominations should be readily available. Read more about why and changing units contextually in [Units, symbols and amount display](https://deploy-preview-63--sad-borg-390916.netlify.app/guide/payments/units-and-symbols/). -Since an amount specified in bitcoin or sats often involve many digits, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example). Applications can let the sender select fractions of the total available balance. Most common is *max*, which also makes it easy for the user to sweep all of the available coins to another wallet. +Since an amount specified in bitcoin or sats often involve many digits, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example). Applications can allow the sender select fractions of the total available balance. Most common is *max* or *all*, which also makes it easy for the user to sweep the entire balance to another wallet. {% include tip-open.html %} Payment links and QR codes can contain an amount — when they do, the amount should be populated automatically. @@ -114,7 +114,7 @@ Payment links and QR codes can contain an amount — when they do, the amount sh ## Transaction fee -The application can automatically estimate a fee and set it for the sender. This would normally prioritise the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they choose to optimize for faster confirmation, or lower fees. +The application can automatically estimate a fee and set it for the sender. This would normally prioritise the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they can choose to optimize for faster confirmation, or lower fees. #### Variations - Automatically set fee rate @@ -126,7 +126,7 @@ The application can automatically estimate a fee and set it for the sender. This The total fee is dependent upon the data size of the transaction multiplied by the fee rate, not the amount being sent. The fee rate is expressed as satoshi's per vByte (sat/vB). Be mindful that not all bitcoin users are familiar with terms such as sat/vB, so it may be necessary to also express the value in their local currencies. {% include tip-open.html %} -Fee estimations are largly inaccurate — this is because the fee rate is impacted by everyone else who are trying to get their transactions into a block. The rate is constantly changing so it is difficult to make an accurate prediction of. +Fee estimations are largely inaccurate — this is because the fee rate is impacted by everyone else who are trying to get their transactions into a block. The rate is constantly changing so it is difficult to make an accurate prediction. The fee recomendation in your application can cause senders to end up over paying in fees, or waiting long periods of time to get their transactions confirmed. {% include tip-close.html %} @@ -137,7 +137,7 @@ The fee recomendation in your application can cause senders to end up over payin When allowing users to set their own fee, it is important to clearly communicate the estimated cost and confirmation time, along with some details on how the fee gets calculated ([see below](#How-are-transaction-fees-calculated)). -Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses). Someone can set a fee rate that's way too high, overpaying in fees or having transactions stuck for long periods of time if the fee is too low. For these reasons you should carefully consider if and how to expose transaction fees to users depending on the usecase. +Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses). Someone can set a fee rate that's way too high, overpaying in fees or having transactions stuck for long periods of time if the fee is too low. For these reasons you should carefully consider if and how to expose transaction fees to users depending on the use case. ### Do's From dc166c05be62216ffcda583cf957ad6ee544a52a Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Fri, 12 Mar 2021 13:34:27 +0100 Subject: [PATCH 05/20] docs(payments): fix typos --- guide/payments/send.md | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index c299d329c..45b6be66d 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -47,7 +47,6 @@ Upon address input, the user should be clearly informed if the address is valid height = 100 layout = "float-left" %} - **QR Code**
Once the camera detects a valid address in the QR Code, it can be automatically inputted. The user will need to grant access your application to be able to scan QR Codes. @@ -88,7 +87,7 @@ Depending on their familiarity with bitcoin, your users may have a preference to - **bitcoin** — most common *(i.e. 0.00019376 btc)* - **local currency** — more familiar *(i.e. $10)* -- **sats / satoshis** — more knowledgable *(i.e. 19376 sats)* +- **sats / satoshis** — more knowledgeable *(i.e. 19376 sats)* Allowing the amount to be inputed in different denominations should be readily available. Read more about why and changing units contextually in [Units, symbols and amount display](https://deploy-preview-63--sad-borg-390916.netlify.app/guide/payments/units-and-symbols/). @@ -114,7 +113,7 @@ Payment links and QR codes can contain an amount — when they do, the amount sh ## Transaction fee -The application can automatically estimate a fee and set it for the sender. This would normally prioritise the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they can choose to optimize for faster confirmation, or lower fees. +The application can automatically estimate a fee and set it for the sender. This would normally prioritize the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they can choose to optimize for faster confirmation, or lower fees. #### Variations - Automatically set fee rate @@ -128,7 +127,7 @@ The total fee is dependent upon the data size of the transaction multiplied by t {% include tip-open.html %} Fee estimations are largely inaccurate — this is because the fee rate is impacted by everyone else who are trying to get their transactions into a block. The rate is constantly changing so it is difficult to make an accurate prediction. -The fee recomendation in your application can cause senders to end up over paying in fees, or waiting long periods of time to get their transactions confirmed. +The fee recommendation in your application can cause senders to end up over paying in fees, or waiting long periods of time to get their transactions confirmed. {% include tip-close.html %} ### Setting the transaction fee manually @@ -141,13 +140,13 @@ Human error with fee selection can lead to [costly mistakes](https://www.coindes ### Do's -- Clearly communicate infomation related to the fee rate options +- Clearly communicate information related to the fee rate options - Display the fee rate and estimated transaction confirmation time - Display bitcoin and local currency denominations for cost reference - Include an option to adjust this rate with either: - Select from priority pre-set options (high, medium, low priority) - Manually entering a fee rate for their transaction -- Display a warning if the user enters an amount far beyond the recommened rate +- Display a warning if the user enters an amount far beyond the recommended rate - Consider offering a [replace by fee]() option to speed up stuck transactions ### Don'ts @@ -176,7 +175,9 @@ If the wallet allows users to set a spending limit and the current transaction e ## Transaction processing and confirmation -Once the transaction is valid it is now in the *memory pool*, and is available for including in a block by miners. When in the *memory pool*, the sender can see the transaction in their wallet as unconfirmed. +Once the transaction is valid it is now in the *memory pool*, and is available for including in a block by miners. When in the *memory pool*, the sender can see the transaction in their wallet as unconfirmed or pending. + +After broadcasting a transaction, the process of propagation and validation is quite fast so showing these states may be infeasible. You may inform the user that their transaction is pending a confirmation, the estimated time to confirm given the current fee market, and once it has gotten its first confirmation. {% include image.html image = "https://i.imgur.com/idV0Mt7.png" @@ -187,15 +188,9 @@ Once the transaction is valid it is now in the *memory pool*, and is available f %} ### Do's -- Notify users of confirmed outgoing/incoming payments -- Show the amount of confirmations a transaction has received +- Clearly indicate state of the outgoing transaction +- Show the amount of confirmations the transaction has gotten - Provide information on transaction/block ID for receipt purposes -- Notify the user which stage of the process their transaction is in: - - Awaiting broadcast - - Broadcast, awaiting validation - - Validated, awaiting propagation - - Awaiting confirmation -- Or, simply show the transaction as pending, perhaps with a time estimate if possible ### Don'ts - Show a the transaction as confirmed until it has received ***at least*** one confirmation, but preferably six \ No newline at end of file From 876e25575420839928797121b324c2f111a44228 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Sun, 14 Mar 2021 22:26:00 +0100 Subject: [PATCH 06/20] style(payments/send): reformat to distinguish between sections on page --- guide/payments/introduction.md | 2 +- guide/payments/send.md | 87 +++++++++++----------------------- 2 files changed, 28 insertions(+), 61 deletions(-) diff --git a/guide/payments/introduction.md b/guide/payments/introduction.md index a73ebf8ff..122865af6 100644 --- a/guide/payments/introduction.md +++ b/guide/payments/introduction.md @@ -27,7 +27,7 @@ We have already established that [Bitcoin is money](https://bitcoin.design/guide --- -**[Transactions overview](/guide/payments/overview/)** +**Transactions overview (coming soon)** An overview of Bitcoin payments, common concepts and the transaction lifecycle. diff --git a/guide/payments/send.md b/guide/payments/send.md index 45b6be66d..5295a76f3 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -15,10 +15,14 @@ Sending bitcoin can be a very straight forward or complex flow in a bitcoin appl Regardless of where the bitcoin is being sent, there are some basic configurations that an application needs to help the user with when creating a transaction: -- Recipient address — Where to send the bitcoin -- Amount — How much to send -- Coin selection — Which coins/inputs to use (optional) -- Fee settings — Prioritize fast confirmation or low cost (optional) +--- + +- **Recipient address** — Where to send the bitcoin +- **Amount** — How much to send +- **Coin selection** — Which coins/inputs to use (optional) +- **Fee settings** — Prioritize fast confirmation or low cost (optional) + +--- The order of configuration for the payment can be tailored to your use case. For example, you may make users set the amount before the address is entered. @@ -33,51 +37,20 @@ Once you have gotten the address, it needs to be inputted on the "create transac Upon address input, the user should be clearly informed if the address is valid or not. If the address is not valid, or incompatible with the current application, sending should be disabled. -![](https://i.imgur.com/M9ajQz9.png) - +**QR Code** -- Once the camera detects a valid address in the QR Code, it can be automatically inputted. The user will need to grant access your application to be able to scan QR Codes. -### Input options +**Copy Paste** -- When the sender receives the address in text format they would need to paste in the address. Your application can detect a valid address in the clipboard and prompt the user to press a button to paste. -
-{% include image.html - image = "https://i.imgur.com/B5MlGKt.png" - retina = "https://i.imgur.com/B5MlGKt.png" - alt-text = "Example image" - width = 100 - height = 100 - layout = "float-left" -%} -**QR Code**
-Once the camera detects a valid address in the QR Code, it can be automatically inputted. The user will need to grant access your application to be able to scan QR Codes. - ---- -
- -
-{% include image.html - image = "https://i.imgur.com/gnMTFpb.png" - retina = "https://i.imgur.com/gnMTFpb.png" - alt-text = "Example image" - width = 100 - height = 100 - layout = "float-left" -%} - -**Copy Paste**
-When the sender receives the address in text format they would need to paste in the address. Your application can detect a valid address in the clipboard and prompt the user to press a button to paste. -
- -{% include tip-open.html %} -Most platforms allow applications to read the contents of the device's clipboard to enable convenient copy/paste. While some users find this helpful, some may perceive it as a privacy infringment. You may want to consider giving them an option to disable automatic reading of the clipboard. -{% include tip-close.html %} +![](https://i.imgur.com/M9ajQz9.png) -### Do's +**Do's** - Indicate clearly if the address is valid or not - Show the whole address if possible to help the user visually verify it is correct - If space is a constraint, truncate the address in the middle so that both the beginning and end are visible +- Most platforms allow applications to read the contents of the device's clipboard to enable convenient copy/paste. While some users find this helpful, some may perceive it as a privacy infringement. You may want to consider giving them an option to disable automatic reading of the clipboard. -### Don'ts +**Don'ts** - Don't allow a transaction to be sent if the address is invalid @@ -93,19 +66,16 @@ Allowing the amount to be inputed in different denominations should be readily a Since an amount specified in bitcoin or sats often involve many digits, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example). Applications can allow the sender select fractions of the total available balance. Most common is *max* or *all*, which also makes it easy for the user to sweep the entire balance to another wallet. -{% include tip-open.html %} -Payment links and QR codes can contain an amount — when they do, the amount should be populated automatically. -{% include tip-close.html %} - ![](https://i.imgur.com/vSYVVLu.png) -### Do's +**Do's** - Allow different denominations to be used for the amount - Show the total balance available to send - Allow selecting max amount (subtracting the required fee) +- Payment links and QR codes can contain an amount — when they do, the amount should be populated automatically. -### Don'ts +**Don'ts** - Don't allow entering more than the available balance @@ -115,7 +85,7 @@ Payment links and QR codes can contain an amount — when they do, the amount sh The application can automatically estimate a fee and set it for the sender. This would normally prioritize the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they can choose to optimize for faster confirmation, or lower fees. -#### Variations +**Variations** - Automatically set fee rate - Allow user to choose from presets - Allow user to enter a custom fee rate (advanced) @@ -124,11 +94,10 @@ The application can automatically estimate a fee and set it for the sender. This The total fee is dependent upon the data size of the transaction multiplied by the fee rate, not the amount being sent. The fee rate is expressed as satoshi's per vByte (sat/vB). Be mindful that not all bitcoin users are familiar with terms such as sat/vB, so it may be necessary to also express the value in their local currencies. -{% include tip-open.html %} +##### Fee Estimation Fee estimations are largely inaccurate — this is because the fee rate is impacted by everyone else who are trying to get their transactions into a block. The rate is constantly changing so it is difficult to make an accurate prediction. The fee recommendation in your application can cause senders to end up over paying in fees, or waiting long periods of time to get their transactions confirmed. -{% include tip-close.html %} ### Setting the transaction fee manually @@ -138,7 +107,7 @@ When allowing users to set their own fee, it is important to clearly communicate Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses). Someone can set a fee rate that's way too high, overpaying in fees or having transactions stuck for long periods of time if the fee is too low. For these reasons you should carefully consider if and how to expose transaction fees to users depending on the use case. -### Do's +**Do's** - Clearly communicate information related to the fee rate options - Display the fee rate and estimated transaction confirmation time @@ -149,7 +118,7 @@ Human error with fee selection can lead to [costly mistakes](https://www.coindes - Display a warning if the user enters an amount far beyond the recommended rate - Consider offering a [replace by fee]() option to speed up stuck transactions -### Don'ts +**Don'ts** - Allow for confusion between total fee and fee rate - Allow users to overpay in transaction fees @@ -160,16 +129,14 @@ A valid transaction that is broadcasted to the network cannot be reversed, so it ![](https://i.imgur.com/mk3pJHa.png) -{% include tip-open.html %} -If the wallet allows users to set a spending limit and the current transaction exceeds it, make sure users go through some security check (biometric, enter PIN, 2FA password, etc). This can also be used if the 100% of the funds are being sent. -{% include tip-close.html %} - -### Do's +**Do's** - Allow users to review payment details and adjust if necessary, before submitting the transaction - Show amount and fee in both bitcoin and local currency denominations +- If the wallet allows users to set a spending limit and the current transaction exceeds it, make sure users go through some security check (biometric, enter PIN, 2FA password, etc). This can also be used if the 100% of the funds are being sent. + -### Don'ts +**Don'ts** - Assume the user has got all the details correct, give them the chance to look over the information before broadcasting the transaction @@ -187,10 +154,10 @@ After broadcasting a transaction, the process of propagation and validation is q height = 800 %} -### Do's +**Do's** - Clearly indicate state of the outgoing transaction - Show the amount of confirmations the transaction has gotten - Provide information on transaction/block ID for receipt purposes -### Don'ts +**Don'ts** - Show a the transaction as confirmed until it has received ***at least*** one confirmation, but preferably six \ No newline at end of file From 0d57e9ef273d29c938e59ef2815181516504f557 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Sun, 14 Mar 2021 22:30:37 +0100 Subject: [PATCH 07/20] style(payments/send): simplify do's list --- guide/payments/send.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index 5295a76f3..bb1a15625 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -112,9 +112,7 @@ Human error with fee selection can lead to [costly mistakes](https://www.coindes - Clearly communicate information related to the fee rate options - Display the fee rate and estimated transaction confirmation time - Display bitcoin and local currency denominations for cost reference -- Include an option to adjust this rate with either: - - Select from priority pre-set options (high, medium, low priority) - - Manually entering a fee rate for their transaction +- Include an option to adjust fee rate based on some presets (e.g. high, medium, low priority) - Display a warning if the user enters an amount far beyond the recommended rate - Consider offering a [replace by fee]() option to speed up stuck transactions From 19fce094eda91bf1e468504b9ab4993084802698 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Wed, 17 Mar 2021 01:54:52 +0100 Subject: [PATCH 08/20] feat(payments/send): add placeholder images --- guide/payments/send.md | 88 +++++++++++++++++++++++++----------------- 1 file changed, 53 insertions(+), 35 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index bb1a15625..3acb72f0e 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -15,15 +15,11 @@ Sending bitcoin can be a very straight forward or complex flow in a bitcoin appl Regardless of where the bitcoin is being sent, there are some basic configurations that an application needs to help the user with when creating a transaction: ---- - -- **Recipient address** — Where to send the bitcoin - **Amount** — How much to send +- **Recipient address** — Where to send the bitcoin - **Coin selection** — Which coins/inputs to use (optional) - **Fee settings** — Prioritize fast confirmation or low cost (optional) ---- - The order of configuration for the payment can be tailored to your use case. For example, you may make users set the amount before the address is entered. ## Get the recipient address @@ -33,6 +29,15 @@ This is easily accomplished by generating a new address in the receiving wallet ## Input an address +
+{% include image.html + image = "/assets/images/guide/payments/send/enter-address.svg" + alt-text = "Example image" + width = 400 + height = 400 + layout = "float-right-desktop" +%} + Once you have gotten the address, it needs to be inputted on the "create transaction" interface. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. Upon address input, the user should be clearly informed if the address is valid or not. If the address is not valid, or incompatible with the current application, sending should be disabled. @@ -40,8 +45,7 @@ Upon address input, the user should be clearly informed if the address is valid **QR Code** -- Once the camera detects a valid address in the QR Code, it can be automatically inputted. The user will need to grant access your application to be able to scan QR Codes. **Copy Paste** -- When the sender receives the address in text format they would need to paste in the address. Your application can detect a valid address in the clipboard and prompt the user to press a button to paste. - -![](https://i.imgur.com/M9ajQz9.png) +
**Do's** @@ -56,17 +60,26 @@ Upon address input, the user should be clearly informed if the address is valid ## Inputing an amount -Depending on their familiarity with bitcoin, your users may have a preference to which denomination the amount should be specified in. Common options include: +{% include image.html + image = "/assets/images/guide/payments/send/input-amount-desktop.svg" + alt-text = "Example image" + width = 1600 + height = 800 +%} -- **bitcoin** — most common *(i.e. 0.00019376 btc)* -- **local currency** — more familiar *(i.e. $10)* -- **sats / satoshis** — more knowledgeable *(i.e. 19376 sats)* +
+{% include image.html + image = "/assets/images/guide/payments/send/input-amount.svg" + alt-text = "Example image" + width = 400 + height = 400 + layout = "float-right-desktop" +%} -Allowing the amount to be inputed in different denominations should be readily available. Read more about why and changing units contextually in [Units, symbols and amount display](https://deploy-preview-63--sad-borg-390916.netlify.app/guide/payments/units-and-symbols/). +Depending on their familiarity with bitcoin, your users may have a preference of which denomination the amount should be specified in. Read more about why and changing units contextually in [Units, symbols and amount display](https://deploy-preview-63--sad-borg-390916.netlify.app/guide/payments/units-and-symbols/). Since an amount specified in bitcoin or sats often involve many digits, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example). Applications can allow the sender select fractions of the total available balance. Most common is *max* or *all*, which also makes it easy for the user to sweep the entire balance to another wallet. - -![](https://i.imgur.com/vSYVVLu.png) +
**Do's** @@ -83,30 +96,27 @@ Since an amount specified in bitcoin or sats often involve many digits, and don' ## Transaction fee +
+{% include image.html + image = "/assets/images/guide/payments/send/select-fee-rate.svg" + alt-text = "Example image" + width = 400 + height = 400 + layout = "float-right-desktop" +%} + The application can automatically estimate a fee and set it for the sender. This would normally prioritize the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they can choose to optimize for faster confirmation, or lower fees. +When allowing users to set their own fee, it is important to clearly communicate the estimated cost and confirmation time, along with some details on how the fee gets calculated ([see below](#How-are-transaction-fees-calculated)). + +Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses). Someone can set a fee rate that's way too high, overpaying in fees or having transactions stuck for long periods of time if the fee is too low. For these reasons you should carefully consider if and how to expose transaction fees to users. +
+ **Variations** - Automatically set fee rate - Allow user to choose from presets - Allow user to enter a custom fee rate (advanced) -#### How are transaction fees calculated? - -The total fee is dependent upon the data size of the transaction multiplied by the fee rate, not the amount being sent. The fee rate is expressed as satoshi's per vByte (sat/vB). Be mindful that not all bitcoin users are familiar with terms such as sat/vB, so it may be necessary to also express the value in their local currencies. - -##### Fee Estimation -Fee estimations are largely inaccurate — this is because the fee rate is impacted by everyone else who are trying to get their transactions into a block. The rate is constantly changing so it is difficult to make an accurate prediction. - -The fee recommendation in your application can cause senders to end up over paying in fees, or waiting long periods of time to get their transactions confirmed. - -### Setting the transaction fee manually - -![](https://i.imgur.com/LcEGYjG.png) - -When allowing users to set their own fee, it is important to clearly communicate the estimated cost and confirmation time, along with some details on how the fee gets calculated ([see below](#How-are-transaction-fees-calculated)). - -Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses). Someone can set a fee rate that's way too high, overpaying in fees or having transactions stuck for long periods of time if the fee is too low. For these reasons you should carefully consider if and how to expose transaction fees to users depending on the use case. - **Do's** - Clearly communicate information related to the fee rate options @@ -121,18 +131,26 @@ Human error with fee selection can lead to [costly mistakes](https://www.coindes - Allow for confusion between total fee and fee rate - Allow users to overpay in transaction fees -## Reviewing and Approving the Payment +## Reviewing and approving the payment + +
+{% include image.html + image = "/assets/images/guide/payments/send/input-amount.svg" + alt-text = "Example image" + width = 400 + height = 400 + layout = "float-right-desktop" +%} A valid transaction that is broadcasted to the network cannot be reversed, so it is critical that the sender is given a chance to double check the payment details (amount, recipient address, total fee, etc) before submitting the transaction. -![](https://i.imgur.com/mk3pJHa.png) +If the wallet allows users to set a spending limit and the current transaction exceeds it, make sure users go through some security check (biometric, enter PIN, 2FA password, etc). This can also be used if the 100% of the funds are being sent. +
**Do's** - Allow users to review payment details and adjust if necessary, before submitting the transaction - Show amount and fee in both bitcoin and local currency denominations -- If the wallet allows users to set a spending limit and the current transaction exceeds it, make sure users go through some security check (biometric, enter PIN, 2FA password, etc). This can also be used if the 100% of the funds are being sent. - **Don'ts** From 2620061aae39ad6e56628ced85b14797e1393578 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Wed, 17 Mar 2021 03:13:54 +0100 Subject: [PATCH 09/20] feat(payments/send): add images to assets --- .../guide/payments/send/input-address.svg | 1 + .../guide/payments/send/input-amount.svg | 22 +++++++++++++++ .../guide/payments/send/review-payment.svg | 1 + .../guide/payments/send/select-fee-rate.svg | 1 + guide/payments/send.md | 27 +++++++------------ 5 files changed, 35 insertions(+), 17 deletions(-) create mode 100644 assets/images/guide/payments/send/input-address.svg create mode 100644 assets/images/guide/payments/send/input-amount.svg create mode 100644 assets/images/guide/payments/send/review-payment.svg create mode 100644 assets/images/guide/payments/send/select-fee-rate.svg diff --git a/assets/images/guide/payments/send/input-address.svg b/assets/images/guide/payments/send/input-address.svg new file mode 100644 index 000000000..829b402f6 --- /dev/null +++ b/assets/images/guide/payments/send/input-address.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/assets/images/guide/payments/send/input-amount.svg b/assets/images/guide/payments/send/input-amount.svg new file mode 100644 index 000000000..218c4c509 --- /dev/null +++ b/assets/images/guide/payments/send/input-amount.svg @@ -0,0 +1,22 @@ + + + + + + + + + + + + + + + + + + + + + + diff --git a/assets/images/guide/payments/send/review-payment.svg b/assets/images/guide/payments/send/review-payment.svg new file mode 100644 index 000000000..f480d3a93 --- /dev/null +++ b/assets/images/guide/payments/send/review-payment.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/assets/images/guide/payments/send/select-fee-rate.svg b/assets/images/guide/payments/send/select-fee-rate.svg new file mode 100644 index 000000000..a0a28b05d --- /dev/null +++ b/assets/images/guide/payments/send/select-fee-rate.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/guide/payments/send.md b/guide/payments/send.md index 3acb72f0e..096dd5509 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -27,7 +27,7 @@ To send a payment on the Bitcoin blockchain we need the recipient's address. Sin This is easily accomplished by generating a new address in the receiving wallet application, then sharing it with the sender. If the sender and receiver are together at the time, scanning the receivers address as a QR code will be easy, but if they are not, they can send the address as text in any regular communication tool like email, sms etc. -## Input an address +## Inputing an address
{% include image.html @@ -38,13 +38,14 @@ This is easily accomplished by generating a new address in the receiving wallet layout = "float-right-desktop" %} -Once you have gotten the address, it needs to be inputted on the "create transaction" interface. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. +Once you have gotten the address, its time to enter the payment details. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. -Upon address input, the user should be clearly informed if the address is valid or not. If the address is not valid, or incompatible with the current application, sending should be disabled. +Once inputted, the user should be clearly informed if the address is valid or not. If the address is not valid, or incompatible with the wallet, sending should be disabled. **QR Code** -- Once the camera detects a valid address in the QR Code, it can be automatically inputted. The user will need to grant access your application to be able to scan QR Codes. -**Copy Paste** -- When the sender receives the address in text format they would need to paste in the address. Your application can detect a valid address in the clipboard and prompt the user to press a button to paste. +**Copy Paste** -- When the sender receives the address in text format they would need to paste in the address. Your application can detect a valid address in the clipboard and prompt the user to press a button to paste. While most platforms allow applications to read the contents of the device's clipboard which enable convenient copy/paste prompts. Some users may perceive it as a privacy infringement. You may want to consider giving them an option to disable such automatic reading of the clipboard contents. +
**Do's** @@ -52,7 +53,6 @@ Upon address input, the user should be clearly informed if the address is valid - Indicate clearly if the address is valid or not - Show the whole address if possible to help the user visually verify it is correct - If space is a constraint, truncate the address in the middle so that both the beginning and end are visible -- Most platforms allow applications to read the contents of the device's clipboard to enable convenient copy/paste. While some users find this helpful, some may perceive it as a privacy infringement. You may want to consider giving them an option to disable automatic reading of the clipboard. **Don'ts** @@ -60,13 +60,6 @@ Upon address input, the user should be clearly informed if the address is valid ## Inputing an amount -{% include image.html - image = "/assets/images/guide/payments/send/input-amount-desktop.svg" - alt-text = "Example image" - width = 1600 - height = 800 -%} -
{% include image.html image = "/assets/images/guide/payments/send/input-amount.svg" @@ -135,7 +128,7 @@ Human error with fee selection can lead to [costly mistakes](https://www.coindes
{% include image.html - image = "/assets/images/guide/payments/send/input-amount.svg" + image = "/assets/images/guide/payments/send/review-payment.svg" alt-text = "Example image" width = 400 height = 400 @@ -158,10 +151,6 @@ If the wallet allows users to set a spending limit and the current transaction e ## Transaction processing and confirmation -Once the transaction is valid it is now in the *memory pool*, and is available for including in a block by miners. When in the *memory pool*, the sender can see the transaction in their wallet as unconfirmed or pending. - -After broadcasting a transaction, the process of propagation and validation is quite fast so showing these states may be infeasible. You may inform the user that their transaction is pending a confirmation, the estimated time to confirm given the current fee market, and once it has gotten its first confirmation. - {% include image.html image = "https://i.imgur.com/idV0Mt7.png" retina = "https://i.imgur.com/idV0Mt7.png" @@ -170,6 +159,10 @@ After broadcasting a transaction, the process of propagation and validation is q height = 800 %} +Once the transaction is valid it is now in the *memory pool*, and is available for including in a block by miners. When in the *memory pool*, the sender can see the transaction in their wallet as unconfirmed or pending. + +After broadcasting a transaction, the process of propagation and validation is quite fast so showing these states may be infeasible. You may inform the user that their transaction is pending a confirmation, the estimated time to confirm given the current fee market, and once it has gotten its first confirmation. + **Do's** - Clearly indicate state of the outgoing transaction - Show the amount of confirmations the transaction has gotten From 7da510eef6b342e5a73712db6152b1ff0fb29538 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Wed, 17 Mar 2021 03:35:41 +0100 Subject: [PATCH 10/20] style(payments/send): change from user to sender --- guide/payments/send.md | 52 +++++++++++++++++++++--------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index 096dd5509..93f274538 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -6,21 +6,21 @@ nav_order: 2 parent: Payments permalink: /guide/payments/send/ main_classes: -no-top-padding -image: /assets/images/guide/payments/overview/page-overview.svg +# image: /assets/images/guide/payments/send/header.svg --- # Sending bitcoin -Sending bitcoin can be a very straight forward or complex flow in a bitcoin application. Users may be sending bitcoin to a known contact, moving it between their own wallets on different devices, or making a purchase through a [payment processor](https://bitcoin.design/guide/getting-started/software/#payment-processors). +Sending bitcoin can be a very straight forward or complex flow in a bitcoin application. People may be sending bitcoin to a known contact, moving it between their own wallets on different devices, or making a purchase through a [payment processor](https://bitcoin.design/guide/getting-started/software/#payment-processors). -Regardless of where the bitcoin is being sent, there are some basic configurations that an application needs to help the user with when creating a transaction: +Regardless of where the bitcoin is being sent, there are some basic configurations that an application needs to help the sender with when creating a transaction: - **Amount** — How much to send - **Recipient address** — Where to send the bitcoin - **Coin selection** — Which coins/inputs to use (optional) - **Fee settings** — Prioritize fast confirmation or low cost (optional) -The order of configuration for the payment can be tailored to your use case. For example, you may make users set the amount before the address is entered. +The order of configuration for the payment can be tailored to your use case. For example, you may make the sender set the amount before the address is entered. ## Get the recipient address To send a payment on the Bitcoin blockchain we need the recipient's address. Since Bitcoin [addresses](https://bitcoin.design/guide/glossary/#address) are long and seemingly random, they are best shared by copying and pasting in plain text, as a [payment link](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links), or as a scannable [QR Code](https://bitcoin.design/guide/foundations/wallet-interoperability/#qr-codes). @@ -31,8 +31,8 @@ This is easily accomplished by generating a new address in the receiving wallet
{% include image.html - image = "/assets/images/guide/payments/send/enter-address.svg" - alt-text = "Example image" + image = "/assets/images/guide/payments/send/input-address.svg" + alt-text = "Address input field prompting the sender to paste the address" width = 400 height = 400 layout = "float-right-desktop" @@ -40,18 +40,18 @@ This is easily accomplished by generating a new address in the receiving wallet Once you have gotten the address, its time to enter the payment details. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. -Once inputted, the user should be clearly informed if the address is valid or not. If the address is not valid, or incompatible with the wallet, sending should be disabled. +Once inputted, the sender should be clearly informed if the address is valid or not. If the address is not valid, or incompatible with the wallet, sending should be disabled. -**QR Code** -- Once the camera detects a valid address in the QR Code, it can be automatically inputted. The user will need to grant access your application to be able to scan QR Codes. +**QR Code** -- Once the camera detects a valid address in the QR Code, it can be automatically inputted. Access will need to be granted to your application to enable scanning of QR Codes. -**Copy Paste** -- When the sender receives the address in text format they would need to paste in the address. Your application can detect a valid address in the clipboard and prompt the user to press a button to paste. While most platforms allow applications to read the contents of the device's clipboard which enable convenient copy/paste prompts. Some users may perceive it as a privacy infringement. You may want to consider giving them an option to disable such automatic reading of the clipboard contents. +**Copy Paste** -- When the sender receives the address in text format they would need to paste in the address. Your application can detect a valid address in the clipboard and prompt the sender to press a button to paste. While most platforms allow applications to read the contents of the device's clipboard which enable convenient copy/paste prompts. Some may perceive it as a privacy infringement so you may want to consider providing the option to disable automatic reading of the clipboard contents in the application preferences.
**Do's** - Indicate clearly if the address is valid or not -- Show the whole address if possible to help the user visually verify it is correct +- Show the whole address if possible to help the sender visually verify it is correct - If space is a constraint, truncate the address in the middle so that both the beginning and end are visible **Don'ts** @@ -63,15 +63,15 @@ Once inputted, the user should be clearly informed if the address is valid or no
{% include image.html image = "/assets/images/guide/payments/send/input-amount.svg" - alt-text = "Example image" + alt-text = "Amount input field with bitcoin, local currency and selections for fractions of the total wallet balance" width = 400 height = 400 layout = "float-right-desktop" %} -Depending on their familiarity with bitcoin, your users may have a preference of which denomination the amount should be specified in. Read more about why and changing units contextually in [Units, symbols and amount display](https://deploy-preview-63--sad-borg-390916.netlify.app/guide/payments/units-and-symbols/). +Depending on their familiarity with bitcoin, the sender may have a preference of which denomination the amount should be specified in. Read more about why and changing units contextually in [Units, symbols and amount display](https://deploy-preview-63--sad-borg-390916.netlify.app/guide/payments/units-and-symbols/). -Since an amount specified in bitcoin or sats often involve many digits, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example). Applications can allow the sender select fractions of the total available balance. Most common is *max* or *all*, which also makes it easy for the user to sweep the entire balance to another wallet. +Since an amount specified in bitcoin or sats often involve many digits, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example). Applications can allow the sender select fractions of the total available balance. Most common is *max* or *all*, which also makes it easy for the sender to sweep the entire balance to another wallet.
**Do's** @@ -92,7 +92,7 @@ Since an amount specified in bitcoin or sats often involve many digits, and don'
{% include image.html image = "/assets/images/guide/payments/send/select-fee-rate.svg" - alt-text = "Example image" + alt-text = "Fee selection component with high, medium, low urgency options" width = 400 height = 400 layout = "float-right-desktop" @@ -100,15 +100,15 @@ Since an amount specified in bitcoin or sats often involve many digits, and don' The application can automatically estimate a fee and set it for the sender. This would normally prioritize the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they can choose to optimize for faster confirmation, or lower fees. -When allowing users to set their own fee, it is important to clearly communicate the estimated cost and confirmation time, along with some details on how the fee gets calculated ([see below](#How-are-transaction-fees-calculated)). +When allowing the sender to set their own fee, it is important to clearly communicate the estimated cost and confirmation time. Be mindful that the way bitcoin fee's are calculated may not map to traditional financial experience so provide details on how the fee gets calculated. -Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses). Someone can set a fee rate that's way too high, overpaying in fees or having transactions stuck for long periods of time if the fee is too low. For these reasons you should carefully consider if and how to expose transaction fees to users. +Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses), and fee estimations are imperfect. Carefully consider if and how to expose transaction fees to senders.
**Variations** - Automatically set fee rate -- Allow user to choose from presets -- Allow user to enter a custom fee rate (advanced) +- Allow sender to choose from presets +- Allow sender to enter a custom fee rate (advanced) **Do's** @@ -116,20 +116,20 @@ Human error with fee selection can lead to [costly mistakes](https://www.coindes - Display the fee rate and estimated transaction confirmation time - Display bitcoin and local currency denominations for cost reference - Include an option to adjust fee rate based on some presets (e.g. high, medium, low priority) -- Display a warning if the user enters an amount far beyond the recommended rate +- Display a warning if the sender enters an amount far beyond the recommended rate - Consider offering a [replace by fee]() option to speed up stuck transactions **Don'ts** - Allow for confusion between total fee and fee rate -- Allow users to overpay in transaction fees +- Allow senders to overpay in transaction fees ## Reviewing and approving the payment
{% include image.html image = "/assets/images/guide/payments/send/review-payment.svg" - alt-text = "Example image" + alt-text = "Approval screen with details of the transaction and confirmation button" width = 400 height = 400 layout = "float-right-desktop" @@ -137,31 +137,31 @@ Human error with fee selection can lead to [costly mistakes](https://www.coindes A valid transaction that is broadcasted to the network cannot be reversed, so it is critical that the sender is given a chance to double check the payment details (amount, recipient address, total fee, etc) before submitting the transaction. -If the wallet allows users to set a spending limit and the current transaction exceeds it, make sure users go through some security check (biometric, enter PIN, 2FA password, etc). This can also be used if the 100% of the funds are being sent. +If your application allows setting spending limits, and the current transaction exceeds it, make sure they go through some security check (biometric, enter PIN, 2FA password, etc). This technique can also be employed if the transaction is attempting to use the max wallet balance.
**Do's** -- Allow users to review payment details and adjust if necessary, before submitting the transaction +- Allow the sender to review payment details and adjust if necessary, before submitting the transaction - Show amount and fee in both bitcoin and local currency denominations **Don'ts** -- Assume the user has got all the details correct, give them the chance to look over the information before broadcasting the transaction +- Assume the sender has got all the details correct, give them the chance to look over the information before broadcasting the transaction ## Transaction processing and confirmation {% include image.html image = "https://i.imgur.com/idV0Mt7.png" retina = "https://i.imgur.com/idV0Mt7.png" - alt-text = "Example image" + alt-text = "Notifications after the transaction is broadcasted" width = 1600 height = 800 %} Once the transaction is valid it is now in the *memory pool*, and is available for including in a block by miners. When in the *memory pool*, the sender can see the transaction in their wallet as unconfirmed or pending. -After broadcasting a transaction, the process of propagation and validation is quite fast so showing these states may be infeasible. You may inform the user that their transaction is pending a confirmation, the estimated time to confirm given the current fee market, and once it has gotten its first confirmation. +After broadcasting a transaction, the process of propagation and validation is quite fast so showing these states may be infeasible. You may inform the sender that their transaction is pending a confirmation, the estimated time to confirm given the current fee market, and once it has gotten its first confirmation. **Do's** - Clearly indicate state of the outgoing transaction From 6e886d84eed32b44236d384fff6a517bf1b78b0a Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Thu, 18 Mar 2021 00:11:22 +0100 Subject: [PATCH 11/20] docs(payments/send): update with feedback from @ConorOkus --- guide/payments/send.md | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index 93f274538..3f514493b 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -11,7 +11,7 @@ main_classes: -no-top-padding # Sending bitcoin -Sending bitcoin can be a very straight forward or complex flow in a bitcoin application. People may be sending bitcoin to a known contact, moving it between their own wallets on different devices, or making a purchase through a [payment processor](https://bitcoin.design/guide/getting-started/software/#payment-processors). +Sending bitcoin can be a very straightforward or complex flow in a Bitcoin application. People may be sending bitcoin to a known contact, moving it between their own wallets on different devices, or making a purchase through a [payment processor](https://bitcoin.design/guide/getting-started/software/#payment-processors). Regardless of where the bitcoin is being sent, there are some basic configurations that an application needs to help the sender with when creating a transaction: @@ -20,10 +20,10 @@ Regardless of where the bitcoin is being sent, there are some basic configuratio - **Coin selection** — Which coins/inputs to use (optional) - **Fee settings** — Prioritize fast confirmation or low cost (optional) -The order of configuration for the payment can be tailored to your use case. For example, you may make the sender set the amount before the address is entered. +You can tailor the configuration's order for the payment. For example, you may make users set the amount before they enter the address. ## Get the recipient address -To send a payment on the Bitcoin blockchain we need the recipient's address. Since Bitcoin [addresses](https://bitcoin.design/guide/glossary/#address) are long and seemingly random, they are best shared by copying and pasting in plain text, as a [payment link](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links), or as a scannable [QR Code](https://bitcoin.design/guide/foundations/wallet-interoperability/#qr-codes). +To send a payment on the Bitcoin blockchain, we need the recipient's address. Since Bitcoin [addresses](https://bitcoin.design/guide/glossary/#address) are long and seemingly random, they are best shared by copying and pasting in plain text, as a [payment link](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links), or as a scannable [QR Code](https://bitcoin.design/guide/foundations/wallet-interoperability/#qr-codes). This is easily accomplished by generating a new address in the receiving wallet application, then sharing it with the sender. If the sender and receiver are together at the time, scanning the receivers address as a QR code will be easy, but if they are not, they can send the address as text in any regular communication tool like email, sms etc. @@ -38,13 +38,11 @@ This is easily accomplished by generating a new address in the receiving wallet layout = "float-right-desktop" %} -Once you have gotten the address, its time to enter the payment details. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. +Once you have gotten the address, its time to enter the payment details. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. The sender should be clearly informed if the address is valid or not. -Once inputted, the sender should be clearly informed if the address is valid or not. If the address is not valid, or incompatible with the wallet, sending should be disabled. +**QR Code** -- Access will need to be granted to your application to enable scanning of QR Codes. Once the camera detects a valid address in the QR Code, it can be automatically inputted. -**QR Code** -- Once the camera detects a valid address in the QR Code, it can be automatically inputted. Access will need to be granted to your application to enable scanning of QR Codes. - -**Copy Paste** -- When the sender receives the address in text format they would need to paste in the address. Your application can detect a valid address in the clipboard and prompt the sender to press a button to paste. While most platforms allow applications to read the contents of the device's clipboard which enable convenient copy/paste prompts. Some may perceive it as a privacy infringement so you may want to consider providing the option to disable automatic reading of the clipboard contents in the application preferences. +**Copy Paste** -- When the sender receives the address as text your application can detect a valid address in the clipboard and prompt the sender to press a button to paste it.
@@ -71,7 +69,9 @@ Once inputted, the sender should be clearly informed if the address is valid or Depending on their familiarity with bitcoin, the sender may have a preference of which denomination the amount should be specified in. Read more about why and changing units contextually in [Units, symbols and amount display](https://deploy-preview-63--sad-borg-390916.netlify.app/guide/payments/units-and-symbols/). -Since an amount specified in bitcoin or sats often involve many digits, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example). Applications can allow the sender select fractions of the total available balance. Most common is *max* or *all*, which also makes it easy for the sender to sweep the entire balance to another wallet. +Since an amount specified in bitcoin or satoshis often involve many digits, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example). + +Applications can allow the sender to select fractions of the total available balance. Most common is *max* or *use full balance*, which also makes it easy for the sender to sweep all of the bitcoin to another wallet.
**Do's** @@ -79,14 +79,13 @@ Since an amount specified in bitcoin or sats often involve many digits, and don' - Allow different denominations to be used for the amount - Show the total balance available to send - Allow selecting max amount (subtracting the required fee) -- Payment links and QR codes can contain an amount — when they do, the amount should be populated automatically. +- Payment links and QR Codes can contain an amount. When they do, the amount should be populated automatically. **Don'ts** - Don't allow entering more than the available balance - ## Transaction fee
@@ -100,7 +99,7 @@ Since an amount specified in bitcoin or sats often involve many digits, and don' The application can automatically estimate a fee and set it for the sender. This would normally prioritize the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they can choose to optimize for faster confirmation, or lower fees. -When allowing the sender to set their own fee, it is important to clearly communicate the estimated cost and confirmation time. Be mindful that the way bitcoin fee's are calculated may not map to traditional financial experience so provide details on how the fee gets calculated. +When allowing the sender to set their own fee, it is important to clearly communicate the estimated cost and confirmation time. Be mindful that the way Bitcoin fee's are calculated may not map to the senders traditional financial experience, so if you allow them to choose their own fee consider providing details on how the fee gets calculated. Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses), and fee estimations are imperfect. Carefully consider if and how to expose transaction fees to senders.
@@ -117,7 +116,6 @@ Human error with fee selection can lead to [costly mistakes](https://www.coindes - Display bitcoin and local currency denominations for cost reference - Include an option to adjust fee rate based on some presets (e.g. high, medium, low priority) - Display a warning if the sender enters an amount far beyond the recommended rate -- Consider offering a [replace by fee]() option to speed up stuck transactions **Don'ts** From 32230edd2f57d01e0f306b4b18613176a45e9349 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Thu, 18 Mar 2021 12:58:58 +0100 Subject: [PATCH 12/20] docs(payments/send): update with feedback from @pavlenex Co-authored-by: Pavlenex --- guide/payments/send.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index 3f514493b..63016dae2 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -157,14 +157,14 @@ If your application allows setting spending limits, and the current transaction height = 800 %} -Once the transaction is valid it is now in the *memory pool*, and is available for including in a block by miners. When in the *memory pool*, the sender can see the transaction in their wallet as unconfirmed or pending. +Once the transaction is valid, it is now in the memory pool and is available for including in a block by miners. When in the memory pool, the sender can see the wallet's transaction as unconfirmed or pending. -After broadcasting a transaction, the process of propagation and validation is quite fast so showing these states may be infeasible. You may inform the sender that their transaction is pending a confirmation, the estimated time to confirm given the current fee market, and once it has gotten its first confirmation. +After broadcasting a transaction, the process of propagation and validation is quite fast so showing these states may be infeasible. You may inform the sender that their transaction is pending a confirmation, the estimated time to confirm the current fee market, and once it has gotten its first confirmation. **Do's** -- Clearly indicate state of the outgoing transaction -- Show the amount of confirmations the transaction has gotten +- Clearly indicate the state of the outgoing transaction +- Show the amount of confirmations the transaction has - Provide information on transaction/block ID for receipt purposes **Don'ts** -- Show a the transaction as confirmed until it has received ***at least*** one confirmation, but preferably six \ No newline at end of file +- Show the transaction as confirmed until it has received ***at least*** one confirmation, but preferably six \ No newline at end of file From 9849bf47970fa997f6fda2eda762a95f0e3cc043 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Fri, 19 Mar 2021 21:32:46 +0100 Subject: [PATCH 13/20] fix(payments/send): reorder fee selection presets --- .../guide/payments/send/select-fee-rate.svg | 54 ++++++++++++++++++- guide/payments/send.md | 6 +-- 2 files changed, 56 insertions(+), 4 deletions(-) diff --git a/assets/images/guide/payments/send/select-fee-rate.svg b/assets/images/guide/payments/send/select-fee-rate.svg index a0a28b05d..eed76b79d 100644 --- a/assets/images/guide/payments/send/select-fee-rate.svg +++ b/assets/images/guide/payments/send/select-fee-rate.svg @@ -1 +1,53 @@ - \ No newline at end of file + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/guide/payments/send.md b/guide/payments/send.md index 63016dae2..a82270d9e 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -25,7 +25,7 @@ You can tailor the configuration's order for the payment. For example, you may m ## Get the recipient address To send a payment on the Bitcoin blockchain, we need the recipient's address. Since Bitcoin [addresses](https://bitcoin.design/guide/glossary/#address) are long and seemingly random, they are best shared by copying and pasting in plain text, as a [payment link](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links), or as a scannable [QR Code](https://bitcoin.design/guide/foundations/wallet-interoperability/#qr-codes). -This is easily accomplished by generating a new address in the receiving wallet application, then sharing it with the sender. If the sender and receiver are together at the time, scanning the receivers address as a QR code will be easy, but if they are not, they can send the address as text in any regular communication tool like email, sms etc. +This is easily accomplished by generating a new address in the receiving wallet application, then sharing it with the sender. If the sender and receiver are physically close to each other, scanning the receiver's address as a QR Code will be easy. Still, if they are not, they can send the address as text in any regular communication tool like email, SMS, etc. ## Inputing an address @@ -38,7 +38,7 @@ This is easily accomplished by generating a new address in the receiving wallet layout = "float-right-desktop" %} -Once you have gotten the address, its time to enter the payment details. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly sharing and inputting addresses. The sender should be clearly informed if the address is valid or not. +Once you have gotten the address, its time to enter the payment details. Bitcoin transactions are irreversible, so both the sender and receiver should take great care in correctly sharing and inputting addresses. The sender should be clearly informed if the address is valid or not. **QR Code** -- Access will need to be granted to your application to enable scanning of QR Codes. Once the camera detects a valid address in the QR Code, it can be automatically inputted. @@ -159,7 +159,7 @@ If your application allows setting spending limits, and the current transaction Once the transaction is valid, it is now in the memory pool and is available for including in a block by miners. When in the memory pool, the sender can see the wallet's transaction as unconfirmed or pending. -After broadcasting a transaction, the process of propagation and validation is quite fast so showing these states may be infeasible. You may inform the sender that their transaction is pending a confirmation, the estimated time to confirm the current fee market, and once it has gotten its first confirmation. +After broadcasting a transaction, the process of propagation and validation is quite fast, so showing these states may be infeasible. You may inform the sender that their transaction is pending a confirmation, the estimated time to confirm given the current fee market, and once it has gotten its first confirmation. **Do's** - Clearly indicate the state of the outgoing transaction From 582fb26be49d097ad2d586ee7d46ce8a42906e8f Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Tue, 30 Mar 2021 23:51:51 +0200 Subject: [PATCH 14/20] docs(payments/send): update with @pavlenex feedback Co-authored-by: Pavlenex --- guide/payments/send.md | 88 ++++++++++++++++++++---------------------- 1 file changed, 41 insertions(+), 47 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index a82270d9e..6e01cfa42 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -11,23 +11,34 @@ main_classes: -no-top-padding # Sending bitcoin -Sending bitcoin can be a very straightforward or complex flow in a Bitcoin application. People may be sending bitcoin to a known contact, moving it between their own wallets on different devices, or making a purchase through a [payment processor](https://bitcoin.design/guide/getting-started/software/#payment-processors). +Sending bitcoin can be a very straightforward or complex flow in a Bitcoin application. People may be sending bitcoin to a known contact, moving it between their wallets on different devices, or making a purchase through a [payment processor](https://bitcoin.design/guide/getting-started/software/#payment-processors). -Regardless of where the bitcoin is being sent, there are some basic configurations that an application needs to help the sender with when creating a transaction: +Let us look at the main transaction options senders need to configure when moving bitcoin: - **Amount** — How much to send - **Recipient address** — Where to send the bitcoin - **Coin selection** — Which coins/inputs to use (optional) - **Fee settings** — Prioritize fast confirmation or low cost (optional) -You can tailor the configuration's order for the payment. For example, you may make users set the amount before they enter the address. - +You do not need to follow the order below. Feel free to tailor the configuration's order for the payment to what best serves your users. For example, you may make users set the amount before they enter the address. + ## Get the recipient address -To send a payment on the Bitcoin blockchain, we need the recipient's address. Since Bitcoin [addresses](https://bitcoin.design/guide/glossary/#address) are long and seemingly random, they are best shared by copying and pasting in plain text, as a [payment link](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links), or as a scannable [QR Code](https://bitcoin.design/guide/foundations/wallet-interoperability/#qr-codes). -This is easily accomplished by generating a new address in the receiving wallet application, then sharing it with the sender. If the sender and receiver are physically close to each other, scanning the receiver's address as a QR Code will be easy. Still, if they are not, they can send the address as text in any regular communication tool like email, SMS, etc. +
+{% include image.html + image = "/assets/images/guide/payments/send/get-recipient-address.svg" + alt-text = "Graphic showing chat messages between the sender and receiver. The sender sends a bitcoin address and the receiver agrees to pay." + width = 400 + height = 400 + layout = "float-right-desktop" +%} + +To send a payment on the Bitcoin blockchain, the sender needs to obtain an address from the recipient. Since Bitcoin [addresses](https://bitcoin.design/guide/glossary/#address) are long and seemingly random, they are best shared by copying and pasting in plain text, as a [payment link](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links), or as a scannable [QR Code](https://bitcoin.design/guide/foundations/wallet-interoperability/#qr-codes). -## Inputing an address +The receiver does this by generating a new address in their wallet application, then sharing it with the sender. If the sender and receiver are physically close to each other, scanning the receiver's address as a QR Code will be easy. Still, if they are not, they can send the address as text in any regular communication tool like email, SMS, etc. +
+ +## Inputting an address
{% include image.html @@ -38,23 +49,23 @@ This is easily accomplished by generating a new address in the receiving wallet layout = "float-right-desktop" %} -Once you have gotten the address, its time to enter the payment details. Bitcoin transactions are irreversible, so both the sender and receiver should take great care in correctly sharing and inputting addresses. The sender should be clearly informed if the address is valid or not. +Once you have gotten the address, its time to enter the payment details. Bitcoin transactions are irreversible, so both the sender and receiver should take great care in correctly sharing and inputting addresses. -**QR Code** -- Access will need to be granted to your application to enable scanning of QR Codes. Once the camera detects a valid address in the QR Code, it can be automatically inputted. +**QR Code** -- Access will need to be granted to your application to enable scanning of QR Codes. Once the camera detects a valid address in the QR Code, it should automatically fill the address field. -**Copy Paste** -- When the sender receives the address as text your application can detect a valid address in the clipboard and prompt the sender to press a button to paste it. +**Copy Paste** -- When the sender receives the address or payment link as text, your application can detect a valid address in the clipboard and prompt the sender to press a button to paste it.
**Do's** - Indicate clearly if the address is valid or not -- Show the whole address if possible to help the sender visually verify it is correct +- Show the full address if possible to help the sender visually verify it is correct - If space is a constraint, truncate the address in the middle so that both the beginning and end are visible **Don'ts** -- Don't allow a transaction to be sent if the address is invalid +- Prevent the transaction to be sent if the address is invalid ## Inputing an amount @@ -67,24 +78,18 @@ Once you have gotten the address, its time to enter the payment details. Bitcoin layout = "float-right-desktop" %} -Depending on their familiarity with bitcoin, the sender may have a preference of which denomination the amount should be specified in. Read more about why and changing units contextually in [Units, symbols and amount display](https://deploy-preview-63--sad-borg-390916.netlify.app/guide/payments/units-and-symbols/). - -Since an amount specified in bitcoin or satoshis often involve many digits, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example). +Unless the sender needs to transfer a specific amount of bitcoin, they should have the ability to switch between other currencies when inputting the amount. It is common practice to provide bitcoin, satoshi, and the sender's preferred fiat currency as options. -Applications can allow the sender to select fractions of the total available balance. Most common is *max* or *use full balance*, which also makes it easy for the sender to sweep all of the bitcoin to another wallet. +Applications sometimes also allow the sender to select fractions of their total available balance by providing a "max" or "use full balance" button. These fractions can be handy when the sender needs to make transfers from their hot wallet to a more secure hardware wallet. **Do's** -- Allow different denominations to be used for the amount -- Show the total balance available to send -- Allow selecting max amount (subtracting the required fee) -- Payment links and QR Codes can contain an amount. When they do, the amount should be populated automatically. - -**Don'ts** - -- Don't allow entering more than the available balance - +- Allow senders to switch which denomination they are inputting the amount with +- State the total balance available (subtracting the required fee) +- Allow selecting max amount or fractions for easier fund management +- Payment links and QR Codes can contain an amount. When they do, your application should populate the amount field automatically +- Indicate if an amount entered is more than the available balance ## Transaction fee @@ -97,30 +102,23 @@ Applications can allow the sender to select fractions of the total available bal layout = "float-right-desktop" %} -The application can automatically estimate a fee and set it for the sender. This would normally prioritize the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they can choose to optimize for faster confirmation, or lower fees. +The application can automatically estimate a fee and set it for the sender. This would typically prioritize the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine-grained fee controls so they can choose to optimize for faster confirmation or lower fees. -When allowing the sender to set their own fee, it is important to clearly communicate the estimated cost and confirmation time. Be mindful that the way Bitcoin fee's are calculated may not map to the senders traditional financial experience, so if you allow them to choose their own fee consider providing details on how the fee gets calculated. +When allowing the sender to set fees, it is essential to communicate the estimated cost in their preferred currency and the estimated time until first confirmation. Be mindful that the way Bitcoin fees get calculated may not map to the sender's traditional financial experience. If you allow adjustment of fees, consider providing details on how it gets calculated. -Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses), and fee estimations are imperfect. Carefully consider if and how to expose transaction fees to senders. +Human error with fee selection can lead to costly mistakes, and fee estimations are imperfect. Carefully consider if and how you expose transaction fees to senders. **Variations** -- Automatically set fee rate +- Automatically set the fee-rate - Allow sender to choose from presets - Allow sender to enter a custom fee rate (advanced) **Do's** -- Clearly communicate information related to the fee rate options -- Display the fee rate and estimated transaction confirmation time -- Display bitcoin and local currency denominations for cost reference -- Include an option to adjust fee rate based on some presets (e.g. high, medium, low priority) -- Display a warning if the sender enters an amount far beyond the recommended rate - -**Don'ts** - -- Allow for confusion between total fee and fee rate -- Allow senders to overpay in transaction fees +- If the sender does not have advanced knowledge about bitcoin fees but wants control over the fee-rate, provide presets to select how urgent the transaction is (e.g. low, medium, high priority) +- When using presets clearly communicate estimated confirmation time and costs related to each of the fee rate options +- When allowing users to enter their own fee rate warn the sender if they enter an amount far beyond the recommended fee-rate for the next block ## Reviewing and approving the payment @@ -135,17 +133,13 @@ Human error with fee selection can lead to [costly mistakes](https://www.coindes A valid transaction that is broadcasted to the network cannot be reversed, so it is critical that the sender is given a chance to double check the payment details (amount, recipient address, total fee, etc) before submitting the transaction. -If your application allows setting spending limits, and the current transaction exceeds it, make sure they go through some security check (biometric, enter PIN, 2FA password, etc). This technique can also be employed if the transaction is attempting to use the max wallet balance. +If your application allows setting spending limits, and the current transaction exceeds it, make sure they go through some security check (biometric, enter PIN, 2FA password, etc). This technique can also be employed if the transaction is attempting to use the max wallet balance. **Do's** -- Allow the sender to review payment details and adjust if necessary, before submitting the transaction -- Show amount and fee in both bitcoin and local currency denominations - -**Don'ts** - -- Assume the sender has got all the details correct, give them the chance to look over the information before broadcasting the transaction +- Allow the sender to review payment details like address, amount, and fees and adjust if necessary before submitting the transaction +- Show the amount being sent and the fee information in both bitcoin and the senders preferred currency ## Transaction processing and confirmation @@ -167,4 +161,4 @@ After broadcasting a transaction, the process of propagation and validation is q - Provide information on transaction/block ID for receipt purposes **Don'ts** -- Show the transaction as confirmed until it has received ***at least*** one confirmation, but preferably six \ No newline at end of file +- Show the transaction as confirmed until it has received ***at least*** one confirmation, but preferably six From 59732be29a2fdc31e8dfe40e3ccf0f6a00387879 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Tue, 30 Mar 2021 23:54:10 +0200 Subject: [PATCH 15/20] docs(payments/send): add get recipient address graphic --- assets/images/guide/payments/send/get-recipient-address.svg | 1 + 1 file changed, 1 insertion(+) create mode 100644 assets/images/guide/payments/send/get-recipient-address.svg diff --git a/assets/images/guide/payments/send/get-recipient-address.svg b/assets/images/guide/payments/send/get-recipient-address.svg new file mode 100644 index 000000000..1c00ba294 --- /dev/null +++ b/assets/images/guide/payments/send/get-recipient-address.svg @@ -0,0 +1 @@ + \ No newline at end of file From 0ffaf3a93f538eadc3b70f12df2be1acda7920b0 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Wed, 31 Mar 2021 10:31:55 +0200 Subject: [PATCH 16/20] docs(payments/send): update processing and confirmation --- guide/payments/send.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index 6e01cfa42..891aacdf4 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -150,10 +150,15 @@ If your application allows setting spending limits, and the current transaction width = 1600 height = 800 %} +Let us look at how we communicate to the sender about the [processing of a transaction]({{ '/guide/payments/transactions/#transaction-lifecycle' | relative_url }}) after it has been broadcasted. There are three main states that you would want to inform or notify the sender of: -Once the transaction is valid, it is now in the memory pool and is available for including in a block by miners. When in the memory pool, the sender can see the wallet's transaction as unconfirmed or pending. +- **Pending/Unconfirmed** -- the transaction is successfully in the nodes memory pool and is being propagated throughout the network. +- **1 confirmation** -- the transaction has been selected by miners and included in a block. Since a reorganization can still happen, a transaction with one confirmation can also be considered a pending state by the receiver. +- **6 confirmations** -- commonly regarded as the final settlement of the payment. Some merchants, for example, would be willing to release the product or service. -After broadcasting a transaction, the process of propagation and validation is quite fast, so showing these states may be infeasible. You may inform the sender that their transaction is pending a confirmation, the estimated time to confirm given the current fee market, and once it has gotten its first confirmation. +While a transaction is pending, inform the sender of when they can expect the first confirmation. The fee market can sometimes be volatile, and the "time until the first confirmation" may change from what was estimated when they had initially broadcasted the transaction. + +After the first confirmation, the application can notify the sender that processing is underway, and by the sixth confirmation, you can indicate that the payment is finalized. **Do's** - Clearly indicate the state of the outgoing transaction From f9725ef6bf13d8344a187d031cc4c870ad8d771f Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Wed, 31 Mar 2021 10:47:15 +0200 Subject: [PATCH 17/20] style(payments/send): update colour scheme of get receipeint address --- assets/images/guide/payments/send/get-recipient-address.svg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/assets/images/guide/payments/send/get-recipient-address.svg b/assets/images/guide/payments/send/get-recipient-address.svg index 1c00ba294..ce70a0bdf 100644 --- a/assets/images/guide/payments/send/get-recipient-address.svg +++ b/assets/images/guide/payments/send/get-recipient-address.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file From 112925d979ed1e3b31715217deef6e648f833629 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Wed, 31 Mar 2021 13:41:11 +0200 Subject: [PATCH 18/20] style(payments/send): reformat processing section --- .../payments/send/get-recipient-address.svg | 2 +- .../guide/payments/send/input-amount.svg | 23 +------- .../guide/payments/send/select-fee-rate.svg | 54 +------------------ guide/payments/send.md | 15 +++--- 4 files changed, 11 insertions(+), 83 deletions(-) diff --git a/assets/images/guide/payments/send/get-recipient-address.svg b/assets/images/guide/payments/send/get-recipient-address.svg index ce70a0bdf..b1c8a7feb 100644 --- a/assets/images/guide/payments/send/get-recipient-address.svg +++ b/assets/images/guide/payments/send/get-recipient-address.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/assets/images/guide/payments/send/input-amount.svg b/assets/images/guide/payments/send/input-amount.svg index 218c4c509..6401db2d2 100644 --- a/assets/images/guide/payments/send/input-amount.svg +++ b/assets/images/guide/payments/send/input-amount.svg @@ -1,22 +1 @@ - - - - - - - - - - - - - - - - - - - - - - + \ No newline at end of file diff --git a/assets/images/guide/payments/send/select-fee-rate.svg b/assets/images/guide/payments/send/select-fee-rate.svg index eed76b79d..b92cafd9a 100644 --- a/assets/images/guide/payments/send/select-fee-rate.svg +++ b/assets/images/guide/payments/send/select-fee-rate.svg @@ -1,53 +1 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + \ No newline at end of file diff --git a/guide/payments/send.md b/guide/payments/send.md index 891aacdf4..1ecab13c0 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -11,7 +11,7 @@ main_classes: -no-top-padding # Sending bitcoin -Sending bitcoin can be a very straightforward or complex flow in a Bitcoin application. People may be sending bitcoin to a known contact, moving it between their wallets on different devices, or making a purchase through a [payment processor](https://bitcoin.design/guide/getting-started/software/#payment-processors). +Sending bitcoin can be a very straightforward or complex flow in a Bitcoin application. People may be sending bitcoin to a known contact, moving it between their wallets on different devices, or making a purchase through a [payment processor]({{ '/guide/getting-started/software/#payment-processors' | relative_url }}). Let us look at the main transaction options senders need to configure when moving bitcoin: @@ -33,7 +33,7 @@ You do not need to follow the order below. Feel free to tailor the configuration layout = "float-right-desktop" %} -To send a payment on the Bitcoin blockchain, the sender needs to obtain an address from the recipient. Since Bitcoin [addresses](https://bitcoin.design/guide/glossary/#address) are long and seemingly random, they are best shared by copying and pasting in plain text, as a [payment link](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links), or as a scannable [QR Code](https://bitcoin.design/guide/foundations/wallet-interoperability/#qr-codes). +To send a payment on the Bitcoin blockchain, the sender needs to obtain an address from the recipient. Since Bitcoin [addresses]({{ '/guide/glossary/#address' | relative_url }}) are long and seemingly random, they are best shared by copying and pasting in plain text, as a [payment link]({{ '/guide/foundations/wallet-interoperability/#payment-links' | relative_url }}), or as a scannable [QR Code]({{ '/guide/foundations/wallet-interoperability/#qr-codes' | relative_url }}). The receiver does this by generating a new address in their wallet application, then sharing it with the sender. If the sender and receiver are physically close to each other, scanning the receiver's address as a QR Code will be easy. Still, if they are not, they can send the address as text in any regular communication tool like email, SMS, etc. @@ -143,6 +143,7 @@ If your application allows setting spending limits, and the current transaction ## Transaction processing and confirmation +
{% include image.html image = "https://i.imgur.com/idV0Mt7.png" retina = "https://i.imgur.com/idV0Mt7.png" @@ -150,16 +151,16 @@ If your application allows setting spending limits, and the current transaction width = 1600 height = 800 %} + Let us look at how we communicate to the sender about the [processing of a transaction]({{ '/guide/payments/transactions/#transaction-lifecycle' | relative_url }}) after it has been broadcasted. There are three main states that you would want to inform or notify the sender of: -- **Pending/Unconfirmed** -- the transaction is successfully in the nodes memory pool and is being propagated throughout the network. -- **1 confirmation** -- the transaction has been selected by miners and included in a block. Since a reorganization can still happen, a transaction with one confirmation can also be considered a pending state by the receiver. -- **6 confirmations** -- commonly regarded as the final settlement of the payment. Some merchants, for example, would be willing to release the product or service. +**Pending/Unconfirmed** -- The transaction is successfully in the nodes' memory pool and is being propagated throughout the network. The fee market can sometimes be volatile, and the "time until the first confirmation" may change from what was estimated when they had initially broadcasted the transaction. While pending, inform the sender of when they can expect the first transaction confirmation. -While a transaction is pending, inform the sender of when they can expect the first confirmation. The fee market can sometimes be volatile, and the "time until the first confirmation" may change from what was estimated when they had initially broadcasted the transaction. +**1 confirmation** -- The transaction has been selected by miners and included in a block. Since a reorganization can still happen, a transaction with one confirmation can also be considered a pending state by the receiver. This is a good point to notify the sender. -After the first confirmation, the application can notify the sender that processing is underway, and by the sixth confirmation, you can indicate that the payment is finalized. +**6 confirmations** -- Commonly regarded as when the final settlement of the payment happens. Merchants, for example, would only be willing to release the product or service at this point. +
**Do's** - Clearly indicate the state of the outgoing transaction - Show the amount of confirmations the transaction has From c49f5d841bfc39fc82f9b73c8ab01d3a37237bfd Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Wed, 31 Mar 2021 15:25:36 +0200 Subject: [PATCH 19/20] fix(payments/send): update with feedback from @pavlenex Co-authored-by: Pavlenex --- guide/payments/send.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/guide/payments/send.md b/guide/payments/send.md index 1ecab13c0..54d2f81fe 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -49,7 +49,7 @@ The receiver does this by generating a new address in their wallet application, layout = "float-right-desktop" %} -Once you have gotten the address, its time to enter the payment details. Bitcoin transactions are irreversible, so both the sender and receiver should take great care in correctly sharing and inputting addresses. +Once you have gotten the address, it's time to enter the payment details. Bitcoin transactions are irreversible, so both the sender and receiver should take great care in correctly sharing and inputting addresses. **QR Code** -- Access will need to be granted to your application to enable scanning of QR Codes. Once the camera detects a valid address in the QR Code, it should automatically fill the address field. @@ -110,15 +110,15 @@ Human error with fee selection can lead to costly mistakes, and fee estimations **Variations** -- Automatically set the fee-rate +- Automatically set the fee rate - Allow sender to choose from presets - Allow sender to enter a custom fee rate (advanced) **Do's** -- If the sender does not have advanced knowledge about bitcoin fees but wants control over the fee-rate, provide presets to select how urgent the transaction is (e.g. low, medium, high priority) -- When using presets clearly communicate estimated confirmation time and costs related to each of the fee rate options -- When allowing users to enter their own fee rate warn the sender if they enter an amount far beyond the recommended fee-rate for the next block +- If the sender does not have advanced knowledge about bitcoin fees but wants control over the fee rate, provide presets to select how urgent the transaction is (e.g. low, medium, high priority) +- When using presets, clearly communicate estimated confirmation time and costs related to each of the fee rate options +- When allowing users to enter their own fee rate, warn the sender if they enter an amount far beyond the recommended fee rate for the next block ## Reviewing and approving the payment @@ -143,7 +143,6 @@ If your application allows setting spending limits, and the current transaction ## Transaction processing and confirmation -
{% include image.html image = "https://i.imgur.com/idV0Mt7.png" retina = "https://i.imgur.com/idV0Mt7.png" @@ -160,10 +159,9 @@ Let us look at how we communicate to the sender about the [processing of a trans **6 confirmations** -- Commonly regarded as when the final settlement of the payment happens. Merchants, for example, would only be willing to release the product or service at this point. -
**Do's** - Clearly indicate the state of the outgoing transaction -- Show the amount of confirmations the transaction has +- Show the number of confirmations the transaction has - Provide information on transaction/block ID for receipt purposes **Don'ts** From e376d6440e688704e167302d02c7fcaf7dab36e7 Mon Sep 17 00:00:00 2001 From: Johns Beharry Date: Wed, 31 Mar 2021 17:54:08 +0200 Subject: [PATCH 20/20] style(payment/send): convert confirmation image to svg --- .../payments/send/first-confirmation.svg | 1 + .../guide/payments/send/input-amount.svg | 23 ++++++++++++++++++- guide/payments/send.md | 3 +-- 3 files changed, 24 insertions(+), 3 deletions(-) create mode 100644 assets/images/guide/payments/send/first-confirmation.svg diff --git a/assets/images/guide/payments/send/first-confirmation.svg b/assets/images/guide/payments/send/first-confirmation.svg new file mode 100644 index 000000000..4ac73a115 --- /dev/null +++ b/assets/images/guide/payments/send/first-confirmation.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/assets/images/guide/payments/send/input-amount.svg b/assets/images/guide/payments/send/input-amount.svg index 6401db2d2..60701b45d 100644 --- a/assets/images/guide/payments/send/input-amount.svg +++ b/assets/images/guide/payments/send/input-amount.svg @@ -1 +1,22 @@ - \ No newline at end of file + + + + + + + + + + + + + + + + + + + + + + diff --git a/guide/payments/send.md b/guide/payments/send.md index 54d2f81fe..ff91433ee 100644 --- a/guide/payments/send.md +++ b/guide/payments/send.md @@ -144,8 +144,7 @@ If your application allows setting spending limits, and the current transaction ## Transaction processing and confirmation {% include image.html - image = "https://i.imgur.com/idV0Mt7.png" - retina = "https://i.imgur.com/idV0Mt7.png" + image = "/assets/images/guide/payments/send/first-confirmation.svg" alt-text = "Notifications after the transaction is broadcasted" width = 1600 height = 800