=== 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, is based on decentralized trust. Instead of a central trusted authority, in Bitcoin, trust is achieved as an emergent property from the interactions of different participants in 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 becomes "trusted" and accepted by the bitcoin mechanism of distributed consensus and is finally recorded on the blockchain, the distributed ledger of all transactions. Subsequent chapters will delve into the technology behind transactions, the network, and mining.
id="DCSover02")))The Bitcoin system, unlike traditional banking and
payment systems, is based on decentralized trust. Instead of a central
trusted authority, in Bitcoin, trust is achieved as an emergent property
from the interactions of different participants in 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 becomes
"trusted" and accepted by the bitcoin mechanism of distributed consensus
and is finally 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.
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
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.
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.
[[bitcoin_e_commerce]]
==== Buying from an Online Store
Alice, introduced in the previous chapter, is a new user who has just acquired her first bitcoin. In <<getting_first_bitcoin>>, Alice met with her friend Joe to exchange some cash for bitcoin. The transaction created by Joe funded Alice's wallet with 0.10 BTC. Now Alice will make her first retail transaction, buying a laptop from Bob's online store.
Alice, introduced in the previous chapter, is a new user who has just
acquired her first bitcoin. In <<getting_first_bitcoin>>, Alice met with
her friend Joe to exchange some cash for bitcoin. The transaction
created by Joe funded Alice's wallet with 0.10 BTC. Now Alice will make
her first retail transaction, buying a laptop 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.
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 shops for a laptop 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.
Alice shops for a laptop 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.
----
Total:
@ -39,9 +76,17 @@ $750 USD
0.01577764 BTC
----
((("payment requests")))((("QR codes", "payment requests")))Bob's e-commerce system will automatically create a QR code containing a _payment request_ (see <<payment-request-QR>>).
e-commerce system will automatically create a QR code containing a
_payment request_ (see <<payment-request-QR>>).
Unlike a QR code that simply contains a destination Bitcoin address, a payment request is a QR-encoded URL that contains a destination address, a payment amount, and a generic description such as "Bob's Store - Order 512". 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.
Unlike a QR code that simply contains a destination Bitcoin address, a
payment request is a QR-encoded URL that contains a destination address,
a payment amount, and a generic description such as "Bob's Store - Order
512". 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
((("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.
((("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.
====
[[payment-request-URL]]
.The payment request QR code encodes the following URL, defined in BIP-21:
@ -70,16 +118,30 @@ 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 of +0.01 BTC+ 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, completing the transaction.
Alice uses her smartphone to scan the barcode on display. Her smartphone
shows a payment of +0.01 BTC+ 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, completing the transaction.
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.
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. Throughout this book, we’ll use the term “bitcoin” to refer to any quantity of bitcoin currency, from the smallest unit (1 satoshi) to the total number (21,000,000) of all bitcoin that will ever be mined.
((("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.
((("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.
((("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
((("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. That transaction created a bitcoin value locked by Alice's key. Her new transaction to Bob's Store references the previous transaction as an input and creates new outputs to pay for the laptop and receive change. The transactions form a chain, where the inputs from the latest transaction correspond to outputs from previous transactions. Alice's key provides the signature that unlocks those previous transaction outputs, thereby proving to the Bitcoin network that she owns the funds. She attaches the payment for the laptop to Bob's address, thereby "encumbering" that output with the requirement that Bob produces a signature in order to spend that amount. This represents a transfer of value between Alice and Bob. This chain of transactions, from Joe to Alice to Bob, is illustrated in <<blockchain-mnemonic>>.
((("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. That
transaction created a bitcoin value locked by Alice's key. Her new
transaction to Bob's Store references the previous transaction as an
input and creates new outputs to pay for the laptop and receive change.
The transactions form a chain, where the inputs from the latest
transaction correspond to outputs from previous transactions. Alice's
key provides the signature that unlocks those previous transaction
outputs, thereby proving to the Bitcoin network that she owns the funds.
She attaches the payment for the laptop to Bob's address, thereby
"encumbering" that output with the requirement that Bob produces a
signature in order to spend that amount. This represents a transfer of
value between Alice and Bob. This chain of transactions, from Joe to
Alice to Bob, is illustrated in <<blockchain-mnemonic>>.
[[blockchain-mnemonic]]
.A chain of transactions, where the output of one transaction is the input of the next transaction
((("change, making")))((("change addresses")))((("addresses", "change addresses")))Many bitcoin transactions will include outputs that reference both an address of the new owner and an address of the current owner, called the _change_ address. 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 US dollar bill to pay for the item, you expect to receive $15 US dollars in change. The same concept applies to bitcoin transaction inputs. If you purchased an item that costs 5 bitcoin but only had a 20 bitcoin input to use, you would send one output of 5 bitcoin to the store owner and one output of 15 bitcoin back to yourself as change (less any applicable transaction fee). 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.
Different wallets may use different strategies when aggregating inputs to make a payment requested by the user. 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.
((("transactions", "defined")))((("outputs and inputs", "defined")))((("inputs", see="outputs and inputs")))In summary, _transactions_ move value from _transaction inputs_ to _transaction outputs_. An input is a reference to a previous transaction's output, showing where the value is coming from. A transaction output directs a specific value to a new owner's Bitcoin address and can include a change output back to the original owner. Outputs from one transaction can be used as inputs in a new transaction, thus creating a chain of ownership as the value is moved from owner to owner (see <<blockchain-mnemonic>>).
addresses")))Many bitcoin transactions will include outputs that
reference both an address of the new owner and an address of the current
owner, called the _change_ address. 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 US dollar bill to pay for the item, you
expect to receive $15 US dollars in change. The same concept applies to
bitcoin transaction inputs. If you purchased an item that costs 5
bitcoin but only had a 20 bitcoin input to use, you would send one
output of 5 bitcoin to the store owner and one output of 15 bitcoin back
to yourself as change (less any applicable transaction fee).
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.
Different wallets may use different strategies when aggregating inputs
to make a payment requested by the user. 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.
((("transactions", "defined")))((("outputs and inputs",
"defined")))((("inputs", see="outputs and inputs")))In summary,
_transactions_ move value from _transaction inputs_ to _transaction
outputs_. An input is a reference to a previous transaction's output,
showing where the value is coming from. A transaction output directs a
specific value to a new owner's Bitcoin address and can include a change
output back to the original owner. Outputs from one transaction can be
used as inputs in a new transaction, thus creating a chain of ownership
as the value is moved from owner to owner (see <<blockchain-mnemonic>>).
==== Common Transaction Forms
The most common form of transaction is a simple payment from one address to another, which often includes some "change" returned to the original owner. This type of transaction has one input and two outputs and is shown in <<transaction-common>>.
The most common form of transaction is a simple payment from one address
to another, which often includes some "change" returned to the original
owner. 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 one that aggregates several inputs into a single output (see <<transaction-aggregating>>). 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 wallet applications to clean up lots of smaller amounts that were received as change for payments.
Another common form of transaction is one that aggregates several inputs
into a single output (see <<transaction-aggregating>>). 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 wallet applications to clean up lots of smaller amounts
Finally, another transaction form that is seen often on the bitcoin ledger is a transaction that distributes one input 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")))
Finally, another transaction form that is seen often on the bitcoin
ledger is a transaction that distributes one input 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
((("transactions", "constructing", id="Tconstruct02")))((("wallets", "constructing transactions")))Alice's wallet application contains all the logic for selecting appropriate inputs and outputs to build a transaction to Alice's specification. Alice only needs to specify a destination and an amount, and the rest happens in the wallet application without her seeing the details. Importantly, a wallet application 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.
"constructing transactions")))Alice's wallet application contains all
the logic for selecting appropriate inputs and outputs to build a
transaction to Alice's specification. Alice only needs to specify a
destination and an amount, and the rest happens in the wallet
application without her seeing the details. Importantly, a wallet
application 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 as a full-node client actually contains a copy of every unspent output from every transaction in the blockchain. This allows a wallet to construct transaction inputs as well as quickly verify incoming transactions as having correct inputs. However, because a full-node client takes up a lot of disk space, most user wallets run "lightweight" clients that track only the user's own unspent outputs.
If the wallet application does not maintain a copy of unspent transaction outputs, 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.
((("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 as a full-node client actually
contains a copy of every unspent output from every transaction in the
blockchain. This allows a wallet to construct transaction inputs as well
as quickly verify incoming transactions as having correct inputs.
However, because a full-node client takes up a lot of disk space, most
user wallets run "lightweight" clients that track only the user's own
unspent outputs.
If the wallet application does not maintain a copy of unspent
transaction outputs, 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.
[[example_2-2]]
.Look up all the unspent outputs for Alice's Bitcoin address
The response in <<example_2-2>> shows one unspent output (one that has not been redeemed yet) under the ownership of Alice's address +1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK+. The response includes the reference to the transaction in which this unspent output is contained (the payment from Joe) and its value in satoshis, at 10 million, equivalent to 0.10 bitcoin. With this information, Alice's wallet application can construct a transaction to transfer that value to new owner addresses.
The response in <<example_2-2>> shows one unspent output (one that has
not been redeemed yet) under the ownership of Alice's address
+1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK+. The response includes the
reference to the transaction in which this unspent output is contained
(the payment from Joe) and its value in satoshis, at 10 million,
equivalent to 0.10 bitcoin. With this information, Alice's wallet
application can construct a transaction to transfer that value to new
owner addresses.
[TIP]
====
View the http://bit.ly/1tAeeGr[transaction from Joe to Alice].
====
As you can see, Alice's wallet contains enough bitcoin in a single unspent output to pay for the laptop. Had this not been the case, Alice's wallet application might have to "rummage" through a pile of smaller unspent outputs, like picking coins from a purse until it could find enough to pay for the laptop. 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).
As you can see, Alice's wallet contains enough bitcoin in a single
unspent output to pay for the laptop. Had this not been the case,
Alice's wallet application might have to "rummage" through a pile of
smaller unspent outputs, like picking coins from a purse until it could
find enough to pay for the laptop. 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 in the form of a 0.10 BTC output, too much money for the 0.015 BTC cup of laptop. Alice will need 0.085 BTC in change. Alice's change payment is created by Alice's wallet as an output 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. If instead of taking 0.085 in change, Alice creates only 0.0845 as the second output, there will be 0.0005 BTC (half a millibitcoin) left over. The input's 0.10 BTC is not fully spent with the two outputs, because they will add up to less than 0.10. The resulting difference is the _transaction fee_ that is collected by the miner as a fee for validating and including the transaction in a block to be recorded on the blockchain.
The resulting transaction can be seen using a blockchain explorer web application, as shown in <<transaction-alice>>.
((("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 in the form of a 0.10 BTC output, too much money for the 0.015
BTC cup of laptop. Alice will need 0.085 BTC in change. Alice's change
payment is created by Alice's wallet as an output 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. If instead of taking 0.085 in change, Alice creates
only 0.0845 as the second output, there will be 0.0005 BTC (half a
millibitcoin) left over. The input's 0.10 BTC is not fully spent with
the two outputs, because they will add up to less than 0.10. The
resulting difference is the _transaction fee_ that is collected by the
miner as a fee for validating and including the transaction in a block
to be recorded on the blockchain.
The resulting transaction can be seen using a blockchain explorer web
application, as shown in <<transaction-alice>>.
[[transaction-alice]]
[role="smallerseventyfive"]
@ -212,61 +419,228 @@ View the https://www.blockchain.com/btc/tx/0627052b6f28912f2703066a912ea577f2ce4
==== Adding the Transaction to the Ledger
The transaction created by Alice's wallet application is 258 bytes long and 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.
The transaction created by Alice's wallet application is 258 bytes long
and 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 client participating by connecting to several other Bitcoin clients. The purpose of the Bitcoin network is to propagate transactions and blocks to all participants.
((("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 client participating by
connecting to several other Bitcoin clients. 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")))Any system, such as a server, desktop application, or wallet, that participates in the Bitcoin network by "speaking" the Bitcoin protocol is called a _Bitcoin node_. 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. 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 _flooding_. Thus, the transaction rapidly propagates out across the peer-to-peer network, reaching a large percentage of the nodes within a few seconds.
system, such as a server, desktop application, or wallet, that
participates in the Bitcoin network by "speaking" the Bitcoin protocol
is called a _Bitcoin node_. 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. 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 _flooding_. 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 node 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 outputs redeemable by Bob's keys. Bob's wallet application can also independently verify that the transaction is well formed, uses previously unspent inputs, and contains sufficient transaction fees to be included in the next block. At this point Bob can assume, with little risk, that the transaction will shortly be included in a block and confirmed.
If Bob's bitcoin wallet application is directly connected to Alice's
wallet application, Bob's wallet application might be the first node 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 outputs redeemable by Bob's
keys. Bob's wallet application can also independently verify that the
transaction is well formed, uses previously unspent inputs, and contains
sufficient transaction fees to be included in the next block. At this
point Bob can assume, with little risk, that the transaction will
shortly be included in a block and confirmed.
[TIP]
====
((("confirmations", "of small-value transactions", secondary-sortas="small-value transactions")))A common misconception about bitcoin transactions is that they must be "confirmed" by waiting 10 minutes for a new block, or up to 60 minutes for a full six confirmations. Although confirmations ensure the transaction has been accepted by the whole network, such a delay is unnecessary for small-value items such as a cup of coffee. A merchant may accept a valid small-value transaction with no confirmations, with no more risk than a credit card payment made without an ID or a signature, as merchants routinely accept today.((("", startref="Tconstruct02")))
((("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 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
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.
((("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
((("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 #277316, which contains Alice's transaction. Below it are 277,316 blocks (including block #0), 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")))
((("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.
@ -274,14 +648,41 @@ 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 client can independently verify the transaction as valid and spendable. Full-node clients can track the source of the funds from the moment the bitcoin were first generated in a block, incrementally from transaction to 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 accepted it as valid.
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 laptop payment to these new owners. Most likely, Bob's bitcoin software will aggregate many small payments into a larger payment, perhaps concentrating all the day's bitcoin revenue into a single transaction. This would aggregate the various payments into a single output (and a single address). For a diagram of an aggregating transaction, see <<transaction-aggregating>>.
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>>.
(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 client can independently verify the
transaction as valid and spendable. Full-node clients can track the
source of the funds from the moment the bitcoin were first generated in
a block, incrementally from transaction to 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 accepted it as valid.
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 laptop payment to these new owners. Most likely, Bob's bitcoin
software will aggregate many small payments into a larger payment,
perhaps concentrating all the day's bitcoin revenue into a single
transaction. This would aggregate the various payments into a single
output (and a single address). For a diagram of an aggregating
transaction, see <<transaction-aggregating>>.
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.
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.
David A. Harding
1 year ago