Table 4-14.

Simplest form of a paper wallet—a printout of the bitcoin address and pri‐
vate key.
Public Address Private Key (WIF)
1424C2F4bC9JidNjjTUZCbUxv6Sa1Mt62x 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn

Paper wallets can be generated easily using a tool such as the client-side JavaScript
generator at bitaddress.org. This page contains all the code necessary to generate keys
and paper wallets, even while completely disconnected from the Internet. To use it, save
the HTML page on your local drive or on an external USB flash drive. Disconnect from
the Internet and open the file in a browser. Even better, boot your computer using a
pristine operating system, such as a CD-ROM bootable Linux OS. Any keys generated
with this tool while offline can be printed on a local printer over a USB cable (not
wirelessly), thereby creating paper wallets whose keys exist only on the paper and have
never been stored on any online system. Put these paper wallets in a fireproof safe and
“send” bitcoin to their bitcoin address, to implement a simple yet highly effective “cold
storage” solution. Figure 4-14 shows a paper wallet generated from the bitaddress.org
site.

Figure 4-14. An example of a simple paper wallet from bitaddress.org

The disadvantage of the simple paper wallet system is that the printed keys are vulnerable
to theft. A thief who is able to gain access to the paper can either steal it or photograph
the keys and take control of the bitcoins locked with those keys. A more sophisticated
paper wallet storage system uses BIP0038 encrypted private keys. The keys printed on
the paper wallet are protected by a passphrase that the owner has memorized. Without
the passphrase, the encrypted keys are useless. Yet, they still are superior to a passphrase-
protected wallet because the keys have never been online and must be physically re‐
trieved from a safe or other physically secured storage. Figure 4-15 shows a paper wallet
with an encrypted private key (BIP0038) created on the bitaddress.org site.

Advanced Keys and Addresses | 105

Figure 4-15. An example of an encrypted paper wallet from bitaddress.org. The pass‐
phrase is “test.”

Although you can deposit funds into a paper wallet several times,
you should withdraw all funds only once, spending everything. This
is because in the process of unlocking and spending funds, you ex‐
pose the private key, and because some wallets might generate a
change address if you spend less than the whole amount. One way
to do this is to withdraw the entire balance stored in the paper wal‐
let and send any remaining funds to a new paper wallet.

Paper wallets come in many designs and sizes, with many different features. Some are
intended to be given as gifts and have seasonal themes, such as Christmas and New
Year’s themes. Others are designed for storage in a bank vault or safe with the private
key hidden in some way, either with opaque scratch-off stickers, or folded and sealed
with tamper-proof adhesive foil. Figures 4-16 through 4-18 show various examples of
paper wallets with security and backup features.

Figure 4-16. An example of a paper wallet from bitcoinpaperwallet.com with the pri‐
vate key on a folding flap.

106 | Chapter 4: Keys, Addresses, Wallets

Figure 4-17. The bitcoinpaperwallet.com paper wallet with the private key concealed.

Other designs feature additional copies of the key and address, in the form of detachable
stubs similar to ticket stubs, allowing you to store multiple copies to protect against fire,
flood, or other natural disasters.

Figure 4-18. An example of a paper wallet with additional copies of the keys on a back‐
up “stub.”

Advanced Keys and Addresses | 107

 CHAPTER 5
Transactions

Introduction
Transactions are the most important part of the bitcoin system. Everything else in bit‐
coin is designed to ensure that transactions can be created, propagated on the network,
validated, and finally added to the global ledger of transactions (the blockchain). Trans‐
actions are data structures that encode the transfer of value between participants in the
bitcoin system. Each transaction is a public entry in bitcoin’s blockchain, the global
double-entry bookkeeping ledger.
In this chapter we will examine all the various forms of transactions, what they contain,
how to create them, how they are verified, and how they become part of the permanent
record of all transactions.

