Bitcoin Design Review - Payments

# Bitcoin Design Review - Payments ## Introduction #### Change 1 ***Was*** > At its core, the Bitcoin protocol enables transactions between people without intermediaries, regardless of where in the world they are. > > This chapter is meant to give an overview of bitcoin transactions, including sending, receiving, and transaction privacy, with advice and best practices. After this chapter, you should be able to design payment solutions that are well suited to your product’s use case and understand best-practices for its implementation. > > We have already established that Bitcoin is money, so let’s dive into how it can be used to facilitate payments. ***Suggested*** > At its core, Bitcoin's protocol enables transactions between people without the need for intermediaries, regardless of where they are in the world. > > This chapter gives an overview of bitcoin transactions, as well as information, advice, and best practises for: sending, receiving, and transaction privacy. > > We have already established that Bitcoin is money, so let’s dive into how it can be used to facilitate payments. ... ## Transactions Overview ### Intro #### Change 2 ***Was*** > This page is meant to help you with understanding how bitcoin transactions get created and processed by the Bitcoin network. Bitcoin is a peer-to-peer push-payment system. This means that you can send, or push, bitcoin to any address at your will, at any time, without passing through a trusted third party. > > This is radically different from the traditional financial system, where it is often possible for others to pull and withdraw money from your account (utility companies, financial institutions, merchants, etc.). When you make a payment, it will pass through systems that might delay, control or block the payment. ***Suggested*** > This page provides an understanding of how bitcoin transactions are created, processed, and verified on the Bitcoin network. > > Bitcoin is a peer-to-peer push-payment system. This means that you can send, or push, bitcoin to any address at your will, at any time, without passing through a trusted third party. > > This is radically different from the traditional financial system, where it is often possible for third parties to pull and withdraw money from your account (utility companies, financial institutions, merchants, etc.). Additionally, traditional financial payments will pass through systems that might delay, control or block the payment. ... ### Transaction Lifecycle #### Change 2 ***Was*** > Let’s lay out the entire payment process. ***Suggested*** > Let’s lay out the entire process of a bitcoin payment. ... #### Change 3 ***Was*** > 3. Signing > - The transaction needs to be signed by the private key(s) of the input address(es) to be valid. The signing is often done in the same application after the transaction has created and configured, but this does not have to be the case. ***Suggested*** > 3. Signing > - In order to be valid, the transaction needs to be signed by the private key(s) of the input address(es) used to fund the transaction. The signing process is often done within the same application after the transaction has been created and configured, however this does not have to be the case. ... #### Change 4 ***Was*** > 4. Broadcasting > - The transaction is broadcasted to a Bitcoin node, normally the one the wallet is connected to. ***Suggested*** > 4. Broadcasting > - The transaction is broadcasted to a Bitcoin node, normally ~~the~~ one the wallet is connected to. ... #### Change 5 ***Was*** > 5. Validation > - The receiving node checks that the transaction is valid. In practice, this means confirming that it was signed by the private key of the relevant address. ***Suggested*** > 5. Validation > - The receiving node checks that the transaction is valid. In practice, this means confirming that it was signed by the private key of the relevant address(es). ... #### Change 6 ***Was*** > 7. Confirmations > - Given that you know how transactions are confirmed, lets look at how the number of confirmations affects the payment settlement. > > - Not every miner creates the new block with the same transactions, so some nodes may have a different version of the blockchain than others for a short time. The Bitcoin protocol’s main function is to bring all nodes to the same version of the blockchain. Through a process called chain reorganization, nodes remove their incorrect block and update with the winning block as determined by the majority of other nodes. > > - There is a slight risk that a transaction with 1 confirmation may revert to 0 confirmations when a chain reorganization occurs. Due to this, some parties may require more confirmations for the transaction before providing the product or service. > > - It is widely accepted that after 6 confirmations, no other reorganizations would occur, and the payment final. ***Suggested*** > 7. Confirmations > - Given that you know how transactions are confirmed, lets look at how the number of confirmations affects the payment settlement. > > - Not every miner creates the new block with the same transactions, so some nodes may have a different version of the blockchain than others for a short time. The Bitcoin protocol’s main function is to bring all nodes to the same version of the blockchain - ***or consensus.*** Through a process called chain reorganization, nodes remove their incorrect block and update with the winning block as determined by the majority of other nodes. > > - There is a slight risk that a transaction with 1 confirmation may revert to 0 confirmations when a chain reorganization occurs. ***Due to this, some parties may require multiple confirmations before considering a payment final and providing a product or service.*** > > - It is widely accepted that after 6 confirmations, no other reorganizations would occur, and the payment ***is*** final. ... ### Transaction Structure #### Change 7 ***Was*** > Think of a transaction as a file that contains the authorizations to spend some bitcoin, as well as the payment details of the recipient(s). Once miners get the transaction they check all the details once more before they include it into a block. ***Suggested*** > Think of a transaction as a file that contains the authorizations to spend some bitcoin, as well as the payment details of the recipient(s). ***Once miners receive a broadcasted transaction, they check all the details once more before including it into a block.*** ... #### Change 8 ***Was*** > In a Bitcoin wallet, funds are often not held in a single address, but more commonly in one address per transaction where you previously received bitcoin. When you are creating a transaction you need to specify which of your addresses you would like to use to fund it. If you need to spend more than what a single address holds, you can specify several. These are called inputs to the transaction. ***Suggested*** > In a Bitcoin wallet, funds are often not held in a single address, ***but more commonly in a collection of addresses (one address per transaction where you previously received bitcoin) managed within one wallet interface. When you create a bitcoin transaction,*** you need to specify which of your addresses you would like to use to fund it. If you need to spend more than what a single address holds, you can specify several. ***These are called transaction inputs.*** ... #### Change 9 ***Was*** > Likewise, you need to specify the destination address or addresses for the transaction. These are called outputs. Should there be more bitcoin in the inputs than are needed for the payment, a new address will be created in your wallet for the remaining change, often called a change output. ***Suggested*** > Likewise, ***you need to specify the destination address(es) for the transaction. These are called transaction outputs.*** Should there be more bitcoin in the inputs than are needed for the payment, a new address will be created in your wallet for the remaining change, often called a change output. ... #### Change 10 ***Was*** > The above image is an example of how transaction outputs become the inputs to new transactions. In this example, the sender wants to send 4 bitcoin to another wallet. In the sender’s wallet, there are two unspent transaction outputs, one containing 3 bitcoin (represented in blue) and another containing 2 bitcoin (represented in green). The sender’s wallet uses both of these as inputs in the transaction, meaning that the transaction involves 5 bitcoin total. 4 bitcoin goes to a payment output in the receiver’s wallet (represented in orange), and 1 bitcoin goes to a change output in the sender’s wallet (represented in purple). ***Suggested*** > The above image is an example of how transaction outputs become the inputs to ***future*** transactions. In this example, the sender wants to send 4 bitcoin to another wallet. ***In the sender’s wallet, there are two unspent transaction outputs (UTXOs): one containing 3 bitcoin (represented in blue), and another containing 2 bitcoin (represented in green). The sender’s wallet uses both of these as inputs for the transaction, resulting in an input total of 5 bitcoin. 4 bitcoin goes to a payment output in the receiver’s wallet (represented in orange), and 1 bitcoin returns to the sender's wallet in the form of a change output (represented in purple).*** ... #### Change 11 ***Was*** > Every transaction needs to pay a fee to incentivize miners to include it in a block. There is no fixed fee for making a transaction as it depends on the amount of data it includes, the amount of other transactions that are trying to get verified, and how much each submitter is prepared to pay. Miners typically pick the transactions that will earn them the highest reward to include in a block. > > Blocks are also limited in size and new ones are created every 10 minutes on average. This means that if you want a transaction to be confirmed in the next block you might have to pay a relatively high price. ***Suggested*** > ***Every transaction requires a fee in order to incentivize miners to include it in a forthcoming block. There is no fixed fee for making a bitcoin transaction as it depends on: the amount of data the transaction includes, the fee rate (set by the wallet or wallet owner), network conjestion or traffic (the amount of other transactions being processed), as well as how much these other transaction creators are prepared to pay. Miners typically prioritise transactions that will earn them the highest reward, including them in the next block.*** > > ***Blocks are also limited in size and new ones are created every 10 minutes on average. This means that if you want a transaction to be confirmed in the next block, you might have to pay a relatively high price.*** ... --- ## Sending Bitcoin ### Introduction #### Change 12 ***Was*** > 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. > Let us look at the main transaction options senders need to configure when moving bitcoin: ***Suggested*** > ***Sending bitcoin can either 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. > ***Let's*** look at the main transaction options senders need to configure when moving bitcoin: ... #### Change 13 ***Was*** > 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. ***Suggested*** > You do not need to follow the order below. ***Feel free to tailor the payment's configuration order to suit what best serves your users.*** For example, you may make users set the amount before they enter the address. ... #### Change 14 ***Was*** > 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. ***Suggested*** > ***The receiver does this by (automatically) generating a new address in their wallet application, then sharing it with the sender. If the sender and receiver are within close proximity of one another, scanning the receiver’s address as a QR Code will be easy. Still, if they are not closeby, they can send the address as text in any regular communication tool like email, SMS, etc.*** ... #### Change 15 ***Was*** > 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. ***Suggested*** > ***Once you have the recipient's 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. ... #### Change 16 ***Was*** > 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. ***Suggested*** > ***Camera 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. ... ### Change 17 ***Was*** > 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. ***Suggested*** > Applications ***also sometimes*** 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. ... #### Change 18 ***Was*** > - Allow senders to switch which denomination they are inputting the amount with ***Suggested*** > - Allow senders to ***change which currency denomination*** they are inputting the amount with ... #### Change 19 ***Was*** > Let us look at how we communicate to the sender about the processing of a transaction after it has been broadcast. There are three main states that you would want to inform or notify the sender of: ***Suggested*** > ***Let's take a look at how we communicate the processing of a transaction after it has been broadcast to the sender.*** There are three main states that you would want to inform or notify the sender of: ... #### Change 20 ***Was*** > **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 broadcast the transaction. While pending, inform the sender of when they can expect the first transaction confirmation. ***Suggested*** > **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 broadcast the transaction. ***While pending, inform and update the sender of when they can expect the first transaction confirmation.*** or > ***While pending, inform the sender of an updated estimate when they can expect the first transaction confirmation.*** ... #### Change 21 ***Was*** > **First 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. - "This is a good point to notift the sender." ***of what?*** Consider also sending a notification after the 6th confirmation too...? Seems more secure at that point? --- ## Receiving Bitcoin ### Introduction #### Change 22 ***Was*** > For someone to receive bitcoin, the sender needs to know the receiver’s Bitcoin address. The receiver must generate an address in their Bitcoin wallet application. A new address should be generated for every payment, as addresses should only use them once. This helps safeguards the receiver’s privacy. ***Suggested*** > ***In order for someone to receive bitcoin, they must first provide the sender with a payment destination. They can do this by generating an address within their Bitcoin wallet application. A new address should be generated for every payment, as addresses should only use them once. This helps safeguard the recipients’s privacy.*** ... ### Preparing the payment request #### Change 23 ***Was*** > The simplest form of requesting bitcoin is creating and sharing a Bitcoin address where the sender should direct the payment. Generating a new address and showing it as a QR code and plain text is the most common way for applications to help the receiver request bitcoin. > > There are multiple types of addresses that could lead to compatibility issues for senders and prevent a successful payment. Read more about address compatibility in foundations. ***Suggested*** >*** The simplest way to receive bitcoin is by generating and sharing a Bitcoin address with the sender, this is the destination where they should direct the payment. Receivers can share this information by either showing it as a scannable QR code, or alternatively as plain text that can be shared via any regular communication tool like email, SMS, etc.*** > ***Before sharing this information, it is important to recognise that there are multiple types of bitcoin addresses. Accidentally sharing the wrong type of address to senders could lead to compatibility issues, preventing a successful payment. Read more about address compatibility in foundations.*** ... #### Change 24 ***Was*** > Many Bitcoin wallet applications focus on providing a minimal interface for requesting payments. This is convenient in the short-term but may not be in the user’s best interest longer-term. Lists of transactions without information about who they are from and their purpose makes it hard to manage personal finances. ***Suggested*** > ***Many Bitcoin wallet applications focus on providing minimalised interfaces for requesting payments. This is convenient in the short-term as it can facilitate fast and easy payments, but may not be in the user’s best interest longer-term. Lists of transactions without information about who they are from and their purpose makes it hard to manage personal finances as well as future transaction privacy.*** ... #### Change 25 ***Was*** > As the blockchain only stores the amount and addresses involved in a transaction, any additional information must be stored in your application. It’s also possible to share some of these details with senders by encoding them in payment links. Either way, these details have to be manually inputted. ***Suggested*** > ***Since the Bitcoin blockchain only stores a limited amount of payment information, such as the amount and addresses involved in a transaction, any additional information must be stored in your application or locally on your device. This additional information can be vital in providing context to wallet owners on their spending habbits and payment histories. It is possible for receivers to share some of these extra details with senders by encoding them in payment links. Either way, these details have to be manually inputted when generating a payment request. ... #### Change 26 ***Was*** ![](https://i.imgur.com/TtCGdgV.png) Check the text for the middle screen, it is currently the same as the left hand screen. ***Middle Screen Suggestion*** > ***The receiver can use a label to specify who the payment is from. This information is stored locally on the receiver's device and is not shared with the sender via a payment link as they may wish to use a different label for their own context.*** ***Right Hand Screen Suggestion*** > ***If wallet owners wish to further contextualise their payments, they can add message fields to help identify "what's the payment for?". Consider easy ways to help add more context, such as pre-selected description fields.*** ... ### Sharing the payment request #### Change 27 ***Was*** > Whether it’s just an address or a payment link, the two methods of sharing the payment details are text or scannable QR Codes. ***Suggested*** > ***Whether it's just an address, or a payment link containing additional payment specifications, the two primary methods of sharing payment details are via scannable QR codes or as plain text.*** ... #### Change 28 ***Was*** > Sharing payment details as text is as straightforward as copying and pasting. It is also typical to provide the receiver with a button to conveniently share in other applications, with “share sheets,” which most mobile operating systems offer. ***Suggested*** > ***Sharing payment details as text is as straightforward as copying and pasting. It is also typical for Bitcoin applications to provide the receiver with a "share" button - allowing them to conveniently share addresses or payment links via other applications, with “share sheets” being offered by most mobile operating systems.*** ... #### Change 29 ***Was*** > Display the QR Code at the largest size so that the scanner can detect it easily. ***Suggested*** > ***Display QR Codes at the largest possible size so that scanners can detect them easily.*** ... ### Awaiting the payment #### Change 30 ***Was*** > Once the payment details are shared, until the sender creates a transaction and broadcast it, there is uncertainty when the payment would be completed. Think about how to keep the receiver informed while they are waiting. If your application has an area where the user can see a list of payment requests, this would be a good place to use it to also indicate which specific stage the payment is in. Then once the payment has been finalized, you should also consider what the receiver may want to do with those funds. You may want to help facilitate those follow-up activities e.g. moving the funds to a shared multi-key wallet or doing a coinjoin. ***Suggested*** > ***Even once the payment details have been shared by the receiver, senders still have to create and broadcast their transaction, leaving room for uncertainty as to when the payment will be completed and received. Think about how to keep the receiver informed whilst they await their payment.*** ***If your application has a section where the user can see a list of their payment requests or transaction history, this would be a good place to privide the user with updates on the payment's status and what stage of completion it is at.*** ***Once the payment has been finalized, you should also consider what the receiver may want to do with those funds. Bitcoin wallet applications can help facilitate those follow-up activities e.g. moving the funds to a shared multi-key wallet or doing a coinjoin.***