bitcoinbook/ch02.asciidoc

[[ch02_bitcoin_overview]]
== How Bitcoin Works

((("bitcoin", "overview of", id="BCover02")))((("central trusted
authority")))((("decentralized systems", "bitcoin overview",
id="DCSover02")))The Bitcoin system, unlike traditional banking and
payment systems, does not require trust in third parties. Instead of a central
trusted authority, in Bitcoin, each user can use software running on
their own computer to verify the correct operation of every
aspect of the Bitcoin system.
In this chapter, we will examine bitcoin from a high level by tracking a
single transaction through the Bitcoin system and watch as it
is recorded on the blockchain, the distributed ledger of all
transactions. Subsequent chapters will delve into the technology behind
transactions, the network, and mining.

=== Bitcoin Overview

In the overview diagram shown in <<bitcoin-overview>>, we see that the
Bitcoin system consists of users with wallets containing keys,
transactions that are propagated across the network, and miners who
produce (through competitive computation) the consensus blockchain,
which is the authoritative ledger of all transactions.

((("blockchain explorer sites")))Each example in this chapter is based
on an actual transaction made on the Bitcoin network, simulating the
interactions between the users (Joe, Alice, Bob, and Gopesh) by sending
funds from one wallet to another. While tracking a transaction through
the Bitcoin network to the blockchain, we will use a _blockchain
explorer_ site to visualize each step. A blockchain explorer is a web
application that operates as a bitcoin search engine, in that it allows
you to search for addresses, transactions, and blocks and see the
relationships and flows between them.

[[bitcoin-overview]]
.Bitcoin overview
image::images/mbc2_0201.png["Bitcoin Overview"]

((("Bitcoin Block Explorer")))((("BlockCypher Explorer")))((("blockchain.info")))((("BitPay Insight")))Popular blockchain explorers include:

* https://blockstream.info/[Blockstream Explorer]
* https://mempool.space[Mempool.Space]
* https://live.blockcypher.com[BlockCypher Explorer]

Each of these has a search function that can take a Bitcoin address,
transaction hash, block number, or block hash and retrieve corresponding
information from the Bitcoin network. With each transaction or block
example, we will provide a URL so you can look it up yourself and study
it in detail.

[[block-explorer-privacy]]
.Block explorer privacy warning
[WARNING]
====
Searching information on a block explorer may disclose to its operator
that you're interested in that information, allowing them to associate
it with your IP address, browser fingerprint, past searches, or other
identifiable information.  If you look up the transactions in this book,
the operator of the block explorer might guess that you're learning
about Bitcoin, which shouldn't be a problem.  But if you look up your
own transactions, the operator may be able to guess how many bitcoins
you've received, spent, and currently own.
====

[[spending_bitcoin]]
==== Buying from an Online Store

Alice, introduced in the previous chapter, is a new user who has just
acquired her first bitcoins. In <<getting_first_bitcoin>>, Alice met with
her friend Joe to exchange some cash for bitcoins. Since then, Alice has
bought additional bitcoins.  Now Alice will make
her first retail transaction, buying access to a premium podcast episode from Bob's online store.

Bob's web store recently started accepting bitcoin payments by adding a
bitcoin option to its website. The prices at Bob's store are listed in
the local currency (US dollars), but at checkout, customers have the
option of paying in either dollars or bitcoin.

Alice finds the podcast episode she wants to buy and proceeds to the checkout page. At checkout,
Alice is offered the option to pay with bitcoin, in addition to the
usual options. The checkout cart displays the price in US dollars and
also in bitcoin (BTC), at Bitcoin's prevailing exchange rate.

((("payment requests")))((("QR codes", "payment requests")))Bob's
e-commerce system will automatically create a QR code containing an
_invoice_ (<<invoice-QR>>).

Unlike a QR code that simply contains a destination Bitcoin address, this
invoice is a QR-encoded URI that contains a destination address,
a payment amount, and a description.
This allows a bitcoin wallet application to prefill the
information used to send the payment while showing a human-readable
description to the user. You can scan the QR code with a bitcoin wallet
application to see what Alice would see.