Transaction Lifecycle
A transaction’s lifecycle starts with the transaction’s creation, also known as origina‐
tion. The transaction is then signed with one or more signatures indicating the author‐
ization to spend the funds referenced by the transaction. The transaction is then broad‐
cast on the bitcoin network, where each network node (participant) validates and prop‐
agates the transaction until it reaches (almost) every node in the network. Finally, the
transaction is verified by a mining node and included in a block of transactions that is
recorded on the blockchain.
Once recorded on the blockchain and confirmed by sufficient subsequent blocks (con‐
firmations), the transaction is a permanent part of the bitcoin ledger and is accepted as
valid by all participants. The funds allocated to a new owner by the transaction can then
be spent in a new transaction, extending the chain of ownership and beginning the
lifecycle of a transaction again.

109
Creating Transactions
In some ways it helps to think of a transaction in the same way as a paper check. Like a
check, a transaction is an instrument that expresses the intent to transfer money and is
not visible to the financial system until it is submitted for execution. Like a check, the
originator of the transaction does not have to be the one signing the transaction.
Transactions can be created online or offline by anyone, even if the person creating the
transaction is not an authorized signer on the account. For example, an accounts payable
clerk might process payable checks for signature by the CEO. Similarly, an accounts
payable clerk can create bitcoin transactions and then have the CEO apply digital sig‐
natures to make them valid. Whereas a check references a specific account as the source
of the funds, a bitcoin transaction references a specific previous transaction as its source,
rather than an account.
Once a transaction has been created, it is signed by the owner (or owners) of the source
funds. If it is properly formed and signed, the signed transaction is now valid and con‐
tains all the information needed to execute the transfer of funds. Finally, the valid trans‐
action has to reach the bitcoin network so that it can be propagated until it reaches a
miner for inclusion in the pubic ledger (the blockchain).

Broadcasting Transactions to the Bitcoin Network

First, a transaction needs to be delivered to the bitcoin network so that it can be propa‐
gated and included in the blockchain. In essence, a bitcoin transaction is just 300 to 400
bytes of data and has to reach any one of tens of thousands of bitcoin nodes. The senders
do not need to trust the nodes they use to broadcast the transaction, as long as they use
more than one to ensure that it propagates. The nodes don’t need to trust the sender or
establish the sender’s “identity.” Because the transaction is signed and contains no con‐
fidential information, private keys, or credentials, it can be publicly broadcast using any
underlying network transport that is convenient. Unlike credit card transactions, for
example, which contain sensitive information and can only be transmitted on encrypted
networks, a bitcoin transaction can be sent over any network. As long as the transaction
can reach a bitcoin node that will propagate it into the bitcoin network, it doesn’t matter
how it is transported to the first node.
Bitcoin transactions can therefore be transmitted to the bitcoin network over insecure
networks such as WiFi, Bluetooth, NFC, Chirp, barcodes, or by copying and pasting
into a web form. In extreme cases, a bitcoin transaction could be transmitted over packet
radio, satellite relay, or shortwave using burst transmission, spread spectrum, or fre‐
quency hopping to evade detection and jamming. A bitcoin transaction could even be
encoded as smileys (emoticons) and posted in a public forum or sent as a text message
or Skype chat message. Bitcoin has turned money into a data structure, making it vir‐
tually impossible to stop anyone from creating and executing a bitcoin transaction.

110 | Chapter 5: Transactions

Propagating Transactions on the Bitcoin Network
Once a bitcoin transaction is sent to any node connected to the bitcoin network, the
transaction will be validated by that node. If valid, that node will propagate it to the
other nodes to which it is connected, and a success message will be returned synchro‐
nously to the originator. If the transaction is invalid, the node will reject it and syn‐
chronously return a rejection message to the originator.
The bitcoin network is a peer-to-peer network, meaning that each bitcoin node is con‐
nected to a few other bitcoin nodes that it discovers during startup through the peer-
to-peer protocol. The entire network forms a loosely connected mesh without a fixed
topology or any structure, making all nodes equal peers. Messages, including transac‐
tions and blocks, are propagated from each node to the peers to which it is connected.
A new validated transaction injected into any node on the network will be sent to three
to four of the neighboring nodes, each of which will send it to three to four more nodes,
and so on. In this way, within a few seconds a valid transaction will propagate in an
exponentially expanding ripple across the network until all connected nodes have re‐
ceived it.
The bitcoin network is designed to propagate transactions and blocks to all nodes in an
efficient and resilient manner that is resistant to attacks. To prevent spamming, denial-
of-service attacks, or other nuisance attacks against the bitcoin system, every node in‐
dependently validates every transaction before propagating it further. A malformed
transaction will not get beyond one node. The rules by which transactions are validated
are explained in more detail in “Independent Verification of Transactions” on page 177.

