mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-23 15:18:11 +00:00
corrections, generation Tx, reward calculation, coinbase data
This commit is contained in:
Andreas M. Antonopoulos
parent
7c2f4f085e
commit
4f4c60ca1f
220
ch08.asciidoc
220
ch08.asciidoc
@ -6,28 +6,28 @@
|
||||
=== Introduction
|
||||
((("blockchain")))
|
||||
|
||||
Bitcoin's blockchain is the global public ledger (list) of all transactions, which everyone in the bitcoin network accepts as the authoritative record of ownership.
|
||||
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. 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.
|
||||
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 consensus emerges from the interplay of three processes that occur independently on nodes across the network:
|
||||
Bitcoin's 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 assembly of the new blocks by every full node into a chain and selection of the chain with the most cumulative computation demonstrated through Proof-of-Work
|
||||
* 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.
|
||||
|
||||
Each of these processes also aggregates smaller bitcoin units into larger data structures. First, unspent transaction outputs (UTXO) are aggregated into transactions. Next, many transactions are aggregated into a block. Finally, blocks are added to a chain of blocks, the blockchain. In the previous chapter we looked at transactions as a data structure. In this chapter we will also look at the larger data structures: blocks and the blockchain.
|
||||
|
||||
{check transition here - maybe move this above previous paragraph?} Each of these processes also aggregates smaller bitcoin units into larger data structures. First, unspent transaction outputs (UTXO) are aggregated into transactions. Next, many transactions are aggregated into a block. Finally, blocks are added to a chain of blocks, the blockchain. In the previous chapter we looked at transactions as a data structure. In this chapter we will also look at the larger data structures: blocks and the blockchain.
|
||||
|
||||
=== 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.
|
||||
In the previous chapter {check reference} 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.
|
||||
|
||||
Every bitcoin node that receives a transaction will first verify the transaction before forwarding it to its neighbors. This ensures that only valid transactions are propagated across the network, while invalid transactions are discarded at the first node that encounters them.
|
||||
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:
|
||||
|
||||
@ -50,29 +50,33 @@ Each node verifies every transaction against a long checklist of criteria:
|
||||
* 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.
|
||||
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.
|
||||
|
||||
=== 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.
|
||||
|
||||
The role of a mining node is to act as a gatekeeper to the public ledger. Mining nodes secure the network by validating transactions and controlling access to the blockchain. This places enormous power in mining nodes. To ensure that they follow the rules and behave honestly the bitcoin consensus mechanism imposes incentives by imposing a heavy burden and offering a lavish reward. The burden is the computational effort expended in mining which consumes electricity and therefore has a real-world cost. For those who carry that burden honestly, there is a possibility of reward. Each new block adds new bitcoin to the monetary supply; transactions within a block include transaction fees. The miner that successfully creates a new block collects both the new bitcoin and the transaction fees as a reward. Rewards are not all profit, in fact the miner will spend most of its winnings on electricity. Even successful miners are in a precarious position of marginal profitability, constantly competing under the scrutiny of the entire network. This fragile equilibrium and fierce competition ensures that honesty is the only winning strategy.
|
||||
|
||||
=== Aggregating Transactions into Blocks
|
||||
|
||||
Some of the nodes on the bitcoin network are specialized nodes called _miners_. A miner will collect, validate and relay new transactions just like any other node. Unlike other nodes, a miner will then aggregate these transactions into a _block_. The block of transactions constructed by a miner is a candidate block and becomes valid only if the miner succeeds in winning the mining competition. Each miner competes by trying billions of possible solutions to an equation based on a cryptographic hash. If they find a solution, they broadcast the candidate block for everyone to record on the blockchain. The competition difficulty is calibrated to ensure that a new block solution is found by someone every 10 minutes on average. We will look at the mining process itself in more detail in <<mining>>. For now, let's look at how miners aggregate 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_.
|
||||
|
||||
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 started mining for bitcoin in 2010, when mining was not as competitive as it is today. At that time, Jing could mine bitcoin using a desktop computer. Today, he uses a much more powerful mining system based on Application Specific Integrated Circuits (ASICs), which are specialized silicon chips designed exclusively for one application - bitcoin mining. Over time, the way Jing participates in the mining process has changed slightly, but the fundamentals remain the same. We will start by looking at how Jing mined in 2010, when things were simpler and then look at how he mines today, as bitcoin mining has become a more complex and competitive activity.
|
||||
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.
|
||||
|
||||
In 2010, Jing mined on a desktop computer. At the time, he would run a full bitcoin node, connected to the bitcoin network. A full bitcoin node keeps a full copy of the blockchain, the list of all transactions since the first ever transaction in 2009. Jing's bitcoin node receives transactions propagated by other nodes, just like any other node on the bitcoin network. After validating those transactions, the bitcoin software adds them to the _memory pool_, or _transaction pool_, where transactions would await until they could be included (mined) into a 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.
|
||||
|
||||
Jing's bitcoin node is also listening for new blocks, propagated on the bitcoin network. 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.
|
||||
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 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 of transactions. Jing's node is listening for transactions, trying to mine a new block and also listening for blocks discovered by other nodes. Jing's node receives an incoming block, propagated by the bitcoin network, which fits into the existing blockchain at height 277,315.
|
||||
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.
|
||||
|
||||
As soon a Jing's bitcoin node receives a valid new block, it immediately starts the next round of competition. Receiving a new block signifies that someone else has won the previous round, meaning that Jing's system did not win that round and should abandon its current efforts and shift its resources to try and win the next round. During the previous 10 minutes, while Jing's node was searching for a solution, it was also collecting transactions. By now it has collected a few hundred transactions in the memory pool. After removing any transactions that appear in the new block recently received, Jing's memory pool is left containing unconfirmed transactions that are waiting to be recorded in a new block.
|
||||
=== Transaction Age, Fees and Priority
|
||||
|
||||
Jing's node immediately constructs a new candidate block, to participate in the competition.
|
||||
|
||||
=== Adding Transactions to a Candidate Block
|
||||
|
||||
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.
|
||||
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:
|
||||
----
|
||||
@ -95,15 +99,177 @@ If there is any space remaining in the block, Jing's mining node may choose to f
|
||||
|
||||
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.
|
||||
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:
|
||||
|
||||
----
|
||||
$ bitcoin-cli getblockhash 277316
|
||||
0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
|
||||
$ bitcoin-cli getblock 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4
|
||||
{
|
||||
"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]]
|
||||
====
|
||||
[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.
|
||||
|
||||
=== 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>>. A regular transaction input 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
|
||||
|=======
|
||||
|
||||
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", also known as the +scriptSig+ field that follows must be between 2 and 100 bytes. This is where miners put the coinbase data. 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.
|
||||
|
||||
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 (little endian) 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.
|
||||
|
||||
The single output of the generation transaction sends the value of 25.09094928 bitcoins to the miner's bitcoin address, in this case +1MxTkeEP2PmHSMze5tUZ1hAV3YTKu2Gh1N+.
|
||||
|
||||
=== Constructing the Block Header
|
||||
|
||||
[[mining]]
|
||||
=== Proof-of-Work (Mining) and Consensus
|
||||
((("Mining", "Proof of Work", "SHA256", "hashing power", "difficulty", "nonce")))
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
@ -112,7 +278,6 @@ Bitcoin miners also earn fees from transactions. Every transaction may include a
|
||||
|
||||
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.
|
||||
|
||||
|
||||
[[figure_sha256_logical]]
|
||||
.The Secure Hash Algorithm (SHA-256)
|
||||
image::images/sha256-logical.png["SHA256"]
|
||||
@ -363,6 +528,11 @@ image::images/BlockChainWithForks.png["chainforks"]
|
||||
|
||||
==== Competition and Coinbase
|
||||
==== Mining Pools
|
||||
|
||||
Jing started mining for bitcoin in 2010, when mining was not as competitive as it is today. At that time, Jing could mine bitcoin using a desktop computer. Today, he uses a much more powerful mining system based on Application Specific Integrated Circuits (ASICs), which are specialized silicon chips designed exclusively for one application - bitcoin mining. Over time, the way Jing participates in the mining process has changed slightly, but the fundamentals remain the same. We will start by looking at how Jing mined in 2010, when things were simpler and then look at how he mines today, as bitcoin mining has become a more complex and competitive activity.
|
||||
|
||||
In 2010, Jing mined on a desktop computer. At the time, he would run a full bitcoin node, connected to the bitcoin network.
|
||||
|
||||
===== Managed Pools
|
||||
===== P2Pool
|
||||
==== Mining Economics
|
||||
@ -370,7 +540,3 @@ image::images/BlockChainWithForks.png["chainforks"]
|
||||
===== 51% Attack
|
||||
===== Selfish Mining Attack
|
||||
|
||||
==== Normal Forks
|
||||
==== Soft Forks
|
||||
==== Hard Forks
|
||||
==== Unusual Forks
|
||||
|
||||
Loading…
Reference in New Issue
Block a user