////
TODO: Replace QR code with test-BTC address
////

[[invoice-QR]]
.Invoice QR code
image::images/mbc2_0202.png["payment-request"]

[TIP]
====
((("QR codes", "warnings and cautions")))((("transactions", "warnings
and cautions")))((("warnings and cautions", "avoid sending money to
addresses appearing in book")))Try to scan this with your wallet to see
the address and amount but DO NOT SEND MONEY.
====
[[invoice-URI]]
.The invoice QR code encodes the following URI, defined in BIP21:
----
bitcoin:bc1qk2g6u8p4qm2s2lh3gts5cpt2mrv5skcuu7u3e4?amount=0.01577764&
label=Bob%27s%20Store&
message=Purchase%20at%20Bob%27s%20Store

Components of the URI

A Bitcoin address: "bc1qk2g6u8p4qm2s2lh3gts5cpt2mrv5skcuu7u3e4"
The payment amount: "0.01577764"
A label for the recipient address: "Bob's Store"
A description for the payment: "Purchase at Bob's Store"
----

Alice uses her smartphone to scan the barcode on display. Her smartphone
shows a payment for the correct amount to +Bob's Store+ and she selects Send to
authorize the payment. Within a few seconds (about the same amount of
time as a credit card authorization), Bob sees the transaction on the
register.

[NOTE]
====
((("fractional values")))((("milli-bitcoin")))((("satoshis")))The
Bitcoin network can transact in fractional values, e.g., from
millibitcoin (1/1000th of a bitcoin) down to 1/100,000,000th of a
bitcoin, which is known as a satoshi.  This book uses the same
pluralization rules used for dollars and other traditional currencies
when talking about amounts greater than one bitcoin and when using
decimal notation, such as "10 bitcoins" or "0.001 bitcoins."  The same
rules also apply to other bitcoin bookkeeping units, such as
millibitcoins and satoshis.
====

You can examine Alice's transaction to Bob's Store on the blockchain
using a block explorer site (<<view_alice_transaction>>):

[[view_alice_transaction]]
.View Alice's transaction on https://blockstream.info/tx/674616f1fbc6cc748213648754724eebff0fc04506f2c81efb1349d1ebc8a2ef[Blockstream Explorer]
====
----
https://blockstream.info/tx/674616f1fbc6cc748213648754724eebff0fc04506f2c81efb1349d1ebc8a2ef
----
====

In the following sections, we will examine this transaction in more
detail. We'll see how Alice's wallet constructed it, how it was
propagated across the network, how it was verified, and finally, how Bob
can spend that amount in subsequent transactions.

=== Bitcoin Transactions

((("transactions", "defined")))In simple terms, a transaction tells the
network that the owner of some bitcoin value has authorized the transfer
of that value to another owner. The new owner can now spend the bitcoin
by creating another transaction that authorizes the transfer to another
owner, and so on, in a chain of ownership.

==== Transaction Inputs and Outputs

((("transactions", "overview of", id="Tover02")))((("outputs and
inputs", "basics of")))Transactions are like lines in a double-entry
bookkeeping ledger.  Each transaction contains one or more "inputs,"
which are like debits against a bitcoin account. On the other side of
the transaction, there are one or more "outputs," which are like credits
added to a bitcoin account. ((("fees", "transaction fees")))The inputs
and outputs (debits and credits) do not necessarily add up to the same
amount. Instead, outputs add up to slightly less than inputs and the
difference represents an implied _transaction fee_, which is a small
payment collected by the miner who includes the transaction in the
ledger. A bitcoin transaction is shown as a bookkeeping ledger entry in
<<transaction-double-entry>>.

The transaction also contains proof of ownership for each amount of
bitcoin (inputs) whose value is being spent, in the form of a digital
signature from the owner, which can be independently validated by
anyone. ((("spending bitcoin", "defined")))In bitcoin terms, "spending"
is signing a transaction that transfers value from a previous
transaction over to a new owner identified by a Bitcoin address.

[[transaction-double-entry]]
.Transaction as double-entry bookkeeping
image::images/mbc2_0203.png["Transaction Double-Entry"]

==== Transaction Chains

((("chain of transactions")))Alice's payment to Bob's Store uses a
previous transaction's output as its input. In the previous chapter,
Alice received bitcoin from her friend Joe in return for cash.
We've labeled that as _Transaction 1_ (Tx1) in <<transaction-chain>>.

Tx1 sent 0.001 bitcoins (100,000 satoshis) to an output locked by
Alice's key. Her new transaction to Bob's Store (Tx2) references the
previous output as an input.  In the illustration, we show that
reference using an arrow and by labeling the input as "Tx1:0".  In an
actual transaction, the reference is the 32-byte transaction identifier
(txid) for the transaction where Alice received the money from Joe.  The
":0" indicates the position of the output where Alice received the
money; in this case, the first position (position 0).

As shown, actual Bitcoin transactions don't
explicitly include the value of their input.  To determine the value of
an input, software needs to use the input's reference to find the
previous transaction output being spent.

Alice's Tx2 contains two new outputs, one paying 75,000 satoshis for the
podcast and another paying 20,000 satoshis back to Alice to receive
change.

////
@startditaa
      Transaction 1             Tx2                   Tx3
     Inputs  Outputs         In     Out           In      Out
   +-------+---------+   +-------+--------+    +-------+--------+
   |       |         |   |       | cDDD   |    |       |        |
<--+ Tx0꞉0 | 100,000 |<--+ Tx1꞉0 | 20,000 |  +-+ Tx2꞉1 | 67,000 |
   |       |         |   |       |        |  | |       |        |
   +-------+---------+   +-------+--------+  | +-------+--------+
   |       | cDDD    |   |       |        |  | |       |        |
   |       | 500,000 |   |       | 75,000 |<-+ |       |        |
   |       |         |   |       |        |    |       |        |
   +-------+---------+   +-------+--------+    +-------+--------+
        Fee꞉ (unknown)           Fee꞉ 5,000            Fee꞉ 8,000
@enddittaa
////

[[transaction-chain]]
.A chain of transactions, where the output of one transaction is the input of the next transaction
image::images/transaction-chain.png["Transaction chain"]

[TIP]
====
Serialized Bitcoin transactions---the data format that software uses for
sending transactions---encodes the value to transfer using an integer
of the smallest defined onchain unit of value.  When Bitcoin was first
created, this unit didn't have a name and some developers simply called
it the _base unit._  Later many users began calling this unit a
_satoshi_ (sat) in honor of Bitcoin's creator.  In <<transaction-chain>>
and some other illustrations in this book, we use satoshi values because
that's what the protocol itself uses.
====

==== Making Change

((("change, making")))((("change addresses")))((("addresses", "change
addresses")))In addition to one or more outputs that pay the receiver of
bitcoins, many transactions will also include an output that pays the
spender of the bitcoins, called a _change_ output.
This is because transaction inputs,
like currency notes, cannot be divided. If you purchase a $5 US dollar
item in a store but use a $20 dollar bill to pay for the item, you
expect to receive $15 dollars in change. The same concept applies to
bitcoin transaction inputs. If you purchased an item that costs 5
bitcoins but only had an input worth 20 bitcoins to use, you would send one
output of 5 bitcoins to the store owner and one output of 15 bitcoins back
to yourself as change (not counting your transaction fee).

At the level of the Bitcoin protocol, there is no difference between a
change output (and the address it pays, called a _change address_) and a
payment output.

Importantly, the change address does not have to be the
same address as that of the input and for privacy reasons is often a new
address from the owner's wallet.  In ideal circumstances, the two
different uses of outputs both use never-before-been addresses and
otherwise look identical, preventing any third party from determining
which outputs are change and which are payments.  However, for
illustration purposes, we've added shading to the change outputs in
<<transaction-chain>>.

==== Coin selection

Different wallets use different strategies when choosing which
inputs to use to a payment, called _coin selection_.

They might aggregate many small
inputs, or use one that is equal to or larger than the desired payment.
Unless the wallet can aggregate inputs in such a way to exactly match
the desired payment plus transaction fees, the wallet will need to
generate some change. This is very similar to how people handle cash. If
you always use the largest bill in your pocket, you will end up with a
pocket full of loose change. If you only use the loose change, you'll
always have only big bills. People subconsciously find a balance between
these two extremes, and bitcoin wallet developers strive to program this
balance.

==== Common Transaction Forms

A very common form of transaction is a simple payment. This type of
transaction has one input and two outputs and is shown in
<<transaction-common>>.

[[transaction-common]]
.Most common transaction
image::images/mbc2_0205.png["Common Transaction"]

Another common form of transaction is a _consolidation transaction_ one that spends several inputs
into a single output (<<transaction-consolidating>>). This represents
the real-world equivalent of exchanging a pile of coins and currency
notes for a single larger note. Transactions like these are sometimes
generated by wallets and business to clean up lots of smaller amounts.

[[transaction-consolidating]]
.Transaction aggregating funds
image::images/mbc2_0206.png["Aggregating Transaction"]

Finally, another transaction form that is seen often on the bitcoin
ledger is _payment batching_ that pays to multiple outputs
representing multiple recipients (<<transaction-distributing>>).
This type of transaction is sometimes used by commercial entities to
distribute funds, such as when processing payroll payments to multiple
employees.((("", startref="Tover02")))

[[transaction-distributing]]
.Transaction distributing funds
image::images/mbc2_0207.png["Distributing Transaction"]

=== Constructing a Transaction

((("transactions", "constructing", id="Tconstruct02")))((("wallets",
"constructing transactions")))Alice's wallet application contains all
the logic for selecting inputs and generating outputs to build a
transaction to Alice's specification. Alice only needs to choose a
destination, amount, and transaction fee, and the rest happens in the wallet
application without her seeing the details. Importantly, if a wallet
already knows what inputs it controls, it can construct transactions
even if it is completely offline.
Like writing a check at home and later sending it to the bank in an
envelope, the transaction does not need to be constructed and signed
while connected to the Bitcoin network.

==== Getting the Right Inputs

((("outputs and inputs", "locating and tracking inputs")))Alice's wallet
application will first have to find inputs that can pay the amount she
wants to send to Bob. Most wallets keep track of all the available
outputs belonging to addresses in the wallet. Therefore, Alice's wallet
would contain a copy of the transaction output from Joe's transaction,
which was created in exchange for cash (see <<getting_first_bitcoin>>).
A bitcoin wallet application that runs on a full node actually
contains a copy of every confirmed transaction's unspent outputs, called
_Unspent Transaction Outputs_ (UTXOs).
However, because full nodes use more resources, most
user wallets run "lightweight" clients that track only the user's own
UTXOs.

If the wallet application does not maintain a copy of all UTXOs, it can
query the Bitcoin network to retrieve this
information using a variety of APIs available by different providers or
by asking a full node using an application programming interface (API)
call. <<example_2-2>> shows an API request, constructed as an HTTP GET
command to a specific URL. This URL will return all the unspent
transaction outputs for an address, giving any application the
information it needs to construct transaction inputs for spending. We
use the simple command-line HTTP client _cURL_ to retrieve the response.
Note that looking up information using a third-party API like this is similar to
using a block explorer; see the privacy warning in
<<block-explorer-privacy>>.

[[example_2-2]]
.Look up all the unspent outputs for Alice's Bitcoin address
====
[source,bash]
----
$ address=bc1pyfw56zu5vsq0ulu9kytasgw4xwnm3eysll6tfdz8d9gtht97k7tqxsz78n
$ curl https://blockchain.info/unspent?active=$address
----
====

[source,json]
----
{
  "notice": "",
  "unspent_outputs": [
    {
      "tx_hash_big_endian": "4ac541802679866935a19d4f40728bb89204d0cac90d85f3a51a19278fe33aeb",
      "tx_hash": "eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a",
      "tx_output_n": 1,
      "script": "5120225d4d0b946400fe7f85b117d821d533a7b8e490fff4b4b4476950bbacbeb796",
      "value": 100000,
      "value_hex": "0186a0",
      "confirmations": 111,
      "tx_index": 8276421070086947
    }
  ]
}
----

The response in <<example_2-2>> shows one unspent output (one that has
not been redeemed yet) under the ownership of Alice's address.
The response includes the reference to the transaction in which this
UTXO is contained (the payment from Joe), the output index
number, its value in satoshis, and the script derived from Alice's
address.  With this information, Alice's wallet
application can construct a transaction to transfer that value to new
owner addresses.

[TIP]
====
View the https://blockstream.info/tx/4ac541802679866935a19d4f40728bb89204d0cac90d85f3a51a19278fe33aeb[transaction from Joe to Alice].
====

In this case, this single
UTXO is sufficient to pay for the podcast. Had this not been the case,
Alice's wallet application might have to combine several
smaller UTXOs, like picking coins from a purse until it could
find enough to pay for the podcast. In both cases, there might be a need
to get some change back, which we will see in the next section, as the
wallet application creates the transaction outputs (payments).


==== Creating the Outputs

((("outputs and inputs", "creating outputs")))A transaction output is
created in the form of a script that creates an encumbrance on the value
and can only be redeemed by the introduction of a solution to the
script. In simpler terms, Alice's transaction output will contain a
script that says something like, "This output is payable to whoever can
present a signature from the key corresponding to Bob's public address."
Because only Bob has the wallet with the keys corresponding to that
address, only Bob's wallet can present such a signature to redeem this
output. Alice will therefore "encumber" the output value with a demand
for a signature from Bob.

This transaction will also include a second output, because Alice's
funds contain more money than the cost of the
podcast. Alice's change
output is created in the very same
transaction as the payment to Bob. Essentially, Alice's wallet breaks
her funds into two outputs: one to Bob and one back to herself. She can
then spend the change output in a subsequent transaction.

Finally, for the transaction to be processed by the network in a timely
fashion, Alice's wallet application will add a small fee. This is not
explicit in the transaction; it is implied by the difference in value between
inputs and outputs.  This _transaction fee_ is collected by the
miner as a fee for validating and including the transaction in a block
to be recorded on the blockchain.

[[transaction-alice-url]]
[TIP]
====
View the https://blockstream.info/tx/466200308696215bbc949d5141a49a4138ecdfdfaa2a8029c1f9bcecd1f96177[transaction from Alice to Bob's Store].
====

==== Adding the Transaction to the Ledger

The transaction created by Alice's wallet application
contains everything necessary to confirm ownership of the funds and
assign new owners. Now, the transaction must be transmitted to the
Bitcoin network where it will become part of the blockchain. In the next
section we will see how a transaction becomes part of a new block and
how the block is mined. Finally, we will see how the new block, once
added to the blockchain, is increasingly trusted by the network as more
blocks are added.

===== Transmitting the transaction

((("propagation", "process of")))Because the transaction contains all
the information necessary to process, it does not matter how or where it
is transmitted to the Bitcoin network. The Bitcoin network is a
peer-to-peer network, with each Bitcoin peer participating by
connecting to several other Bitcoin peers. The purpose of the Bitcoin
network is to propagate transactions and blocks to all participants.

===== How it propagates

((("Bitcoin nodes", "defined")))((("nodes", see="Bitcoin nodes")))
Peers in the Bitcoin peer-to-peer network are programs that have both
the software logic and the data necessary for them to fully verify the
correctness of a new transaction.  The connections between peers are
often visualized as edges (lines) in a graph, with the peers themselves
being the nodes (dots).  For that reason, Bitcoin peers are commonly
called "full verification nodes", or _full nodes_ for short.

Alice's wallet application can send the new
transaction to any Bitcoin node it is connected to over any type of
connection: wired, WiFi, mobile, etc.  It can also send the transaction
to another program (such as a block explorer) that will relay it to a
node.  Her bitcoin wallet does not have
to be connected to Bob's bitcoin wallet directly and she does not have
to use the internet connection offered by the cafe, though both those
options are possible, too. ((("propagation", "flooding
technique")))((("flooding technique")))Any Bitcoin node that receives a
valid transaction it has not seen before will immediately forward it to
all other nodes to which it is connected, a propagation technique known
as _gossiping_. Thus, the transaction rapidly propagates out across the
peer-to-peer network, reaching a large percentage of the nodes within a
few seconds.

===== Bob's view

If Bob's bitcoin wallet application is directly connected to Alice's
wallet application, Bob's wallet application might be the first to
receive the transaction. However, even if Alice's wallet sends the
transaction through other nodes, it will reach Bob's wallet within a few
seconds. Bob's wallet will immediately identify Alice's transaction as
an incoming payment because it contains an output redeemable by Bob's
keys. Bob's wallet application can also independently verify that the
transaction is well formed.  If Bob is using his own full node, his
wallet can further verify Alice's transaction only spends valid UTXOs.

=== Bitcoin Mining

((("mining and consensus", "overview of",
id="MACover02")))((("blockchain (the)", "overview of mining",
id="BToverview02")))Alice's transaction is now propagated on the Bitcoin
network. It does not become part of the _blockchain_ until it is
verified and included in a block by a process called _mining_. See
<<mining>> for a detailed explanation.

The Bitcoin system of counterfeit protection is based on computation.
Transactions are bundled into _blocks_.  Blocks have a very small header
that must be formed in a very specific way, requiring an enormous
amount of computation to get right--but only a small amount of
computation to verify as correct.
The mining process serves two purposes in bitcoin:

* ((("mining and consensus", "consensus rules", "security provided
by")))((("consensus", see="mining and consensus")))Miners can only
receive honest income from creating blocks that follow all of Bitcoin's
_consensus rules_.  Therefore, miners are normally incentivized to
only include valid transactions in their blocks and the blocks they
build upon.  This allows users to optionally trust that any transaction
in a block is a valid transaction.

* Mining currently creates new bitcoin in each block, almost like a central bank
printing new money. The amount of bitcoin created per block is limited
and diminishes with time, following a fixed issuance schedule.


Mining achieves a fine balance between cost and reward. Mining uses
electricity to solve a computational problem. A successful miner will
collect a _reward_ in the form of new bitcoin and transaction fees.
However, the reward will only be collected if the miner has correctly
validated all the transactions, to the satisfaction of the rules of
_consensus_. This delicate balance provides security for bitcoin without
a central authority.

Mining is designed to be a decentralized lottery.  Each miner can create
their own lottery ticket by creating a _block template_ that includes
the new transactions they want to mine plus some additional data fields.
The miner inputs their template into a specially-designed algorithm that
scrambles (or "hashes") the data, producing output that looks nothing
like the input data.  This _hash_ function will always produce the same
output for the same input--but nobody can predict what the output will
look like for a new input, even if it is only slighly different from a
previous input.  If the output of hash function matches a template
determined by the Bitcoin protocol, the miner wins the lottery and
Bitcoin users will accept the block template with its transactions as a
valid block.  If the output doesn't match the template, the miner makes
a small change to their block template and tries again.  As of this
writing, the number of block templates miners need to try before finding
a winning combination is about 168 billion trillions.  That's also how
many times the hash function needs to be run.

However, once a winning combination has been found, anyone can verify
the block is valid by running the hash function just once.  That makes a
valid block something that requires an incredible amount of work to
create but only a trivial amount of work to verify.  The simple
verification process is able to probabalistically prove the work was
done, so the data necessary to generate that proof--in this case, the
block--is called Proof-of-Work (PoW).

((("mining and consensus", "mining farms and pools")))In
<<user-stories>>, we introduced ((("use cases", "mining for
bitcoin")))Jing, an entrepreneur in Shanghai. Jing runs a _mining farm_,
which is a business that runs thousands of specialized mining computers,
competing for the block reward. Jing's mining
computers compete against thousands of similar systems in the global
lottery to create the next block.

Jing started mining in 2010 using a very fast desktop computer to find a
suitable Proof-of-Work for new blocks. As more miners started joining
the Bitcoin network, the Bitcoin protocol automatically increased the
difficulty of finding a new block.
Soon, Jing and other miners upgraded to more specialized hardware, such
as high-end dedicated graphical processing units (GPUs)
used in gaming desktops. At the time of this writing,
the difficulty is so high that it is profitable only to mine with
((("application-specific integrated circuits
(ASIC)")))application-specific integrated circuits (ASIC), essentially
hundreds of mining algorithms printed in hardware, running in parallel
on a single silicon chip. ((("mining pools", "defined")))Jing's company
also participates in a _mining pool_, which much like a lottery pool
allows several participants to share their efforts and rewards. Jing's
company now runs a warehouse containing thousands of  ASIC miners to
mine for bitcoin 24 hours a day. The company pays its electricity costs
by selling the bitcoin it is able to generate from mining, creating some
income from the profits.

=== Mining Transactions in Blocks

((("blocks", "mining transactions in")))New transactions are constantly
flowing into the network from user wallets and other applications. As
these are seen by the Bitcoin network nodes, they get added to a
temporary pool of unverified transactions maintained by each node. As
miners construct a new block, they add unverified transactions from this
pool to the new block and then attempt to prove the validity of that new
block, with the mining algorithm (Proof-of-Work). The process of mining
is explained in detail in <<mining>>.

Transactions are added to the new block, prioritized by the highest-fee
transactions first and a few other criteria. Each miner starts the
process of mining a new block of transactions as soon as he receives the
previous block from the network, knowing he has lost that previous round
of competition. He immediately creates a new block, fills it with
transactions and the fingerprint of the previous block, and starts
calculating the Proof-of-Work for the new block. Each miner includes a
special transaction in his block, one that pays his own Bitcoin address
the block reward (currently 12.5 newly created bitcoin) plus the sum of
transaction fees from all the transactions included in the block. If he
finds a solution that makes that block valid, he "wins" this reward
because his successful block is added to the global blockchain and the
reward transaction he included becomes spendable. ((("mining pools",
"operation of")))Jing, who participates in a mining pool, has set up his
software to create new blocks that assign the reward to a pool address.
From there, a share of the reward is distributed to Jing and other
miners in proportion to the amount of work they contributed in the last
round.

((("candidate blocks")))((("blocks", "candidate blocks")))Alice's
transaction was picked up by the network and included in the pool of
unverified transactions. Once validated by a full node, it was
included in a block template generated by Jing's
mining pool. All the miners participating in that mining pool
immediately start trying to generate a Proof-of-Work for the block template.
Approximately five minutes after the transaction was first transmitted
by Alice's wallet, one of Jing's ASIC miners found a solution for the
block and announced it to the network. After other miners
validated the winning block, they started a new lottery to generate the next
block.

Jing's winning block containing Alice's transaction became part of the
blockchain. The block containing Alice's transaction is counted as one
"confirmation" of that transaction.  After the block containing Alice's
transaction has propagated through the network, creating an alternative
block with a different version of Alice's transaction (such as a
transaction that doesn't pay Bob) would require performing the same
amount of work as it will take all Bitcoin miners to create an entirely
new block.  For the entire network to accept an alternative block, an
additional new block would need to be mined on top of the alternative.

That means miners have a choice.  They can work with Alice on an
alternative version of the transaction where she pays Bob, perhaps with
Alice paying miners a share of the money she previously paid Bob.  This
dishonest behavior will require they expend the effort required to
create two new blocks.  Instead, miners who behave honestly can create a
single new block and and receive all of the fees from the transactions
they include in it, plus the block reward.  Normally, the high cost of
dishonestly creating two blocks for a small additional payment is much
less profitable than honestly creating a new block, making it unlikely
that a confirmed transaction will be deliberately changed.  For Bob, this
means that he can begin to believe that the payment from Alice can be
relied upon.

[TIP]
====
You can see the block that includes
https://blockstream.info/block/000000000000000000027d39da52dd790d98f85895b02e764611cb7acf552e90[Alice's transaction].
====

((("confirmations", "role in transactions")))Approximately 19 minutes
after Jing's block, a new block is mined by another miner. Because this
new block is built on top of the block that contained Alice's
transaction (giving Alice's transaction two confirmations) Alice's
transaction can now only be changed if two alternative blocks are
mined--plus a new block built on top of them--for a total of three
blocks that would need to be mined for Alice to take back the money she
sent Bob.  Each block mined on top of the one containing Alice's
transaction counts as an additional confirmation.  As the blocks pile on
top of each other, it becomes harder to reverse the transaction, thereby
giving Bob more and more confidence that Alice's payment is secure.

((("genesis block")))((("blocks", "genesis block")))((("blockchain
(the)", "genesis block")))In <<block-alice1>>,  we can
the block which contains Alice's transaction. Below it are
hundreds of thousands of blocks, linked to each other in a chain of
blocks (blockchain) all the way back to block #0, known as the _genesis
block_. Over time, as the "height" of new blocks increases, so does the
computation difficulty for the chain as a whole.
By convention, any block with more than six confirmations
is considered very hard to change, because it would require an immense amount of
computation to recalculate six blocks (plus one new block). We will examine
the process of mining and the way it builds confidence in more detail in
<<mining>>.((("", startref="BToverview02")))((("",
startref="MACover02")))

[[block-alice1]]
.Alice's transaction included in a block
image::images/mbc2_0209.png["Alice's transaction included in a block"]

=== Spending the Transaction

((("spending bitcoin", "simple-payment-verification
(SPV)")))((("simple-payment-verification (SPV)")))Now that Alice's
transaction has been embedded in the blockchain as part of a block, it
is part of the distributed ledger of Bitcoin and visible to all Bitcoin
applications. Each bitcoin full node can independently verify the
transaction as valid and spendable. Full nodes validate every transfer
of the funds from the moment the bitcoin were first generated in
a block through each subsequent transaction until they reach
Bob's address. Lightweight clients can do what is called a simplified
payment verification (see <<spv_nodes>>) by confirming that the
transaction is in the blockchain and has several blocks mined after it,
thus providing assurance that the miners expended significant effort
committing to it.

Bob can now spend the output from this and other transactions. For
example, Bob can pay a contractor or supplier by transferring value from
Alice's podcast payment to these new owners. Bob's bitcoin
software might consolidate many small payments into a larger payment,
perhaps concentrating all the day's bitcoin revenue into a single
transaction. This would consolidate the various payments into a single
output (and a single address). For a diagram of a consolidation
transaction, see <<transaction-consolidating>>.

As Bob spends the payments received from Alice and other customers, he
extends the chain of transactions. Let's assume that Bob pays his web
designer Gopesh((("use cases", "offshore contract services"))) in
Bangalore for a new website page. Now the chain of transactions will
look like <<block-alice2>>.

[[block-alice2]]
.Alice's transaction as part of a transaction chain from Joe to Gopesh
image::images/mbc2_0210.png["Alice's transaction as part of a transaction chain"]

In this chapter, we saw how transactions build a chain that moves value
from owner to owner. We also tracked Alice's transaction, from the
moment it was created in her wallet, through the Bitcoin network and to
the miners who recorded it on the blockchain. In the rest of this book,
we will examine the specific technologies behind wallets, addresses,
signatures, transactions, the network, and finally mining.