mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-23 15:18:11 +00:00
a543abe388
This advice may have been somewhat accurate when the first edition of this book was published and opt-in replace-by-fee wasn't available, but that's no longer the case. And now, especially, with default replace-by-fee on the probable horizon, there's even less safety in accepting unconfirmed transactions as final without some type of secondary protection.
719 lines
34 KiB
Plaintext
719 lines
34 KiB
Plaintext
[[ch02_bitcoin_overview]]
|
||
== How Bitcoin Works
|
||
|
||
=== Transactions, Blocks, Mining, and the Blockchain
|
||
|
||
((("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.
|
||
====
|
||
|
||
[[bitcoin_e_commerce]]
|
||
==== 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_ (see <<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.
|
||
|
||
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.
|
||
|
||
[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
|
||
----
|
||
====
|
||
|
||
=== 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 in the illustration, 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 one or more outputs that pay the receiver of
|
||
bitcoins, many tranactions 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 (see <<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 (see <<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 are 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 payments: one to Bob and one back to herself. She can
|
||
then use (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 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 trust is based on computation. Transactions are
|
||
bundled into _blocks_, which require an enormous amount of computation
|
||
to prove, but only a small amount of computation to verify as proven.
|
||
The mining process serves two purposes in bitcoin:
|
||
|
||
* ((("mining and consensus", "consensus rules", "security provided
|
||
by")))((("consensus", see="mining and consensus")))Mining nodes validate
|
||
all transactions by reference to bitcoin's _consensus rules_. Therefore,
|
||
mining provides security for bitcoin transactions by rejecting invalid
|
||
or malformed transactions.
|
||
|
||
* Mining 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 mathematical 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.
|
||
|
||
A good way to describe mining is like a giant competitive game of sudoku
|
||
that resets every time someone finds a solution and whose difficulty
|
||
automatically adjusts so that it takes approximately 10 minutes to find
|
||
a solution. Imagine a giant sudoku puzzle, several thousand rows and
|
||
columns in size. If I show you a completed puzzle you can verify it
|
||
quite quickly. However, if the puzzle has a few squares filled and the
|
||
rest are empty, it takes a lot of work to solve! The difficulty of the
|
||
sudoku can be adjusted by changing its size (more or fewer rows and
|
||
columns), but it can still be verified quite easily even if it is very
|
||
large. The "puzzle" used in bitcoin is based on a cryptographic hash and
|
||
exhibits similar characteristics: it is asymmetrically hard to solve but
|
||
easy to verify, and its difficulty can be adjusted.
|
||
|
||
((("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 reward. Every 10 minutes or so, Jing's mining
|
||
computers compete against thousands of similar systems in a global race
|
||
to find a solution to a block of transactions. ((("Proof-of-Work
|
||
algorithm")))((("mining and consensus", "Proof-of-Work
|
||
algorithm")))Finding such a solution, the so-called _Proof-of-Work_
|
||
(PoW), requires quadrillions of hashing operations per second across the
|
||
entire Bitcoin network. The algorithm for Proof-of-Work involves
|
||
repeatedly hashing the header of the block and a random number with the
|
||
SHA256 cryptographic algorithm until a solution matching a predetermined
|
||
pattern emerges. The first miner to find such a solution wins the round
|
||
of competition and publishes that block into the blockchain.
|
||
|
||
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 difficulty of the problem increased rapidly.
|
||
Soon, Jing and other miners upgraded to more specialized hardware, such
|
||
as high-end dedicated graphical processing units (GPUs) cards such as
|
||
those used in gaming desktops or consoles. 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 the mining software it was
|
||
included in a new block, called a _candidate block_, generated by Jing's
|
||
mining pool. All the miners participating in that mining pool
|
||
immediately start computing Proof-of-Work for the candidate block.
|
||
Approximately five minutes after the transaction was first transmitted
|
||
by Alice's wallet, one of Jing's ASIC miners found a solution for the
|
||
candidate block and announced it to the network. Once other miners
|
||
validated the winning block they started the race to generate the next
|
||
block.
|
||
|
||
Jing's winning block became part of the blockchain as block #277316,
|
||
containing 419 transactions, including Alice's transaction. The block
|
||
containing Alice's transaction is counted as one "confirmation" of that
|
||
transaction.
|
||
|
||
[TIP]
|
||
====
|
||
You can see the block that includes
|
||
https://blockstream.info/block/000000000000000000027d39da52dd790d98f85895b02e764611cb7acf552e90[Alice's transaction].
|
||
====
|
||
|
||
((("confirmations", "role in transactions")))Approximately 19 minutes
|
||
later, a new block, #277317, is mined by another miner. Because this new
|
||
block is built on top of block #277316 that contained Alice's
|
||
transaction, it added even more computation to the blockchain, thereby
|
||
strengthening the trust in those transactions. Each block mined on top
|
||
of the one containing the transaction counts as an additional
|
||
confirmation for Alice's transaction. As the blocks pile on top of each
|
||
other, it becomes exponentially harder to reverse the transaction,
|
||
thereby making it more and more trusted by the network.
|
||
|
||
((("genesis block")))((("blocks", "genesis block")))((("blockchain
|
||
(the)", "genesis block")))In the diagram in <<block-alice1>>, we can
|
||
see block 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" in blocks increases, so does the
|
||
computation difficulty for each block and the chain as a whole. The
|
||
blocks mined after the one that contains Alice's transaction act as
|
||
further assurance, as they pile on more computation in a longer and
|
||
longer chain. By convention, any block with more than six confirmations
|
||
is considered irrevocable, because it would require an immense amount of
|
||
computation to invalidate and recalculate six blocks. We will examine
|
||
the process of mining and the way it builds trust 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.
|