arno
/
bitcoinbook
mirror of https://github.com/bitcoinbook/bitcoinbook
1
0
Fork 0
Code Issues Releases Wiki Activity

CH12: small edits for accuracy, consistency, voice, and grammar

Browse Source
develop
David A. Harding 12 months ago
parent d9a730a512
commit 06fae7d78e
1 changed files with 145 additions and 174 deletions
Show Stats Download Patch File Download Diff File

319
ch10.asciidoc
Unescape View File

@ -1,13 +1,6 @@
[[mining]]
== Mining and Consensus
[[duplicate_transactions]]
=== Preventing Duplicate Transactions
FIXME:BIP30 and 34
=== Introduction
((("mining and consensus", "purpose of")))The word "mining" is somewhat
misleading. By evoking the extraction of precious metals, it focuses our
attention on the reward for mining, the new bitcoin created in each
@ -16,8 +9,8 @@ purpose of mining is not the reward or the generation of new coins. If
you view mining only as the process by which coins are created, you are
mistaking the means (incentives) as the goal of the process. Mining is
the mechanism that underpins the decentralized clearinghouse, by which
transactions are validated and cleared. Mining is the invention that
makes bitcoin special, a decentralized security mechanism that is the
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.
((("mining and consensus", "decentralized consensus")))((("central
@ -32,7 +25,7 @@ implementing the monetary supply.
====
((("decentralized systems", "bitcoin mining and")))The purpose of mining
is not the creation of new bitcoin. That's the incentive system. Mining
is the mechanism by which bitcoin's _security_ is _decentralized_.
is the mechanism by which Bitcoin's _consensus security_ is _decentralized_.
====
Miners record new transactions on the global ledger. A
@ -55,26 +48,25 @@ solution to the problem, called the Proof-of-Work, is included in the
new block and acts as proof that the miner expended significant
computing effort. The competition to solve the Proof-of-Work algorithm
to earn the reward and the right to record transactions on the
blockchain is the basis for bitcoin's security model.
blockchain is the basis for Bitcoin's security model.
The process is called mining because the reward (new coin generation) is
designed to simulate diminishing returns, just like mining for precious
metals. Bitcoin's money supply is created through mining, similar to how
Bitcoin's money supply is created in a process that's similar to how
a central bank issues new money by printing bank notes. The maximum
amount of newly created bitcoin a miner can add to a block decreases
approximately every four years (or precisely every 210,000 blocks). It
started at 50 bitcoin per block in January of 2009 and halved to 25
bitcoin per block in November of 2012. It halved again to 12.5 bitcoin
in July 2016. Based on this formula, bitcoin mining rewards decrease
in July 2016, and again to 6.25 in May 2020. Based on this formula, bitcoin mining rewards decrease
exponentially until approximately the year 2140, when all bitcoin
(20.99999998 million) will have been issued. After 2140, no new bitcoin
will have been issued. After 2140, no new bitcoin
will be issued.
Bitcoin miners also earn fees from transactions. Every transaction may
include a transaction fee, in the form of a surplus of bitcoin between
the transaction's inputs and outputs. The winning bitcoin miner gets to
"keep the change" on the transactions included in the winning block.
Today, the fees represent 0.5% or less of a bitcoin miner's income, the
Today, the fees usually represent only a small percentage of a bitcoin
miner's income, with the
vast majority coming from the newly minted bitcoin. However, as the
reward decreases over time and the number of transactions per block
increases, a greater proportion of bitcoin mining earnings will come
@ -85,7 +77,7 @@ will be incentivized only by transaction fees.
In this chapter, we will first examine mining as a monetary supply
mechanism and then look at the most important function of mining: the
decentralized consensus mechanism that underpins bitcoin's security.
decentralized consensus mechanism that underpins Bitcoin's security.
To understand mining and consensus, we will follow Alice's transaction
as it is received and added to a block by Jing's mining equipment. Then
@ -93,7 +85,7 @@ we will follow the block as it is mined, added to the blockchain, and
accepted by the Bitcoin network through the process of emergent
consensus.
==== Bitcoin Economics and Currency Creation
=== Bitcoin Economics and Currency Creation
((("mining and consensus", "bitcoin economics and currency
creation")))((("currency creation")))((("money supply")))((("issuance
@ -104,15 +96,15 @@ minutes, contains entirely new bitcoin, created from nothing. Every
rate is decreased by 50%. For the first four years of operation of the
network, each block contained 50 new bitcoin.
In November 2012, the new bitcoin issuance rate was decreased to 25
bitcoin per block. In July of 2016 it was decreased again to 12.5
bitcoin per block. It will halve again to 6.25 bitcoin at block 630,000,
which will be mined sometime in 2020. The rate of new coins decreases
like this exponentially over 32 "halvings" until block 6,720,000 (mined
The first halving occurred at block 210,000. The next expected halving
after publication of this book will occur at block 840,000, which will
probably be produced in April or May of 2024.
The rate of new coins decreases
exponentially over 32 of these _halvings_ until block 6,720,000 (mined
approximately in year 2137), when it reaches the minimum currency unit
of 1 satoshi. Finally, after 6.93 million blocks, in approximately 2140,
almost 2,099,999,997,690,000 satoshis, or almost 21 million bitcoin,
will be issued. Thereafter, blocks will contain no new bitcoin, and
will have been issued. Thereafter, blocks will contain no new bitcoin, and
miners will be rewarded solely through the transaction fees.
<<bitcoin_money_supply>> shows the total bitcoin in circulation over
time, as the issuance of currency decreases.
@ -156,8 +148,8 @@ Total BTC to ever be created: 2099999997690000 Satoshis
The finite and diminishing issuance creates a fixed monetary supply that
resists inflation. Unlike a fiat currency, which can be printed in
infinite numbers by a central bank, bitcoin can never be inflated by
printing.
infinite numbers by a central bank, no individual party has the ability
to inflate the supply of bitcoin.
.Deflationary Money
****
@ -166,7 +158,7 @@ fixed and diminishing monetary issuance is that the currency tends to be
inherently _deflationary_. Deflation is the phenomenon of appreciation
of value due to a mismatch in supply and demand that drives up the value
(and exchange rate) of a currency. The opposite of inflation, price
deflation, means that the money has more purchasing power over time.
deflation means that the money has more purchasing power over time.
Many economists argue that a deflationary economy is a disaster that
should be avoided at all costs. That is because in a period of rapid
@ -225,7 +217,7 @@ 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
interaction of thousands of independent nodes, all following simple
rules. All the properties of bitcoin, including currency, transactions,
rules. All the properties of Bitcoin, including currency, transactions,
payments, and the security model that does not depend on central
authority or trust, derive from this invention.
@ -256,8 +248,8 @@ trusted, public, global ledger.
((("mining and consensus", "independent transaction
verification")))((("transactions", "independent verification of")))In
<<transactions>>, we saw how wallet software creates transactions by
collecting UTXO, providing the appropriate unlocking scripts, and then
<<c_transactions>>, we saw how wallet software creates transactions by
collecting UTXO, providing the appropriate authentication data, and then
constructing new outputs assigned to a new owner. The resulting
transaction is then sent to the neighboring nodes in the Bitcoin network
so that it can be propagated across the entire Bitcoin network.
@ -298,11 +290,8 @@ criteria:
- The scripts for each input must validate against the
corresponding output scripts.
These conditions can be seen in detail in the functions
+AcceptToMemoryPool+, +CheckTransaction+, and +CheckInputs+ in Bitcoin
Core. Note that the conditions change over time, to address new types of
denial-of-service attacks or sometimes to relax the rules so as to
include more types of transactions.
Note that the conditions change over time, to add new features or
address new types of denial-of-service attacks.
By independently verifying each transaction as it is received and before
propagating it, every node builds a pool of valid (but unconfirmed)
@ -315,7 +304,7 @@ _mempool_.
nodes")))Some of the nodes on the Bitcoin network are specialized nodes
called _miners_. In <<ch01_intro_what_is_bitcoin>> we introduced ((("use
cases", "mining for bitcoin", id="jingten")))Jing, a computer
engineering student in Shanghai, China, who is a bitcoin miner. Jing
engineering student in Shanghai, China, who is a Bitcoin miner. Jing
earns bitcoin by running a "mining rig," which is a specialized
computer-hardware system designed to mine bitcoin. Jing's specialized
mining hardware is connected to a server running a full Bitcoin node.
@ -326,7 +315,7 @@ however, also aggregates these transactions into new blocks.
Jing's node is listening for new blocks, propagated on the Bitcoin
network, as do all nodes. However, the arrival of a new block has
special significance for a mining node. The competition among miners
special significance for a mining node. Each round of competition among miners
effectively ends with the propagation of a new block that acts as an
announcement of a winner. To miners, receiving a valid new block means
someone else won the competition and they lost. However, the end of one
@ -370,7 +359,7 @@ preparation for the next block. By now it has collected a few thousand
transactions in the memory pool. Upon receiving the new block and
validating it, Jing's node will also compare it against all the
transactions in the memory pool and remove any that were included in
block that block. Whatever transactions remain in the memory pool are
that block. Whatever transactions remain in the memory pool are
unconfirmed and are waiting to be recorded in a new block.
((("Proof-of-Work algorithm")))((("mining and consensus", "Proof-of-Work
@ -384,6 +373,7 @@ When Jing's node aggregates all the transactions from the memory pool,
the new candidate block has several thousand transactions that pays him
their total transaction fees.
==== The Coinbase Transaction
((("coinbase transactions", id="coinbtrans10")))((("transactions",
@ -525,6 +515,7 @@ is filled with 4 bytes all set to 0xFF (255 decimal). The
+scriptSig+ is replaced by coinbase data, a data field used by
the miners, as we will see next.
[[duplicate_transactions]]
==== Coinbase Data
((("coinbase transactions", "coinbase data")))Coinbase transactions do
@ -538,12 +529,12 @@ be used by miners in any way they want; it is arbitrary data.
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 date and to convey a message. Currently,
miners use the coinbase data to include extra nonce values and strings
miners often use the coinbase data to include extra nonce values and strings
identifying the mining pool.
The first few bytes of the coinbase used to be arbitrary, but that is no
longer the case. As per BIP34, version-2 blocks (blocks with the
version field set to 2) must contain the block height index as a script
version field set to 2 or higher) must contain the block height index as a script
"push" operation in the beginning of the coinbase field.
<<satoshi_words>> uses the libbitcoin library introduced in
@ -610,7 +601,7 @@ nonce field.
[TIP]
====
The protocol upgrades defined in BIPs 34, 66, and 65 occured in that
The protocol upgrades defined in BIPs 34, 66, and 65 occurred in that
order--with BIP66 (strict DER) occuring before BIP65
(+OP_CHECKTIMELOCKVERIFY+)--so Bitcoin developers often list them in
that order rather than sorted numerically.
@ -679,7 +670,7 @@ for Jing's hardware mining rig to "mine" the block, to find a solution
to the Proof-of-Work algorithm that makes the block valid. Throughout
this book we have studied cryptographic hash functions as used in
various aspects of the Bitcoin system. The hash function SHA256 is the
function used in bitcoin's mining process.((("", startref="jingten")))
function used in Bitcoin's mining process.((("", startref="jingten")))
((("mining and consensus", "defined")))In the simplest terms, mining is
the process of hashing the block header repeatedly, changing one
@ -687,7 +678,7 @@ parameter, until the resulting hash matches a specific target. The hash
function's result cannot be determined in advance, nor can a pattern be
created that will produce a specific hash value. This feature of hash
functions means that the only way to produce a hash result matching a
specific target is to try again and again, randomly modifying the input
specific target is to try again and again, modifying the input
until the desired hash result appears by chance.
==== Proof-of-Work Algorithm
@ -864,7 +855,7 @@ hash of this block's header and sees if it is smaller than the current
_target_. If the hash is not less than the target, the miner will modify
the nonce (usually just incrementing it by one) and try again. At the
current difficulty in the Bitcoin network, miners have to try
quadrillions of times before finding a nonce that results in a low
a huge number of times before finding a nonce that results in a low
enough block header hash.
A very simplified Proof-of-Work algorithm is implemented in Python in
@ -960,8 +951,8 @@ second, it still requires 10 minutes on a laptop to find this solution.
==== Target Representation
((("mining and consensus", "mining the block", "target
representation")))((("targets", id="targets10")))In <<block277316>>, we
saw that the block contains the target, in a notation called "target
representation")))((("targets", id="targets10")))
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
coefficient/exponent format, with the first two hexadecimal digits for
@ -1022,7 +1013,7 @@ Proof-of-Work algorithm. This leads to the obvious questions: Why is the
difficulty adjustable, who adjusts it, and how?
Bitcoin's blocks are generated every 10 minutes, on average. This is
bitcoin's heartbeat and underpins the frequency of currency issuance and
Bitcoin's heartbeat and underpins the frequency of currency issuance and
the speed of transaction settlement. It has to remain constant not just
over the short term, but over a period of many decades. Over this time,
it is expected that computer power will continue to increase at a rapid
@ -1091,7 +1082,6 @@ total time of the previous 2,015 blocks (not 2,016 as it should be),
resulting in a retargeting bias toward higher difficulty by 0.05%.
====
The parameters +Interval+ (2,016 blocks) and +TargetTimespan+ (two weeks
as 1,209,600 seconds) are defined in _chainparams.cpp_.
@ -1115,8 +1105,8 @@ by lowering or raising the target.
Note that the target is independent of the number of transactions or the
value of transactions. This means that the amount of hashing power and
therefore electricity expended to secure bitcoin is also entirely
independent of the number of transactions. Bitcoin can scale up, achieve
broader adoption, and remain secure without any increase in hashing
independent of the number of transactions. Bitcoin can scale up
and remain secure without any increase in hashing
power from today's level. The increase in hashing power represents
market forces as new miners enter the market to compete for the reward.
As long as enough hashing power is under the control of miners acting
@ -1174,7 +1164,7 @@ To remove the incentive to lie and strengthen the security of timelocks,
BIP113 was proposed and activated at the same time as the BIPs for
relative timelocks.
The median time past became the consensus
time and is used for all timelock calculations. By taking the midpoint
time used for all timelock calculations. By taking the midpoint
from approximately two hours in the past, the influence of any one
block's timestamp is reduced. By incorporating 11 blocks, no single
miner can influence the timestamps in order to gain fees from
@ -1201,7 +1191,7 @@ Jing's desktop transmits the block header to his mining hardware, which
starts testing trillions of nonces per second. Because the nonce is only
32 bits, after exhausting all the nonce possibilities (about 4 billion),
the mining hardware changes the block header (adjusting the coinbase
extra nonce space or timestamp) and resets the nonce counter, testing
extra nonce space, versionbits, or timestamp) and resets the nonce counter, testing
new combinations.
Almost 11 minutes after starting to mine a particular block, one of the
@ -1229,17 +1219,16 @@ startref="MACmining10")))((("", startref="jingtentwo")))
=== Validating a New Block
((("mining and consensus", "new block validation")))((("blocks", "new
block validation")))((("validation")))The third step in bitcoin's
block validation")))((("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 before propagating
it to its peers. This ensures that only valid blocks are propagated on
the network. The independent validation also ensures that miners who act
each node performs a series of tests to validate it.
The independent validation also ensures that miners who act
honestly get their blocks incorporated in the blockchain, thus earning
the reward. Those miners who act dishonestly have their blocks rejected
and not only lose the reward, but also waste the effort expended to find
a Proof-of-Work solution, thus incurring the cost of electricity without
compensation.
a Proof-of-Work solution, thus incurring all of the costs of creating a
block but receiving none of the rewards.
When a node receives a new block, it will validate the block by checking
it against a long list of criteria that must all be met; otherwise, the
@ -1265,7 +1254,7 @@ The independent validation of each new block by every node on the
network ensures that the miners cannot cheat. In previous sections we
saw how miners get to write a transaction that awards them the new
bitcoin created within the block and claim the transaction fees. Why
don't miners write themselves a transaction for a thousand bitcoin
don't miners write themselves a transaction for a thousand bitcoins
instead of the correct reward? Because every node validates blocks
according to the same rules. An invalid coinbase transaction would make
the entire block invalid, which would result in the block being rejected
@ -1280,15 +1269,15 @@ independent validation is a key component of decentralized consensus.
((("mining and consensus", "assembling and selecting chains of blocks",
id="MACassembling10")))((("blocks", "assembling and selecting chains
of", id="Bassemble10")))The final step in bitcoin's decentralized
of", id="Bassemble10")))The final step 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. Once a node has
validated a new block, it will then attempt to assemble a chain by
connecting the block to the existing blockchain.
Nodes maintain three sets of blocks: those connected to the best
blockchain, those that form branches off the best blockchain (stale
blocks), and finally. Invalid blocks are rejected as soon as any one
blockchain and those that form branches off the best blockchain (stale
blocks). Invalid blocks are rejected as soon as any one
of the validation criteria fails and are therefore not included in any
chain.
@ -1303,7 +1292,7 @@ chains is extended to exceed the best chain in work. In the next section
(<<forks>>), we will see how secondary chains occur as a result of an
almost simultaneous mining of blocks at the same height.
When a new block is received, a node will try to slot it into the
When a new block is received, a node will try to add it onto the
existing blockchain. The node will look at the block's "previous block
hash" field, which is the reference to the block's parent. Then, the
node will attempt to find that parent in the existing blockchain. Most
@ -1314,10 +1303,10 @@ Sometimes, as we will see in <<forks>>, the new block extends a chain
that is not the best chain. In that case, the node will attach the new
block to the secondary chain it extends and then compare the work of the
secondary chain to the best chain. If the secondary chain has more
cumulative work than the best chain, the node will _reconverge_ on the
secondary chain, meaning it will select the secondary chain as its new
cumulative work than the best chain, the node will _reorganize_ its
chain to use the secondary chain, meaning it will select the secondary chain as its new
best chain, making the old best chain a secondary chain. If the node is
a miner, it will now construct a block extending this new, longer,
a miner, it will now construct a candidate block extending this new, more-Proof of Work,
chain.
By selecting the greatest-cumulative-work valid chain, all nodes
@ -1342,9 +1331,9 @@ id="forks10")))Because the blockchain is a decentralized data structure,
different copies of it are not always consistent. Blocks might arrive at
different nodes at different times, causing the nodes to have different
perspectives of the blockchain. To resolve this, each node always
selects and attempts to extend the chain of blocks that represents the
most Proof-of-Work, also known as the longest chain or greatest
cumulative work chain. By summing the work recorded in each block in a
selects and attempts to extend the valid chain of blocks that contains the
most Proof-of-Work, also known as the _best blockchain_.
By summing the work recorded in each block in a
chain, a node can calculate the total amount of work that has been
expended to create that chain. As long as all nodes select the
greatest-cumulative-work chain, the global Bitcoin network eventually
@ -1382,7 +1371,7 @@ of the blockchain, with the star block as the tip of the best chain.
.Before the fork&#x2014;all nodes have the same perspective
image::images/mbc2_1002.png["Before the fork - all nodes have the same perspective"]
A "fork" occurs whenever there are two candidate blocks competing to
A "fork" occurs whenever there are two valid blocks competing to
form the longest blockchain. This occurs under normal conditions
whenever two miners solve the Proof-of-Work algorithm within a short
period of time from each other. As both miners discover a solution for
@ -1487,7 +1476,7 @@ to revise their view of the blockchain to incorporate the new evidence
of a longer chain. Any miners working on extending the chain
star-upside-down-triangle will now stop that work because their
candidate block is "stale," as its parent "upside-down-triangle" is
no longer on the longest chain. The transactions within
no longer on the best chain. The transactions within
"upside-down-triangle" that are not within "triangle" are re-inserted in
the mempool for inclusion in the next block to become a part of the best
chain. The entire network converges on a single blockchain
@ -1505,11 +1494,9 @@ image::images/mbc2_1005.png["Visualization of a blockchain fork event: a new blo
.Visualization of a blockchain fork event: the network reorganizes on a new longest chain
image::images/mbc2_1006.png["Visualization of a blockchain fork event: the network reorganizes on a new longest chain"]
It is theoretically possible for a fork to extend to two blocks, if two
It is possible for a fork to extend to two blocks, if two
blocks are found almost simultaneously by miners on opposite "sides" of
a previous fork. However, the chance of that happening is very low.
Whereas a one-block fork might occur every day, a two-block fork occurs
at most once every few weeks.
a previous fork. However, the chance of that happening is low.
Bitcoin's block interval of 10 minutes is a design compromise between
fast confirmation times and the probability
@ -1527,23 +1514,23 @@ secure. A malicious miner wanting to double spend that transaction
would need to do an amount of work equal to 10 minutes of the total
network hash rate in order to create a chain with equal proof of work.
Shorter times between blocks doesn't result in earlier settlement. It's
Shorter times between blocks doesn't result in earlier settlement. Its
only advantage is providing weaker guarantees to people who are willing
to accept those guarantees. For example, if you're willing to accept
three minutes of miners agreeing on the best block chain as sufficient
security, you'd prefer a system with 1-minute blocks, where you could
wait for there blocks, over a system with 10-minute blocks.
wait for three blocks, over a system with 10-minute blocks.
====
((("",
startref="Bassemble10")))((("", startref="MACassembling10")))((("",
startref="forks10")))((("", startref="BCTfork10")))
=== Mining and the Hashing Race
=== Mining and the Hashing Competition
((("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
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
using CPU mining to GPU mining and field programmable gate array (FPGA)
@ -1558,11 +1545,9 @@ leaps left in Bitcoin mining equipment,
because the industry has reached the forefront of Moore's Law, which
stipulates that computing density will double approximately every 18
months. Still, the mining power of the network continues to advance at
an exponential pace as the race for higher density chips is matched with
a race for higher density data centers where thousands of these chips
can be deployed. It's no longer about how much mining can be done with
one chip, but how many chips can be squeezed into a building, while
still dissipating the heat and providing adequate power.
a rapid pace as the race for higher density chips is matched with
a race for locations with lower electrical costs where these chips
can be deployed.
[[extra_nonce]]
==== The Extra Nonce Solution
@ -1583,7 +1568,9 @@ exceeding the TH/sec hash rate, the mining software needed more space
for nonce values in order to find valid blocks. The timestamp could be
stretched a bit, but moving it too far into the future would cause the
block to become invalid. A new source of "change" was needed in the
block header. The solution was to use the coinbase transaction as a
block header.
One solution that was widely implemented was to use the coinbase transaction as a
source of extra nonce values. Because the coinbase script can store
between 2 and 100 bytes of data, miners started using that space as
extra nonce space, allowing them to explore a much larger range of block
@ -1596,7 +1583,7 @@ modify the timestamp.
Another solution widely used today is to use up to 16 bits of the block
header versionbits field for mining, as described in BIP320. If each
piece of mining equimpent has its own coinbase transaction, this allows
piece of mining equipment has its own coinbase transaction, this allows
an individual piece of mining equipment to perform up to 281 TH/s by
only making changes to the block header. This keeps mining equipment
and protocols simpler than incrementing the extranonce in the coinbase
@ -1612,7 +1599,7 @@ 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
the fastest consumer ASIC mining system cannot keep up with commercial
systems that stack tens of thousands of these chips in giant warehouses
near hydroelectric powerstations. Miners now collaborate to form mining
near hydroelectric powerstations. Many miners now collaborate to form mining
pools, pooling their hashing power and sharing the reward among
thousands of participants. By participating in a pool, miners get a
smaller share of the overall reward, but typically get rewarded every
@ -1632,7 +1619,7 @@ same amount (not counting pool fees) as if they found an average block
on their own. The only fundamental difference is the frequency of the
payments they receive.
Mining pools coordinate many hundreds or thousands of miners, over
Mining pools coordinate many hundreds or thousands of miners over
specialized pool-mining protocols. The individual miners configure their
mining equipment to connect to a pool server, after creating an account
with the pool. Their mining hardware remains connected to the pool
@ -1655,14 +1642,14 @@ successfully mines a block, the reward is earned by the pool and then
shared with all miners in proportion to the number of shares they
contributed to the effort.
Pools are open to any miner, big or small, professional or amateur. A
Many pools are open to any miner, big or small, professional or amateur. A
pool will therefore have some participants with a single small mining
machine, and others with a garage full of high-end mining hardware. Some
will be mining with a few tens of a kilowatt of electricity, others will
be running a data center consuming a megawatt of power. How does a
be running a data center consuming megawatts of power. How does a
mining pool measure the individual contributions, so as to fairly
distribute the rewards, without the possibility of cheating? The answer
is to use bitcoin's Proof-of-Work algorithm to measure each pool miner's
is to use Bitcoin's Proof-of-Work algorithm to measure each pool miner's
contribution, but set at a lower difficulty so that even the smallest
pool miners win a share frequently enough to make it worthwhile to
contribute to the pool. By setting a lower difficulty for earning
@ -1707,24 +1694,17 @@ percentage fee of the earnings.
The pool server runs specialized software and a pool-mining protocol
that coordinate the activities of the pool miners. The pool server is
also connected to one or more full Bitcoin nodes and has direct access
to a full copy of the blockchain database. This allows the pool server
also connected to one or more full Bitcoin nodes.
This allows the pool server
to validate blocks and transactions on behalf of the pool miners,
relieving them of the burden of running a full node. For pool miners,
this is an important consideration, because a full node requires a
dedicated computer with at least 100 to 150 GB of persistent storage
(disk) and at least 2 to 4 GB of memory (RAM). Furthermore, the Bitcoin
software running on the full node needs to be monitored, maintained, and
upgraded frequently. Any downtime caused by a lack of maintenance or
lack of resources will hurt the miner's profitability. For many miners,
the ability to mine without running a full node is another big benefit
relieving them of the burden of running a full node.
For some miners,
the ability to mine without running a full node is another benefit
of joining a managed pool.
Pool miners connect to the pool server using a mining protocol such as
Stratum (STM) or GetBlockTemplate (GBT). An older standard called
GetWork (GWK) has been mostly obsolete since late 2012, because it does
not easily support mining at hash rates above 4 GH/s. Both the STM and
GBT protocols create block _templates_ that contain a template of a
Stratum (either version 1 or version 2).
Stratum v1 creates block _templates_ that contain a template of a
candidate block header. The pool server constructs a candidate block by
aggregating transactions, adding a coinbase transaction (with extra
nonce space), calculating the merkle root, and linking to the previous
@ -1734,10 +1714,14 @@ block template, at a higher (easier) target than the Bitcoin network
target, and sends any successful results back to the pool server to earn
shares.
Stratum v2 optionally allows individual miners in the pool to choose
which transactions appear in their own blocks, which they can select
using their own full node.
===== Peer-to-peer mining pool (P2Pool)
((("mining pools", "peer-to-peer pools (P2Pool)")))((("peer-to-peer
pools (P2Pool)")))Managed pools create the possibility of cheating by
pools (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
@ -1761,7 +1745,7 @@ pool miners who contributed to all the shares that preceded the winning
share block. Essentially, instead of a pool server keeping track of pool
miner shares and rewards, the share chain allows all pool miners to keep
track of all shares using a decentralized consensus mechanism like
bitcoin's blockchain consensus mechanism.
Bitcoin's blockchain consensus mechanism.
P2Pool mining is more complex than pool mining because it requires that
the pool miners run a dedicated computer with enough disk space, memory,
@ -1779,7 +1763,10 @@ Even though P2Pool reduces the concentration of power by mining pool
operators, it is conceivably vulnerable to 51% attacks against the share
chain itself. A much broader adoption of P2Pool does not solve the 51%
attack problem for bitcoin itself. Rather, P2Pool makes bitcoin more
robust overall, as part of a diversified mining ecosystem.((("",
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")))((("", startref="MACoverpool10")))
[[consensus_attacks]]
@ -1796,18 +1783,13 @@ can achieve a significant share of the mining power, they can attack the
consensus mechanism so as to disrupt the security and availability of
the Bitcoin network.
It is important to note that consensus attacks can only affect future
consensus, or at best, the most recent past (tens of blocks). Bitcoin's
It is important to note that consensus attacks have the greatest effect on future
consensus. Bitcoin's
ledger becomes more and more immutable as time passes. While in theory,
a fork can be achieved at any depth, in practice, the computing power
needed to force a very deep fork is immense, making old blocks
practically immutable. Consensus attacks also do not affect the security
of the private keys and signing algorithm (ECDSA). A consensus attack
cannot steal bitcoin, spend bitcoin without signatures, redirect
bitcoin, or otherwise change past transactions or ownership records.
((("denial-of-service attacks")))((("security", "denial-of-service
attacks")))Consensus attacks can only affect the most recent blocks and
cause denial-of-service disruptions on the creation of future blocks.
very hard to change. Consensus attacks also do not affect the security
of the private keys and signing algorithms.
One attack scenario against the consensus mechanism is called the "51%
attack." In this scenario a group of miners, controlling a majority
@ -1828,10 +1810,10 @@ 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 for a cup of coffee. Bob, the cafe owner, is
willing to accept payment for cups of coffee without waiting for
coffee")))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 cup of coffee is low in comparison to the convenience of rapid
a small item is low in comparison to the convenience of rapid
customer service. This is similar to the practice of coffee shops that
accept credit card payments without a signature for amounts below $25,
because the risk of a credit-card chargeback is low while the cost of
@ -1847,7 +1829,7 @@ the corresponding transaction in the old chain.
In our example, malicious attacker Mallory goes to ((("use cases",
"retail sales", id="carolten")))Carol's gallery and purchases a
beautiful triptych painting depicting Satoshi Nakamoto as Prometheus.
set of beautiful triptych paintings depicting Satoshi Nakamoto as Prometheus.
Carol sells "The Great Fire" paintings for $250,000 in bitcoin to
Mallory. Instead of waiting for six or more confirmations on the
transaction, Carol wraps and hands the paintings to Mallory after only
@ -1906,10 +1888,7 @@ Security research groups have used statistical modeling to claim that
various types of consensus attacks are possible with as little as 30% of
the hashing power.
The massive increase of total hashing power has arguably made bitcoin
impervious to attacks by a single miner. There is no possible way for a
solo miner to control more than a small percentage of the total mining
power. However, the centralization of control caused by mining pools has
The centralization of control caused by mining pools has
introduced the risk of for-profit attacks by a mining pool operator. The
pool operator in a managed pool controls the construction of candidate
blocks and also controls which transactions are included. This gives the
@ -1924,17 +1903,16 @@ network without the possibility of profiting from such disruption. A
malicious attack aimed at crippling bitcoin would require enormous
investment and covert planning, but could conceivably be launched by a
well-funded, most likely state-sponsored, attacker. Alternatively, a
well-funded attacker could attack bitcoin's consensus by simultaneously
well-funded attacker could attack Bitcoin's consensus by simultaneously
amassing mining hardware, compromising pool operators, and attacking
other pools with denial-of-service. All of these scenarios are
theoretically possible, but increasingly impractical as the Bitcoin
network's overall hashing power continues to grow exponentially.
theoretically possible.
Undoubtedly, a serious consensus attack would erode confidence in
bitcoin in the short term, possibly causing a significant price decline.
However, the Bitcoin network and software are constantly evolving, so
consensus attacks would be met with immediate countermeasures by the
bitcoin community, making bitcoin more robust.((("",
Bitcoin community, making Bitcoin more robust.((("",
startref="Cattack10")))((("", startref="MACattack10")))((("",
startref="Sconsens10")))
@ -1950,11 +1928,11 @@ network.
While the consensus rules are invariable in the short term and must be
consistent across all nodes, they are not invariable in the long term.
In order to evolve and develop the Bitcoin system, the rules have to
In order to evolve and develop the Bitcoin system, the rules can
change from time to time to accommodate new features, improvements, or
bug fixes. Unlike traditional software development, however, upgrades to
a consensus system are much more difficult and require coordination
between all the participants.
between all participants.
[[hard_forks]]
==== Hard Forks
@ -1969,8 +1947,8 @@ after one or more blocks are mined.
There is another scenario in which the network may diverge into
following two chains: a change in the consensus rules. This type of fork
is called a _hard fork_, because after the fork the network does not
converge onto a single chain. Instead, the two chains evolve
is called a _hard fork_, because after the fork the network may not
converge onto a single chain. Instead, the two chains can evolve
independently. Hard forks occur when part of the network is operating
under a different set of consensus rules than the rest of the network.
This may occur because of a bug or because of a deliberate change in the
@ -2004,8 +1982,9 @@ node running the new implementation creates a transaction that contains
a foocoin and a miner with the updated software mines block 7b
containing this transaction.
signatures is now unable to process block 7b. From their perspective,
both the transaction that contained a Foo signature and block 7b that
Any node or miner that has not upgraded the software to validate foocoin
is now unable to process block 7b. From their perspective,
both the transaction that contained a foocoin and block 7b that
contained that transaction are invalid, because they are evaluating them
based upon the old consensus rules. These nodes will reject the
transaction and the block and will not propagate them. Any miners that
@ -2040,8 +2019,8 @@ new software implementation of the consensus rules must be developed,
adopted, and launched.
Examples of software forks that have attempted to change consensus rules
include Bitcoin XT, Bitcoin Classic, and most recently Bitcoin
Unlimited. However, none of these software forks have resulted in a hard
include Bitcoin XT and Bitcoin Classic.
However, neither of those programs resulted in a hard
fork. While a software fork is a necessary precondition, it is not in
itself sufficient for a hard fork to occur. For a hard fork to occur,
the competing implementation must be adopted and the new rules
@ -2064,32 +2043,24 @@ used to store blocks.
Conceptually, we can think of a hard fork as developing in four stages:
a software fork, a network fork, a mining fork, and a chain fork.
The process begins when an alternative implementation of the client,
with modified consensus rules, is created by developers.
When this forked implementation is deployed in the network, a certain
percentage of miners, wallet users, and intermediate nodes may adopt and
run this implementation. A resulting fork will depend upon whether the
new consensus rules apply to blocks, transactions, or some other aspect
of the system. If the new consensus rules pertain to transactions, then
a wallet creating a transaction under the new rules may precipitate a
network fork, followed by a hard fork when the transaction is mined into
a block. If the new rules pertain to blocks, then the hard fork process
will begin when a block is mined under the new rules.
run this implementation.
First, the network will fork. Nodes based on the original implementation
of the consensus rules will reject any transactions and blocks that are
created under the new rules. Furthermore, the nodes following the
original consensus rules will temporarily ban and disconnect from any
original consensus rules may disconnect from any
nodes that are sending them these invalid transactions and blocks. As a
result, the network will partition into two: old nodes will only remain
result, the network may partition into two: old nodes will only remain
connected to old nodes and new nodes will only be connected to new
nodes. A single transaction or block based on the new rules will ripple
nodes. A single block based on the new rules will ripple
through the network and result in the partition into two networks.
Once a miner using the new rules mines a block, the mining power and
chain will also fork. New miners will mine on top of the new block,
chain will also fork. New miners may mine on top of the new block,
while old miners will mine a separate chain based on the old rules. The
partitioned network will make it so that the miners operating on
separate consensus rules won't likely receive each other's blocks, as
@ -2132,8 +2103,8 @@ transactions.
==== Contentious Hard Forks
((("forks", "changing consensus rules", "contentious hard
forks")))((("hard forks")))This is the dawn of consensus software
development. Just as open source development changed both the methods
forks")))((("hard forks")))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
represents a new frontier in computer science. Out of the debates,
@ -2151,8 +2122,7 @@ that do not have near-unanimous support are considered too "contentious"
to attempt without risking a partition of the system.
The issue of hard forks is highly controversial in the bitcoin
development community, especially as it relates to any proposed changes
to the consensus rules controlling the maximum block size limit. Some
development community. Some
developers are opposed to any form of hard fork, seeing it as too risky.
Others see the mechanism of hard fork as an essential tool for upgrading
the consensus rules in a way that avoids "technical debt" and provides a
@ -2162,7 +2132,7 @@ only under near-unanimous consensus.
Already we have seen the emergence of new methodologies to address the
risks of hard forks. In the next section, we will look at soft forks,
and the BIP34 and BIP9 methods for signaling and activation of
and the methods for signaling and activation of
consensus modifications.
==== Soft Forks
@ -2206,7 +2176,7 @@ A soft fork therefore can modify the semantics of a NOP code to give it
new meaning. For example, BIP65 (+CHECKLOCKTIMEVERIFY+) reinterpreted
the NOP2 opcode. Clients implementing BIP65 interpret NOP2 as
+OP_CHECKLOCKTIMEVERIFY+ and impose an absolute locktime consensus rule
on UTXO that contain this opcode in their locking scripts. This change
on UTXOs that contain this opcode in their locking scripts. This change
is a soft fork because a transaction that is valid under BIP65 is also
valid on any client that is not implementing (ignorant of) BIP65. To
the old clients, the script contains an NOP code, which is ignored.
@ -2236,7 +2206,7 @@ upgrades, as well as other soft fork upgrades.
Irreversible upgrades:: Because soft forks create transactions with
additional consensus constraints, they become irreversible upgrades in
practice. If a soft fork upgrade were to be reversed after beings
practice. If a soft fork upgrade were to be reversed after being
activated, any transactions created under the new rules could result in
a loss of funds under the old rules. For example, if a CLTV transaction
is evaluated under the old rules, there is no timelock constraint and it
@ -2249,12 +2219,12 @@ lead to loss of funds.((("", startref="Crule10")))
((("forks", "changing consensus rules", "soft fork
activation")))((("soft forks", "activation")))Since soft forks allow
unmodified clients to continue to operate within consensus, the
mechanism for "activating" a soft fork is through miners signaling
readiness: a majority of miners must agree that they are ready and
willing to enforce the new consensus rules. To coordinate their actions,
there is a signaling mechanism that allows them to show their support
for a consensus rule change. This mechanism was introduced with the
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
all miners enforce the new rules, there's no risk of unmodified
nodes accepting a block that upgraded nodes would reject.
This mechanism was introduced with the
activation of BIP34 in March 2013 and replaced by the activation of
BIP9 in July 2016.
@ -2320,6 +2290,7 @@ The standard is defined in
https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki[BIP34
(Block v2, Height in Coinbase)].
[[bip9]]
==== BIP9 Signaling and Activation
((("bitcoin improvement proposals", "Version bits with timeout and delay
@ -2431,9 +2402,9 @@ to enforce segwit for several months.
It was later discovered that some miners, especially miners associated
with the dissenters, may have been using hardware that gave them a
hidden advantage over other miners using a feature called _covert
ASICBoost_. Unintentionally, segwit interferred with the ability to use
covert ASICBoost---if segwit was activated, the miners would lose their
hidden advantage.
ASICBoost_. Unintentionally, segwit interfered with the ability to use
covert ASICBoost--if segwit was activated, the miners using it would
lose their hidden advantage.
After the community discovered this conflict of interest, some users
decided they wanted to exercise their power not to accept blocks from
@ -2446,11 +2417,11 @@ BIP148, which required any node implementing it to reject all blocks
that didn't signal for segwit starting on a certain date and continuing
until segwit activated.
Although only a limited number of users actually ran that code, many
Although only a limited number of users actually ran BIP148 code, many
other users seemed to agree with the sentiment and may have been
prepared to commit to BIP148. A few days before BIP148 was due to go
into effect, almost all miners began signaling their readiness to
enforce segwit's rules. Segwit reach its lock-in threshold about two
enforce segwit's rules. Segwit reached its lock-in threshold about two
weeks later and activated about two weeks after that.
Many users came to believe that it was a flaw in BIP9 that miners could
@ -2496,7 +2467,7 @@ _speedy trial_ by one of the people who helped promote it.
Speedy trial activation was tried, miners quickly signaled their
willingness to enforce the rules of taproot, and taproot was successful
activated about six months later. To proponents of speedy trial, it was
a clear success. Others were still disapointed that BIP8 wasn't used.
a clear success. Others were still disappointed that BIP8 wasn't used.
It's not clear whether or not speedy trial will be used again for a
future attempt to activate a soft fork.
@ -2510,13 +2481,13 @@ discussion on the various mechanisms for changing the consensus rules.
By its very nature, bitcoin sets a very high bar on coordination and
consensus for changes. As a decentralized system, it has no "authority"
that can impose its will on the participants of the network. Power is
diffused between multiple constituencies such as miners, core
diffused between multiple constituencies such as miners, protocol
developers, wallet developers, exchanges, merchants, and end users.
Decisions cannot be made unilaterally by any of these constituencies.
For example, while miners can theoretically change the rules by simple
For example, while miners can censor transactions by simple
majority (51%), they are constrained by the consent of the other
constituencies. If they act unilaterally, the rest of the participants
may simply refuse to follow them, keeping the economic activity on a
may refuse to accept their blocks, keeping the economic activity on a
minority chain. Without economic activity (transactions, merchants,
wallets, exchanges), the miners will be mining a worthless coin with
empty blocks. This diffusion of power means that all the participants
@ -2534,4 +2505,4 @@ consensus software development is that change is difficult and consensus
forces compromise.
Some see this as a weakness of consensus systems. In time, you may come
to see it as I do, as the system's greatest strength.
to see it as the system's greatest strength.

Write Preview
Loading…
Cancel
Save