How Bitcoin Transactions Work on the Blockchain

A Bitcoin transaction is just data, formatted in hexadecimal, that contains information about the address sending a specified amount of Bitcoin to an address receiving that amount.

Inputs from the sender create new outputs for the receiver, and in many cases, an output is created for the sender which represents change due back to them.  

When creating a transaction with Bitcoin, if you don’t have a UTXO equal to the value of the transaction, you’ll receive a new UTXO back as change.  Every spent (consumed) UTXO creates new UTXOs as outputs of the transaction.  

For example, you walk into a store and want to buy a pack of gum for $1.  

You hand the cashier a $10 bill as an input for the transaction. That $10 bill was once an output from a previous transaction.

The store receives an output of $1 and you receive an output of $9 as change.  

The outputs are ‘locked’ when the $10 is placed in the cashier’s drawer and you place the bills in your wallet or pocket.  The cashier can unlock the ‘locked’ outputs when they swipe their ID to sign that they are authorized to use the $10 in future transactions.  

In Bitcoin speak, these outputs are called UTXOs or Unspent Transaction Outputs.

Bitcoin Transaction Inputs and Outputs

Inputs are just Outputs from previous transactions, each with an assigned quantity of Bitcoin.   

The first step of a transaction is for the sender or sender’s wallet to build the input outpoints by referencing previous transaction IDs (TXID) to identify the UTXO(s) that are valid to be spent as inputs in the transaction. 

These outputs are fixed with a locking script (scriptPubKey) which contains the conditions that must be met to unlock the outputs with an unlocking script (scriptSig or Witness Script).

Once the previous steps are completed, an unlocking script is created to unlock the locking script of the previous transaction’s UTXO (inputs) which will be spent in this new transaction.

New Outputs are created by unlocking and spending the transaction’s inputs.

An output needs 1) a value expressed in satoshis (fractional Bitcoin 0.xxxxxxxx BTC) and 2) a lock which the recipient can unlock in the future proving they are authorized to spend the UTXO they received from the transaction.

These locked outputs (UTXOs) can only be unlocked with the recipient’s unlocking script, called scriptSig. 

Next, the input and output data is compiled into a serialized ‘line of data’, called a TXID which gets cryptographically hashed then shared with the Bitcoin network only after the sender signs the transaction using their private key which unlocks (authorizes) the transaction and prevents anyone else from spending their Bitcoin.  

If a transaction doesn’t contain an unlocking script, it will be rejected by the node and NOT stored in the mempool.  

The transaction is then added to the mempool only if it contains the unlocking script.  A valid transaction is eventually mined and added to a block on the blockchain. The sender’s UTXO(s) that were spent as inputs for the transaction become unspendable are referred to as spent transaction outputs which removes them from the Bitcoin Network’s UTXO set.

How do I Create a Bitcoin Transaction?

There are 7 sequential steps of a Bitcoin Transaction:

  1. Get Recipient’s Address
    1. The sender needs the recipient’s public bitcoin address where they will receive the sender’s bitcoin.  The address is generated by the recipient and can be shared via plain text, QR code, payment link or with NFC.
  1. Create Transaction
    1. The sender creates the transaction following their wallet’s prompts to enter values for the recipient address, coin (BTC), amount, and network priority (fee rate).
    2. This transaction data gets hashed through SHA-256 algorithm not once but twice for a little extra encryption.  The result is a 32-byte (64 characters) hexadecimal Transaction ID (TXID).
  1. Signing
    1. The Message (m) + the sender’s private keys (SK) which are stored by the wallet sign the transaction input(s).  The Digital Signature (Sig) proves that the sender’s private key is connected to the public key without having to reveal the private key.  Private keys are NEVER included in the transaction.  
  1. Broadcasting
    1. Once the sender’s input address signs the transaction with their private keys, the transaction is broadcasted to the Bitcoin network by a node, often the node maintained by the wallet provider.  If you run your own node, you can create and broadcast your transaction.
  1. Validation
    1. Verification that the Signature (Sig) is valid for the Message (m) and the Public Key (PK).  The node checks and confirms transaction validity based on the rules programmed into the node’s Bitcoin Core software.  
    2. If the (m) hash and the (pk) hash correspond, the recipient validates that the sender’s message is authentic and has not been altered. 
  1. Propagation
    1. The node then broadcasts the transaction to other nodes on the network which make up the collective memory pool (mempool).  The unconfirmed transaction waits in the mempool until it’s confirmed by a miner and added to a block on the Bitcoin Blockchain. 
  1. Transaction Confirmation
    1. Every transaction contains the sending address, receiving address, timestamp, amount, and the number of network confirmations.  The confirmation count is the number of blocks mined in succession (including yours).   6 confirmations are generally required before a transaction is officially recognized as confirmed and the transaction is final because miners are not always working on the same block.  Blocks are mined every ~10 minutes, so wait an hour after the first confirmation to consider this transaction confirmed and finalized.  