Transaction Structure
A transaction is a data structure that encodes a transfer of value from a source of funds,
called an input, to a destination, called an output. Transaction inputs and outputs are
not related to accounts or identities. Instead, you should think of them as bitcoin
amounts—chunks of bitcoin—being locked with a specific secret that only the owner,
or person who knows the secret, can unlock. A transaction contains a number of fields,
as shown in Table 5-1.
Table 5-1. The structure of a transaction
Size Field Description
4 bytes Version Specifies which rules this transaction follows
1–9 bytes (VarInt) Input Counter How many inputs are included
Variable Inputs One or more transaction inputs
1–9 bytes (VarInt) Output Counter How many outputs are included
Variable Outputs One or more transaction outputs
4 bytes Locktime A Unix timestamp or block number

Transaction Structure | 111

 Transaction Locktime
Locktime defines the earliest time that a transaction can be added to the blockchain. It
is set to zero in most transactions to indicate immediate execution. If locktime is nonzero
and below 500 million, it is interpreted as a block height, meaning the transaction is not
included in the blockchain prior to the specified block height. If it is above 500 million,
it is interpreted as a Unix Epoch timestamp (seconds since Jan-1-1970) and the trans‐
action is not included in the blockchain prior to the specified time. The use of locktime
is equivalent to postdating a paper check.

Transaction Outputs and Inputs

The fundamental building block of a bitcoin transaction is an unspent transaction out‐
put, or UTXO. UTXO are indivisible chunks of bitcoin currency locked to a specific
owner, recorded on the blockchain, and recognized as currency units by the entire net‐
work. The bitcoin network tracks all available (unspent) UTXO currently numbering
in the millions. Whenever a user receives bitcoin, that amount is recorded within the
blockchain as a UTXO. Thus, a user’s bitcoin might be scattered as UTXO amongst
hundreds of transactions and hundreds of blocks. In effect, there is no such thing as a
stored balance of a bitcoin address or account; there are only scattered UTXO, locked
to specific owners. The concept of a user’s bitcoin balance is a derived construct created
by the wallet application. The wallet calculates the user’s balance by scanning the block‐
chain and aggregating all UTXO belonging to that user.

There are no accounts or balances in bitcoin; there are only unspent

transaction outputs (UTXO) scattered in the blockchain.

A UTXO can have an arbitrary value denominated as a multiple of satoshis. Just like
dollars can be divided down to two decimal places as cents, bitcoins can be divided
down to eight decimal places as satoshis. Although UTXO can be any arbitrary value,
once created it is indivisible just like a coin that cannot be cut in half. If a UTXO is larger
than the desired value of a transaction, it must still be consumed in its entirety and
change must be generated in the transaction. In other words, if you have a 20 bitcoin
UTXO and want to pay 1 bitcoin, your transaction must consume the entire 20 bitcoin
UTXO and produce two outputs: one paying 1 bitcoin to your desired recipient and
another paying 19 bitcoin in change back to your wallet. As a result, most bitcoin trans‐
actions will generate change.

112 | Chapter 5: Transactions

