mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-23 15:18:11 +00:00
610 lines
55 KiB
Plaintext
610 lines
55 KiB
Plaintext
[[ch8]]
|
|
== Chapter 8 - Consensus & Mining
|
|
|
|
*DRAFT - DO NOT SUBMIT ISSUES OR PULL REQUESTS YET PLEASE - CONSTANT CHANGES HAPPENING*
|
|
|
|
[[mining]]
|
|
=== Introduction - Mining and Consensus
|
|
|
|
Mining is the process by which new bitcoin is added to the money supply. Mining also serves to secure the bitcoin system against fraudulent transactions or transactions spending the same amount of bitcoin more than once, known as a double-spend. Miners act as a decentralized clearinghouse, validating new transactions and recording them on the global ledger. A new block, containing transactions which occurred since the last block, is "mined" every 10 minutes 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 spend the bitcoin they received in those transactions. Miners receive two types of reward for mining: new coins created with each new block and transaction fees from all the transactions included in the block. To earn this reward, the miners compete to solve a difficult mathematical problem 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 reward and the right to record transactions on the blockchain is the basis for bitcoin's security model.
|
|
|
|
=== Mining
|
|
|
|
Bitcoin's security is underpinned by computation. New blocks are added to the blockchain through a consensus mechanism called the _Proof-of-Work_ (PoW) that requires a predictable computational effort, one that takes approximately 10 minutes to solve on average. Specialized bitcoin nodes called _miners_ validate transactions and collect them into blocks, then attempt to find the solution that satisfies the Proof-of-Work algorithm. The first miner to find such a solution, propagates the newly created block across the network. All other nodes on the network verify that the new block contains valid transactions and satisfies the Proof-of-Work algorithm, then they add it to the blockchain, thereby extending it by one block. The miners add a special coin generation transaction into the blocks they build, which creates new bitcoin from nothing and is payable to the miner's own bitcoin address. Once the block is accepted as valid by the entire network, that transaction is also recorded on the blockchain, thereby rewarding the miner for the computational effort it took to satisfy the Proof-of-Work. This de-centralized consensus mechanism, based on a global competition and requiring computation to create new blocks, is the basis for the security of the bitcoin transaction ledger and also for the issuance of new bitcoin. {move the last sentence to the beginning of the paragraph - to explain more about security} The equilibrium between the incentive of bitcoin reward and the immense computing effort required to win it force the participants to behave honestly, without the need for a centralized clearinghouse or currency issuer. The bitcoin consensus mechanism is a dynamic, self-regulating and completely decentralized security model that operates at very large scale.
|
|
|
|
The process of new coin generation is called mining, because the reward is designed to simulate diminishing returns, just like mining for precious metals. Bitcoin's money supply is created through mining, just like a central bank issues new money by printing bank notes. The 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 will halve again to 12.5 bitcoin per block sometime in 2016. Based on this formula, bitcoin mining rewards decrease exponentially until approximately the year 2140 when all 21 million bitcoin have been 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 bitcoin miner gets to "keep the change" on the transactions.
|
|
|
|
Today the fees represent 1% or less of a bitcoin miner's income, the vast majority coming from the newly minted bitcoins. 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. After 2140 all bitcoin miner earnings will be in the form of transaction fees.
|
|
|
|
=== Mining Nodes
|
|
|
|
Some of the nodes on the bitcoin network are specialized nodes called _miners_. In Chapter 1 we introduced 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 bitcoins. 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 which acts as an announcement of a winner. To a miner, receiving a 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 starting the race for the next block.
|
|
|
|
==== Bitcoin Economics and Currency Creation
|
|
|
|
Bitcoins are "minted" during the creation of each block at a fixed and diminishing rate. Each block, generated on average every 10 minutes, contains a _reward_ that consists of entirely new bitcoins. The reward was 50BTC for the first four years of operation of the network. Every four years the reward is decreased by 50%, resulting in a diminishing rate of issuance over time. In 2012, the reward was decreased to 25BTC and it will decrease again to 12.5BTC in 2016. By approximately 2140, the last fragments of a bitcoin will be mined, for a total of 21 million bitcoins. {Clarify coinbase transaction as first - includes the reward and transactions. Discuss how the coinbase transaction will change in 2140}
|
|
|
|
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.
|
|
|
|
===== Monetary supply
|
|
|
|
Bitcoin's monetary supply is defined as the number of coins in circulation (minted). Like any other currency, this measure of monetary supply is called M0, which represents the narrowest measure of the money supply. Just like any other currency, bitcoin can also have a _fractional reserve banking_ which means that an organization can trade bitcoins "off blockchain" which are not part of the M0 monetary measure, but of the broader monetary supply measures M1-M3. {have you explained M1-M3?}{also, i think you should explain fractional reserve banking a bit here}
|
|
|
|
While the total bitcoins in circulation will not exceed 21m, that monetary base can support a much broader economy through fractional reserve banking and expansion of the available credit.
|
|
|
|
===== Deflationary Money
|
|
|
|
The most important and debated consequence of a fixed and diminishing monetary issuance is that the currency will tend 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 your 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, the incentives for regular people are to hoard the money and not spend 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, we associate deflation 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 predictably constrained supply.
|
|
|
|
In practice, it has become evident that the hoarding instinct caused by a deflationary currency can be overcome by discounting from vendors, until the discount overcomes the hoarding instinct of the buyer. Since the seller is also motivated to hoard, the discount becomes the equilibrium price at which the two hoarding instincts are matched. With discounts of 30% on the bitcoin price, most bitcoin retailers are not experiencing difficulty overcoming the hoarding instinct and generating revenue. It remains to be seen whether the deflationary aspect of the currency is really a problem when it is not driven by rapid economic retraction.
|
|
|
|
=== De-centralized Consensus
|
|
|
|
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 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.
|
|
|
|
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 central authority or trust derive from this invention.
|
|
|
|
Bitcoin's de-centralized consensus emerges from the interplay of four processes that occur independently on nodes across the network:
|
|
|
|
* 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.
|
|
|
|
Before we explore the details of emergent consensus, we will first discuss mining and the central role it plays in this process.
|
|
|
|
=== Independent Verification of Transactions
|
|
|
|
In the previous chapter 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 may 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:
|
|
|
|
* Check the syntactic correctness of the transaction's data structure
|
|
* Make sure 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 0)
|
|
* Check none of the inputs have hash=0, N=-1 (coinbase transactions should not be relayed)
|
|
* Check that nLockTime is less than or equal to INT_MAX
|
|
* Check that the transaction size in bytes is greater than or equal to 100
|
|
* Check the number of signature operations contained in the transaction is less than the signature operation limit
|
|
* Reject "nonstandard" transactions: unlocking script (scriptSig) doing anything other than pushing numbers on the stack, or the locking script (scriptPubkey) not matching isStandard forms
|
|
* Check for a matching transaction in the pool, or in a block in the main branch, if so reject this transaction
|
|
* For each input, if the referenced output exists in any other transaction in the pool, reject this transaction.
|
|
* 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, 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; else reject this transaction
|
|
* For each input, if the referenced output does not exist (e.g. never existed or has already been spent), reject this transaction
|
|
* 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 < sum of output values
|
|
* Reject if transaction fee would be too low to get into an empty block
|
|
* Verify the unlocking scripts for each input against the corresponding output locking scripts
|
|
|
|
These conditions can be seen in detail in the functions +AcceptToMemoryPool+, +CheckTransaction+ and +CheckInputs+ in the bitcoin reference client. 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 new transactions (the transaction pool), roughly in the same order.
|
|
|
|
=== Aggregating Transactions into Blocks
|
|
|
|
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 <<cup_of_coffee>>). Alice's transaction was included in block 277316. For the purpose of demonstrating the concepts in this chapter let's assume that block was mined by Jing's mining system and follow Alice's transaction as it becomes part of this new block.
|
|
|
|
Jing's mining node maintains a local copy of the blockchain, the list of all blocks created since the beginning of the bitcoin system in 2009. By the time Alice buys the cup of coffee, Jing's node has assembled a chain of 277,314 blocks. 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 check all the transactions in the memory pool and remove any that were included in block 277,315. Whatever transaction remain in the memory pool are unconfirmed and are waiting to be recorded in a new block.
|
|
|
|
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.
|
|
|
|
==== Transaction Age, Fees and Priority
|
|
|
|
To construct the candidate block Jing's bitcoin node selects transactions from the memory pool, by applying a priority metric to each transaction and adding the highest priority transactions first. Transactions are prioritized based on the "age" of the UTXO that is being spent in their inputs, allowing for old and high-value inputs to be prioritized over newer and smaller inputs. Prioritized transactions can be sent without any fees, if there is enough space in the block.
|
|
|
|
The priority of a transaction is calculated as the sum of the value and age of the inputs divided by the total size of the transaction:
|
|
----
|
|
Priority = Sum (Value of input * Input Age) / Transaction Size
|
|
----
|
|
|
|
In the equation above, the value of an input is measured in the base unit, satoshis (1/100m of a bitcoin). The age of a UTXO is the number of blocks that have elapsed since the UTXO was recorded on the blockchain, measuring how many blocks "deep" into the blockchain it is. The size of the transaction is measured in bytes.
|
|
|
|
For a transaction to be considered "high priority" its priority must be greater than 57,600,000, which corresponds to one bitcoin (100m satoshis), aged one day (144 blocks) in a transaction of 250 bytes total size.
|
|
|
|
----
|
|
High Priority = 100,000,000 satoshis * 144 blocks / 250 bytes = 57,600,000
|
|
----
|
|
|
|
The first 50 kilobytes of transaction space in a block are set aside for high priority transactions. Jing's node will fill the first 50 kilobytes, prioritizing the highest priority transactions first, regardless of fee. This allows high-priority transactions to be processed even if they carry zero fees.
|
|
|
|
Jing's mining node then fills the rest of the block up to the maximum block size (MAX_BLOCK_SIZE in the code), with transactions that carry at least the minimum fee, prioritizing those with the highest fee per kilobyte of transaction.
|
|
|
|
If there is any space remaining in the block, Jing's mining node may choose to fill it with no-fee transactions. Some miners choose to mine transactions without fees on a best-effort basis. Other miners may choose to ignore transactions without fees.
|
|
|
|
Any transactions left in the memory pool after the block is filled will remain in the pool for inclusion in the next block. As transactions remain in the memory pool, their inputs "age", as the UTXO they spend get deeper into the blockchain with new blocks added on top. Since a transactions priority depends on the age of its inputs, transactions remaining in the pool will age and therefore increase in priority. Eventually a transaction without fees may reach a high enough priority to be included in the block for free.
|
|
|
|
Bitcoin transactions do not have an expiration time-out. A transaction that is valid now will be valid in perpetuity. However, if a transaction is only propagated across the network once it will persist only as long as it is held in a mining node memory pool. When a mining node is restarted, its memory pool is wiped clear, as it is a transient non-persistent form of storage. While a valid transaction may have been propagated across the network, if it is not executed it may eventually not reside in the memory pool of any miner. Wallet software is expected to retransmit such transactions or reconstruct them with higher fees if they are not successfully executed within a reasonable amount of time.
|
|
|
|
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:
|
|
====
|
|
[source,bash]
|
|
----
|
|
$ bitcoin-cli getblockhash 277316
|
|
0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
|
|
|
|
$ bitcoin-cli getblock 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
|
|
----
|
|
====
|
|
[[block277316]]
|
|
.Block 277,316
|
|
====
|
|
[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",
|
|
"nextblockhash" : "000000000000000010236c269dd6ed714dd5db39d36b33959079d78dfd431ba7"
|
|
}
|
|
----
|
|
====
|
|
|
|
==== The Generation Transaction
|
|
|
|
The first transaction added to the block is a special transaction, called a _generation transaction_ or _coinbase transaction_. This transaction is constructed by Jing's node and is his reward for the mining effort. Jing's node creates the generation 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 bitcoins) and the transaction fees (0.09094928) from all the transactions included in the block.
|
|
|
|
|
|
====
|
|
[source, bash]
|
|
----
|
|
$ bitcoin-cli getrawtransaction d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f 1
|
|
----
|
|
====
|
|
|
|
[[generation_tx_example]]
|
|
.Generation Transaction
|
|
====
|
|
[source,json]
|
|
----
|
|
{
|
|
"hex" : "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0f03443b0403858402062f503253482fffffffff0110c08d9500000000232102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac00000000",
|
|
"txid" : "d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f",
|
|
"version" : 1,
|
|
"locktime" : 0,
|
|
"vin" : [
|
|
{
|
|
"coinbase" : "03443b0403858402062f503253482f",
|
|
"sequence" : 4294967295
|
|
}
|
|
],
|
|
"vout" : [
|
|
{
|
|
"value" : 25.09094928,
|
|
"n" : 0,
|
|
"scriptPubKey" : {
|
|
"asm" : "02aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21 OP_CHECKSIG",
|
|
"hex" : "2102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac",
|
|
"reqSigs" : 1,
|
|
"type" : "pubkey",
|
|
"addresses" : [
|
|
"1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N"
|
|
]
|
|
}
|
|
}
|
|
],
|
|
"blockhash" : "0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4",
|
|
"confirmations" : 35566,
|
|
"time" : 1388185914,
|
|
"blocktime" : 1388185914
|
|
}
|
|
----
|
|
====
|
|
|
|
Unlike regular transactions, the generation transaction does not consume (spend) UTXO as inputs. Instead, it has only one input, called the _coinbase_, which creates bitcoin from nothing. The generation transaction has one output, payable to the miner's own bitcoin address. The output of the generation transaction sends the value of 25.09094928 bitcoins to the miner's bitcoin address, in this case +1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N+.
|
|
|
|
==== Coinbase Reward and Fees
|
|
|
|
To construct the generation 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. Since this block is at height 277,316, the correct reward is 25 bitcoin.
|
|
|
|
The calculation can be seen in function +GetBlockValue+ in the Bitcoin Core client:
|
|
|
|
[[getblockvalue_source]]
|
|
.Calculating the block reward - Function GetBlockValue, Bitcoin Core Client, main.cpp, line 1305
|
|
====
|
|
[source, cpp]
|
|
----
|
|
int64_t GetBlockValue(int nHeight, int64_t nFees)
|
|
{
|
|
int64_t nSubsidy = 50 * COIN;
|
|
int halvings = nHeight / Params().SubsidyHalvingInterval();
|
|
|
|
// Force block reward to zero when right shift is undefined.
|
|
if (halvings >= 64)
|
|
return nFees;
|
|
|
|
// Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
|
|
nSubsidy >>= halvings;
|
|
|
|
return nSubsidy + nFees;
|
|
}
|
|
----
|
|
====
|
|
|
|
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.
|
|
|
|
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 (return only the fees) if the 64 halvings is exceeded.
|
|
|
|
Next, the function uses the binary-right-shift operator to divide the reward (+nSubsidy+) by 2 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 bitcoin. The binary-right-shift operator is used because it is more efficient for division by 2 than integer or floating point division.
|
|
|
|
Finally, the coinbase reward (+nSubsidy+) is added to the transaction fees (+nFees+), and the sum is returned.
|
|
|
|
==== Structure of the Generation Transaction
|
|
|
|
With these calculations, Jing's node then constructs the generation transaction to pay himself 25.09094928 bitcoin. The generation transaction is the first transaction in the block, so we can see it in more detail using the Bitcoin Core command-line interface:
|
|
|
|
As you can see in <<generation_tx_example>>, the generation 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 <<tx_in_structure>>. Let's compare a regular transaction input with a generation transaction input. A regular transaction looks like this:
|
|
|
|
.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
|
|
|=======
|
|
|
|
|
|
The generation transaction input, however, looks like this:
|
|
|
|
.The structure of a generation 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: 0xFFFF
|
|
| 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 generation 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" is replaced by coinbase data, an arbitrary data field used by the miners.
|
|
|
|
==== Coinbase Data
|
|
|
|
Generation transactions do not have an unlocking script (a.k.a scriptSig) field. Instead, this field is replaced by coinbase data, which must be between 2 and 100 bytes. Except for the first few bytes (see below) the rest of the coinbase data can be used by miners in any way they want, it is arbitrary data.
|
|
|
|
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 (see <<mining>>) and strings identifying the mining pool, as we will see in the following sections.
|
|
|
|
The first few bytes of the coinbase used to be arbitrary, but that is no longer the case. As per Bitcoin Improvement Proposal 34 (BIP0034), 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 3 bytes onto the script stack (see <<tx_script_ops_table_pushdata>>). The next 3 bytes, +0x443b04+, are the block height encoded in little-endian format (backwards, least significant bit first). Reverse the order of the bytes and the result is +0x043b44+ which is 277,316 in decimal.
|
|
|
|
The next few hexadecimal digits (+03858402062+) are used to encode an extra _nonce_, or random value, used to find a suitable proof-of-work solution. This is discussed in more detail in the next section on <<mining>>
|
|
|
|
The final part of the coinbase data (+2f503253482f+) is the ASCII-encoded string "/P2SH/", which indicates that mining node that mined this block supports the Pay-to-Script-Hash (P2SH) improvement defined in BIP0016. The introduction of the P2SH capability required a "vote" by miners to endorse either BIP0016 or BIP0017. Those endorsing the BIP0016 implementation were to include "/P2SH/" in their coinbase data. Those endorsing the BIP0017 implementation of P2SH were to include the string "p2sh/CHV" in their coinbase data. The BIP0016 was elected as the winner, and many miners continued including the string "/P2SH/" in their coinbase to indicate support for this feature.
|
|
|
|
=== Constructing the Block Header
|
|
|
|
To construct the block header, the mining node needs to fill in six fields:
|
|
|
|
[[block_header_structure]]
|
|
.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 | Difficulty Target | The proof-of-work algorithm difficulty target for this block
|
|
| 4 bytes | Nonce | A counter used for the proof-of-work algorithm
|
|
|=======
|
|
|
|
At the time 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+.
|
|
|
|
Next, the mining node needs to add the "Previous Block Hash". 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+.
|
|
|
|
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 generation 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 +c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e+ which you can see listed as "merkle root" in <<block277316>>
|
|
|
|
The 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 1st, 1970, midnight UTC/GMT. The time +1388185914+ is equal to Friday, 27 Dec 2013, 23:11:54 UTC/GMT.
|
|
|
|
The node then fills in the difficulty target, which defines the required proof-of-work difficulty to make this a valid block. The difficulty is stored in the block as a "difficulty bits" metric, which is a mantissa-exponent encoding of the target. The encoding has a one-byte exponent, followed by a 3 byte mantissa (coefficient). In block 277,316, for example, the difficulty bits value is +0x1903a30c+. The first part +0x19+ is a hexadecimal exponent, while the next part +0x03a30c+ is the coefficient. The concept of a difficulty target is explained in <<difficulty_target>> and the "difficulty bits" representation is explained in <<difficulty_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 difficulty 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
|
|
|
|
==== Proof-of-Work Algorithm
|
|
|
|
With SHA-256, the output is always 256 bits long, regardless of the size of the input. In the example below, we will use the Python interpreter to calculate the SHA256 hash of the phrase "I am Satoshi Nakamoto".
|
|
|
|
[[sha256_example1]]
|
|
.SHA256 Example
|
|
----
|
|
$ *python*
|
|
Python 2.7.1
|
|
>>> import hashlib
|
|
>>> print hashlib.sha256("I am Satoshi Nakamoto").hexdigest()
|
|
5d7c7ba21cbbcd75d14800b100252d5b428e5b1213d27c385bc141ca6b47989e
|
|
----
|
|
|
|
The example shows that if we calculate the hash of the phrase +"I am Satoshi Nakamoto"+, it will produce +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 character will produce a different hash.
|
|
|
|
Now, if we vary the phrase, we will expect to see completely different hashes. Let's try that by adding a number to the end of our phrase, using this simple Python script
|
|
|
|
[[sha256_example_generator]]
|
|
.SHA256 A script for generating many hashes by iterating on a nonce
|
|
====
|
|
[source, python]
|
|
----
|
|
include::code/hash_example.py[]
|
|
----
|
|
====
|
|
|
|
Running this will produce the hashes of several phrases, made different by adding a unique number, called a _nonce_ at the end of the text. By incrementing the nonce, we can get different hashes.
|
|
((("nonce")))
|
|
[[sha256_example_generator_output]]
|
|
.SHA256 Output of a script for generating many hashes by iterating on a nonce
|
|
----
|
|
$ *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 re-produce the exact results in this example on any computer with Python and see the same exact hashes.
|
|
|
|
To make a challenge out of this algorithm, let's set an arbitrary target: find a phrase starting with "I am Satoshi Nakamoto" which produces a hash that starts with a zero. In numerical terms, that means finding a hash value that is less than +0x1000000000000000000000000000000000000000000000000000000000000000+. Fortunately, this isn't so difficult! If you notice above, we can see that the phrase "I am Satoshi Nakamoto13" produces the hash 0ebc56d59a34f5082aaef3d66b37a661696c2b618e62432727216ba9531041a5, which fits our criteria. It only took 13 attempts to find it.
|
|
|
|
Bitcoin's proof-of-work is very similar to the problem above. First, a miner will generate a new block, containing:
|
|
((("block")))
|
|
* Transactions waiting to be included in a block
|
|
* The hash from the previous block
|
|
* A _nonce_
|
|
|
|
The only part a miner can modify is the nonce. Now, the miner will calculate the hash of this block's header and see if it is smaller than the current _target difficulty_. The miner will likely have to try many nonces before finding one that results in a low enough hash.
|
|
|
|
A very simplified proof-of-work algorithm is implemented in Python here:
|
|
((("proof of work")))
|
|
[[pow_example1]]
|
|
.Simplified Proof-Of-Work Implementation
|
|
====
|
|
[source, python]
|
|
----
|
|
include::code/proof-of-work-example.py[]
|
|
----
|
|
====
|
|
|
|
Running the code above, 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 the following examples, you can see how it works on an average laptop:
|
|
|
|
[[pow_example_outputs]]
|
|
.Running the proof-of-work example for various difficulties
|
|
----
|
|
$ *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 an exponential increase 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 the example above, 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 thousand hashes per second, it still requires ten minutes on a consumer laptop to find this solution.
|
|
|
|
At the time of writing this, the network is attempting to find a block whose header hash is less than +000000000000004c296e6376db3a241271f43fd3f5de7ba18986e517a243baa7+. As you can see, there are a lot of zeroes at the beginning of that hash, meaning that the acceptable range of hashes is much smaller, hence more difficult to find a valid hash. It will take on average more 150 quadrillion hash calculations per second for the network to discover the next block. That seems like an impossible task, but fortunately the network is bringing 500 TH/sec of processing power to bear, which will be able to find a block in about 10 minutes on average.
|
|
|
|
==== Difficulty Representation
|
|
|
|
The formula to calculate the difficulty target from this representation is:
|
|
|
|
----
|
|
target = coefficient * 2^(8 * (exponent - 3))
|
|
----
|
|
|
|
Using that formula, we can
|
|
difficulty bits is 0x1903a30c
|
|
|
|
----
|
|
target = 0x03a30c * 2^(0x08 * (0x19 - 0x03))^
|
|
=> target = 0x03a30c * 2^(0x08 * 0x16)^
|
|
=> target = 238,348 * 2^176^
|
|
=> target = 238,348 * 2^176^
|
|
=> target = 9,223,372,036,854,775,807
|
|
=> target = 0x0000000000000003A30C00000000000000000000000000000000000000000000
|
|
----
|
|
|
|
==== Difficulty Target and Re-Targetting
|
|
|
|
Bitcoin is tuned to generate blocks approximately every 10 minutes. This is achieved by automatically adjusting the target difficulty to account for increases and decreases in the available computing power on the network. This process occurs automatically and on every full node independently. Each node recalculates the expected difficulty every 2106 blocks, based on the time it took to hash the previous 2106 blocks. In simple terms: If the network is finding blocks faster than every 10 minutes, the difficulty increases. If block discovery is slower than expected, the difficulty will decrease.
|
|
|
|
{miners that are on mining pools get the difficulty (do not calculate difficulty independently) they are given the difficulty from the mining pool so they don't have to calculate the difficulty themselves and they are actually given a lower difficulty target. There are essentially two classifications of miners today - pool miners and solo miners. Solo miners run a full node and compete on their own. Whereas pool miners collaborate with one another and compete against the network as a team, while sharing the reward. The reason miners join pools - solo miners need an enormous amount of hashing power in order to have even the slimmest chance of finding a solution to a block which will make their earnings erratic. By participating in a pool, miners get smaller shares but a more regular share of rewards, reducing uncertainty. Solo mining is becoming obsolete, as the difficulty increases the likelihood of a solo miner finding a solution is more like winning the lottery.}
|
|
|
|
{ASIC miners do not run full nodes. Full nodes independently calculate the difficulty using the same equation on the same block, arriving at the same result for the new difficulty. Retargeting the difficulty at block heights that are multiples of 2106 from the genesis block. The equation for retargeting difficulty measures the time it took to find the last 2106 blocks, compares that to the expected time of 21,060 minutes (based upon a desired 10 minute block time), the difference is calculated as a percentage and a corresponding percentage adjustment is made to the difficulty. To avoid extreme volatility in the difficulty, the retargeting adjustment cannot exceed {X%} per retargeting. The difficulty will only be retargeted up or down by maximum of {X%} per cycle. If the required difficulty adjustment is greater than the maximum it will be reflected in the next retargeting adjustment as the imbalance will persist through the next 2106 blocks. Large discrepancies between hashing power and difficulty may take several cycles to even out. This leads to a potential problem which has been observed in alt coins, where very large changes in difficulty can cause hashing power to collapse leading to excessively long block times. If the aggregate network hashing power collapses due to the departure of many miners simultaneously, the remaining hashing power may be insufficient to meet the difficulty target leading to excessively long block intervals. Since retargeting is not a function of time but rather block number, a large hashing deficit can mean the next cycle is very far in the future. Usually this is caused for two reasons - scenario one - entry for a brief period of a lot of hashing which temporarily increases the difficulty, followed by the departure of that hashing, resulting in a collapse of block solutions. Essentially a hashing pump and dump. Usually a deliberate attack. This is not a concern in bitcoin because new hashing power introduced into the network will not effect the average enough to cause a major change in difficulty. The other scenario in which hashing power can collapse is a crash in bitcoin price, making mining unprofitable. (If the miner cannot pay their electricity bill, the miner will leave the network.) This is a weakness of the protocol, as an insurmountable hashing deficit could occur with a precipitous collapse in price and corresponding reduction in available hashing power. The network would be unable to recover because ... }
|
|
|
|
[TIP]
|
|
====
|
|
The difficulty of finding a bitcoin block is approximately '10 minutes of processing' for the entire network, based on the time it took to find the previous 2106 blocks, adjusted every 2106 blocks.
|
|
====
|
|
|
|
Note that the target difficulty 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 target difficulty 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 in bitcoin, as that determines the profitability of mining and therefore the incentives to enter or exit the mining market.
|
|
|
|
=== Selecting the Highest-Difficulty Chain
|
|
|
|
[[forks]]
|
|
==== Blockchain Forks
|
|
|
|
{Discuss chain selection: As new blocks are found they are added to the chain. Each full node constructs a chain and calculates the cumulative difficulty of that chain. As blocks are constructed and propagated across the network,}
|
|
|
|
{create a graphic showing propagating transaction}
|
|
|
|
{Because the blockchain is a decentralized data structure, different copies of it are not always consistent. Blocks may arrive at different nodes at different times, causing them to have a different perspective o ft 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 difficulty chain, by adding the difficulty recorded in each block for a chain a node can calculate the total amount of PoW that has been expended to create that chain. As long as all nodes select the longest, i.e. the longest cumulative difficulty 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 the eventual reconvergence.}
|
|
|
|
{Bitcoin's _consensus mechanism_, which creates the is comprised of the independent validation of transactions by every node, the cumulative work of the miners, and the network convergence upon the greatest difficulty chain. The interplay of these three processes manifests the emergent property of consensus that allows for a global decentralized public ledger without a central authority. which creates one global public ledger, emerges as a property of (1) the selection of the greatest difficulty chain. This chapter is about the emergent property of consensus. This consensus is created by the interplay of three processes - (1) ,2,3. The emergent property of network-wide consensus is what establishes a trusted decentralized global public ledger. Satohsi's invention was not proof of work, elliptic curve cryptography. Satoshi's invention was how the interplay of these processes creates emergent consensus in a decentralized network without the need for a centralized trusted authority.}
|
|
|
|
|
|
[[fork1]]
|
|
.Visualization of a blockchain fork event - Before the Fork
|
|
image::images/GlobalFork1.png["globalfork1"]
|
|
|
|
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 their blockchain, extending the blockchain by one block. If that node later sees another candidate block extending the same parent, they ignore the second candidate. 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.
|
|
|
|
{create a graphic with the globe, two miners each - bitcoin topology map}
|
|
|
|
[[fork2]]
|
|
.Visualization of a blockchain fork event - Two blocks found simultaneously
|
|
image::images/GlobalFork2.png["globalfork2"]
|
|
|
|
Let's assume for example that a miner in Canada finds a proof-of-work solution for block "A" that extends the blockchain from height 315000 to height 315001, building on top of parent block "P". Almost simultaneously, an Australian miner who was also extending block "P", finds a solution for block "B", their candidate block. Now, there are two possible candidates for block height 315001, one we call "A", originating in Canada and one we call "B", originating in Australia. Both blocks are valid, both blocks contain a valid solution to the proof of work, both blocks extend the same parent. Both blocks likely contain most of the same transactions, with only perhaps a few differences in the order of transactions.
|
|
|
|
[[fork2]]
|
|
.Visualization of a blockchain fork event - Two blocks propagate, splitting the network
|
|
image::images/GlobalFork3.png["globalfork3"]
|
|
|
|
From that moment, the bitcoin network nodes closest (topologically, not geographically) to the Canadian node will hear about block "A" first and will create a new greatest-cumulative-difficulty blockchain with height 315001 and "A" as the last block in the chain (e.g. P-A), ignoring the candidate block "B" that arrives a bit later. Meanwhile, nodes closer to the Australian node will take that block as the winner and extend the blockchain to height 315001 with "B" as the last block (e.g. P-B), ignoring "A" when it arrives a few seconds later. Any miners that saw "A" first will immediately build candidate blocks that reference "A" as the parent and start trying to solve the PoW for these candidate blocks. The miners that accepted "B" instead, will start extending that chain.
|
|
|
|
----
|
|
Block "A" extends the chain: P-A
|
|
Block "B" also extends the chain: P-B
|
|
----
|
|
|
|
[[fork4]]
|
|
.Visualization of a blockchain fork event - A new block extends one fork
|
|
image::images/GlobalFork4.png["globalfork4"]
|
|
|
|
Forks are almost always resolved within one block. As part of the network's hashing power is dedicated to building on top of "A" as the parent, another part of the hashing power is focused on building on top of "B". 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 "B" find a new block "X" that extends the chain to height 315002 (e.g. P-B-X). They immediately propagate this new block and the entire network sees it as a valid solution.
|
|
|
|
All nodes that had chosen "B" as the winner in the previous round will simply extend the chain one more block. The nodes that chose "A" as the winner, however, will now see a block extending an even longer chain (greater-cumulative difficulty), that does not include "A" in it. Any miners working on extending the chain P-A will now stop that work because their candidate block is an "orphan", as its parent "A" is no longer on the longest chain. The block "A" is removed from the blockchain by any nodes that had accepted it and any transactions within it are queued up again for processing in the next block. The entire network re-converges on a single blockchain P-B-X, with "X" as the last block in the chain. All miners immediately start working on candidate blocks that reference "X" as their parent to extend the P-B-X 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 may occur every week, a two-block fork is exceedingly rare.
|
|
----
|
|
Block "X" extends the chain: P-B-X
|
|
Old chain is now "shorter": P-A
|
|
----
|
|
|
|
[TIP]
|
|
====
|
|
As of version 0.9, Bitcoin Core's +alertnotify+ option will send alerts whenever a 6-block or longer fork occurs
|
|
====
|
|
|
|
[[chainforks]]
|
|
.A blockchain showing two instances of forking
|
|
image::images/BlockChainWithForks.png["chainforks"]
|
|
|
|
|
|
=== Mining Pools
|
|
==== Managed Pools
|
|
==== P2Pool
|
|
=== Consensus Attacks
|
|
==== 51% Attack
|
|
==== Selfish Mining Attack
|