mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2025-06-14 12:08:50 +00:00
CH02: edits for Mark (Xekyo) Erhardt feedback (thanks!)
- Drop unnecessary mentions of people from CH01 - FIXMEs: add notes for image corrections and best blockchain change - Drop unnecessary mention of debits and credits - Remove mention about asking block explorer for UTXOs to construct a transaction. This is unnecessary detail and it can never entirely work for our example if we later use it to spend the output (because then the output won't be unspent) - Instead of "new block" use "candidate block" - Drop unnecessary mention of payment consolidation. We already adequetely introduce this concept earlier in the chapter.
This commit is contained in:
parent
0249c97460
commit
71cf4bc97a
119
ch02.asciidoc
119
ch02.asciidoc
@ -24,7 +24,7 @@ which is the authoritative ledger of all transactions.
|
|||||||
|
|
||||||
((("blockchain explorer sites")))Each example in this chapter is based
|
((("blockchain explorer sites")))Each example in this chapter is based
|
||||||
on an actual transaction made on the Bitcoin network, simulating the
|
on an actual transaction made on the Bitcoin network, simulating the
|
||||||
interactions between the users (Joe, Alice, Bob, and Gopesh) by sending
|
interactions between several users by sending
|
||||||
funds from one wallet to another. While tracking a transaction through
|
funds from one wallet to another. While tracking a transaction through
|
||||||
the Bitcoin network to the blockchain, we will use a _blockchain
|
the Bitcoin network to the blockchain, we will use a _blockchain
|
||||||
explorer_ site to visualize each step. A blockchain explorer is a web
|
explorer_ site to visualize each step. A blockchain explorer is a web
|
||||||
@ -32,6 +32,7 @@ application that operates as a bitcoin search engine, in that it allows
|
|||||||
you to search for addresses, transactions, and blocks and see the
|
you to search for addresses, transactions, and blocks and see the
|
||||||
relationships and flows between them.
|
relationships and flows between them.
|
||||||
|
|
||||||
|
//FIXME: priv key to P2PKH address
|
||||||
[[bitcoin-overview]]
|
[[bitcoin-overview]]
|
||||||
.Bitcoin overview
|
.Bitcoin overview
|
||||||
image::images/mbc2_0201.png["Bitcoin Overview"]
|
image::images/mbc2_0201.png["Bitcoin Overview"]
|
||||||
@ -171,10 +172,10 @@ owner, and so on, in a chain of ownership.
|
|||||||
((("transactions", "overview of", id="Tover02")))((("outputs and
|
((("transactions", "overview of", id="Tover02")))((("outputs and
|
||||||
inputs", "basics of")))Transactions are like lines in a double-entry
|
inputs", "basics of")))Transactions are like lines in a double-entry
|
||||||
bookkeeping ledger. Each transaction contains one or more "inputs,"
|
bookkeeping ledger. Each transaction contains one or more "inputs,"
|
||||||
which are like debits against a bitcoin account. On the other side of
|
which spend funds. On the other side of
|
||||||
the transaction, there are one or more "outputs," which are like credits
|
the transaction, there are one or more "outputs," which receive funds.
|
||||||
added to a bitcoin account. ((("fees", "transaction fees")))The inputs
|
((("fees", "transaction fees")))The inputs
|
||||||
and outputs (debits and credits) do not necessarily add up to the same
|
and outputs do not necessarily add up to the same
|
||||||
amount. Instead, outputs add up to slightly less than inputs and the
|
amount. Instead, outputs add up to slightly less than inputs and the
|
||||||
difference represents an implied _transaction fee_, which is a small
|
difference represents an implied _transaction fee_, which is a small
|
||||||
payment collected by the miner who includes the transaction in the
|
payment collected by the miner who includes the transaction in the
|
||||||
@ -234,6 +235,8 @@ change.
|
|||||||
@enddittaa
|
@enddittaa
|
||||||
////
|
////
|
||||||
|
|
||||||
|
//FIXME: clarify that these aren't the same transactions as described in
|
||||||
|
//the text
|
||||||
[[transaction-chain]]
|
[[transaction-chain]]
|
||||||
.A chain of transactions, where the output of one transaction is the input of the next transaction
|
.A chain of transactions, where the output of one transaction is the input of the next transaction
|
||||||
image::images/transaction-chain.png["Transaction chain"]
|
image::images/transaction-chain.png["Transaction chain"]
|
||||||
@ -257,7 +260,7 @@ addresses")))In addition to one or more outputs that pay the receiver of
|
|||||||
bitcoins, many transactions will also include an output that pays the
|
bitcoins, many transactions will also include an output that pays the
|
||||||
spender of the bitcoins, called a _change_ output.
|
spender of the bitcoins, called a _change_ output.
|
||||||
This is because transaction inputs,
|
This is because transaction inputs,
|
||||||
like currency notes, cannot be divided. If you purchase a $5 US dollar
|
like currency notes, cannot be partly spent. If you purchase a $5 US dollar
|
||||||
item in a store but use a $20 dollar bill to pay for the item, you
|
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
|
expect to receive $15 dollars in change. The same concept applies to
|
||||||
bitcoin transaction inputs. If you purchased an item that costs 5
|
bitcoin transaction inputs. If you purchased an item that costs 5
|
||||||
@ -308,7 +311,7 @@ Another common form of transaction is a _consolidation transaction_ one that spe
|
|||||||
into a single output (<<transaction-consolidating>>). This represents
|
into a single output (<<transaction-consolidating>>). This represents
|
||||||
the real-world equivalent of exchanging a pile of coins and currency
|
the real-world equivalent of exchanging a pile of coins and currency
|
||||||
notes for a single larger note. Transactions like these are sometimes
|
notes for a single larger note. Transactions like these are sometimes
|
||||||
generated by wallets and business to clean up lots of smaller amounts.
|
generated by wallets and businesses to clean up lots of smaller amounts.
|
||||||
|
|
||||||
[[transaction-consolidating]]
|
[[transaction-consolidating]]
|
||||||
.Transaction aggregating funds
|
.Transaction aggregating funds
|
||||||
@ -354,62 +357,6 @@ However, because full nodes use more resources, most
|
|||||||
user wallets run "lightweight" clients that track only the user's own
|
user wallets run "lightweight" clients that track only the user's own
|
||||||
UTXOs.
|
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
|
In this case, this single
|
||||||
UTXO is sufficient to pay for the podcast. Had this not been the case,
|
UTXO is sufficient to pay for the podcast. Had this not been the case,
|
||||||
Alice's wallet application might have to combine several
|
Alice's wallet application might have to combine several
|
||||||
@ -441,8 +388,8 @@ her funds into two outputs: one to Bob and one back to herself. She can
|
|||||||
then spend the change output in a subsequent transaction.
|
then spend the change output in a subsequent transaction.
|
||||||
|
|
||||||
Finally, for the transaction to be processed by the network in a timely
|
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
|
fashion, Alice's wallet application will add a small fee. The fee is not
|
||||||
explicit in the transaction; it is implied by the difference in value between
|
explicitly stated in the transaction; it is implied by the difference in value between
|
||||||
inputs and outputs. This _transaction fee_ is collected by the
|
inputs and outputs. This _transaction fee_ is collected by the
|
||||||
miner as a fee for validating and including the transaction in a block
|
miner as a fee for validating and including the transaction in a block
|
||||||
to be recorded on the blockchain.
|
to be recorded on the blockchain.
|
||||||
@ -489,10 +436,10 @@ 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
|
to another program (such as a block explorer) that will relay it to a
|
||||||
node. Her bitcoin wallet does not have
|
node. Her bitcoin wallet does not have
|
||||||
to be connected to Bob's bitcoin wallet directly and she 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
|
to use the internet connection offered by Bob, though both those
|
||||||
options are possible, too. ((("propagation", "flooding
|
options are possible, too. ((("propagation", "flooding
|
||||||
technique")))((("flooding technique")))Any Bitcoin node that receives a
|
technique")))((("flooding technique")))Any Bitcoin node that receives a
|
||||||
valid transaction it has not seen before will immediately forward it to
|
valid transaction it has not seen before will forward it to
|
||||||
all other nodes to which it is connected, a propagation technique known
|
all other nodes to which it is connected, a propagation technique known
|
||||||
as _gossiping_. Thus, the transaction rapidly propagates out across the
|
as _gossiping_. Thus, the transaction rapidly propagates out across the
|
||||||
peer-to-peer network, reaching a large percentage of the nodes within a
|
peer-to-peer network, reaching a large percentage of the nodes within a
|
||||||
@ -516,7 +463,8 @@ wallet can further verify Alice's transaction only spends valid UTXOs.
|
|||||||
id="MACover02")))((("blockchain (the)", "overview of mining",
|
id="MACover02")))((("blockchain (the)", "overview of mining",
|
||||||
id="BToverview02")))Alice's transaction is now propagated on the Bitcoin
|
id="BToverview02")))Alice's transaction is now propagated on the Bitcoin
|
||||||
network. It does not become part of the _blockchain_ until it is
|
network. It does not become part of the _blockchain_ until it is
|
||||||
verified and included in a block by a process called _mining_. See
|
included in a block by a process called _mining_ and that block has been
|
||||||
|
validated by full nodes. See
|
||||||
<<mining>> for a detailed explanation.
|
<<mining>> for a detailed explanation.
|
||||||
|
|
||||||
The Bitcoin system of counterfeit protection is based on computation.
|
The Bitcoin system of counterfeit protection is based on computation.
|
||||||
@ -606,26 +554,26 @@ income from the profits.
|
|||||||
flowing into the network from user wallets and other applications. As
|
flowing into the network from user wallets and other applications. As
|
||||||
these are seen by the Bitcoin network nodes, they get added to a
|
these are seen by the Bitcoin network nodes, they get added to a
|
||||||
temporary pool of unverified transactions maintained by each node. As
|
temporary pool of unverified transactions maintained by each node. As
|
||||||
miners construct a new block, they add unverified transactions from this
|
miners construct a new candidate block, they add unverified transactions from this
|
||||||
pool to the new block and then attempt to prove the validity of that new
|
pool to the candidate block and then attempt to prove the validity of that
|
||||||
block, with the mining algorithm (Proof-of-Work). The process of mining
|
candidate block, with the mining algorithm (Proof-of-Work). The process of mining
|
||||||
is explained in detail in <<mining>>.
|
is explained in detail in <<mining>>.
|
||||||
|
|
||||||
Transactions are added to the new block, prioritized by the highest-fee
|
Transactions are added to the new block, prioritized by the highest fee rate
|
||||||
transactions first and a few other criteria. Each miner starts the
|
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
|
process of mining a new candidate block of transactions as soon as he receives the
|
||||||
previous block from the network, knowing he has lost that previous round
|
previous block from the network, knowing he has lost that previous round
|
||||||
of competition. He immediately creates a new block, fills it with
|
of competition. He immediately creates a new candidate block, fills it with
|
||||||
transactions and the fingerprint of the previous block, and starts
|
transactions and the fingerprint of the previous block, and starts
|
||||||
calculating the Proof-of-Work for the new block. Each miner includes a
|
calculating the Proof-of-Work for the candidate block. Each miner includes a
|
||||||
special transaction in his block, one that pays his own Bitcoin address
|
special transaction in his candidate block, one that pays his own Bitcoin address
|
||||||
the block reward (currently 12.5 newly created bitcoin) plus the sum of
|
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
|
transaction fees from all the transactions included in the candidate block. If he
|
||||||
finds a solution that makes that block valid, he "wins" this reward
|
finds a solution that makes the candidate into a valid block, he "wins" this reward
|
||||||
because his successful block is added to the global blockchain and the
|
because his successful block is added to the global blockchain and the
|
||||||
reward transaction he included becomes spendable. ((("mining pools",
|
reward transaction he included becomes spendable. ((("mining pools",
|
||||||
"operation of")))Jing, who participates in a mining pool, has set up his
|
"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.
|
software to create candidate blocks that assign the reward to a pool address.
|
||||||
From there, a share of the reward is distributed to Jing and other
|
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
|
miners in proportion to the amount of work they contributed in the last
|
||||||
round.
|
round.
|
||||||
@ -638,10 +586,11 @@ mining pool. All the miners participating in that mining pool
|
|||||||
immediately start trying to generate a Proof-of-Work for the block template.
|
immediately start trying to generate a Proof-of-Work for the block template.
|
||||||
Approximately five minutes after the transaction was first transmitted
|
Approximately five minutes after the transaction was first transmitted
|
||||||
by Alice's wallet, one of Jing's ASIC miners found a solution for the
|
by Alice's wallet, one of Jing's ASIC miners found a solution for the
|
||||||
block and announced it to the network. After other miners
|
block and announced it to the network. After each other miner
|
||||||
validated the winning block, they started a new lottery to generate the next
|
validates the winning block, they start a new lottery to generate the next
|
||||||
block.
|
block.
|
||||||
|
|
||||||
|
//FIXME:Murch CH2 feedback about most-PoW chain
|
||||||
Jing's winning block containing Alice's transaction became part of the
|
Jing's winning block containing Alice's transaction became part of the
|
||||||
blockchain. The block containing Alice's transaction is counted as one
|
blockchain. The block containing Alice's transaction is counted as one
|
||||||
"confirmation" of that transaction. After the block containing Alice's
|
"confirmation" of that transaction. After the block containing Alice's
|
||||||
@ -719,13 +668,7 @@ committing to it.
|
|||||||
|
|
||||||
Bob can now spend the output from this and other transactions. For
|
Bob can now spend the output from this and other transactions. For
|
||||||
example, Bob can pay a contractor or supplier by transferring value from
|
example, Bob can pay a contractor or supplier by transferring value from
|
||||||
Alice's podcast payment to these new owners. Bob's bitcoin
|
Alice's podcast payment to these new owners.
|
||||||
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
|
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
|
extends the chain of transactions. Let's assume that Bob pays his web
|
||||||
designer Gopesh((("use cases", "offshore contract services"))) in
|
designer Gopesh((("use cases", "offshore contract services"))) in
|
||||||
|
Loading…
Reference in New Issue
Block a user