|
|
[[mining]]
|
|
|
== Mining and Consensus
|
|
|
|
|
|
[[mtp]]
|
|
|
=== Median Time Past (MTP)
|
|
|
|
|
|
((("scripting", "timelocks",
|
|
|
"Median-Tme-Past")))((("Median-Tme-Past")))((("timelocks",
|
|
|
"Median-Tme-Past")))As part of the activation of relative timelocks,
|
|
|
there was also a change in the way "time" is calculated for timelocks
|
|
|
(both absolute and relative). In bitcoin there is a subtle, but very
|
|
|
significant, difference between wall time and consensus time. Bitcoin is
|
|
|
a decentralized network, which means that each participant has his or
|
|
|
her own perspective of time. Events on the network do not occur
|
|
|
instantaneously everywhere. Network latency must be factored into the
|
|
|
perspective of each node. Eventually everything is synchronized to
|
|
|
create a common ledger. Bitcoin reaches consensus every 10 minutes about
|
|
|
the state of the ledger as it existed in the _past_.
|
|
|
|
|
|
The timestamps set in block headers are set by the miners. There is a
|
|
|
certain degree of latitude allowed by the consensus rules to account for
|
|
|
differences in clock accuracy between decentralized nodes. However, this
|
|
|
creates an unfortunate incentive for miners to lie about the time in a
|
|
|
block so as to earn extra fees by including timelocked transactions that
|
|
|
are not yet mature. See the following section for more information.
|
|
|
|
|
|
To remove the incentive to lie and strengthen the security of timelocks,
|
|
|
a BIP was proposed and activated at the same time as the BIPs for
|
|
|
relative timelocks. This is BIP113, which defines a new consensus
|
|
|
measurement of time called _Median-Time-Past_.
|
|
|
|
|
|
Median-Time-Past is calculated by taking the timestamps of the last 11
|
|
|
blocks and finding the median. That median time then becomes consensus
|
|
|
time and is 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
|
|
|
transactions with a timelock that hasn't yet matured.
|
|
|
|
|
|
Median-Time-Past changes the implementation of time calculations for
|
|
|
+nLocktime+, +CLTV+, +nSequence+, and +CSV+. The consensus time
|
|
|
calculated by Median-Time-Past is always approximately one hour behind
|
|
|
wall clock time. If you create timelock transactions, you should account
|
|
|
for it when estimating the desired value to encode in +nLocktime+,
|
|
|
+nSequence+, +CLTV+, and +CSV+.
|
|
|
|
|
|
Median-Time-Past is specified in
|
|
|
https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki[BIP113].
|
|
|
|
|
|
[[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
|
|
|
block. Although mining is incentivized by this reward, the primary
|
|
|
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
|
|
|
basis for P2P digital cash.
|
|
|
|
|
|
((("mining and consensus", "decentralized consensus")))((("central
|
|
|
trusted authority")))Mining _secures the Bitcoin system_ and enables the
|
|
|
emergence of network-wide _consensus without a central authority_.
|
|
|
((("fees", "transaction fees")))The reward of newly minted coins and
|
|
|
transaction fees is an incentive scheme that aligns the actions of
|
|
|
miners with the security of the network, while simultaneously
|
|
|
implementing the monetary supply.
|
|
|
|
|
|
[TIP]
|
|
|
====
|
|
|
((("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_.
|
|
|
====
|
|
|
|
|
|
Miners record new transactions on the global ledger. A
|
|
|
new block, containing transactions that occurred since the last block,
|
|
|
is "mined" every 10 minutes on average, thereby adding those
|
|
|
transactions to the blockchain. Transactions that become part of a block
|
|
|
and added to the blockchain are considered "confirmed," which allows the
|
|
|
new owners of bitcoin to know that irrevocable effort was expended
|
|
|
securing the bitcoin they received in those
|
|
|
transactions.
|
|
|
|
|
|
((("fees", "mining rewards")))((("mining and consensus", "mining rewards
|
|
|
and fees")))((("Proof-of-Work algorithm")))((("mining and consensus",
|
|
|
"Proof-of-Work algorithm")))Miners receive two types of rewards in
|
|
|
return for the security provided by mining: new coins created with each
|
|
|
new block (called the _subsidy_), and transaction fees from all the transactions included in
|
|
|
the block. To earn this reward, miners compete to satisfy a challenge
|
|
|
based on a cryptographic hash algorithm. The
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
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
|
|
|
exponentially until approximately the year 2140, when all bitcoin
|
|
|
(20.99999998 million) 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
|
|
|
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
|
|
|
from fees. Gradually, the mining reward will be dominated by transaction
|
|
|
fees, which will form the primary incentive for miners. After 2140, the
|
|
|
amount of new bitcoin in each block drops to zero and bitcoin mining
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
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
|
|
|
|
|
|
((("mining and consensus", "bitcoin economics and currency
|
|
|
creation")))((("currency creation")))((("money supply")))((("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 bitcoin, created from nothing. Every
|
|
|
210,000 blocks, or approximately every four years, the currency issuance
|
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
|
|
|
[[bitcoin_money_supply]]
|
|
|
.Supply of bitcoin currency over time based on a geometrically decreasing issuance rate
|
|
|
image::images/mbc2_1001.png["BitcoinMoneySupply"]
|
|
|
|
|
|
[NOTE]
|
|
|
====
|
|
|
The maximum number of coins mined is the _upper limit_ of possible
|
|
|
mining rewards for bitcoin. In practice, a miner may intentionally mine
|
|
|
a block taking less than the full reward. Such blocks have already been
|
|
|
mined and more may be mined in the future, resulting in a lower total
|
|
|
issuance of the currency.
|
|
|
====
|
|
|
|
|
|
In the example code in <<max_money>>, we calculate the total amount of
|
|
|
bitcoin that will be issued.
|
|
|
|
|
|
[[max_money]]
|
|
|
.A script for calculating how much total bitcoin will be issued
|
|
|
====
|
|
|
[source, python]
|
|
|
----
|
|
|
include::code/max_money.py[]
|
|
|
----
|
|
|
====
|
|
|
|
|
|
<<max_money_run>> shows the output produced by running this script.
|
|
|
|
|
|
[[max_money_run]]
|
|
|
.Running the max_money.py script
|
|
|
====
|
|
|
[source,bash]
|
|
|
----
|
|
|
$ python max_money.py
|
|
|
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.
|
|
|
|
|
|
.Deflationary Money
|
|
|
****
|
|
|
((("deflationary money")))The most important and debated consequence of
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
deflation, people tend to hoard money instead of spending it, hoping
|
|
|
that prices will fall. Such a phenomenon unfolded during Japan's "Lost
|
|
|
Decade," when a complete collapse of demand pushed the currency into a
|
|
|
deflationary spiral.
|
|
|
|
|
|
Bitcoin experts argue that deflation is not bad per se. Rather,
|
|
|
deflation is associated with a collapse in demand because that is the
|
|
|
only example of deflation we have to study. In a fiat currency with the
|
|
|
possibility of unlimited printing, it is very difficult to enter a
|
|
|
deflationary spiral unless there is a complete collapse in demand and an
|
|
|
unwillingness to print money. Deflation in bitcoin is not caused by a
|
|
|
collapse in demand, but by a predictably constrained supply.
|
|
|
|
|
|
The positive aspect of deflation, of course, is that it is the opposite
|
|
|
of inflation. Inflation causes a slow but inevitable debasement of
|
|
|
currency, resulting in a form of hidden taxation that punishes savers in
|
|
|
order to bail out debtors (including the biggest debtors, governments
|
|
|
themselves). Currencies under government control suffer from the moral
|
|
|
hazard of easy debt issuance that can later be erased through debasement
|
|
|
at the expense of savers.
|
|
|
|
|
|
It remains to be seen whether the deflationary aspect of the currency is
|
|
|
a problem when it is not driven by rapid economic retraction, or an
|
|
|
advantage because the protection from inflation and debasement far
|
|
|
outweighs the risks of deflation.
|
|
|
****
|
|
|
|
|
|
=== Decentralized Consensus
|
|
|
|
|
|
((("mining and consensus", "decentralized consensus")))((("decentralized
|
|
|
systems", "consensus in")))In the previous chapter we looked at the
|
|
|
blockchain, the global public ledger (list) of all transactions, which
|
|
|
everyone in the Bitcoin network accepts as the authoritative record of
|
|
|
ownership.
|
|
|
|
|
|
But how can everyone in the network agree on a single universal "truth"
|
|
|
about who owns what, without having to trust anyone? All traditional
|
|
|
payment systems depend on a trust model that has a central authority
|
|
|
providing a clearinghouse service, basically verifying and clearing all
|
|
|
transactions. Bitcoin has no central authority, yet somehow every full
|
|
|
node has a complete copy of a public ledger that it can trust as the
|
|
|
authoritative record. The blockchain is not created by a central
|
|
|
authority, but is assembled independently by every node in the network.
|
|
|
Somehow, every node in the network, acting on information transmitted
|
|
|
across insecure network connections, can arrive at the same conclusion
|
|
|
and assemble a copy of the same public ledger as everyone else. This
|
|
|
chapter examines the process by which the Bitcoin network achieves
|
|
|
global consensus without central authority.
|
|
|
|
|
|
((("emergent consensus")))((("mining and consensus", "emergent
|
|
|
consensus")))Satoshi Nakamoto's main invention 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
|
|
|
interaction of thousands of independent nodes, all following simple
|
|
|
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.
|
|
|
|
|
|
Bitcoin's decentralized consensus emerges from the interplay of four
|
|
|
processes that occur independently on nodes across the network:
|
|
|
|
|
|
[role="pagebreak-before"]
|
|
|
- Independent verification of each transaction, by every full node,
|
|
|
based on a comprehensive list of criteria
|
|
|
|
|
|
- Independent aggregation of those transactions into new blocks by
|
|
|
mining nodes, coupled with demonstrated computation through a
|
|
|
Proof-of-Work algorithm
|
|
|
|
|
|
- Independent verification of the new blocks by every node and assembly
|
|
|
into a chain
|
|
|
|
|
|
- Independent selection, by every node, of the chain with the most
|
|
|
cumulative computation demonstrated through Proof-of-Work
|
|
|
|
|
|
In the next few sections we will examine these processes and how they
|
|
|
interact to create the emergent property of network-wide consensus that
|
|
|
allows any Bitcoin node to assemble its own copy of the authoritative,
|
|
|
trusted, public, global ledger.
|
|
|
|
|
|
[[tx_verification]]
|
|
|
=== Independent Verification of Transactions
|
|
|
|
|
|
((("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
|
|
|
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.
|
|
|
|
|
|
However, before forwarding transactions to its neighbors, every Bitcoin
|
|
|
node that receives a transaction will first verify the transaction. This
|
|
|
ensures that only valid transactions are propagated across the network,
|
|
|
while invalid transactions are discarded at the first node that
|
|
|
encounters them.
|
|
|
|
|
|
Each node verifies every transaction against a long checklist of
|
|
|
criteria:
|
|
|
|
|
|
- The transaction's syntax and data structure must be correct.
|
|
|
|
|
|
- Neither lists of inputs or outputs are empty.
|
|
|
|
|
|
- The transaction size in bytes is less than +MAX_BLOCK_SIZE+.
|
|
|
|
|
|
- Each output value, as well as the total, must be within the allowed
|
|
|
range of values (less than 21m coins, more than the _dust_ threshold).
|
|
|
|
|
|
- None of the inputs have hash=0, N=–1 (coinbase transactions should not
|
|
|
be relayed).
|
|
|
|
|
|
- +nLocktime+ is equal to +INT_MAX+, or +nLocktime+ and +nSequence+
|
|
|
values are satisfied according to +MedianTimePast+.
|
|
|
|
|
|
- The transaction size in bytes is greater than or equal to 100.
|
|
|
|
|
|
- The number of signature operations (SIGOPS) contained in the
|
|
|
transaction is less than the signature operation limit.
|
|
|
|
|
|
- The unlocking script (+scriptSig+) can only push numbers on the stack,
|
|
|
and the locking script (+scriptPubkey+) must match +IsStandard+ forms
|
|
|
(this rejects "nonstandard" transactions).
|
|
|
|
|
|
- A matching transaction in the pool, or in a block in the main branch,
|
|
|
must exist.
|
|
|
|
|
|
- For each input, if the referenced output exists in any other
|
|
|
transaction in the pool, the transaction must be rejected.
|
|
|
|
|
|
- For each input, look in the main branch and the transaction pool to
|
|
|
find the referenced output transaction. If the output transaction is
|
|
|
missing for any input, this will be an orphan transaction. Add to the
|
|
|
orphan transactions pool, if a matching transaction is not already in
|
|
|
the pool.
|
|
|
|
|
|
- For each input, if the referenced output transaction is a coinbase
|
|
|
output, it must have at least +COINBASE_MATURITY+ (100) confirmations.
|
|
|
|
|
|
- For each input, the referenced output must exist and cannot already be
|
|
|
spent.
|
|
|
|
|
|
- Using the referenced output transactions to get input values, check
|
|
|
that each input value, as well as the sum, are in the allowed range of
|
|
|
values (less than 21m coins, more than 0).
|
|
|
|
|
|
- Reject if the sum of input values is less than sum of output values.
|
|
|
|
|
|
- Reject if transaction fee would be too low (+minRelayTxFee+) to get
|
|
|
into an empty block.
|
|
|
|
|
|
- The unlocking scripts for each input must validate against the
|
|
|
corresponding output locking 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.
|
|
|
|
|
|
By independently verifying each transaction as it is received and before
|
|
|
propagating it, every node builds a pool of valid (but unconfirmed)
|
|
|
transactions known as the _transaction pool_, _memory pool_, or
|
|
|
_mempool_.
|
|
|
|
|
|
=== Mining Nodes
|
|
|
|
|
|
((("mining and consensus", "mining nodes")))((("Bitcoin nodes", "mining
|
|
|
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
|
|
|
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.
|
|
|
Unlike Jing, some miners mine without a full node, as we will see in
|
|
|
<<mining_pools>>. Like every other full node, Jing's node receives and
|
|
|
propagates unconfirmed transactions on the Bitcoin network. Jing's node,
|
|
|
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
|
|
|
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
|
|
|
round of a competition is also the beginning of the next round. The new
|
|
|
block is not just a checkered flag, marking the end of the race; it is
|
|
|
also the starting pistol in the race for the next block.
|
|
|
|
|
|
=== Aggregating Transactions into Blocks
|
|
|
|
|
|
((("mining and consensus", "aggregating transactions into blocks",
|
|
|
id="MACaggreg10")))((("transactions", "aggregating into blocks",
|
|
|
id="Taggreg10")))((("blocks", "aggregating transactions into",
|
|
|
id="Baggreg10")))((("blocks", "candidate blocks")))((("candidate
|
|
|
blocks")))((("transaction pools")))((("memory pools (mempools)")))After
|
|
|
validating transactions, a Bitcoin node will add them to the _memory
|
|
|
pool_, or _transaction pool_, where transactions await until they can be
|
|
|
included (mined) into a block. Jing's node collects, validates, and
|
|
|
relays new transactions just like any other node. Unlike other nodes,
|
|
|
however, Jing's node will then aggregate these transactions into a
|
|
|
_candidate block_.
|
|
|
|
|
|
Let's follow the blocks that were created during the time Alice bought a
|
|
|
cup of coffee from Bob's Cafe (see <<spending_bitcoin>>). Alice's
|
|
|
transaction was included in block 277,316. For the purpose of
|
|
|
demonstrating the concepts in this chapter, let's assume that block was
|
|
|
mined by Jing's mining system and follows Alice's transaction as it
|
|
|
becomes part of this new block.
|
|
|
|
|
|
Jing's mining node maintains a local copy of the blockchain. By the time
|
|
|
((("use cases", "buying coffee")))Alice buys the cup of coffee, Jing's
|
|
|
node has assembled a chain up to block 277,314. Jing's node is listening
|
|
|
for transactions, trying to mine a new block and also listening for
|
|
|
blocks discovered by other nodes. As Jing's node is mining, it receives
|
|
|
block 277,315 through the Bitcoin network. The arrival of this block
|
|
|
signifies the end of the competition for block 277,315 and the beginning
|
|
|
of the competition to create block 277,316.
|
|
|
|
|
|
During the previous 10 minutes, while Jing's node was searching for a
|
|
|
solution to block 277,315, it was also collecting transactions in
|
|
|
preparation for the next block. By now it has collected a few hundred
|
|
|
transactions in the memory pool. Upon receiving block 277,315 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 277,315. 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
|
|
|
algorithm")))Jing's node immediately constructs a new empty block, a
|
|
|
candidate for block 277,316. 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
|
|
|
finding a solution to the Proof-of-Work algorithm.
|
|
|
|
|
|
When Jing's node aggregates all the transactions from the memory pool,
|
|
|
the new candidate block has 418 transactions with total transaction fees
|
|
|
of 0.09094928 bitcoin. You can see this block in the blockchain using
|
|
|
the Bitcoin Core client command-line interface, as shown in
|
|
|
<<block277316>>.
|
|
|
|
|
|
[[block277316]]
|
|
|
.Using the command line to retrieve block 277,316
|
|
|
====
|
|
|
[source,bash]
|
|
|
----
|
|
|
$ bitcoin-cli getblockhash 277316
|
|
|
|
|
|
0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
|
|
|
|
|
|
$ bitcoin-cli getblock 0000000000000001b6b9a13b095e96db41c4a928b97ef2d9\
|
|
|
44a9b31b2cc7bdc4
|
|
|
----
|
|
|
|
|
|
|
|
|
[source,json]
|
|
|
----
|
|
|
{
|
|
|
"hash" : "0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4",
|
|
|
"confirmations" : 35561,
|
|
|
"size" : 218629,
|
|
|
"height" : 277316,
|
|
|
"version" : 2,
|
|
|
"merkleroot" : "c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e",
|
|
|
"tx" : [
|
|
|
"d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f",
|
|
|
"b268b45c59b39d759614757718b9918caf0ba9d97c56f3b91956ff877c503fbe",
|
|
|
|
|
|
... 417 more transactions ...
|
|
|
|
|
|
],
|
|
|
"time" : 1388185914,
|
|
|
"nonce" : 924591752,
|
|
|
"bits" : "1903a30c",
|
|
|
"difficulty" : 1180923195.25802612,
|
|
|
"chainwork" : "000000000000000000000000000000000000000000000934695e92aaf53afa1a",
|
|
|
"previousblockhash" : "0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569"
|
|
|
}
|
|
|
----
|
|
|
====
|
|
|
|
|
|
==== The Coinbase Transaction
|
|
|
|
|
|
((("coinbase transactions", id="coinbtrans10")))((("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 contains his _reward_ for
|
|
|
the mining effort.
|
|
|
|
|
|
[NOTE]
|
|
|
====
|
|
|
When block 277,316 was mined, the reward was 25 bitcoin per block. Since
|
|
|
then, one "halving" period has elapsed. The block reward changed to 12.5
|
|
|
bitcoin in July 2016. It will be halved again in 210,000 blocks, in the
|
|
|
year 2020.
|
|
|
====
|
|
|
|
|
|
Jing's node creates the coinbase transaction as a payment to his own
|
|
|
wallet: "Pay Jing's address 25.09094928 bitcoin." The total amount of
|
|
|
reward that Jing collects for mining a block is the sum of the coinbase
|
|
|
reward (25 new bitcoin) and the transaction fees (0.09094928) from all
|
|
|
the transactions included in the block as shown in
|
|
|
<<generation_tx_example>>.
|
|
|
|
|
|
|
|
|
[[generation_tx_example]]
|
|
|
.Coinbase transaction
|
|
|
====
|
|
|
----
|
|
|
$ bitcoin-cli getrawtransaction d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f 1
|
|
|
----
|
|
|
|
|
|
[source,json]
|
|
|
[role="c_less_space"]
|
|
|
----
|
|
|
{
|
|
|
"hex" : "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0f03443b0403858402062f503253482fffffffff0110c08d9500000000232102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac00000000",
|
|
|
"txid" : "d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f",
|
|
|
"version" : 1,
|
|
|
"locktime" : 0,
|
|
|
"vin" : [
|
|
|
{
|
|
|
"coinbase" : "03443b0403858402062f503253482f",
|
|
|
"sequence" : 4294967295
|
|
|
}
|
|
|
],
|
|
|
"vout" : [
|
|
|
{
|
|
|
"value" : 25.09094928,
|
|
|
"n" : 0,
|
|
|
"scriptPubKey" : {
|
|
|
"asm" : "02aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21OP_CHECKSIG",
|
|
|
"hex" : "2102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac",
|
|
|
"reqSigs" : 1,
|
|
|
"type" : "pubkey",
|
|
|
"addresses" : [
|
|
|
"1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N"
|
|
|
]
|
|
|
}
|
|
|
}
|
|
|
]
|
|
|
}
|
|
|
----
|
|
|
====
|
|
|
|
|
|
Unlike regular transactions, the coinbase transaction does not consume
|
|
|
(spend) UTXO as inputs. Instead, it has only one input, called the
|
|
|
_coinbase_, which creates bitcoin from nothing. The coinbase transaction
|
|
|
has one output, payable to the miner's own Bitcoin address. The output
|
|
|
of the coinbase transaction sends the value of 25.09094928 bitcoin to
|
|
|
the miner's Bitcoin address; in this case it is
|
|
|
+1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N+.
|
|
|
|
|
|
==== Coinbase Reward and Fees
|
|
|
|
|
|
((("coinbase transactions", "rewards and fees")))((("fees", "transaction
|
|
|
fees")))((("mining and consensus", "rewards and fees")))To construct the
|
|
|
coinbase transaction, Jing's node first calculates the total amount of
|
|
|
transaction fees by adding all the inputs and outputs of the 418
|
|
|
transactions that were added to the block. The fees are calculated as:
|
|
|
|
|
|
----
|
|
|
Total Fees = Sum(Inputs) - Sum(Outputs)
|
|
|
----
|
|
|
|
|
|
In block 277,316, the total transaction fees are 0.09094928 bitcoin.
|
|
|
|
|
|
Next, Jing's node calculates the correct reward for the new block. The
|
|
|
reward is calculated based on the block height, starting at 50 bitcoin
|
|
|
per block and reduced by half every 210,000 blocks. Because this block
|
|
|
is at height 277,316, the correct reward is 25 bitcoin.
|
|
|
|
|
|
The calculation can be seen in function +GetBlockSubsidy+ in the Bitcoin
|
|
|
Core client, as shown in <<getblocksubsidy_source>>.
|
|
|
|
|
|
[[getblocksubsidy_source]]
|
|
|
.Calculating the block reward—Function GetBlockSubsidy, Bitcoin Core Client, main.cpp
|
|
|
====
|
|
|
[role="c_less_space"]
|
|
|
[source, cpp]
|
|
|
----
|
|
|
CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
|
|
|
{
|
|
|
int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
|
|
|
// Force block reward to zero when right shift is undefined.
|
|
|
if (halvings >= 64)
|
|
|
return 0;
|
|
|
|
|
|
CAmount nSubsidy = 50 * COIN;
|
|
|
// Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
|
|
|
nSubsidy >>= halvings;
|
|
|
return nSubsidy;
|
|
|
}
|
|
|
----
|
|
|
====
|
|
|
|
|
|
The initial subsidy is calculated in satoshis by multiplying 50 with the
|
|
|
+COIN+ constant (100,000,000 satoshis). This sets the initial reward
|
|
|
(+nSubsidy+) at 5 billion satoshis.
|
|
|
|
|
|
((("halvings")))Next, the function calculates the number of +halvings+
|
|
|
that have occurred by dividing the current block height by the halving
|
|
|
interval (+SubsidyHalvingInterval+). In the case of block 277,316, with
|
|
|
a halving interval every 210,000 blocks, the result is 1 halving.
|
|
|
|
|
|
The maximum number of halvings allowed is 64, so the code imposes a zero
|
|
|
reward (returns only the fees) if the 64 halvings is exceeded.
|
|
|
|
|
|
Next, the function uses the binary-right-shift operator to divide the
|
|
|
reward (+nSubsidy+) by two for each round of halving. In the case of
|
|
|
block 277,316, this would binary-right-shift the reward of 5 billion
|
|
|
satoshis once (one halving) and result in 2.5 billion satoshis, or 25
|
|
|
bitcoins. The binary-right-shift operator is used because it is more
|
|
|
efficient than multiple repeated divisions. To avoid a potential bug,
|
|
|
the shift operation is skipped after 63 halvings, and the subsidy is set
|
|
|
to 0.
|
|
|
|
|
|
Finally, the coinbase reward (+nSubsidy+) is added to the transaction
|
|
|
fees (+nFees+), and the sum is returned.
|
|
|
|
|
|
[TIP]
|
|
|
====
|
|
|
If Jing's mining node writes the coinbase transaction, what stops Jing
|
|
|
from "rewarding" himself 100 or 1000 bitcoin? The answer is that an
|
|
|
incorrect reward would result in the block being deemed invalid by
|
|
|
everyone else, wasting Jing's electricity used for Proof-of-Work. Jing
|
|
|
only gets to spend the reward if the block is accepted by everyone.
|
|
|
====
|
|
|
|
|
|
==== Structure of the Coinbase Transaction
|
|
|
|
|
|
((("coinbase transactions", "structure of")))With these calculations,
|
|
|
Jing's node then constructs the coinbase transaction to pay himself
|
|
|
25.09094928 bitcoin.
|
|
|
|
|
|
As you can see in <<generation_tx_example>>, the coinbase transaction
|
|
|
has a special format. Instead of a transaction input specifying a
|
|
|
previous UTXO to spend, it has a "coinbase" input. We examined
|
|
|
transaction inputs in <<inputs>>. Let's compare a regular transaction
|
|
|
input with a coinbase transaction input. <<table_8-1>> shows the
|
|
|
structure of a regular transaction, while <<table_8-2>> shows the
|
|
|
structure of the coinbase transaction's input.
|
|
|
|
|
|
[[table_8-1]]
|
|
|
.The structure of a "normal" transaction input
|
|
|
[options="header"]
|
|
|
|=======
|
|
|
|Size| Field | Description
|
|
|
| 32 bytes | Transaction Hash | Pointer to the transaction containing the UTXO to be spent
|
|
|
| 4 bytes | Output Index | The index number of the UTXO to be spent, first one is 0
|
|
|
| 1–9 bytes (VarInt) | Unlocking-Script Size | Unlocking-Script length in bytes, to follow
|
|
|
| Variable | Unlocking-Script | A script that fulfills the conditions of the UTXO locking script
|
|
|
| 4 bytes | Sequence Number | Currently disabled Tx-replacement feature, set to 0xFFFFFFFF
|
|
|
|=======
|
|
|
|
|
|
[[table_8-2]]
|
|
|
.The structure of a coinbase transaction input
|
|
|
[options="header"]
|
|
|
|=======
|
|
|
|Size| Field | Description
|
|
|
| 32 bytes | Transaction Hash | All bits are zero: Not a transaction hash reference
|
|
|
| 4 bytes | Output Index | All bits are ones: 0xFFFFFFFF
|
|
|
| 1–9 bytes (VarInt) | Coinbase Data Size | Length of the coinbase data, from 2 to 100 bytes
|
|
|
| Variable | Coinbase Data | Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height
|
|
|
| 4 bytes | Sequence Number | Set to 0xFFFFFFFF
|
|
|
|=======
|
|
|
|
|
|
In a coinbase transaction, the first two fields are set to values that
|
|
|
do not represent a UTXO reference. Instead of a "transaction hash," the
|
|
|
first field is filled with 32 bytes all set to zero. The "output index"
|
|
|
is filled with 4 bytes all set to 0xFF (255 decimal). The "Unlocking
|
|
|
Script" (+scriptSig+) is replaced by coinbase data, a data field used by
|
|
|
the miners, as we will see next.
|
|
|
|
|
|
==== Coinbase Data
|
|
|
|
|
|
((("coinbase transactions", "coinbase data")))Coinbase transactions do
|
|
|
not have an unlocking script (aka, +scriptSig+) field. Instead, this
|
|
|
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.
|
|
|
|
|
|
((("nonce values")))((("blocks", "genesis block")))((("blockchain
|
|
|
(the)", "genesis block")))((("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 date and to convey a message. Currently,
|
|
|
miners 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
|
|
|
"push" operation in the beginning of the coinbase field.
|
|
|
|
|
|
In block 277,316 we see that the coinbase (see
|
|
|
<<generation_tx_example>>), which is in the unlocking script or
|
|
|
+scriptSig+ field of the transaction input, contains the hexadecimal
|
|
|
value +03443b0403858402062f503253482f+. Let's decode this value.
|
|
|
|
|
|
The first byte, +03+, instructs the script execution engine to push the
|
|
|
next three bytes onto the script stack (see
|
|
|
<<tx_script_ops_table_pushdata>>). The next three bytes, +0x443b04+, are
|
|
|
the block height encoded in little-endian format (backward,
|
|
|
least-significant byte first). Reverse the order of the bytes and the
|
|
|
result is +0x043b44+, which is 277,316 in decimal.
|
|
|
|
|
|
The next few hexadecimal digits (+0385840206+) are used to encode an
|
|
|
extra _nonce_ (see <<extra_nonce>>), or random value, used to find a
|
|
|
suitable Proof-of-Work solution.
|
|
|
|
|
|
((("bitcoin improvement proposals", "Pay to Script Hash
|
|
|
(BIP16)")))((("bitcoin improvement proposals", "CHECKHASHVERIFY
|
|
|
(BIP17)")))((("CHECKHASHVERIFY (CHV)")))((("Pay-to-Script-Hash (P2SH)",
|
|
|
"coinbase data")))The final part of the coinbase data (+2f503253482f+)
|
|
|
is the ASCII-encoded string pass:[<span
|
|
|
class="keep-together"><code>/P2SH/</code></span>], which indicates that
|
|
|
the mining node that mined this block supports the P2SH improvement
|
|
|
defined in BIP16. The introduction of the P2SH capability required
|
|
|
signaling by miners to endorse either BIP16 or BIP17. Those endorsing
|
|
|
the BIP16 implementation were to include +/P2SH/+ in their coinbase
|
|
|
data. Those endorsing the BIP17 implementation of P2SH were to include
|
|
|
the string +p2sh/CHV+ in their coinbase data. The BIP16 was elected as
|
|
|
the winner, and many miners continued including the string +/P2SH/+ in
|
|
|
their coinbase to indicate support for this feature.
|
|
|
|
|
|
<<satoshi_words>> uses the libbitcoin library introduced in
|
|
|
<<alt_libraries>> to extract the coinbase data from the genesis block,
|
|
|
displaying Satoshi's message. Note that the libbitcoin library contains
|
|
|
a static copy of the genesis block, so the example code can retrieve the
|
|
|
genesis block directly from the library.
|
|
|
|
|
|
[[satoshi_words]]
|
|
|
.Extract the coinbase data from the genesis block
|
|
|
====
|
|
|
[source, cpp]
|
|
|
----
|
|
|
include::code/satoshi-words.cpp[]
|
|
|
----
|
|
|
====
|
|
|
|
|
|
We compile the code with the GNU C++ compiler and run the resulting
|
|
|
executable, as shown in <<satoshi_words_run>>.((("",
|
|
|
startref="MACaggreg10")))((("", startref="Baggreg10")))((("",
|
|
|
startref="Taggreg10")))((("", startref="Tcoinb10")))((("",
|
|
|
startref="coinbtrans10")))
|
|
|
|
|
|
[[satoshi_words_run]]
|
|
|
.Compiling and running the satoshi-words example code
|
|
|
====
|
|
|
[source,bash]
|
|
|
----
|
|
|
$ # Compile the code
|
|
|
$ g++ -o satoshi-words satoshi-words.cpp $(pkg-config --cflags --libs libbitcoin)
|
|
|
$ # Run the executable
|
|
|
$ ./satoshi-words
|
|
|
^D<><44><GS>^A^DEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks
|
|
|
----
|
|
|
====
|
|
|
|
|
|
=== Constructing the Block Header
|
|
|
|
|
|
((("mining and consensus", "constructing block headers")))((("blocks",
|
|
|
"headers")))((("headers")))((("blockchain (the)", "block headers")))To
|
|
|
construct the block header, the mining node needs to fill in six fields,
|
|
|
as listed in <<block_header_structure_ch10>>.
|
|
|
|
|
|
[[block_header_structure_ch10]]
|
|
|
.The structure of the block header
|
|
|
[options="header"]
|
|
|
|=======
|
|
|
|Size| Field | Description
|
|
|
| 4 bytes | Version | A version number to track software/protocol upgrades
|
|
|
| 32 bytes | Previous Block Hash | A reference to the hash of the previous (parent) block in the chain
|
|
|
| 32 bytes | Merkle Root | A hash of the root of the merkle tree of this block's transactions
|
|
|
| 4 bytes | Timestamp | The approximate creation time of this block (seconds from Unix Epoch)
|
|
|
| 4 bytes | Target | The Proof-of-Work algorithm target for this block
|
|
|
| 4 bytes | Nonce | A counter used for the Proof-of-Work algorithm
|
|
|
|=======
|
|
|
|
|
|
At the time that block 277,316 was mined, the version number describing
|
|
|
the block structure is version 2, which is encoded in little-endian
|
|
|
format in 4 bytes as +0x02000000+.
|
|
|
|
|
|
((("blocks", "parent blocks")))((("parent blocks")))Next, the mining
|
|
|
node needs to add the "Previous Block Hash" (also known as +prevhash+).
|
|
|
That is the hash of the block header of block 277,315, the previous
|
|
|
block received from the network, which Jing's node has accepted and
|
|
|
selected as the _parent_ of the candidate block 277,316. The block
|
|
|
header hash for block 277,315 is:
|
|
|
|
|
|
----
|
|
|
0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569
|
|
|
----
|
|
|
|
|
|
[TIP]
|
|
|
====
|
|
|
By selecting the specific _parent_ block, indicated by the Previous
|
|
|
Block Hash field in the candidate block header, Jing is committing his
|
|
|
mining power to extending the chain that ends in that specific block. In
|
|
|
essence, this is how Jing "votes" with his mining power for the
|
|
|
longest-difficulty valid chain.
|
|
|
====
|
|
|
|
|
|
((("merkle trees")))((("blockchain (the)", "merkle trees")))The next
|
|
|
step is to summarize all the transactions with a merkle tree, in order
|
|
|
to add the merkle root to the block header. The coinbase transaction is
|
|
|
listed as the first transaction in the block. Then, 418 more
|
|
|
transactions are added after it, for a total of 419 transactions in the
|
|
|
block. As we saw in the <<merkle_trees>>, there must be an even number
|
|
|
of "leaf" nodes in the tree, so the last transaction is duplicated,
|
|
|
creating 420 nodes, each containing the hash of one transaction. The
|
|
|
transaction hashes are then combined, in pairs, creating each level of
|
|
|
the tree, until all the transactions are summarized into one node at the
|
|
|
"root" of the tree. The root of the merkle tree summarizes all the
|
|
|
transactions into a single 32-byte value, which you can see listed as
|
|
|
"merkle root" in <<block277316>>, and here:
|
|
|
|
|
|
----
|
|
|
c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e
|
|
|
----
|
|
|
|
|
|
Jing's mining node will then add a 4-byte timestamp, encoded as a Unix
|
|
|
"epoch" timestamp, which is based on the number of seconds elapsed from
|
|
|
January 1, 1970, midnight UTC/GMT. The time +1388185914+ is equal to
|
|
|
Friday, 27 Dec 2013, 23:11:54 UTC/GMT.
|
|
|
|
|
|
Jing's node then fills in the target, which defines the required
|
|
|
Proof-of-Work to make this a valid block. The target is stored in the
|
|
|
block as a "target bits" metric, which is a mantissa-exponent encoding
|
|
|
of the target. The encoding has a 1-byte exponent, followed by a 3-byte
|
|
|
mantissa (coefficient). In block 277,316, for example, the target bits
|
|
|
value is +0x1903a30c+. The first part +0x19+ is a hexadecimal exponent,
|
|
|
while the next part, +0x03a30c+, is the coefficient. The concept of a
|
|
|
target is explained in <<target>> and the "target bits" representation
|
|
|
is explained in <<target_bits>>.
|
|
|
|
|
|
The final field is the nonce, which is initialized to zero.
|
|
|
|
|
|
With all the other fields filled, the block header is now complete and
|
|
|
the process of mining can begin. The goal is now to find a value for the
|
|
|
nonce that results in a block header hash that is less than the target.
|
|
|
The mining node will need to test billions or trillions of nonce values
|
|
|
before a nonce is found that satisfies the requirement.
|
|
|
|
|
|
=== Mining the Block
|
|
|
|
|
|
((("mining and consensus", "mining the block", id="MACmining10")))Now
|
|
|
that a candidate block has been constructed by Jing's node, it is time
|
|
|
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")))
|
|
|
|
|
|
((("mining and consensus", "defined")))In the simplest terms, mining is
|
|
|
the process of hashing the block header repeatedly, changing one
|
|
|
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
|
|
|
until the desired hash result appears by chance.
|
|
|
|
|
|
==== Proof-of-Work Algorithm
|
|
|
|
|
|
((("Proof-of-Work algorithm", id="proof10")))((("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, a digital fingerprint of the input. For any specific input, the
|
|
|
resulting hash will always be the same and can be easily calculated and
|
|
|
verified by anyone implementing the same hash algorithm.
|
|
|
((("collisions")))The key characteristic of a cryptographic hash
|
|
|
algorithm is that it is computationally infeasible to find two different
|
|
|
inputs that produce the same fingerprint (known as a _collision_). As a
|
|
|
corollary, it is also virtually impossible to select an input in such a
|
|
|
way as to produce a desired fingerprint, other than trying random
|
|
|
inputs.
|
|
|
|
|
|
With SHA256, the output is always 256 bits long, regardless of the size
|
|
|
of the input. In <<sha256_example1>>, we will use the Python interpreter
|
|
|
to calculate the SHA256 hash of the phrase, "I am Satoshi Nakamoto."
|
|
|
|
|
|
[[sha256_example1]]
|
|
|
.SHA256 example
|
|
|
====
|
|
|
[source,bash]
|
|
|
----
|
|
|
$ python
|
|
|
----
|
|
|
[source,pycon]
|
|
|
----
|
|
|
Python 2.7.1
|
|
|
>>> import hashlib
|
|
|
>>> print hashlib.sha256("I am Satoshi Nakamoto").hexdigest()
|
|
|
5d7c7ba21cbbcd75d14800b100252d5b428e5b1213d27c385bc141ca6b47989e
|
|
|
----
|
|
|
====
|
|
|
|
|
|
<<sha256_example1>> shows the result of calculating the hash of +"I am
|
|
|
Satoshi Nakamoto"+:
|
|
|
+5d7c7ba21cbbcd75d14800b100252d5b428e5b1213d27c385bc141ca6b47989e+. This
|
|
|
256-bit number is the _hash_ or _digest_ of the phrase and depends on
|
|
|
every part of the phrase. Adding a single letter, punctuation mark, or
|
|
|
any other character will produce a different hash.
|
|
|
|
|
|
Now, if we change the phrase, we should expect to see completely
|
|
|
different hashes. Let's try that by adding a number to the end of our
|
|
|
phrase, using the simple Python scripting in
|
|
|
<<sha256_example_generator>>.
|
|
|
|
|
|
[[sha256_example_generator]]
|
|
|
.SHA256 script for generating many hashes by iterating on a nonce
|
|
|
====
|
|
|
[role="c_less_space"]
|
|
|
[source, python]
|
|
|
----
|
|
|
include::code/hash_example.py[]
|
|
|
----
|
|
|
====
|
|
|
|
|
|
Running this will produce the hashes of several phrases, made different
|
|
|
by adding a number at the end of the text. By incrementing the number,
|
|
|
we can get different hashes, as shown in
|
|
|
<<sha256_example_generator_output>>.
|
|
|
|
|
|
[[sha256_example_generator_output]]
|
|
|
.SHA256 output of a script for generating many hashes by iterating on a nonce
|
|
|
====
|
|
|
[source,bash]
|
|
|
----
|
|
|
$ python hash_example.py
|
|
|
----
|
|
|
|
|
|
----
|
|
|
I am Satoshi Nakamoto0 => a80a81401765c8eddee25df36728d732...
|
|
|
I am Satoshi Nakamoto1 => f7bc9a6304a4647bb41241a677b5345f...
|
|
|
I am Satoshi Nakamoto2 => ea758a8134b115298a1583ffb80ae629...
|
|
|
I am Satoshi Nakamoto3 => bfa9779618ff072c903d773de30c99bd...
|
|
|
I am Satoshi Nakamoto4 => bce8564de9a83c18c31944a66bde992f...
|
|
|
I am Satoshi Nakamoto5 => eb362c3cf3479be0a97a20163589038e...
|
|
|
I am Satoshi Nakamoto6 => 4a2fd48e3be420d0d28e202360cfbaba...
|
|
|
I am Satoshi Nakamoto7 => 790b5a1349a5f2b909bf74d0d166b17a...
|
|
|
I am Satoshi Nakamoto8 => 702c45e5b15aa54b625d68dd947f1597...
|
|
|
I am Satoshi Nakamoto9 => 7007cf7dd40f5e933cd89fff5b791ff0...
|
|
|
I am Satoshi Nakamoto10 => c2f38c81992f4614206a21537bd634a...
|
|
|
I am Satoshi Nakamoto11 => 7045da6ed8a914690f087690e1e8d66...
|
|
|
I am Satoshi Nakamoto12 => 60f01db30c1a0d4cbce2b4b22e88b9b...
|
|
|
I am Satoshi Nakamoto13 => 0ebc56d59a34f5082aaef3d66b37a66...
|
|
|
I am Satoshi Nakamoto14 => 27ead1ca85da66981fd9da01a8c6816...
|
|
|
I am Satoshi Nakamoto15 => 394809fb809c5f83ce97ab554a2812c...
|
|
|
I am Satoshi Nakamoto16 => 8fa4992219df33f50834465d3047429...
|
|
|
I am Satoshi Nakamoto17 => dca9b8b4f8d8e1521fa4eaa46f4f0cd...
|
|
|
I am Satoshi Nakamoto18 => 9989a401b2a3a318b01e9ca9a22b0f3...
|
|
|
I am Satoshi Nakamoto19 => cda56022ecb5b67b2bc93a2d764e75f...
|
|
|
----
|
|
|
====
|
|
|
|
|
|
Each phrase produces a completely different hash result. They seem
|
|
|
completely random, but you can reproduce the exact results in this
|
|
|
example on any computer with Python and see the same exact hashes.
|
|
|
|
|
|
The number used as a variable in such a scenario is called a _nonce_.
|
|
|
The nonce is used to vary the output of a cryptographic function, in
|
|
|
this case to vary the SHA256 fingerprint of the phrase.
|
|
|
|
|
|
To make a challenge out of this algorithm, let's set a target: find a
|
|
|
phrase that produces a hexadecimal hash that starts with a zero.
|
|
|
Fortunately, this isn't difficult! <<sha256_example_generator_output>>
|
|
|
shows that the phrase "I am Satoshi Nakamoto13" produces the hash
|
|
|
+0ebc56d59a34f5082aaef3d66b37a661696c2b618e62432727216ba9531041a5+,
|
|
|
which fits our criteria. It took 13 attempts to find it. In terms of
|
|
|
probabilities, if the output of the hash function is evenly distributed
|
|
|
we would expect to find a result with a 0 as the hexadecimal prefix once
|
|
|
every 16 hashes (one out of 16 hexadecimal digits 0 through F). In
|
|
|
numerical terms, that means finding a hash value that is less than
|
|
|
+0x1000000000000000000000000000000000000000000000000000000000000000+. We
|
|
|
call this threshold the _target_ and the goal is to find a hash that is
|
|
|
numerically less than the target. If we decrease the target, the task of
|
|
|
finding a hash that is less than the target becomes more and more
|
|
|
difficult.
|
|
|
|
|
|
To give a simple analogy, imagine a game where players throw a pair of
|
|
|
dice repeatedly, trying to throw less than a specified target. In the
|
|
|
first round, the target is 12. Unless you throw double-six, you win. In
|
|
|
the next round the target is 11. Players must throw 10 or less to win,
|
|
|
again an easy task. Let's say a few rounds later the target is down to
|
|
|
5. Now, more than half the dice throws will exceed the target and
|
|
|
therefore be invalid. It takes exponentially more dice throws to win,
|
|
|
the lower the target gets. Eventually, when the target is 2 (the minimum
|
|
|
possible), only one throw out of every 36, or 2% of them, will produce a
|
|
|
winning result.
|
|
|
|
|
|
From the perspective of an observer who knows that the target of the
|
|
|
dice game is 2, if someone has succeeded in casting a winning throw it
|
|
|
can be assumed that they attempted, on average, 36 throws. In other
|
|
|
words, one can estimate the amount of work it takes to succeed from the
|
|
|
difficulty imposed by the target. When the algorithm is a based on a
|
|
|
deterministic function such as SHA256, the input itself constitutes
|
|
|
_proof_ that a certain amount of _work_ was done to produce a result
|
|
|
below the target. Hence, _Proof-of-Work_.
|
|
|
|
|
|
[TIP]
|
|
|
====
|
|
|
Even though each attempt produces a random outcome, the probability of
|
|
|
any possible outcome can be calculated in advance. Therefore, an outcome
|
|
|
of specified difficulty constitutes proof of a specific amount of work.
|
|
|
====
|
|
|
|
|
|
In <<sha256_example_generator_output>>, the winning "nonce" is 13 and
|
|
|
this result can be confirmed by anyone independently. Anyone can add the
|
|
|
number 13 as a suffix to the phrase "I am Satoshi Nakamoto" and compute
|
|
|
the hash, verifying that it is less than the target. The successful
|
|
|
result is also Proof-of-Work, because it proves we did the work to find
|
|
|
that nonce. While it only takes one hash computation to verify, it took
|
|
|
us 13 hash computations to find a nonce that worked. If we had a lower
|
|
|
target (higher difficulty) it would take many more hash computations to
|
|
|
find a suitable nonce, but only one hash computation for anyone to
|
|
|
verify. Furthermore, by knowing the target, anyone can estimate the
|
|
|
difficulty using statistics and therefore know how much work was needed
|
|
|
to find such a nonce.
|
|
|
|
|
|
[TIP]
|
|
|
====
|
|
|
The Proof-of-Work must produce a hash that is _less than_ the target. A
|
|
|
higher target means it is less difficult to find a hash that is below
|
|
|
the target. A lower target means it is more difficult to find a hash
|
|
|
below the target. The target and difficulty are inversely related.
|
|
|
====
|
|
|
|
|
|
((("targets")))Bitcoin's Proof-of-Work is very similar to the challenge
|
|
|
shown in <<sha256_example_generator_output>>. The miner constructs a
|
|
|
candidate block filled with transactions. Next, the miner calculates the
|
|
|
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
|
|
|
enough block header hash.
|
|
|
|
|
|
A very simplified Proof-of-Work algorithm is implemented in Python in
|
|
|
<<pow_example1>>.
|
|
|
|
|
|
[[pow_example1]]
|
|
|
.Simplified Proof-of-Work implementation
|
|
|
====
|
|
|
[source, python]
|
|
|
----
|
|
|
include::code/proof-of-work-example.py[]
|
|
|
----
|
|
|
====
|
|
|
|
|
|
Running this code, you can set the desired difficulty (in bits, how many
|
|
|
of the leading bits must be zero) and see how long it takes for your
|
|
|
computer to find a solution. In <<pow_example_outputs>>, you can see how
|
|
|
it works on an average laptop.
|
|
|
|
|
|
[[pow_example_outputs]]
|
|
|
.Running the Proof-of-Work example for various difficulties
|
|
|
====
|
|
|
[source, bash]
|
|
|
----
|
|
|
$ python proof-of-work-example.py*
|
|
|
----
|
|
|
|
|
|
----
|
|
|
Difficulty: 1 (0 bits)
|
|
|
|
|
|
[...]
|
|
|
|
|
|
Difficulty: 8 (3 bits)
|
|
|
Starting search...
|
|
|
Success with nonce 9
|
|
|
Hash is 1c1c105e65b47142f028a8f93ddf3dabb9260491bc64474738133ce5256cb3c1
|
|
|
Elapsed Time: 0.0004 seconds
|
|
|
Hashing Power: 25065 hashes per second
|
|
|
Difficulty: 16 (4 bits)
|
|
|
Starting search...
|
|
|
Success with nonce 25
|
|
|
Hash is 0f7becfd3bcd1a82e06663c97176add89e7cae0268de46f94e7e11bc3863e148
|
|
|
Elapsed Time: 0.0005 seconds
|
|
|
Hashing Power: 52507 hashes per second
|
|
|
Difficulty: 32 (5 bits)
|
|
|
Starting search...
|
|
|
Success with nonce 36
|
|
|
Hash is 029ae6e5004302a120630adcbb808452346ab1cf0b94c5189ba8bac1d47e7903
|
|
|
Elapsed Time: 0.0006 seconds
|
|
|
Hashing Power: 58164 hashes per second
|
|
|
|
|
|
[...]
|
|
|
|
|
|
Difficulty: 4194304 (22 bits)
|
|
|
Starting search...
|
|
|
Success with nonce 1759164
|
|
|
Hash is 0000008bb8f0e731f0496b8e530da984e85fb3cd2bd81882fe8ba3610b6cefc3
|
|
|
Elapsed Time: 13.3201 seconds
|
|
|
Hashing Power: 132068 hashes per second
|
|
|
Difficulty: 8388608 (23 bits)
|
|
|
Starting search...
|
|
|
Success with nonce 14214729
|
|
|
Hash is 000001408cf12dbd20fcba6372a223e098d58786c6ff93488a9f74f5df4df0a3
|
|
|
Elapsed Time: 110.1507 seconds
|
|
|
Hashing Power: 129048 hashes per second
|
|
|
Difficulty: 16777216 (24 bits)
|
|
|
Starting search...
|
|
|
Success with nonce 24586379
|
|
|
Hash is 0000002c3d6b370fccd699708d1b7cb4a94388595171366b944d68b2acce8b95
|
|
|
Elapsed Time: 195.2991 seconds
|
|
|
Hashing Power: 125890 hashes per second
|
|
|
|
|
|
[...]
|
|
|
|
|
|
Difficulty: 67108864 (26 bits)
|
|
|
Starting search...
|
|
|
Success with nonce 84561291
|
|
|
Hash is 0000001f0ea21e676b6dde5ad429b9d131a9f2b000802ab2f169cbca22b1e21a
|
|
|
Elapsed Time: 665.0949 seconds
|
|
|
Hashing Power: 127141 hashes per second
|
|
|
----
|
|
|
====
|
|
|
|
|
|
As you can see, increasing the difficulty by 1 bit causes a doubling in
|
|
|
the time it takes to find a solution. If you think of the entire 256-bit
|
|
|
number space, each time you constrain one more bit to zero, you decrease
|
|
|
the search space by half. In <<pow_example_outputs>>, it takes 84
|
|
|
million hash attempts to find a nonce that produces a hash with 26
|
|
|
leading bits as zero. Even at a speed of more than 120,000 hashes per
|
|
|
second, it still requires 10 minutes on a laptop to find this solution.
|
|
|
|
|
|
At the time of writing, the network is attempting to find a block whose
|
|
|
header hash is less than:
|
|
|
|
|
|
----
|
|
|
0000000000000000029AB9000000000000000000000000000000000000000000
|
|
|
----
|
|
|
|
|
|
As you can see, there are a lot of zeros at the beginning of that
|
|
|
target, meaning that the acceptable range of hashes is much smaller,
|
|
|
hence it's more difficult to find a valid hash. It will take on average
|
|
|
more than 1.8 zeta-hashes (thousand billion billion hashes) per second
|
|
|
for the network to discover the next block. That seems like an
|
|
|
impossible task, but fortunately the network is bringing 3 exa-hashes
|
|
|
per second (EH/sec) of processing power to bear, which will be able to
|
|
|
find a block in about 10 minutes on average.((("",
|
|
|
startref="Cproof10")))((("", startref="proof10")))
|
|
|
|
|
|
[[target_bits]]
|
|
|
==== 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
|
|
|
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
|
|
|
the exponent and the next six hex digits as the coefficient. In this
|
|
|
block, therefore, the exponent is +0x19+ and the coefficient is
|
|
|
+0x03a30c+.
|
|
|
|
|
|
The formula to calculate the difficulty target from this representation
|
|
|
is:
|
|
|
|
|
|
++++
|
|
|
<ul class="simplelist">
|
|
|
<li>target = coefficient * 2<sup>(8*(exponent–3))</sup></li>
|
|
|
</ul>
|
|
|
++++
|
|
|
|
|
|
Using that formula, and the difficulty bits value 0x1903a30c, we get:
|
|
|
|
|
|
++++
|
|
|
<ul class="simplelist">
|
|
|
<li>target = 0x03a30c * 2<sup>0x08*(0x19-0x03)</sup></li>
|
|
|
<li>=> target = 0x03a30c * 2<sup>(0x08*0x16)</sup></li>
|
|
|
<li>=> target = 0x03a30c * 2<sup>0xB0</sup></li>
|
|
|
</ul>
|
|
|
++++
|
|
|
|
|
|
which in decimal is:
|
|
|
|
|
|
++++
|
|
|
<ul class="simplelist">
|
|
|
<li>=> target = 238,348 * 2<sup>176</sup></li>
|
|
|
<li>=> target = <br/>22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328</li>
|
|
|
</ul>
|
|
|
++++
|
|
|
|
|
|
switching back to hexadecimal:
|
|
|
|
|
|
++++
|
|
|
<ul class="simplelist">
|
|
|
<li>=> target = <br/>0x0000000000000003A30C00000000000000000000000000000000000000000000</li>
|
|
|
</ul>
|
|
|
++++
|
|
|
|
|
|
This means that a valid block for height 277,316 is one that has a block
|
|
|
header hash that is less than the target. In binary that number must
|
|
|
have more than 60 leading bits set to zero. With this level of
|
|
|
difficulty, a single miner processing 1 trillion hashes per second (1
|
|
|
terahash per second or 1 TH/sec) would only find a solution once every
|
|
|
8,496 blocks or once every 59 days, on average.
|
|
|
|
|
|
[[target]]
|
|
|
==== Retargeting to Adjust Difficulty
|
|
|
|
|
|
((("mining and consensus", "mining the block", "retargeting to adjust
|
|
|
difficulty")))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?
|
|
|
|
|
|
Bitcoin's blocks are generated every 10 minutes, on average. This is
|
|
|
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
|
|
|
pace. Furthermore, the number of participants in mining and the
|
|
|
computers they use will also constantly change. To keep the block
|
|
|
generation time at 10 minutes, the difficulty of mining must be adjusted
|
|
|
to account for these changes. In fact, the Proof-of-Work target is a
|
|
|
dynamic parameter that is periodically adjusted to meet a 10-minute
|
|
|
block interval goal. In simple terms, the target is set so that the
|
|
|
current mining power will result in a 10-minute block interval.
|
|
|
|
|
|
How, then, is such an adjustment made in a completely decentralized
|
|
|
network? Retargeting occurs automatically and on every node
|
|
|
independently. Every 2,016 blocks, all nodes retarget the Proof-of-Work.
|
|
|
The equation for retargeting measures the time it took to find the last
|
|
|
2,016 blocks and compares that to the expected time of 20,160 minutes
|
|
|
(2,016 blocks times the desired 10-minute block interval). The ratio
|
|
|
between the actual timespan and desired timespan is calculated and a
|
|
|
proportionate adjustment (up or down) is made to the target. In simple
|
|
|
terms: If the network is finding blocks faster than every 10 minutes,
|
|
|
the difficulty increases (target decreases). If block discovery is
|
|
|
slower than expected, the difficulty decreases (target increases).
|
|
|
|
|
|
The equation can be summarized as:
|
|
|
|
|
|
----
|
|
|
New Target = Old Target * (Actual Time of Last 2016 Blocks / 20160 minutes)
|
|
|
----
|
|
|
|
|
|
<<retarget_code>> shows the code used in the Bitcoin Core client.
|
|
|
|
|
|
[[retarget_code]]
|
|
|
.Retargeting the Proof-of-Work—CalculateNextWorkRequired() in pow.cpp
|
|
|
====
|
|
|
[source,cpp]
|
|
|
----
|
|
|
|
|
|
// Limit adjustment step
|
|
|
int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
|
|
|
LogPrintf(" nActualTimespan = %d before bounds\n", nActualTimespan);
|
|
|
if (nActualTimespan < params.nPowTargetTimespan/4)
|
|
|
nActualTimespan = params.nPowTargetTimespan/4;
|
|
|
if (nActualTimespan > params.nPowTargetTimespan*4)
|
|
|
nActualTimespan = params.nPowTargetTimespan*4;
|
|
|
|
|
|
// Retarget
|
|
|
const arith_uint256 bnPowLimit = UintToArith256(params.powLimit);
|
|
|
arith_uint256 bnNew;
|
|
|
arith_uint256 bnOld;
|
|
|
bnNew.SetCompact(pindexLast->nBits);
|
|
|
bnOld = bnNew;
|
|
|
bnNew *= nActualTimespan;
|
|
|
bnNew /= params.nPowTargetTimespan;
|
|
|
|
|
|
if (bnNew > bnPowLimit)
|
|
|
bnNew = bnPowLimit;
|
|
|
|
|
|
----
|
|
|
====
|
|
|
|
|
|
[NOTE]
|
|
|
====
|
|
|
While the target calibration happens every 2,016 blocks, because of an
|
|
|
off-by-one error in the original Bitcoin Core client it is based on the
|
|
|
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_.
|
|
|
|
|
|
To avoid extreme volatility in the difficulty, the retargeting
|
|
|
adjustment must be less than a factor of four (4) per cycle. If the
|
|
|
required target adjustment is greater than a factor of four, it will be
|
|
|
adjusted by a factor of 4 and not more. Any further adjustment will be
|
|
|
accomplished in the next retargeting period because the imbalance will
|
|
|
persist through the next 2,016 blocks. Therefore, large discrepancies
|
|
|
between hashing power and difficulty might take several 2,016 block
|
|
|
cycles to balance out.
|
|
|
|
|
|
[TIP]
|
|
|
====
|
|
|
The difficulty of mining a bitcoin block is approximately '10 minutes of
|
|
|
processing' for the entire network, based on the time it took to mine
|
|
|
the previous 2,016 blocks, adjusted every 2,016 blocks. This is achieved
|
|
|
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
|
|
|
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
|
|
|
honestly in pursuit of the reward, it is enough to prevent "takeover"
|
|
|
attacks and, therefore, it is enough to secure bitcoin.
|
|
|
|
|
|
The difficulty of mining is closely related to the cost of electricity
|
|
|
and the exchange rate of bitcoin vis-a-vis the currency used to pay for
|
|
|
electricity. High-performance mining systems are about as efficient as
|
|
|
possible with the current generation of silicon fabrication, converting
|
|
|
electricity into hashing computation at the highest rate possible. The
|
|
|
primary influence on the mining market is the price of one kilowatt-hour
|
|
|
of electricity in bitcoin, because that determines the profitability of
|
|
|
mining and therefore the incentives to enter or exit the mining
|
|
|
market.((("", startref="targets10")))
|
|
|
|
|
|
=== Successfully Mining the Block
|
|
|
|
|
|
((("mining and consensus", "mining the block", "successful
|
|
|
completion")))((("use cases", "mining for bitcoin", id="jingtentwo")))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
|
|
|
integrated circuits run the SHA256 algorithm in parallel at incredible
|
|
|
speeds. Many of these specialized machines are connected to his mining
|
|
|
node over USB or a local area network. Next, the mining node running on
|
|
|
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
|
|
|
new combinations.
|
|
|
|
|
|
Almost 11 minutes after starting to mine block 277,316, one of the
|
|
|
hardware mining machines finds a solution and sends it back to the
|
|
|
mining node.
|
|
|
|
|
|
When inserted into the block header, the nonce 924,591,752 produces a
|
|
|
block hash of:
|
|
|
|
|
|
----
|
|
|
0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
|
|
|
----
|
|
|
|
|
|
which is less than the target:
|
|
|
|
|
|
----
|
|
|
0000000000000003A30C00000000000000000000000000000000000000000000
|
|
|
----
|
|
|
|
|
|
Immediately, Jing's mining node transmits the block to all its peers.
|
|
|
They receive, validate, and then propagate the new block. As the block
|
|
|
ripples out across the network, each node adds it to its own copy of the
|
|
|
blockchain, extending it to a new height of 277,316 blocks. As mining
|
|
|
nodes receive and validate the block, they abandon their efforts to find
|
|
|
a block at the same height and immediately start computing the next
|
|
|
block in the chain, using Jing's block as the "parent." By building on
|
|
|
top of Jing's newly discovered block, the other miners are essentially
|
|
|
"voting" with their mining power and endorsing Jing's block and the
|
|
|
chain it extends.
|
|
|
|
|
|
In the next section, we'll look at the process each node uses to
|
|
|
validate a block and select the longest chain, creating the consensus
|
|
|
that forms the decentralized blockchain.((("",
|
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
block is rejected. These criteria can be seen in the Bitcoin Core client
|
|
|
in the functions +CheckBlock+ and +CheckBlockHeader+ and include:
|
|
|
|
|
|
- The block data structure is syntactically valid
|
|
|
|
|
|
- The block header hash is less than the target (enforces the
|
|
|
Proof-of-Work)
|
|
|
|
|
|
- The block timestamp is less than two hours in the future (allowing for
|
|
|
time errors)
|
|
|
|
|
|
- The block size is within acceptable limits
|
|
|
|
|
|
- The first transaction (and only the first) is a coinbase transaction
|
|
|
|
|
|
- All transactions within the block are valid using the transaction
|
|
|
checklist discussed in <<tx_verification>>
|
|
|
|
|
|
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
|
|
|
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
|
|
|
and, therefore, that transaction would never become part of the ledger.
|
|
|
The miners have to construct a perfect block, based on the shared rules
|
|
|
that all nodes follow, and mine it with a correct solution to the
|
|
|
Proof-of-Work. To do so, they expend a lot of electricity in mining, and
|
|
|
if they cheat, all the electricity and effort is wasted. This is why
|
|
|
independent validation is a key component of decentralized consensus.
|
|
|
|
|
|
=== Assembling and Selecting Chains of Blocks
|
|
|
|
|
|
((("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
|
|
|
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
|
|
|
of the validation criteria fails and are therefore not included in any
|
|
|
chain.
|
|
|
|
|
|
The "best blockchain" at any time is whichever _valid_ chain of blocks has
|
|
|
the most cumulative Proof-of-Work associated with it. Under most
|
|
|
circumstances this is also the chain with the most blocks in it, unless
|
|
|
there are two equal-length chains and one has more Proof-of-Work. The
|
|
|
best chain will also have branches with blocks that are "siblings" to
|
|
|
the blocks on the best chain. These blocks are valid but not part of the
|
|
|
best chain. They are kept for future reference, in case one of those
|
|
|
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
|
|
|
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
|
|
|
of the time, the parent will be the "tip" of the best chain, meaning
|
|
|
this new block extends the best chain. For example, the new block
|
|
|
277,316 has a reference to the hash of its parent block 277,315. Most
|
|
|
nodes that receive 277,316 will already have block 277,315 as the tip of
|
|
|
their best chain and will therefore link the new block and extend that
|
|
|
chain.
|
|
|
|
|
|
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
|
|
|
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,
|
|
|
chain.
|
|
|
|
|
|
By selecting the greatest-cumulative-work valid chain, all nodes
|
|
|
eventually achieve network-wide consensus. Temporary discrepancies
|
|
|
between chains are resolved eventually as more work is added, extending
|
|
|
one of the possible chains. Mining nodes "vote" with their mining power
|
|
|
by choosing which chain to extend by mining the next block. When they
|
|
|
mine a new block and extend the chain, the new block itself represents
|
|
|
their vote.
|
|
|
|
|
|
In the next section we will look at how discrepancies between competing
|
|
|
chains (forks) are resolved by the independent selection of the
|
|
|
greatest-cumulative-work chain.
|
|
|
|
|
|
[[forks]]
|
|
|
==== Blockchain Forks
|
|
|
|
|
|
((("mining and consensus", "assembling and selecting chains of blocks",
|
|
|
"blockchain forks")))((("blockchain (the)", "blockchain forks",
|
|
|
id="BCTfork10")))((("forks", "blockchain fork events",
|
|
|
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
|
|
|
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
|
|
|
converges to a consistent state. Forks occur as temporary
|
|
|
inconsistencies between versions of the blockchain, which are resolved
|
|
|
by eventual reorganization as more blocks are added to one of the forks.
|
|
|
|
|
|
[TIP]
|
|
|
====
|
|
|
The blockchain forks described in this section occur naturally as a
|
|
|
result of transmission delays in the global network. We will also look
|
|
|
at deliberately induced forks later in this chapter.
|
|
|
====
|
|
|
|
|
|
In the next few diagrams, we follow the progress of a "fork" event
|
|
|
across the network. The diagram is a simplified representation of the
|
|
|
Bitcoin network. For illustration purposes, different blocks are shown
|
|
|
as different shapes (star, triangle, upside-down triangle, rhombus),
|
|
|
spreading across the network. Each node in the network is represented as
|
|
|
a circle.
|
|
|
|
|
|
Each node has its own perspective of the global blockchain. As each node
|
|
|
receives blocks from its neighbors, it updates its own copy of the
|
|
|
blockchain, selecting the greatest-cumulative-work chain. For
|
|
|
illustration purposes, each node contains a shape that represents the
|
|
|
block that it believes is currently the tip of the best chain. So, if
|
|
|
you see a star shape in the node, that means that the star block is the
|
|
|
tip of the best chain, as far as that node is concerned.
|
|
|
|
|
|
In the first diagram (<<fork1>>), the network has a unified perspective
|
|
|
of the blockchain, with the star block as the tip of the best chain.
|
|
|
|
|
|
[[fork1]]
|
|
|
[role="smallereighty"]
|
|
|
.Before the fork—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
|
|
|
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
|
|
|
their respective candidate blocks, they immediately broadcast their own
|
|
|
"winning" block to their immediate neighbors who begin propagating the
|
|
|
block across the network. Each node that receives a valid block will
|
|
|
incorporate it into its blockchain, extending the blockchain by one
|
|
|
block. If that node later sees another candidate block extending the
|
|
|
same parent, it connects the second candidate on a secondary chain. As a
|
|
|
result, some nodes will "see" one candidate block first, while other
|
|
|
nodes will see the other candidate block and two competing versions of
|
|
|
the blockchain will emerge.
|
|
|
|
|
|
In <<fork2>>, we see two miners (Node X and Node Y) who mine two
|
|
|
different blocks almost simultaneously. Both of these blocks are
|
|
|
children of the star block, and extend the chain by building on top of
|
|
|
the star block. To help us track it, one is visualized as a triangle
|
|
|
block originating from Node X, and the other is shown as an upside-down
|
|
|
triangle block originating from Node Y.
|
|
|
|
|
|
[[fork2]]
|
|
|
[role="smallersixty"]
|
|
|
.Visualization of a blockchain fork event: two blocks found simultaneously
|
|
|
image::images/mbc2_1003.png["Visualization of a blockchain fork event: two blocks found simultaneously"]
|
|
|
|
|
|
Let's assume, for example, that a miner Node X finds a Proof-of-Work
|
|
|
solution for a block "triangle" that extends the blockchain, building on
|
|
|
top of the parent block "star." Almost simultaneously, the miner Node Y
|
|
|
who was also extending the chain from block "star" finds a solution for
|
|
|
block "upside-down triangle," his candidate block. Now, there are two
|
|
|
possible blocks; one we call "triangle," originating in Node X; and one
|
|
|
we call "upside-down triangle," originating in Node Y. Both blocks are
|
|
|
valid, both blocks contain a valid solution to the Proof-of-Work, and
|
|
|
both blocks extend the same parent (block "star"). Both blocks likely
|
|
|
contain most of the same transactions, with only perhaps a few
|
|
|
differences in the order of transactions.
|
|
|
|
|
|
As the two blocks propagate, some nodes receive block "triangle" first
|
|
|
and some receive block "upside-down triangle" first. As shown in
|
|
|
<<fork3>>, the network splits into two different perspectives of the
|
|
|
blockchain; one side topped with a triangle block, the other with the
|
|
|
upside-down-triangle block.
|
|
|
|
|
|
[[fork3]]
|
|
|
[role="smallersixty"]
|
|
|
.Visualization of a blockchain fork event: two blocks propagate, splitting the network
|
|
|
image::images/mbc2_1004.png["Visualization of a blockchain fork event: two blocks propagate, splitting the network"]
|
|
|
|
|
|
In the diagram, a randomly chosen "Node X" received the triangle block
|
|
|
first and extended the star chain with it. Node X selected the chain
|
|
|
with "triangle" block as the best chain. Later, Node X also received the
|
|
|
"upside-down triangle" block. Since it was received second, it is
|
|
|
assumed to have "lost" the race. Yet, the "upside-down triangle" block
|
|
|
is not discarded. It is linked to the "star" block parent and forms a
|
|
|
secondary chain. While Node X assumes it has correctly selected the
|
|
|
winning chain, it keeps the "losing" chain so that it has the
|
|
|
information needed to reorganize if the "losing" chain ends up
|
|
|
"winning."
|
|
|
|
|
|
On the other side of the network, Node Y constructs a blockchain based
|
|
|
on its own perspective of the sequence of events. It received
|
|
|
"upside-down triangle" first and elected that chain as the "winner."
|
|
|
When it later received "triangle" block, it connected it to the "star"
|
|
|
block parent as a secondary chain.
|
|
|
|
|
|
Neither side is "correct," or "incorrect." Both are valid perspectives
|
|
|
of the blockchain. Only in hindsight will one prevail, based on how
|
|
|
these two competing chains are extended by additional work.
|
|
|
|
|
|
Mining nodes whose perspective resembles Node X will immediately begin
|
|
|
mining a candidate block that extends the chain with "triangle" as its
|
|
|
tip. By linking "triangle" as the parent of their candidate block, they
|
|
|
are voting with their hashing power. Their vote supports the chain that
|
|
|
they have elected as the best chain.
|
|
|
|
|
|
Any mining node whose perspective resembles Node Y will start building a
|
|
|
candidate node with "upside-down triangle" as its parent, extending the
|
|
|
chain that they believe is the best chain. And so, the race begins
|
|
|
again.
|
|
|
|
|
|
Forks are almost always resolved within one block. While part of the
|
|
|
network's hashing power is dedicated to building on top of "triangle" as
|
|
|
the parent, another part of the hashing power is focused on building on
|
|
|
top of "upside-down triangle." Even if the hashing power is almost
|
|
|
evenly split, it is likely that one set of miners will find a solution
|
|
|
and propagate it before the other set of miners have found any
|
|
|
solutions. Let's say, for example, that the miners building on top of
|
|
|
"triangle" find a new block "rhombus" that extends the chain (e.g.,
|
|
|
star-triangle-rhombus). They immediately propagate this new block and
|
|
|
the entire network sees it as a valid solution as shown in <<fork4>>.
|
|
|
|
|
|
All nodes that had chosen "triangle" as the winner in the previous round
|
|
|
will simply extend the chain one more block. The nodes that chose
|
|
|
"upside-down triangle" as the winner, however, will now see two chains:
|
|
|
star-triangle-rhombus and star-upside-down-triangle. The chain
|
|
|
star-triangle-rhombus is now longer (more cumulative work) than the
|
|
|
other chain. As a result, those nodes will set the chain
|
|
|
star-triangle-rhombus as the best chain and change the
|
|
|
star-upside-down-triangle chain to a secondary chain, as shown in
|
|
|
<<fork5>>. This is a chain reorganization, because those nodes are forced
|
|
|
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
|
|
|
"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
|
|
|
star-triangle-rhombus, with "rhombus" as the last block in the chain.
|
|
|
All miners immediately start working on candidate blocks that reference
|
|
|
"rhombus" as their parent to extend the star-triangle-rhombus chain.
|
|
|
|
|
|
[[fork4]]
|
|
|
[role="smallereighty"]
|
|
|
.Visualization of a blockchain fork event: a new block extends one fork, reorganizing the network
|
|
|
image::images/mbc2_1005.png["Visualization of a blockchain fork event: a new block extends one fork"]
|
|
|
|
|
|
[[fork5]]
|
|
|
[role="smallereighty"]
|
|
|
.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
|
|
|
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.
|
|
|
|
|
|
Bitcoin's block interval of 10 minutes is a design compromise between
|
|
|
fast confirmation times (settlement of transactions) and the probability
|
|
|
of a fork. A faster block time would make transactions clear faster but
|
|
|
lead to more frequent blockchain forks, whereas a slower block time
|
|
|
would decrease the number of forks but make settlement slower.((("",
|
|
|
startref="Bassemble10")))((("", startref="MACassembling10")))((("",
|
|
|
startref="forks10")))((("", startref="BCTfork10")))
|
|
|
|
|
|
=== Mining and the Hashing Race
|
|
|
|
|
|
((("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
|
|
|
using CPU mining to GPU mining and field programmable gate array (FPGA)
|
|
|
mining. In 2013 the introduction of ASIC mining lead to another giant
|
|
|
leap in mining power, by placing the SHA256 function directly on silicon
|
|
|
chips specialized for the purpose of mining. The first such chips could
|
|
|
deliver more mining power in a single box than the entire Bitcoin
|
|
|
network in 2010.
|
|
|
|
|
|
The following list shows the total hashing power of the Bitcoin network,
|
|
|
over the first eight years of operation:
|
|
|
|
|
|
2009:: 0.5 MH/sec–8 MH/sec (16× growth)
|
|
|
2010:: 8 MH/sec–116 GH/sec (14,500× growth)
|
|
|
2011:: 116 GH/sec–9 TH/sec (78× growth)
|
|
|
2012:: 9 TH/sec–23 TH/sec (2.5× growth)
|
|
|
2013:: 23 TH/sec–10 PH/sec (450× growth)
|
|
|
2014:: 10 PH/sec–300 PH/sec (30× growth)
|
|
|
2015:: 300 PH/sec-800 PH/sec (2.66× growth)
|
|
|
2016:: 800 PH/sec-2.5 EH/sec (3.12× growth)
|
|
|
|
|
|
In the chart in <<network_hashing_power>>, we can see that Bitcoin
|
|
|
network's hashing power increased over the past two years. As you can
|
|
|
see, the competition between miners and the growth of bitcoin has
|
|
|
resulted in an exponential increase in the hashing power (total hashes
|
|
|
per second across the network).
|
|
|
|
|
|
[[network_hashing_power]]
|
|
|
.Total hashing power, terahashes per second (TH/sec)
|
|
|
image::images/mbc2_1007.png["NetworkHashingRate"]
|
|
|
|
|
|
As the amount of hashing power applied to mining bitcoin has exploded,
|
|
|
the difficulty has risen to match it. The difficulty metric in the chart
|
|
|
shown in <<bitcoin_difficulty>> is measured as a ratio of current
|
|
|
difficulty over minimum difficulty (the difficulty of the first block).
|
|
|
|
|
|
[[bitcoin_difficulty]]
|
|
|
.Bitcoin's mining difficulty metric
|
|
|
image::images/mbc2_1008.png["BitcoinDifficulty"]
|
|
|
|
|
|
In the last two years, the ASIC mining chips have become increasingly
|
|
|
denser, approaching the cutting edge of silicon fabrication with a
|
|
|
feature size (resolution) of 16 nanometers (nm). Currently, ASIC
|
|
|
manufacturers are aiming to overtake general-purpose CPU chip
|
|
|
manufacturers, designing chips with a feature size of 14 nm, because the
|
|
|
profitability of mining is driving this industry even faster than
|
|
|
general computing. There are no more giant leaps left in bitcoin mining,
|
|
|
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.
|
|
|
|
|
|
[[extra_nonce]]
|
|
|
==== The Extra Nonce Solution
|
|
|
|
|
|
((("nonce values")))Since 2012, bitcoin mining has evolved to resolve a
|
|
|
fundamental limitation in the structure of the block header. In the
|
|
|
early days of bitcoin, a miner could find a block by iterating through
|
|
|
the nonce until the resulting hash was below the target. As difficulty
|
|
|
increased, miners often cycled through all 4 billion values of the nonce
|
|
|
without finding a block. However, this was easily resolved by updating
|
|
|
the block timestamp to account for the elapsed time. Because the
|
|
|
timestamp is part of the header, the change would allow miners to
|
|
|
iterate through the values of the nonce again with different results.
|
|
|
Once mining hardware exceeded 4 GH/sec, however, this approach became
|
|
|
increasingly difficult because the nonce values were exhausted in less
|
|
|
than a second. As ASIC mining equipment started pushing and then
|
|
|
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
|
|
|
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
|
|
|
header values to find valid blocks. The coinbase transaction is included
|
|
|
in the merkle tree, which means that any change in the coinbase script
|
|
|
causes the merkle root to change. Eight bytes of extra nonce, plus the 4
|
|
|
bytes of "standard" nonce allow miners to explore a total 2^96^ (8
|
|
|
followed by 28 zeros) possibilities _per second_ without having to
|
|
|
modify the timestamp. If, in the future, miners could run through all
|
|
|
these possibilities, they could then modify the timestamp. There is also
|
|
|
more space in the coinbase script for future expansion of the extra
|
|
|
nonce space.
|
|
|
|
|
|
[[mining_pools]]
|
|
|
==== Mining Pools
|
|
|
|
|
|
((("mining pools", id="MACoverpool10")))((("mining pools", "benefits
|
|
|
of")))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
|
|
|
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
|
|
|
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
|
|
|
day, reducing uncertainty.
|
|
|
|
|
|
Let's look at a specific example. Assume a miner has purchased mining
|
|
|
hardware with a combined hashing rate of 0.0001% of current the total
|
|
|
network hash rate. If the protocol difficulty never changes, that miner
|
|
|
will find a new block approximately once every 20 years. That's a
|
|
|
potentially long time to wait to get paid. However, if that miner works
|
|
|
together in a mining pool with other miners whose aggregate hash rate is
|
|
|
1% of the total network hash rate, they'll average more than one block
|
|
|
per day. That miner will only receive their portion of the rewards
|
|
|
(minus any fees charged by the pool), so they'll only receive a small
|
|
|
amount per day. If they mined every day for 20 years, they'd earn the
|
|
|
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
|
|
|
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
|
|
|
server while mining, synchronizing their efforts with the other miners.
|
|
|
Thus, the pool miners share the effort to mine a block and then share in
|
|
|
the rewards.
|
|
|
|
|
|
Successful blocks pay the reward to a pool Bitcoin address, rather than
|
|
|
individual miners. The pool server will periodically make payments to
|
|
|
the miners' Bitcoin addresses, once their share of the rewards has
|
|
|
reached a certain threshold. Typically, the pool server charges a
|
|
|
percentage fee of the rewards for providing the pool-mining service.
|
|
|
|
|
|
((("mining pools", "operation of")))Miners participating in a pool split
|
|
|
the work of searching for a solution to a candidate block, earning
|
|
|
"shares" for their mining contribution. The mining pool sets a higher
|
|
|
target (lower difficulty) for earning a share, typically more than 1,000
|
|
|
times easier than the Bitcoin network's target. When someone in the pool
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
shares, the pool measures the amount of work done by each miner. Each
|
|
|
time a pool miner finds a block header hash that is less than the pool
|
|
|
target, she proves she has done the hashing work to find that result.
|
|
|
More importantly, the work to find shares contributes, in a
|
|
|
statistically measurable way, to the overall effort to find a hash lower
|
|
|
than the bitcoin network's target. Thousands of miners trying to find
|
|
|
low-value hashes will eventually find one low enough to satisfy the
|
|
|
bitcoin network target.
|
|
|
|
|
|
Let's return to the analogy of a dice game. If the dice players are
|
|
|
throwing dice with a goal of throwing less than four (the overall
|
|
|
network difficulty), a pool would set an easier target, counting how
|
|
|
many times the pool players managed to throw less than eight. When pool
|
|
|
players throw less than eight (the pool share target), they earn shares,
|
|
|
but they don't win the game because they don't achieve the game target
|
|
|
(less than four). The pool players will achieve the easier pool target
|
|
|
much more often, earning them shares very regularly, even when they
|
|
|
don't achieve the harder target of winning the game. Every now and then,
|
|
|
one of the pool players will throw a combined dice throw of less than
|
|
|
four and the pool wins. Then, the earnings can be distributed to the
|
|
|
pool players based on the shares they earned. Even though the target of
|
|
|
eight-or-less wasn't winning, it was a fair way to measure dice throws
|
|
|
for the players, and it occasionally produces a less-than-four throw.
|
|
|
|
|
|
Similarly, a mining pool will set a (higher and easier) pool target that
|
|
|
will ensure that an individual pool miner can find block header hashes
|
|
|
that are less than the pool target often, earning shares. Every now and
|
|
|
then, one of these attempts will produce a block header hash that is
|
|
|
less than the Bitcoin network target, making it a valid block and the
|
|
|
whole pool wins.
|
|
|
|
|
|
===== Managed pools
|
|
|
|
|
|
((("mining pools", "managed pools")))((("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.
|
|
|
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
block hash. The header of the candidate block is then sent to each of
|
|
|
the pool miners as a template. Each pool miner then mines using the
|
|
|
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.
|
|
|
|
|
|
===== 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
|
|
|
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
|
|
|
single-point-of-failure. If the pool server is down or is slowed by a
|
|
|
denial-of-service attack, the pool miners cannot mine. In 2011, to
|
|
|
resolve these issues of centralization, a new pool mining method was
|
|
|
proposed and implemented: P2Pool, a peer-to-peer mining pool without a
|
|
|
central operator.
|
|
|
|
|
|
P2Pool works by decentralizing the functions of the pool server,
|
|
|
implementing a parallel blockchain-like system called a _share chain_. A
|
|
|
share chain is a blockchain running at a lower difficulty than the
|
|
|
Bitcoin blockchain. The share chain allows pool miners to collaborate in
|
|
|
a decentralized pool by mining shares on the share chain at a rate of
|
|
|
one share block every 30 seconds. Each of the blocks on the share chain
|
|
|
records a proportionate share reward for the pool miners who contribute
|
|
|
work, carrying the shares forward from the previous share block. When
|
|
|
one of the share blocks also achieves the Bitcoin network target, it is
|
|
|
propagated and included on the Bitcoin blockchain, rewarding all the
|
|
|
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.
|
|
|
|
|
|
P2Pool mining is more complex than pool mining because it requires that
|
|
|
the pool miners run a dedicated computer with enough disk space, memory,
|
|
|
and internet bandwidth to support a full Bitcoin node and the P2Pool
|
|
|
node software. P2Pool miners connect their mining hardware to their
|
|
|
local P2Pool node, which simulates the functions of a pool server by
|
|
|
sending block templates to the mining hardware. On P2Pool, individual
|
|
|
pool miners construct their own candidate blocks, aggregating
|
|
|
transactions much like solo miners, but then mine collaboratively on the
|
|
|
share chain. P2Pool is a hybrid approach that has the advantage of much
|
|
|
more granular payouts than solo mining, but without giving too much
|
|
|
control to a pool operator like managed pools.
|
|
|
|
|
|
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.((("",
|
|
|
startref="MAChash10")))((("", startref="MACoverpool10")))
|
|
|
|
|
|
[[consensus_attacks]]
|
|
|
=== Consensus Attacks
|
|
|
|
|
|
((("mining and consensus", "consensus attacks",
|
|
|
id="Cattack10")))((("security", "consensus attacks",
|
|
|
id="Sconsens10")))Bitcoin's consensus mechanism is, at least
|
|
|
theoretically, vulnerable to attack by miners (or pools) that attempt to
|
|
|
use their hashing power to dishonest or destructive ends. As we saw, the
|
|
|
consensus mechanism depends on having a majority of the miners acting
|
|
|
honestly out of self-interest. However, if a miner or group of miners
|
|
|
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
|
|
|
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.
|
|
|
|
|
|
One attack scenario against the consensus mechanism is called the "51%
|
|
|
attack." In this scenario a group of miners, controlling a majority
|
|
|
(51%) of the total network's hashing power, collude to attack bitcoin.
|
|
|
With the ability to mine the majority of the blocks, the attacking
|
|
|
miners can cause deliberate "forks" in the blockchain and double-spend
|
|
|
transactions or execute denial-of-service attacks against specific
|
|
|
transactions or addresses. A fork/double-spend attack is where the
|
|
|
attacker causes previously confirmed blocks to be invalidated by forking
|
|
|
below them and re-converging on an alternate chain. With sufficient
|
|
|
power, an attacker can invalidate six or more blocks in a row, causing
|
|
|
transactions that were considered immutable (six confirmations) to be
|
|
|
invalidated. Note that a double-spend can only be done on the attacker's
|
|
|
own transactions, for which the attacker can produce a valid signature.
|
|
|
Double-spending one's own transactions is profitable if by invalidating
|
|
|
a transaction 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 for a cup of coffee. Bob, the cafe owner, is
|
|
|
willing to accept payment for cups of coffee 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
|
|
|
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
|
|
|
delaying the transaction to obtain a signature is comparatively larger.
|
|
|
In contrast, selling a more expensive item for bitcoin runs the risk of
|
|
|
a double-spend attack, where the buyer broadcasts a competing
|
|
|
transaction that spends the same inputs (UTXO) and cancels the payment
|
|
|
to the merchant. A double-spend attack can happen in two ways: either
|
|
|
before a transaction is confirmed, or if the attacker takes advantage of
|
|
|
a blockchain fork to undo several blocks. A 51% attack allows attackers
|
|
|
to double-spend their own transactions in the new chain, thus undoing
|
|
|
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.
|
|
|
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
|
|
|
one confirmation. Mallory works with an accomplice, Paul, who operates a
|
|
|
large mining pool, and the accomplice launches a 51% attack as soon as
|
|
|
Mallory's transaction is included in a block. Paul directs the mining
|
|
|
pool to remine the same block height as the block containing Mallory's
|
|
|
transaction, replacing Mallory's payment to Carol with a transaction
|
|
|
that double-spends the same input as Mallory's payment. The double-spend
|
|
|
transaction consumes the same UTXO and pays it back to Mallory's wallet,
|
|
|
instead of paying it to Carol, essentially allowing Mallory to keep the
|
|
|
bitcoin. Paul then directs the mining pool to mine an additional block,
|
|
|
so as to make the chain containing the double-spend transaction longer
|
|
|
than the original chain (causing a fork below the block containing
|
|
|
Mallory's transaction). When the blockchain fork resolves in favor of
|
|
|
the new (longer) chain, the double-spent transaction replaces the
|
|
|
original payment to Carol. Carol is now missing the three paintings and
|
|
|
also has no bitcoin payment. Throughout all this activity, Paul's mining
|
|
|
pool participants might remain blissfully unaware of the double-spend
|
|
|
attempt, because they mine with automated miners and cannot monitor
|
|
|
every transaction or block.((("", startref="carolten")))
|
|
|
|
|
|
((("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. Alternatively,
|
|
|
the merchant should use an escrow multisignature account, again waiting
|
|
|
for several confirmations after the escrow account is funded. The more
|
|
|
confirmations elapse, the harder it becomes to invalidate a transaction
|
|
|
with a 51% attack. For high-value items, payment by bitcoin will still
|
|
|
be convenient and efficient even if the buyer has to wait 24 hours for
|
|
|
delivery, which would correspond to approximately 144 confirmations.
|
|
|
|
|
|
In addition to a double-spend attack, the other scenario for a consensus
|
|
|
attack is to deny service to specific bitcoin participants (specific
|
|
|
Bitcoin addresses). An attacker with a majority of the mining power can
|
|
|
simply ignore specific transactions. If they are included in a block
|
|
|
mined by another miner, the attacker can deliberately fork and remine
|
|
|
that block, again excluding the specific transactions. This type of
|
|
|
attack can result in a sustained denial-of-service against a specific
|
|
|
address or set of addresses for as long as the attacker controls the
|
|
|
majority of the mining power.
|
|
|
|
|
|
Despite its name, the 51% attack scenario doesn't actually require 51%
|
|
|
of the hashing power. In fact, such an attack can be attempted with a
|
|
|
smaller percentage of the hashing power. The 51% threshold is simply the
|
|
|
level at which such an attack is almost guaranteed to succeed. A
|
|
|
consensus attack is essentially a tug-of-war for the next block and the
|
|
|
"stronger" group is more likely to win. With less hashing power, the
|
|
|
probability of success is reduced, because other miners control the
|
|
|
generation of some blocks with their "honest" mining power. One way to
|
|
|
look at it is that the more hashing power an attacker has, the longer
|
|
|
the fork he can deliberately create, the more blocks in the recent past
|
|
|
he can invalidate, or the more blocks in the future he can control.
|
|
|
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
|
|
|
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
|
|
|
pool operator the power to exclude transactions or introduce
|
|
|
double-spend transactions. If such abuse of power is done in a limited
|
|
|
and subtle way, a pool operator could conceivably profit from a
|
|
|
consensus attack without being noticed.
|
|
|
|
|
|
Not all attackers will be motivated by profit, however. One potential
|
|
|
attack scenario is where an attacker intends to disrupt the Bitcoin
|
|
|
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
|
|
|
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.
|
|
|
|
|
|
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.((("",
|
|
|
startref="Cattack10")))((("", startref="MACattack10")))((("",
|
|
|
startref="Sconsens10")))
|
|
|
|
|
|
[[consensus_changes]]
|
|
|
=== Changing the Consensus Rules
|
|
|
|
|
|
((("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
|
|
|
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
|
|
|
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.
|
|
|
|
|
|
[[hard_forks]]
|
|
|
==== Hard Forks
|
|
|
|
|
|
((("forks", "changing consensus rules", id="forks10a")))((("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
|
|
|
of the network and how the network converges on a common blockchain
|
|
|
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
|
|
|
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
|
|
|
implementation of the consensus rules.
|
|
|
|
|
|
Hard forks can be used to change the rules of consensus, but they
|
|
|
require coordination between all participants in the system. Any nodes
|
|
|
that do not upgrade to the new consensus rules are unable to participate
|
|
|
in the consensus mechanism and are forced onto a separate chain at the
|
|
|
moment of the hard fork. Thus, a change introduced by a hard fork can be
|
|
|
thought of as not "forward compatible," in that nonupgraded systems can
|
|
|
no longer process the new consensus rules.
|
|
|
|
|
|
Let's examine the mechanics of a hard fork with a specific example.
|
|
|
|
|
|
<<blockchainwithforks>> shows a blockchain with two forks. At block
|
|
|
height 4, a one-block fork occurs. This is the type of spontaneous fork
|
|
|
we saw in <<forks>>. With the mining of block 5, the network converges
|
|
|
on one chain and the fork is resolved.
|
|
|
|
|
|
[[blockchainwithforks]]
|
|
|
.A blockchain with forks
|
|
|
image::images/mbc2_1009.png[A blockchain with forks]
|
|
|
|
|
|
Later, however, at block height 6, a hard fork occurs. Let's assume that
|
|
|
a new implementation of the client is released with a change in the
|
|
|
consensus rules. Starting on block height 7, miners running this new
|
|
|
implementation will accept a new type of digital signature, let's call
|
|
|
it a "Smores" signature, that is not ECDSA based. Immediately after, a
|
|
|
node running the new implementation creates a transaction that contains
|
|
|
a Smores signature and a miner with the updated software mines block 7b
|
|
|
containing this transaction.
|
|
|
|
|
|
Any node or miner that has not upgraded the software to validate Smores
|
|
|
signatures is now unable to process block 7b. From their perspective,
|
|
|
both the transaction that contained a Smores signature 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
|
|
|
are using the old rules will not accept block 7b and will continue to
|
|
|
mine a candidate block whose parent is block 6. In fact, miners using
|
|
|
the old rules may not even receive block 7b if all the nodes they are
|
|
|
connected to are also obeying the old rules and therefore not
|
|
|
propagating the block. Eventually, they will be able to mine block 7a,
|
|
|
which is valid under the old rules and does not contain any transactions
|
|
|
with Smores signatures.
|
|
|
|
|
|
The two chains continue to diverge from this point. Miners on the "b"
|
|
|
chain will continue to accept and mine transactions containing Smores
|
|
|
signatures, while miners on the "a" chain will continue to ignore these
|
|
|
transactions. Even if block 8b does not contain any Smores-signed
|
|
|
transactions, the miners on the "a" chain cannot process it. To them it
|
|
|
appears to be an invalid block, as its parent "7b" is not recognized as a
|
|
|
valid block.
|
|
|
|
|
|
==== Hard Forks: Software, Network, Mining, and Chain
|
|
|
|
|
|
((("forks", "changing consensus rules", "software forks")))For software
|
|
|
developers, the term "fork" has another meaning, adding confusion to the
|
|
|
term "hard fork." In open source software, a fork occurs when a group of
|
|
|
developers choose to follow a different software roadmap and start a
|
|
|
competing implementation of an open source project. We've already
|
|
|
discussed two circumstances that will lead to a hard fork: a bug in the
|
|
|
consensus rules and a deliberate modification of the consensus rules. In
|
|
|
the case of a deliberate change to the consensus rules, a software fork
|
|
|
precedes the hard fork. However, for this type of hard fork to occur, a
|
|
|
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
|
|
|
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
|
|
|
activated, by miners, wallets, and intermediary nodes. Conversely, there
|
|
|
are numerous alternative implementations of Bitcoin Core, and even
|
|
|
software forks, that do not change the consensus rules and barring a
|
|
|
bug, can coexist on the network and interoperate without causing a hard
|
|
|
fork.
|
|
|
|
|
|
Consensus rules may differ in obvious and explicit ways, in the
|
|
|
validation of transactions or blocks. The rules may also differ in more
|
|
|
subtle ways, in the implementation of the consensus rules as they apply
|
|
|
to bitcoin scripts or cryptographic primitives such as digital
|
|
|
signatures. Finally, the consensus rules may differ in unanticipated
|
|
|
ways because of implicit consensus constraints imposed by system
|
|
|
limitations or implementation details. An example of the latter was seen
|
|
|
in the unanticipated hard fork during the upgrade of Bitcoin Core 0.7 to
|
|
|
0.8, which was caused by a limitation in the Berkley DB implementation
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
nodes that are sending them these invalid transactions and blocks. As a
|
|
|
result, the network will 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
|
|
|
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,
|
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
|
|
|
Let's assume, for example, an 80%–20% split, with the majority of
|
|
|
the mining power using the new consensus rules. Let's also assume that
|
|
|
the fork occurs immediately after a retargeting period.
|
|
|
|
|
|
The two chains would each inherit the difficulty from the retargeting
|
|
|
period. The new consensus rules would have 80% of the previously
|
|
|
available mining power committed to them. From the perspective of this
|
|
|
chain, the mining power has suddenly declined by 20% vis-a-vis the
|
|
|
previous period. Blocks will be found on average every 12.5 minutes,
|
|
|
representing the 20% decline in mining power available to extend this
|
|
|
chain. This rate of block issuance will continue (barring any changes in
|
|
|
hashing power) until 2016 blocks are mined, which will take
|
|
|
approximately 25,200 minutes (at 12.5 minutes per block), or 17.5 days.
|
|
|
After 17.5 days, a retarget will occur and the difficulty will adjust
|
|
|
(reduced by 20%) to produce 10-minute blocks again, based on the reduced
|
|
|
amount of hashing power in this chain.
|
|
|
|
|
|
The minority chain, mining under the old rules with only 20% of the
|
|
|
hashing power, will face a much more difficult task. On this chain,
|
|
|
blocks will now be mined every 50 minutes on average. The difficulty
|
|
|
will not be adjusted for 2016 blocks, which will take 100,800 minutes,
|
|
|
or approximately 10 weeks to mine. Assuming a fixed capacity per block,
|
|
|
this will also result in a reduction of transaction capacity by a factor
|
|
|
of 5, as there are fewer blocks per hour available to record
|
|
|
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
|
|
|
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,
|
|
|
experiments, and tribulations of the bitcoin development roadmap, we
|
|
|
will see new development tools, practices, methodologies, and
|
|
|
communities emerge.
|
|
|
|
|
|
Hard forks are seen as risky because they force a minority to either
|
|
|
upgrade or remain on a minority chain. The risk of splitting the entire
|
|
|
system into two competing systems is seen by many as an unacceptable
|
|
|
risk. As a result, many developers are reluctant to use the hard fork
|
|
|
mechanism to implement upgrades to the consensus rules, unless there is
|
|
|
near-unanimous support from the entire network. Any hard fork proposals
|
|
|
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
|
|
|
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
|
|
|
clean break with the past. Finally, some developers see hard forks as a
|
|
|
mechanism that should be used rarely, with a lot of advance planning and
|
|
|
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
|
|
|
consensus modifications.
|
|
|
|
|
|
==== Soft Forks
|
|
|
|
|
|
((("forks", "changing consensus rules", "soft forks")))((("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
|
|
|
can happen without a fork.
|
|
|
|
|
|
The term _soft fork_ was introduced to distinguish this upgrade method
|
|
|
from a "hard fork." In practice, a soft fork is not a fork at all. A
|
|
|
soft fork is a forward-compatible change to the consensus rules that
|
|
|
allows unupgraded clients to continue to operate in consensus with the
|
|
|
new rules.
|
|
|
|
|
|
One aspect of soft forks that is not immediately obvious is that soft
|
|
|
fork upgrades can only be used to constrain the consensus rules, not to
|
|
|
expand them. In order to be forward compatible, transactions and blocks
|
|
|
created under the new rules must be valid under the old rules too, but
|
|
|
not vice versa. The new rules can only limit what is valid; otherwise,
|
|
|
they will trigger a hard fork when rejected under the old rules.
|
|
|
|
|
|
Soft forks can be implemented in a number of ways—the term does
|
|
|
not specify a particular method, rather a set of methods that all have
|
|
|
one thing in common: they don't require all nodes to upgrade or force
|
|
|
nonupgraded nodes out of consensus.
|
|
|
|
|
|
===== Soft forks redefining NOP opcodes
|
|
|
|
|
|
((("opcodes", "redefinition by soft forks")))((("soft forks",
|
|
|
"redefinition of NOP codes")))A number of 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
|
|
|
script is interpreted as a null-potent operator, meaning they have no
|
|
|
effect. Execution continues after the NOP opcode as if it wasn't there.
|
|
|
|
|
|
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
|
|
|
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.
|
|
|
|
|
|
===== Other ways to soft fork upgrade
|
|
|
|
|
|
The reinterpretation of NOP opcodes was both planned for and an obvious
|
|
|
mechanism for consensus upgrades. Recently, however, another soft fork
|
|
|
mechanism was introduced that does not rely on NOP opcodes for a very
|
|
|
specific type of consensus change. This is examined in more detail in
|
|
|
<<segwit>>. Segwit is an architectural change to the structure of a
|
|
|
transaction, which moves the unlocking script (witness) from inside the
|
|
|
transaction to an external data structure (segregating it). Segwit was
|
|
|
initially envisioned as a hard fork upgrade, as it modified a
|
|
|
fundamental structure (transaction). In November 2015, a developer
|
|
|
working on Bitcoin Core proposed a mechanism by which segwit could be
|
|
|
introduced as a soft fork. The mechanism used for this is a modification
|
|
|
of the locking script of UTXO created under segwit rules, such that
|
|
|
unmodified clients see the locking script as redeemable with any
|
|
|
unlocking script whatsoever. As a result, segwit can be introduced
|
|
|
without requiring every node to upgrade or split from the chain: a soft
|
|
|
fork.
|
|
|
|
|
|
It is likely that there are other, yet to be discovered, mechanisms by
|
|
|
which upgrades can be made in a forward-compatible way as a soft fork.
|
|
|
|
|
|
==== Criticisms of Soft Forks
|
|
|
|
|
|
((("forks", "changing consensus rules", "soft fork drawbacks")))((("soft
|
|
|
forks", "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.
|
|
|
|
|
|
However, many developers are concerned that other methods of soft fork
|
|
|
upgrades make unacceptable tradeoffs. Common criticisms of soft fork
|
|
|
changes include:
|
|
|
|
|
|
Technical debt:: Because soft forks are more technically complex than a
|
|
|
hard fork upgrade, they introduce _technical debt_, a term that refers
|
|
|
to increasing the future cost of code maintenance because of design
|
|
|
tradeoffs made in the past. Code complexity in turn increases the
|
|
|
likelihood of bugs and security vulnerabilities.
|
|
|
|
|
|
Validation relaxation:: Unmodified clients see transactions as valid,
|
|
|
without evaluating the modified consensus rules. In effect, the
|
|
|
unmodified clients are not validating using the full range of consensus
|
|
|
rules, as they are blind to the new rules. This applies to NOP-based
|
|
|
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
|
|
|
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
|
|
|
can be spent at any time. Therefore, critics contend that a failed soft
|
|
|
fork that had to be reversed because of a bug would almost certainly
|
|
|
lead to loss of funds.((("", startref="Crule10")))
|
|
|
|
|
|
[[softforksignaling]]
|
|
|
=== Soft Fork Signaling with Block Version
|
|
|
|
|
|
((("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
|
|
|
activation of BIP34 in March 2013 and replaced by the activation of
|
|
|
BIP9 in July 2016.
|
|
|
|
|
|
==== BIP34 Signaling and Activation
|
|
|
|
|
|
((("bitcoin improvement proposals", "Block v2, Height in Coinbase
|
|
|
(BIP34)")))The first implementation, in 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_.
|
|
|
|
|
|
BIP34 defined a consensus rule change that required the coinbase field
|
|
|
(input) of the coinbase transaction to contain the block height. Prior
|
|
|
to BIP34, the coinbase could contain any arbitrary data the miners
|
|
|
chose to include. After activation of BIP34, valid blocks had to
|
|
|
contain a specific block-height at the beginning of the coinbase and be
|
|
|
identified with a version number greater than or equal to "2."
|
|
|
|
|
|
To signal the change and activation of BIP34, miners set the block
|
|
|
version to "2," instead of "1." This did not immediately make version
|
|
|
"1" blocks invalid. Once activated, version "1" blocks would become
|
|
|
invalid and all version "2" blocks would be required to contain the
|
|
|
block height in the coinbase to be valid.
|
|
|
|
|
|
BIP34 defined a two-step activation mechanism, based on a rolling
|
|
|
window of 1000 blocks. A miner would signal his or her individual
|
|
|
readiness for BIP34 by constructing blocks with "2" as the version
|
|
|
number. Strictly speaking, these blocks did not yet have to comply with
|
|
|
the new consensus rule of including the block-height in the coinbase
|
|
|
transaction because the consensus rule had not yet been activated. The
|
|
|
consensus rules activated in two steps:
|
|
|
|
|
|
- If 75% (750 of the most recent 1000 blocks) are marked with version
|
|
|
"2," then version "2" blocks must contain block height in the coinbase
|
|
|
transaction or they are rejected as invalid. Version "1" blocks are
|
|
|
still accepted by the network and do not need to contain block-height.
|
|
|
The old and new consensus rules coexist during this period.
|
|
|
|
|
|
- When 95% (950 of the most recent 1000 blocks) are version "2," version
|
|
|
"1" blocks are no longer considered valid. Version "2" blocks are
|
|
|
valid only if they contain the block-height in the coinbase (as per
|
|
|
the previous threshold). Thereafter, all blocks must comply with the
|
|
|
new consensus rules, and all valid blocks must contain block-height in
|
|
|
the coinbase transaction.
|
|
|
|
|
|
After successful signaling and activation under the BIP34 rules, this
|
|
|
mechanism was used twice more to activate soft forks:
|
|
|
|
|
|
- https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki[BIP66]
|
|
|
Strict DER Encoding of Signatures was activated by BIP34 style
|
|
|
signaling with a block version "3" and invalidating version "2"
|
|
|
blocks.
|
|
|
|
|
|
- https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65]
|
|
|
+CHECKLOCKTIMEVERIFY+ was activated by BIP34 style signaling with a
|
|
|
block version "4" and invalidating version "3" blocks.
|
|
|
|
|
|
After the activation of BIP65, the signaling and activation mechanism
|
|
|
of BIP34 was retired and replaced with the BIP9 signaling mechanism
|
|
|
described next.
|
|
|
|
|
|
The standard is defined in
|
|
|
https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki[BIP34
|
|
|
(Block v2, Height in Coinbase)].
|
|
|
|
|
|
==== BIP9 Signaling and Activation
|
|
|
|
|
|
((("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
|
|
|
because it had several limitations:
|
|
|
|
|
|
- By using the integer value of the block version, only one soft fork
|
|
|
could be activated at a time, so it required coordination between soft
|
|
|
fork proposals and agreement on their prioritization and sequencing.
|
|
|
|
|
|
- Furthermore, because the block version was incremented, the mechanism
|
|
|
didn't offer a straightforward way to reject a change and then propose
|
|
|
a different one. If old clients were still running, they could mistake
|
|
|
signaling for a new change as signaling for the previously rejected
|
|
|
change.
|
|
|
|
|
|
- Each new change irrevocably reduced the available block versions for
|
|
|
future changes.
|
|
|
|
|
|
BIP9 was proposed to overcome these challenges and improve the rate and
|
|
|
ease of implementing future changes.
|
|
|
|
|
|
BIP9 interprets the block version as a bit field instead of an integer.
|
|
|
Because the block version was originally used as an integer, versions 1
|
|
|
through 4, only 29 bits remain available to be used as a bit field. This
|
|
|
leaves 29 bits that can be used to independently and simultaneously
|
|
|
signal readiness on 29 different proposals.
|
|
|
|
|
|
BIP9 also sets a maximum time for signaling and activation. This way
|
|
|
miners don't need to signal forever. If a proposal is not activated
|
|
|
within the +TIMEOUT+ period (defined in the proposal), the proposal is
|
|
|
considered rejected. The proposal may be resubmitted for signaling with
|
|
|
a different bit, renewing the activation period.
|
|
|
|
|
|
Furthermore, after the +TIMEOUT+ has passed and a feature has been
|
|
|
activated or rejected, the signaling bit can be reused for another
|
|
|
feature without confusion. Therefore, up to 29 changes can be signaled
|
|
|
in parallel and after +TIMEOUT+ the bits can be "recycled" to propose
|
|
|
new changes.
|
|
|
|
|
|
[NOTE]
|
|
|
====
|
|
|
While signaling bits can be reused or recycled, as long as the voting
|
|
|
period does not overlap, the authors of BIP9 recommend that bits are
|
|
|
reused only when necessary; unexpected behavior could occur due to bugs
|
|
|
in older software. In short, we should not expect to see reuse until all
|
|
|
29 bits have been used once.
|
|
|
====
|
|
|
|
|
|
Proposed changes are identified by a data structure that contains the following fields:
|
|
|
|
|
|
name:: A short description used to distinguish between proposals. Most
|
|
|
often the BIP describing the proposal, as "bipN," where N is the BIP
|
|
|
number.
|
|
|
|
|
|
bit:: 0 through 28, the bit in the block version that miners use to
|
|
|
signal approval for this proposal.
|
|
|
|
|
|
starttime:: The time (based on Median Time Past, or MTP) that signaling
|
|
|
starts after which the bit's value is interpreted as signaling readiness
|
|
|
for the proposal.
|
|
|
|
|
|
endtime:: The time (based on MTP) after which the change is considered
|
|
|
rejected if it has not reached the activation threshold.
|
|
|
|
|
|
Unlike BIP34, BIP9 counts activation signaling in whole intervals
|
|
|
based on the difficulty retarget period of 2016 blocks. For every
|
|
|
retarget period, if the sum of blocks signaling for a proposal exceeds
|
|
|
95% (1916 of 2016), the proposal will be activated one retarget period
|
|
|
later.
|
|
|
|
|
|
BIP9 offers a proposal state diagram to illustrate the various stages
|
|
|
and transitions for a proposal, as shown in <<bip9states>>.
|
|
|
|
|
|
Proposals start in the +DEFINED+ state, once their parameters are known
|
|
|
(defined) in the bitcoin software. For blocks with MTP after the start
|
|
|
time, the proposal state transitions to +STARTED+. If the voting
|
|
|
threshold is exceeded within a retarget period and the timeout has not
|
|
|
been exceeded, the proposal state transitions to +LOCKED_IN+. One
|
|
|
retarget period later, the proposal becomes +ACTIVE+. Proposals remain
|
|
|
in the +ACTIVE+ state perpetually once they reach that state. If the
|
|
|
timeout elapses before the voting threshold has been reached, the
|
|
|
proposal state changes to +FAILED+, indicating a rejected proposal.
|
|
|
+FAILED+ proposals remain in that state perpetually.
|
|
|
|
|
|
[[bip9states]]
|
|
|
.BIP9 state transition diagram
|
|
|
image::images/mbc2_1010.png[BIP9 Proposal State Transition Diagram]
|
|
|
|
|
|
BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+
|
|
|
and associated BIPs (68, 112, 113). The proposal named "csv" was
|
|
|
activated successfully in July of 2016.((("", startref="forks10a")))
|
|
|
|
|
|
The standard is defined in
|
|
|
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki[BIP9
|
|
|
(Version bits with timeout and delay)].
|
|
|
|
|
|
=== Consensus Software Development
|
|
|
|
|
|
((("mining and consensus", "consensus software
|
|
|
development")))((("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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
must coordinate, or no changes can be made. Status quo is the stable
|
|
|
state of this system with only a few changes possible if there is strong
|
|
|
consensus by a very large majority. The 95% threshold for soft forks is
|
|
|
reflective of this reality.
|
|
|
|
|
|
((("hard forks")))It is important to recognize that there is no perfect
|
|
|
solution for consensus development. Both hard forks and soft forks
|
|
|
involve tradeoffs. For some types of changes, soft forks may be a better
|
|
|
choice; for others, hard forks may be a better choice. There is no
|
|
|
perfect choice; both carry risks. The one constant characteristic of
|
|
|
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.
|