Pro Tip: The main function of the Bitcoin protocol is to bring all nodes to consensus to work on the same version of the blockchain. 

In some cases, Chain Reorganization is required and nodes automatically remove an ‘incorrect’ block and replace it with the winning block which was determined by the majority of other nodes on the network. This is a function hardcoded into the Bitcoin Core Protocol.  

Technical Structure of a Bitcoin Transaction 

Transaction data plays an important role on the Bitcoin Network.  The size (weight) of the data contributes to the fees you pay on the network to validate transactions.  

Every transaction contains the following data descriptors and attributes:

  • Txin_count: Total number of (UTXOs) used as transaction inputs.
  • Txins: List of all transaction UTXO inputs who’s combined value is ≥ amount sent.
  • Txout_count: The total number of transaction outputs, including the ‘change’ UTXO.
  • Txouts: A list of transaction outputs.  (Value sent to receiver & ‘change’ back to sender) 
  • Lock_time: Default ‘0’ makes transaction valid immediately after being included in the mined block.  Optional condition that locks a transaction until a future time or future block.
  • Script_witnesses: SegWit transaction specific serialized witness data.

SegWit (Segregated Witness) transactions include additional data descriptors and attributes:

  • Version: The version being used. 
  • Txins: List of all transaction UTXO inputs who’s combined value is ≥ amount sent.

Transaction data contains detailed information about the sender, amount of Bitcoin, who it’s being sent to and how much change is due back to the sender.    

This information is standardized, publicly verifiable and ensures an accurate ledger of transactions on the Bitcoin Blockchain.

Learn how to decode a Bitcoin transaction.  A technical ‘down the transaction rabbit hole’ guide covering outpoint structure, header packets and more can be found here

Validating and Signing Bitcoin Transactions:

Bitcoin transactions use Elliptic Curve Digital Signature Algorithm (ECDSA) or Schnorr (for Taproot), to generate a digital signature from a private key.  

These algorithms create a pathway, using Distinguished Encoding Rules (DER) to encode the signature with a random number (r value) and the signature (s value) on an x,y axis of an elliptical curve to sign, secure and and verify transactions (another rabbit hole).

This sounds complicated because it is.  All nodes are pre-programmed to run the same code, called Bitcoin Core, which executes scripted functions to send, receive and validate transactions.

This is how nodes validate a user’s legitimacy to spend Bitcoin UTXOs in a transaction:

  1. The sender collects the relevant data to create a transaction (called origination) including the confirmed recipient (public) address, amount of Bitcoin (in Satoshis), and transaction fee.
  1. The transaction details (data) is processed through a SHA-256 hash function which generates a message hash (z) of the transaction details.  
  1. A random number (k) is multiplied by a generator point (G) to calculate the random point (r ) for the x-coordinate on the ECDSA curve.  Next, the message hash (z) + sender’s private key (dA)) = (s).  (s) is a unique number used to find the random number ( r) on an elliptical curve.

The combination of (r ) + (s), represented as [r, s], is converted to a 256-bit number = Digital Signature which locks (encrypts) the Bitcoin transaction.

  1. A message (m) containing the transaction data, sender’s public key (Q) and Digital Signature [r, s] is delivered to the recipient’s public address.
    1. The sender’s public key (Q) decrypts the Digital Signature [r, s] = a 256-bit number.  The public key (Q) is = Generator Point (G) * private key.
    2. The recipient uses the (SHA256) hash function on the unencrypted message data to generate a hash of the message (m).  
  1. The unencrypted message (m) is processed through a SHA-256 hash function which generates a 256-bit message hash (z).
  1. A Validation node, confirms the message hash (z) = hash of the Digital Signature [r,s] + public key.  A Validation node processes the Signature Script with the PubKey Script.
  1. The valid transaction will remain in the mempool until a miner picks up the transaction,  runs the Signature Script with the PubKey Script to produce a ‘TRUE’ result so they can include the transaction in a block.  Once the block is mined, and confirmed by at least 6 nodes, the transaction is marked as completed.
  1. A UTXO is locked to the recipient’s PubKey and contains an Index (transaction ID), the location (to expedite future transactions), and the amount in satoshis which gets locked to your PubKey Hash by the PubKey Script.  

What are Bitcoin Scripts and Opcodes?

Bitcoin Script is a computer language.  Script is Bitcoin’s unique computer code programmed with instructions to determine if Bitcoins can be spent by verifying transactions, lock/unlocking UTXOs, and transferring value across the network.  