Imagine a shopper buying a $1.50 beverage, reaching into her wallet and trying to find
a combination of coins and bank notes to cover the $1.50 cost. The shopper will choose
exact change if available (a dollar bill and two quarters), or a combination of smaller
denominations (six quarters), or if necessary, a larger unit such as a five dollar bank
note. If she hands too much money, say $5, to the shop owner, she will expect $3.50
change, which she will return to her wallet and have available for future transactions.
Similarly, a bitcoin transaction must be created from a user’s UTXO in whatever de‐
nominations that user has available. Users cannot cut a UTXO in half any more than
they can cut a dollar bill in half and use it as currency. The user’s wallet application will
typically select from the user’s available UTXO various units to compose an amount
greater than or equal to the desired transaction amount.
As with real life, the bitcoin application can use several strategies to satisfy the purchase
amount: combining several smaller units, finding exact change, or using a single unit
larger than the transaction value and making change. All of this complex assembly of
spendable UTXO is done by the user’s wallet automatically and is invisible to users. It
is only relevant if you are programmatically constructing raw transactions from UTXO.
The UTXO consumed by a transaction are called transaction inputs, and the UTXO
created by a transaction are called transaction outputs. This way, chunks of bitcoin value
move forward from owner to owner in a chain of transactions consuming and creating
UTXO. Transactions consume UTXO by unlocking it with the signature of the current
owner and create UTXO by locking it to the bitcoin address of the new owner.
The exception to the output and input chain is a special type of transaction called the
coinbase transaction, which is the first transaction in each block. This transaction is
placed there by the “winning” miner and creates brand-new bitcoin payable to that
miner as a reward for mining. This is how bitcoin’s money supply is created during the
mining process, as we will see in Chapter 8.

What comes first? Inputs or outputs, the chicken or the egg? Strictly
speaking, outputs come first because coinbase transactions, which
generate new bitcoin, have no inputs and create outputs from nothing.

Transaction Outputs
Every bitcoin transaction creates outputs, which are recorded on the bitcoin ledger.
Almost all of these outputs, with one exception (see “Data Output (OP_RETURN)” on
page 130) create spendable chunks of bitcoin called unspent transaction outputs or UTXO,
which are then recognized by the whole network and available for the owner to spend
in a future transaction. Sending someone bitcoin is creating an unspent transaction
output (UTXO) registered to their address and available for them to spend.

Transaction Outputs and Inputs | 113

UTXO are tracked by every full-node bitcoin client in a database held in memory, called
the UTXO set or UTXO pool. New transactions consume (spend) one or more of these
outputs from the UTXO set.
Transaction outputs consist of two parts:

• An amount of bitcoin, denominated in satoshis, the smallest bitcoin unit

• A locking script, also known as an “encumbrance” that “locks” this amount by spec‐
ifying the conditions that must be met to spend the output

The transaction scripting language, used in the locking script mentioned previously, is
discussed in detail in “Transaction Scripts and Script Language” on page 121. Table 5-2
shows the structure of a transaction output.
Table 5-2. The structure of a transaction output
Size Field Description
8 bytes Amount Bitcoin value in satoshis (10-8 bitcoin)
1-9 bytes (VarInt) Locking-Script Size Locking-Script length in bytes, to follow
Variable Locking-Script A script defining the conditions needed to spend the output

In Example 5-1, we use the blockchain.info API to find the unspent outputs (UTXO)
of a specific address.
Example 5-1. A script that calls the blockchain.info API to find the UTXO related to an
address
# get unspent outputs from blockchain API

import json
import requests

# example address
address = '1Dorian4RoXcnBv9hnQ4Y2C1an6NJ4UrjX'

# The API URL is https://blockchain.info/unspent?active=<address>

# It returns a JSON object with a list "unspent_outputs", containing UTXO, like
this:
#{ "unspent_outputs":[
# {
# "tx_hash":"ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad9084062167",
# "tx_index":51919767,
# "tx_output_n": 1,
# "script":"76a9148c7e252f8d64b0b6e313985915110fcfefcf4a2d88ac",
# "value": 8000000,
# "value_hex": "7a1200",
# "confirmations":28691
# },
# ...

114 | Chapter 5: Transactions