mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-22 22:58:09 +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:
David A. Harding
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
|
||||
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
|
||||
the Bitcoin network to the blockchain, we will use a _blockchain
|
||||
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
|
||||
relationships and flows between them.
|
||||
|
||||
//FIXME: priv key to P2PKH address
|
||||
[[bitcoin-overview]]
|
||||
.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
|
||||
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
|
||||
which spend funds. On the other side of
|
||||
the transaction, there are one or more "outputs," which receive funds.
|
||||
((("fees", "transaction fees")))The inputs
|
||||
and outputs 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
|
||||
@ -234,6 +235,8 @@ change.
|
||||
@enddittaa
|
||||
////
|
||||
|
||||
//FIXME: clarify that these aren't the same transactions as described in
|
||||
//the text
|
||||
[[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"]
|
||||
@ -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
|
||||
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
|
||||
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
|
||||
expect to receive $15 dollars in change. The same concept applies to
|
||||
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
|
||||
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.
|
||||
generated by wallets and businesses to clean up lots of smaller amounts.
|
||||
|
||||
[[transaction-consolidating]]
|
||||
.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
|
||||
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
|
||||
@ -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.
|
||||
|
||||
Finally, for the transaction to be processed by the network in a timely
|
||||
fashion, Alice's wallet application will add a small fee. This is not
|
||||
explicit in the transaction; it is implied by the difference in value between
|
||||
fashion, Alice's wallet application will add a small fee. The fee is not
|
||||
explicitly stated in the transaction; it is implied by the difference in value between
|
||||
inputs and outputs. This _transaction fee_ is collected by the
|
||||
miner as a fee for validating and including the transaction in a block
|
||||
to be recorded on the blockchain.
|
||||
@ -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
|
||||
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
|
||||
to use the internet connection offered by Bob, 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
|
||||
valid transaction it has not seen before will 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
|
||||
@ -516,7 +463,8 @@ wallet can further verify Alice's transaction only spends valid UTXOs.
|
||||
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
|
||||
included in a block by a process called _mining_ and that block has been
|
||||
validated by full nodes. See
|
||||
<<mining>> for a detailed explanation.
|
||||
|
||||
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
|
||||
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
|
||||
miners construct a new candidate block, they add unverified transactions from this
|
||||
pool to the candidate block and then attempt to prove the validity of that
|
||||
candidate 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 are added to the new block, prioritized by the highest fee rate
|
||||
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
|
||||
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
|
||||
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
|
||||
calculating the Proof-of-Work for the candidate block. Each miner includes a
|
||||
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
|
||||
transaction fees from all the transactions included in the block. If he
|
||||
finds a solution that makes that block valid, he "wins" this reward
|
||||
transaction fees from all the transactions included in the candidate block. If he
|
||||
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
|
||||
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.
|
||||
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
|
||||
miners in proportion to the amount of work they contributed in the last
|
||||
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.
|
||||
Approximately five minutes after the transaction was first transmitted
|
||||
by Alice's wallet, one of Jing's ASIC miners found a solution for the
|
||||
block and announced it to the network. After other miners
|
||||
validated the winning block, they started a new lottery to generate the next
|
||||
block and announced it to the network. After each other miner
|
||||
validates the winning block, they start a new lottery to generate the next
|
||||
block.
|
||||
|
||||
//FIXME:Murch CH2 feedback about most-PoW chain
|
||||
Jing's winning block containing Alice's transaction became part of the
|
||||
blockchain. The block containing Alice's transaction is counted as one
|
||||
"confirmation" of that transaction. After the block containing Alice's
|
||||
@ -719,13 +668,7 @@ 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>>.
|
||||
|
||||
Alice's podcast payment to these new owners.
|
||||
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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user