Script is stack-based and processed left to right. Data is pushed to the stack in the processing order and written like <data>.  

A command or function or OPERATION (Opcode) references the input <data> and performs a task like ‘verify’, ‘check’, ‘remove’, ‘duplicate’, ‘copy’, ‘compare’  if [else] condition, and hashing functions.

Script outputs are pushed back to the stack for processing.  They can be as simple as adding (pushing to top) or removing (popping off) items (data) on the stack.  More complex Opcode outputs like TRUE/FALSE, Nothing, fail, and 1 or 0 are interpreted resulting in a transaction being marked as valid or invalid.  

At its most basic level, Script requires a public key and signature to spend Bitcoin.  The nodes run this code to verify that the public key matches the recipient’s address and the sender proves they are authorized to send bitcoin with a signature derived from their private key. 

To spend the received bitcoin, the recipient must then provide their public key and the signature of the ‘spending’ transaction to prove they have the private key.  

Let’s breakdown the technical Opcodes for an example valid transaction using P2PKH

<Signature> <PublicKey> OP_DUP OP_HASH160 <PKHash> OP_EQUALVERIFY OP_CHECKSIG

Stack: true

Step 1: Start with the sender’s Signature Script (ScriptSig) & add the public key (PubKey).

Step 2: For security, the OP_DUP script duplicates the PubKey which is at the top of stack. 

Step 3: OP_HASH160 then creates a hash of the duplicated public key (Pk Hash).

Step 4: PubKey (Pk) Hash that locked your UTXO(s) in a previous transaction.

Step 5: OP_EQUALVERIFY checks the PK Hash (Step 4) is equal to PK Hash (Step 3).

Step 6: OP_CHECKSIG uses PubKey Script to decrypt the Signature Script (ScriptSig).  

  • TRUE is returned if the Digital Signature = the transaction data output that was hashed twice sending your transaction to the mempool to get picked up and mined.

When the sender initiates a transaction to send Bitcoin to a recipient’s address.

The transaction must be verified which includes unlocking inputs and locking outputs.  

There are several different output scripts depending on the type of wallet address the sender and receiver are using.

The table below describes the different types of Script used depending on the transaction output type the UTXO uses:

Output typeLocking scriptUnlocking scriptRedeem scriptwitness
P2PK<pubkey>OP_CHECKSIG<signature>
P2PKHOP_DUPOP_HASH160<pubKeyHash> OP_EQUALVERIFYOP_CHECKSIG<signature><public key>
P2SHOP_HASH160<scripthash>OP_EQUAL<data pushes><redeem script><arbitrary>
P2WPKH0<pubKeyHash><signature><public key>
P2WSH0<witnessScriptHash><data pushes><witness script>
P2SH-P2WPKHOP_HASH160<redeemScriptHash>OP_EQUAL<redeem script>0<pubKeyHash><signature><public key>
P2SH-P2WSHOP_HASH160<redeemScriptHash>OP_EQUAL<redeem script>0<scriptHash><data pushes><witness script>
P2TR (key path)1<public key><signature>
P2TR (script path)1<public key>– <data pushes><script><control block>

Pro Tip: Because Bitcoin transactions can be created online or offline and don’t contain sensitive information, they can be sent to a node via secure and insecure methods.  For example, a transaction can be sent over WiFi (secure and unsecured), bluetooth, NFC, barcodes, QR codes, text message, satellite, radio waves, and even encoding into emojis 🤯

Pseudonymous Transactions with Bitcoin

Now that we know the technical details of transactions there’s one missing piece.  

Transactions on the Bitcoin Network are pseudonymous (not anonymous or personally identifiable) by design.

If transactions on a public blockchain were anonymous, the transaction would be impossible to trace:

For example: {redacted} sent 0.05 BTC to {redacted}.

If transactions on a public blockchain were public, the transaction would disincentivize usage due to the disclosure of too much personally identifiable information.

For example:  Bob Jones sent 0.05 BTC to Alice Smith. 

Anyone with an internet connection could see how much Bitcoin Bob and Alice have.  

The Bitcoin Blockchain Network is a public ledger of transactions between pseudonymous parties which are cryptographically secured by a network of mining nodes.  

Maintaining your privacy and following our best practices on crypto security and self custody will help ensure an efficient experience when transacting on the Bitcoin Network. 

Note: Stratus does NOT provide investment, legal or tax advice.  All information in this article is for educational purposes and should not be interpreted as investment, legal or tax advice.  The opinions expressed are those of the author for informational purposes and neither Stratus nor the author are liable for any errors, inaccuracies or omissions.  .  Digital assets, such as cryptocurrencies or decentralized finance, present unique risks for investors.  For investment, legal, tax, or other financial guidance you should consult your own advisor.