@ -13,8 +13,7 @@ transactions are validated and cleared. Mining is one of the inventions that
makes Bitcoin special, a decentralized consensus mechanism that is the
basis for P2P digital cash.
((("central
trusted authority")))Mining _secures the Bitcoin system_ and enables the
((("centraltrusted authority")))Mining _secures the Bitcoin system_ and enables the
emergence of network-wide _consensus without a central authority_.
The reward of newly minted bitcoins and
transaction fees is an incentive scheme that aligns the actions of
@ -52,8 +51,7 @@ In some protocols built on top of Bitcoin, the topological order of
Bitcoin transactions is also used to establish a sequence of events;
we'll discuss that idea further in <<single_use_seals>>.
((("mining and consensus", "mining rewards
and fees")))((("mining and consensus",
((("mining and consensus", "mining rewardsand fees")))((("mining and consensus",
"Proof-of-Work algorithm")))Miners receive two types of rewards in
return for the security provided by mining: new bitcoins created with each
new block (called the _subsidy_), and transaction fees from all the transactions included in
@ -102,8 +100,7 @@ consensus.
=== Bitcoin Economics and Currency Creation
((("mining and consensus", "bitcoin economics and currency
creation")))((("issuance
((("mining and consensus", "bitcoin economics and currencycreation")))((("issuance
rate")))Bitcoin are minted during the creation of each block at a
fixed and diminishing rate. Each block, generated on average every 10
minutes, contains entirely new bitcoins, created from nothing. Every
@ -206,8 +203,7 @@ outweighs the risks of deflation.
=== Decentralized Consensus
((("decentralized
systems", "consensus in")))In the previous chapter we looked at the
((("decentralizedsystems", "consensus in")))In the previous chapter we looked at the
blockchain, the global list of all transactions, which
everyone in the Bitcoin network accepts as the authoritative record of
ownership transfers.
@ -226,8 +222,7 @@ and assemble a copy of the same blockchain as everyone else. This
chapter examines the process by which the Bitcoin network achieves
global consensus without central authority.
((("mining and consensus", "emergent
consensus")))One of Satoshi Nakamoto's inventions is the decentralized
((("mining and consensus", "emergentconsensus")))One of Satoshi Nakamoto's inventions is the decentralized
mechanism for _emergent consensus_. Emergent, because consensus is not
achieved explicitly—there is no election or fixed moment when consensus
occurs. Instead, consensus is an emergent artifact of the asynchronous
@ -260,8 +255,7 @@ trusted, public, global blockchain.
[[tx_verification]]
=== Independent Verification of Transactions
((("mining and consensus", "independent transaction
verification")))In
((("mining and consensus", "independent transactionverification")))In
<<c_transactions>>, we saw how wallet software creates transactions by
collecting UTXOs, providing the appropriate authentication data, and then
constructing new outputs assigned to a new owner. The resulting
@ -316,8 +310,7 @@ _mempool_.
=== Mining Nodes
((("Bitcoin nodes", "mining
nodes")))Some of the nodes on the Bitcoin network are specialized nodes
((("Bitcoin nodes", "miningnodes")))Some of the nodes on the Bitcoin network are specialized nodes
called _miners_. Jing is a
Bitcoin miner; he
earns bitcoin by running a "mining rig," which is a specialized
@ -352,8 +345,7 @@ transactions in the memory pool and remove any that were included in
that block. Whatever transactions remain in the memory pool are
unconfirmed and are waiting to be recorded in a new block.
((("mining and consensus", "Proof-of-Work
algorithm")))Jing's node immediately constructs a new partial block, a
((("mining and consensus", "Proof-of-Workalgorithm")))Jing's node immediately constructs a new partial block, a
candidate for the next block. This block is called a _candidate block_
because it is not yet a valid block, as it does not contain a valid
proof-of-work. The block becomes valid only if the miner succeeds in
@ -365,8 +357,7 @@ transaction fees he'll attempt to claim.
==== The Coinbase Transaction
((("transactions",
"coinbase transactions", id="Tcoinb10")))The first transaction in any
((("transactions","coinbase transactions", id="Tcoinb10")))The first transaction in any
block is a special transaction, called a _coinbase transaction_. This
transaction is constructed by Jing's node and pays out his _reward_ for
the mining effort.
@ -389,8 +380,7 @@ reward.
==== Coinbase Reward and Fees
((("fees", "transaction
fees")))To construct the
((("fees", "transactionfees")))To construct the
coinbase transaction, Jing's node first calculates the total amount of
transaction fees:
@ -510,8 +500,7 @@ field is replaced by coinbase data, which must be between 2 and 100
bytes. Except for the first few bytes, the rest of the coinbase data can
be used by miners in any way they want; it is arbitrary data.
((("blockchain
(the)", "genesis block")))In the genesis block, for
((("blockchain(the)", "genesis block")))In the genesis block, for
example, Satoshi Nakamoto added the text "The Times 03/Jan/2009
Chancellor on brink of second bailout for banks" in the coinbase data,
using it as a proof of the earliest date this block chould have been
@ -526,8 +515,7 @@ version field set to 2 or higher) must contain the block height as a script
=== Constructing the Block Header
((("blocks",
"headers")))To
((("blocks","headers")))To
construct the block header, the mining node needs to fill in six fields,
as listed in <<block_header_structure_ch10>>.
@ -641,8 +629,7 @@ until the desired hash result appears by chance.
==== Proof-of-Work Algorithm
((("mining and consensus",
"Proof-of-Work algorithm", id="Cproof10")))A hash algorithm takes an
((("mining and consensus","Proof-of-Work algorithm", id="Cproof10")))A hash algorithm takes an
arbitrary-length data input and produces a fixed-length deterministic
result, called a _digest_. The digest is a digital commitment to the
input. For any specific input, the resulting digest will always be the
@ -768,8 +755,7 @@ enough block header hash.
//TODO:use visual representation like I did on bitcoin.org
((("mining and consensus", "mining the block", "target
representation")))
((("mining and consensus", "mining the block", "targetrepresentation")))
Block headers contain the target in a notation called "target
bits" or just "bits," which in block 277,316 has the value of
+0x1903a30c+. This notation expresses the Proof-of-Work target as a
@ -824,8 +810,7 @@ terahash per second or 1 TH/sec) would only find a solution once every
[[target]]
==== Retargeting to Adjust Difficulty
((("mining and consensus", "mining the block", "retargeting to adjust
difficulty")))As we saw, the target determines the difficulty and
((("mining and consensus", "mining the block", "retargeting to adjustdifficulty")))As we saw, the target determines the difficulty and
therefore affects how long it takes to find a solution to the
Proof-of-Work algorithm. This leads to the obvious questions: Why is the
difficulty adjustable, who adjusts it, and how?
@ -987,8 +972,7 @@ sequence, +CLTV+, and +CSV+.
=== Successfully Mining the Block
((("mining and consensus", "mining the block", "successful
completion")))As
((("mining and consensus", "mining the block", "successfulcompletion")))As
we saw earlier, Jing's node has constructed a candidate block and
prepared it for mining. Jing has several hardware mining rigs with
application-specific integrated circuits, where hundreds of thousands of
@ -1020,13 +1004,11 @@ chain it extends.
In the next section, we'll look at the process each node uses to
validate a block and select the most-work chain, creating the consensus
that forms the decentralized blockchain.((("",
startref="MACmining10")))
that forms the decentralized blockchain.((("",startref="MACmining10")))
=== Validating a New Block
((("blocks", "new
block validation")))The third step in Bitcoin's
((("blocks", "newblock validation")))The third step in Bitcoin's
consensus mechanism is independent validation of each new block by every
node on the network. As the newly solved block moves across the network,
each node performs a series of tests to validate it.
@ -1077,8 +1059,7 @@ independent validation is a key component of decentralized consensus.
[[forks]]
=== Assembling and Selecting Chains of Blocks
((("mining and consensus", "assembling and selecting chains of blocks",
id="MACassembling10")))((("blocks", "assembling and selecting chains
((("mining and consensus", "assembling and selecting chains of blocks",id="MACassembling10")))((("blocks", "assembling and selecting chains
of", id="Bassemble10")))The final part in Bitcoin's decentralized
consensus mechanism is the assembly of blocks into chains and the
selection of the chain with the most Proof-of-Work.
@ -1153,14 +1134,12 @@ forks (in addition to other problems), so many people prefer Bitcoin's
10-minute blocks over shorter block intervals.
====
((("",
startref="Bassemble10")))((("",
((("",startref="Bassemble10")))((("",
startref="forks10")))
=== Mining and the Hash Lottery
((("mining and consensus", "hashing power race",
id="MAChash10")))Bitcoin mining is an extremely competitive industry.
((("mining and consensus", "hashing power race",id="MAChash10")))Bitcoin mining is an extremely competitive industry.
The hashing power has increased exponentially every year of Bitcoin's
existence. Some years the growth has reflected a complete change of
technology, such as in 2010 and 2011 when many miners switched from
@ -1222,8 +1201,7 @@ entire left flank of the merkle tree up to the root.
[[mining_pools]]
==== Mining Pools
((("mining pools", "benefits
of")))In this highly competitive environment, individual miners working
((("mining pools", "benefitsof")))In this highly competitive environment, individual miners working
alone (also known as solo miners) don't stand a chance. The likelihood
of them finding a block to offset their electricity and hardware costs
is so low that it represents a gamble, like playing the lottery. Even
@ -1322,8 +1300,7 @@ whole pool wins.
===== Managed pools
((("pool operators",
seealso="mining pools")))Most mining pools are "managed," meaning that
((("pool operators",seealso="mining pools")))Most mining pools are "managed," meaning that
there is a company or individual running a pool server. The owner of the
pool server is called the _pool operator_, and he charges pool miners a
percentage fee of the earnings.
@ -1356,8 +1333,7 @@ using their own full node.
===== Peer-to-peer mining pool (P2Pool)
((("peer-to-peer
pools (P2Pool)")))Managed pools using Stratum v1 create the possibility of cheating by
((("peer-to-peerpools (P2Pool)")))Managed pools using Stratum v1 create the possibility of cheating by
the pool operator, who might direct the pool effort to double-spend
transactions or invalidate blocks (see <<consensus_attacks>>).
Furthermore, centralized pool servers represent a
@ -1402,8 +1378,7 @@ attack problem for bitcoin itself. Rather, P2Pool makes bitcoin more
robust overall, as part of a diversified mining ecosystem. As of this
writing, P2Pool has fallen into disuse, but new protocols such as
Stratum v2 can allow individual miners to choose the transactions they
include in their blocks.((("",
startref="MAChash10")))
include in their blocks.((("",startref="MAChash10")))
[[consensus_attacks]]
=== Hashrate Attacks
@ -1443,8 +1418,7 @@ a transaction allows the attacker can get an irreversible exchange payment or
product without paying for it.
Let's examine a practical example of a 51% attack. In the first chapter,
we looked at a transaction between ((("use cases", "buying
coffee")))Alice and Bob. Bob, the seller, is
we looked at a transaction between ((("use cases", "buyingcoffee")))Alice and Bob. Bob, the seller, is
willing to accept payment without waiting for
confirmation (mining in a block), because the risk of a double-spend on
a small item is low in comparison to the convenience of rapid
@ -1463,8 +1437,7 @@ the corresponding transaction in the old chain.
//TODO:distinguish between majority attack and sub-majority "reorg"
//attack.
In our example, malicious attacker Mallory goes to ((("use cases",
"retail sales", id="carolten")))Carol's gallery and purchases a
In our example, malicious attacker Mallory goes to ((("use cases","retail sales", id="carolten")))Carol's gallery and purchases a
set of beautiful paintings depicting Satoshi Nakamoto as Prometheus.
Carol sells the paintings for $250,000 in bitcoins to
Mallory. Instead of waiting for six or more confirmations on the
@ -1488,8 +1461,7 @@ pool participants might remain blissfully unaware of the double-spend
attempt, because they mine with automated miners and cannot monitor
every transaction or block.
((("confirmations", "of large-value transactions",
secondary-sortas="large-value transactions")))To protect against this
((("confirmations", "of large-value transactions",secondary-sortas="large-value transactions")))To protect against this
kind of attack, a merchant selling large-value items must wait at least
six confirmations before giving the product to the buyer. Waiting for
more than six confirmations may sometimes be warranted. Alternatively,
@ -1557,8 +1529,7 @@ Bitcoin community.
[[consensus_changes]]
=== Changing the Consensus Rules
((("mining and consensus", "consensus rules", "changing",
id="Crule10")))The rules of consensus determine the validity of
((("mining and consensus", "consensus rules", "changing",id="Crule10")))The rules of consensus determine the validity of
transactions and blocks. These rules are the basis for collaboration
between all Bitcoin nodes and are responsible for the convergence of all
local perspectives into a single consistent blockchain across the entire
@ -1575,8 +1546,7 @@ between all participants.
[[hard_forks]]
==== Hard Forks
((("forks",
"changing consensus rules", "hard forks")))In <<forks>> we looked at how
((("forks","changing consensus rules", "hard forks")))In <<forks>> we looked at how
the Bitcoin network may briefly diverge, with two parts of the network
following two different branches of the blockchain for a short time. We
saw how this process occurs naturally, as part of the normal operation
@ -1705,8 +1675,7 @@ they are connected to two separate networks.
==== Diverging Miners and Difficulty
((("forks", "changing consensus rules", "diverging miners and
difficulty")))As miners diverge into mining two different chains, the
((("forks", "changing consensus rules", "diverging miners anddifficulty")))As miners diverge into mining two different chains, the
hashing power is split between the chains. The mining power can be split
in any proportion between the two chains. The new rules may only be
followed by a minority, or by the vast majority of the mining power.
@ -1739,8 +1708,7 @@ transactions.
==== Contentious Hard Forks
((("forks", "changing consensus rules", "contentious hard
forks")))This is the dawn of the development of software
((("forks", "changing consensus rules", "contentious hardforks")))This is the dawn of the development of software
for decentralized consensus. Just as other innovations in development changed both the methods
and products of software and created new methodologies, new tools, and
new communities in its wake, consensus software development also
@ -1765,8 +1733,7 @@ consensus modifications.
==== Soft Forks
((("soft forks",
"defined")))Not all consensus rule changes cause a hard fork. Only
((("soft forks","defined")))Not all consensus rule changes cause a hard fork. Only
consensus changes that are forward-incompatible cause a fork. If the
change is implemented in such a way that an unmodified client still sees
the transaction or block as valid under the previous rules, the change
@ -1792,8 +1759,7 @@ nonupgraded nodes out of consensus.
===== Soft forks redefining NOP opcodes
((("soft forks",
"redefinition of NOP codes")))Two soft forks have been
((("soft forks","redefinition of NOP codes")))Two soft forks have been
implemented in Bitcoin, based on the re-interpretation of NOP opcodes.
Bitcoin Script had ten opcodes reserved for future use, NOP1 through
NOP10. Under the consensus rules, the presence of these opcodes in a
@ -1811,8 +1777,7 @@ the old clients, the script contains an NOP code, which is ignored.
==== Criticisms of Soft Forks
((("soft
forks", "drawbacks of")))Soft forks based on the NOP opcodes are
((("softforks", "drawbacks of")))Soft forks based on the NOP opcodes are
relatively uncontroversial. The NOP opcodes were placed in Bitcoin
Script with the explicit goal of allowing non-disruptive upgrades.
@ -1845,8 +1810,7 @@ lead to loss of funds.
[[softforksignaling]]
=== Soft Fork Signaling with Block Version
((("forks", "changing consensus rules", "soft fork
activation")))Since soft forks allow
((("forks", "changing consensus rules", "soft forkactivation")))Since soft forks allow
unmodified clients to continue to operate within consensus, one
mechanism for "activating" a soft fork is through miners signaling that
they are ready and willing to enforce the new consensus rules. If
@ -1856,8 +1820,7 @@ This mechanism was introduced by BIP34.
==== BIP34 Signaling and Activation
((("bitcoin improvement proposals", "Block v2, Height in Coinbase
(BIP34)")))BIP34 used the block version
((("bitcoin improvement proposals", "Block v2, Height in Coinbase(BIP34)")))BIP34 used the block version
field to allow miners to signal readiness for a specific consensus rule
change. Prior to BIP34, the block version was set to "1" by
_convention_ not enforced by _consensus_.
@ -1914,8 +1877,7 @@ described next.
[[bip9]]
==== BIP9 Signaling and Activation
((("bitcoin improvement proposals", "Version bits with timeout and delay
(BIP9)")))((("bitcoin improvement proposals", "CHECKLOCKTIMEVERIFY
((("bitcoin improvement proposals", "Version bits with timeout and delay(BIP9)")))((("bitcoin improvement proposals", "CHECKLOCKTIMEVERIFY
(BIP65)")))((("bitcoin improvement proposals", "Strict DER signatures
(BIP66)")))The mechanism used by BIP34, BIP66, and BIP65 was
successful in activating three soft forks. However, it was replaced
@ -2095,8 +2057,7 @@ future attempt to activate a soft fork.
=== Consensus Software Development
((("mining and consensus", "consensus software
development")))((("development environment", "consensus software
((("mining and consensus", "consensus softwaredevelopment")))((("development environment", "consensus software
development")))Consensus software continues to evolve and there is much
discussion on the various mechanisms for changing the consensus rules.
By its very nature, Bitcoin sets a very high bar on coordination and
theresa jones
8 months ago