Skip to content Link Search Menu Expand Document Video
Process of transaction being mined, and new payments being made, mixed and sent to multiple other wallets

3D payments and transaction lifecycle illustration by Alexa Aker

Transactions

This page is meant to help you understand how users’ transactions get created and processed by the bitcoin and lightning networks. Bitcoin is a peer-to-peer push-payment system. This means that you can send, or push, bitcoin 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.

A note about terminology

In most places in the Guide, the term “transaction” and “payment” are used interchangeably. For the remainder of this page, the term transaction refers specifically to on-chain bitcoin transactions, and the term payment refers specifically to payments routed over the lightning network.

Comparing bitcoin and lightning

Bitcoin Lightning
Users send bitcoin transactions. Users send lightning payments.
Bitcoin transactions are settled on average every 10 minutes. Lightning payments are settled almost instantly.
A valid bitcoin transaction will always be mined, but may be delayed if the fee is too low. A successful lightning payment depends on lightning network liquidity and finding a path to the recipient.
Bitcoin is typically better for larger amounts of funds and less frequent transactions. Lightning is typically better for smaller amounts of funds and more frequent payments.

For a more detailed look, see the Technology Primer.

Lightning payment lifecycle

For most use cases, the lightning network is the best option, as it will enable the recipient to receive their bitcoin quicker and the sender to pay less in fees.

Flow chart of the process of a lightning payment from invoice creation through successful payment

1. Create invoice

To make a lightning payment, the sender requires an invoice created by the recipient. The recipient’s wallet application creates a preimage, or payment secret, which is then used to create an invoice for one-time use. The recipient can share the invoice with the sender as a QR code, over NFC, in plain text, or as a payment link.

Note that the recipient does not always need to produce the invoice manually. For example, an ecommerce site could generate invoices automatically on behalf of the recipient, or the recipient could rely on a static QR code that allows the sender’s wallet to retrieve the invoice or necessary data dynamically.

2. Confirm payment

The sender loads the invoice into their wallet application. After reviewing that the amount looks correct and the fee estimate is satisfactory, the sender confirms that they would like to make the lightning payment.

3. Pathfinding & routing

The wallet application attempts to route the lightning payment to the recipient. In order to do this, it must attempt to construct a path through the lightning network. Pathfinding is a complex, probabilistic process, which means that the routing fees shown in the prior step are only an estimate.

If the payment fails along a particular path, the wallet application will repeatedly attempt the payment again with a different path until the payment succeeds.

4. Receive payment and reveal preimage

The payment reaches the intended recipient. The recipient’s wallet application reveals the preimage to the previous node in the successful path. The preimage is passed in reverse through the path by every node in the path.

5. Payment complete

Once the preimage is passed all the way to the sender’s wallet application, the sender’s wallet application can consider the payment to be complete.

This sounds like a complicated process; however, steps 3 - 5 are handled by software, and they happen very quickly. Users are not typically exposed to these details.

Bitcoin transaction lifecycle

Some things are accomplished better on-chain. For example, the user’s wallet application may have difficulty finding a suitable path to route a larger lightning payment, or the user may prefer to send their funds to a multi-sig storage vault.

Flow chart of the process of a transaction getting created and then finally confirmed

1. Get recipient address

The sender needs a valid address to send the bitcoin transaction to. The recipient can share the address as a QR code, over NFC, in plain text, or as a payment link.

Note that the recipient does not always need to produce the address manually. For example, an ecommerce site could generate addresses automatically on behalf of the recipient. The recipient could rely on a static address QR code, but this is not recommended for good transaction privacy.

2. Creation

The wallet application guides the sender through collecting the required information (address and amount) and any optional configurations (which coins to send, fee options, etc.) in order to create a transaction.

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 been created and configured, but this does not have to be the case.

4. Broadcasting

The transaction is broadcasted to a bitcoin node, normally the one the wallet is connected to.

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.

6. Propagation

Once validated, the node passes the transaction on to other nodes in the network. The transaction is now in the memory pool, and remains there until it is mined. At this stage, the transaction has 0 confirmations.

7. Confirmations

Given that you know how transactions are confirmed, lets look at how the number of confirmations affects the transaction 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 can affect this transaction, and the transaction is final.

Transaction structure

Think of a bitcoin 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.

The principal properties are:

  • Amount – the amount of bitcoin, in satoshis
  • Inputs – the source of funds
  • Outputs – the recipient or change destination(s)
  • Lock time – the earliest the transaction can be broadcasted (optional)

Input and outputs

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 a single address holds, you can specify several. These are called inputs to the transaction.

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.

A flow chart depicting outputs beings used as the inputs to new transactions, which in turn have their own outputs.

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).

Transaction fee

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.

Now let’s discuss wallet privacy.