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