Bitcoin Developer Guide (1)-Blockchain _ Blockchain

noun

Block Chain: Block chain

Utxo:unspent Transaction output, non-spent trade outputs

Genesis BLOCK: Blocks 0, Genesis block

Spv:simplified Payment Verification, simple payment verification

Bip:bitcoin improvement proposal, Bitcoin improvement proposal

Proof of work: proof of workload

block Chain

The blockchain provides a public account of Bitcoin, an orderly, time-stamped transaction (transaction) record. The system is designed to prevent recurring costs (double spending) and to modify previous transactions.

Each full node in the Bitcoin network stores only the blockchain that has been validated by the node. When multiple nodes have the same block in their block chain, they are considered to have reached a consensus. These nodes follow the consensus-maintaining validation rules known as consensus rules. This section describes many of the consensus rules used by Bitcoin core.

block Chain Overview

The diagram above shows a simplified version of the blockchain. The block of one or more new trades is collected into the transaction data section of a chunk. A copy of each transaction data will be hashed, the hashes 22 paired, and then hashed until a hash of the topmost layer is obtained, which is the root of a tree of Merkle.

The root of the Merkle is stored in this chunk header. Each block also stores the hash value of the header of the previous block, so that the blocks are linked together. This ensures that the transaction cannot be modified without modifying the block that records the transaction and all subsequent blocks.

Transaction records are also linked together. Bitcoin wallet software gives a feeling of how much Cong (Satoshi, unit) of Bitcoin is sent or received from the wallet, but in fact Bitcoin is actually circulating in the transaction. Each transaction spends the amount of money previously received in one or more earlier transactions, so the input to a trade is the output of the previous trade.

A single transaction can create multiple outputs, as is the case when sent to multiple addresses, but each output of a particular transaction can only be used as input once in the blockchain. Any subsequent references are forbidden to repeat the cost-try to spend the same number of wise Bitcoins two times.

The output is bound to the transaction identifier (TXID), which is the hash value of the validated transaction.

Because the output of a particular transaction is only allowed once, all the trade outputs contained in the blockchain can be categorized as an unused trade output (Utxos) or a spent trade output. To make the payment valid, use only the unused trade output utxos as input.

Do not start with Bitcoin trading (detailed later), if the output of a transaction exceeds the input of the transaction, the transaction will be rejected-but if the input exceeds the output, the difference can be rewarded as a transaction fee to the Bitcoin miner who created the block. For example, in the figure above, each transaction costs 10000 more than its associated trading input, in effect paying a 10000-wise transaction fee.

Proof of workload

Blockchain is maintained by peers in the network, so bitcoin requires a certain amount of effort per chunk to ensure that dishonest nodes that want to tamper with historical chunks pay a greater price than the honest nodes that want to create new chunks on the blockchain.

The link blocks together make it impossible to modify the transactions contained in this chunk without modifying all subsequent chunks. As a result, the cost of modifying a particular chunk increases as each new chunk is added to the blockchain, amplifying the effect of the proof of effort.

The amount of work used in Bitcoin uses explicit random characteristics of cryptographic hashes. A good cryptographic hashing algorithm converts arbitrary data into seemingly random numbers. If the data is modified in any way and the hashes are re-obtained, a new seemingly random number is generated, so the data cannot be modified so that the hash value can be predicted.

To prove that you have done some extra work to create a chunk, you must create a hash of the chunk header that does not exceed a certain value. For example, if the maximum possible hash value is 2256-1, you can prove that you are combining a maximum of 22 attempts by generating a hash value of less than 2255.

In the example given above, an average of every other attempt will produce a successful hash. You can even estimate the probability that a given hash attempt will generate a number below the target threshold. Bitcoin assumes a linear probability, which makes the target threshold lower and requires more hash attempts on average.

New blocks are added to the block chain, only if their hash difficulty is at least as large as the difficulty value expected by the consensus protocol. Every 2016 blocks, the Bitcoin network calculates the number of seconds elapsed between the first chunk and the last chunk of the previous 2016 blocks, using a timestamp stored in each header. This ideal value is 1.2096 million seconds (two weeks).

If it takes less than two weeks to generate 2016 blocks, the expected difficulty value will increase proportionally (up to 300%), and when the hash is checked at the same rate, the next 2016 blocks should be generated in exactly two weeks.

If the generated block takes two weeks, the expected difficulty value is proportionally reduced (75%) for the same reason.

(Note: A timestamp error in the Bitcoin core implementation resulted in a slight offset for every 2016 block update difficulty value from only 2015 blocks.) ）

Because each chunk must be hashed to a value below the target threshold, and because each block is linked to the previous one fast, the average need to spread the hash of a changed chunk is as much as the entire Bitcoin network consumes between the initial block creation time and the current time. You can reliably perform this 51% attack based on the transaction history only if you have obtained the hash function of most networks (however, it should be noted that even a percentage less than 50 of the hash strength still has a good chance of doing this attack).

The size provides several easy-to-modify fields, such as dedicated nonce fields, so getting a new hash does not require waiting for a new transaction to arrive. In addition, only 80 bytes of block size are hashed for work proofs, so containing a large amount of transactional data in a chunk does not slow down the hash of extra I/O and add additional transactional data only needs to recalculate the ancestor hash in the Merkle tree.

block height and fork

Any Bitcoin miner who calculates the hash value of a block is below the target threshold can add the entire chunk to the block chain (assuming the block is valid). These blocks are usually positioned by their block height-the number of blocks between them and the first Bitcoin block (block 0, most commonly called the Genesis Block). For example, Block 2016 is where you can first adjust the difficulty value.

Multiple chunks may have the same block height, which is common when 2 or more miners produce suitable blocks at roughly the same time. This creates a distinct fork in the block chain, as shown in the figure above.

When miners generate new chunks at the end of the blockchain, each node independently chooses which chunk to accept. In the absence of other considerations, nodes typically use the first block they see, as described below.

Eventually, one miner produces another block, which is attached only to a block that competes for simultaneous mining. This makes the fork's side stronger than the other side. Assuming that a fork contains only valid chunks, normal nodes are usually followed by the most difficult chain to grow, discarding obsolete chunks that are part of the short fork. (outdated blocks are sometimes referred to as orphans or orphan blocks, but these terms are also used for true orphan blocks that do not have a known parent block)

If different miners work for the opposite purpose, for example some miners are trying to expand the block chain while other miners are trying to launch 51% attacks to modify the trading history, then long-term forks are possible.

Since multiple blocks can have the same height in the bifurcation of a blockchain, the chunk height should not be used as a globally unique identifier. Instead, blocks are usually referenced by their hash of the size (usually reversed in byte order, in hexadecimal form).

Transaction Data

Each block must contain one or more transactions. The first of these transactions must be a currency-based transaction, also known as a generated transaction, which should collect and spend block bonuses (including block subsidies and any transaction fees paid by the transactions included in the Block).

The unused trade output utxo for a currency base transaction has a special condition that requires at least 100 blocks to be produced before it can be used (as input). This temporarily prevents miners from spending trading fees and block bonuses on chunks that may be eliminated from a forked chain (hence the deletion of currency-based transactions).

Chunks do not need to include any non-currency-based transactions, but miners almost always contain additional transactions in order to obtain their transaction fees.

All transactions, including currency-based transactions, are encoded into blocks in binary original trading format.

The original transaction format is hashed as the transaction identifier (TXID). These txid,merkle trees are formed by pairing each txid with another txid and then grouping them together. If there is an odd number of txids, then TXID with no partners will hash using its own copy.

Each of the resulting hashes itself is paired with another hash and hashed together. The hash of the partner does not seek its own value. The process repeats until only one hash is left, which is the Merkle root.

For example, if a transaction is only added (not hash), then a merkle tree of five trades will look like the following figure:

Based on the discussion of the sub-section of the Simple Payment verification (SPV), the Merkle tree allows the Merkle root to be validated from a fully fragmented block size and a series of intermediate hash values to validate a transaction in the chunk. Complete shards do not need to be trusted: it is expensive to forge a size, the middle hash cannot be forged, or the validation fails.

For example, in order to verify that transaction D is added to a chunk, the SPV client needs only C,ab and eeee hashes in addition to the Merkle root; the customer does not need to know any other transactions. If the five trades in this block are at maximum, it will take more than 500,000 bytes to download the entire block, but downloading three hashes plus a size requires only 140 bytes.

Note: If the same txids is found in the same block, it is possible that the Merkle tree may be removed from the block, where some or all of the duplicates are deleted due to how unbalanced Merkle tree is implemented (replicating an island hash). Since it is impractical to use a separate transaction with the same txids, this does not burden the honest software, but it must be checked if the invalid state of the block is cached, otherwise the valid block of the deleted duplicates can have the same Merkle root and block hash, but the cached invalid result is rejected, resulting in a security vulnerability, such as cve-2012-2459.

consensus rule changes

To maintain consensus, all nodes use the same consensus rules to validate blocks. However, there are times when consensus rules are changed to introduce new features or prevent misuse of the network. When the new rule is implemented, there may be a time when the non-upgraded nodes follow the old rules and the upgrade nodes follow the new rules, leading to two possible ways to break the consensus:

Blocks that follow the new consensus rule are accepted by the upgraded node, but rejected by the non-upgraded node. For example, use the new trading feature in a block: The Upgrade node understands the feature and accepts the feature, but the non-upgraded node rejects it because it violates the old rule.

Blocks that violate the new consensus rule are rejected by the upgraded node, but are accepted by the non-upgraded nodes. For example, the abuse trading feature is used in blocks: The post-upgrade node rejects it because it violates the new rule, but the node that does not upgrade accepts it because it follows the old rules.

In the first case, rejected by non-upgraded nodes, mining software that acquires blockchain data from other non-upgraded nodes is rejected and mining software that acquires data from upgraded nodes is created on the same chain. This creates a permanently divergent chain-one for non-upgraded nodes, and one link for the upgrade node-this is called a hard fork.

In the second case, the upgraded node rejects, and if the upgraded node controls the main hash rate, it may prevent the blockchain from permanently diverging. This is because, in this case, the non-upgraded nodes accept the same fast as the upgraded nodes, so the upgraded nodes can create a stronger chain and are accepted by the non-upgraded nodes. This is called a soft fork.

Although a fork is actually a divergence in the blockchain, the change in consensus rules is often described as a potential to create a hard fork or soft fork. For example, "increasing the size of a block to more than 1 MB requires a hard fork." In this example, an actual block-chain fork is not required-but this is a possible result.

Changes in the consensus rules may be activated in various ways. In the first two years of Bitcoin, Nakamoto issued a few soft forks with a backward-compatible client change that immediately forced the use of the new rule. Multiple soft forks, such as BIP30, have been activated by marking day, where new rules start to be enforced at preset times or block heights. The forks that are activated by marking the day are called user-activated soft forks, because they depend on enough user nodes to force the new rule after the Mark Day.

Later soft forks wait for most hash rates (typically 75% or 95%) to show that they are ready to implement the new consensus rule. Once the signaling threshold has passed, all nodes will start executing the new rule. Such forks are called miners ' active Soft forks (MASF), because they depend on miners for activation.

Resources: BIP16,BIP30 and BIP34 are implemented as a possible result of soft forks. BIP50 describes an unexpected hard fork and a deliberate hard fork that can be resolved by temporarily downgrading the ability of the post-upgrade node. The documentation from Gavin Andresen outlines how to implement future rule changes.

Detection Fork

Nodes that are not upgraded can use and distribute incorrect information in two types of forks, resulting in several situations that could lead to financial loss. In particular, non-upgraded nodes can relay and accept transactions that are considered invalid by the upgraded nodes, and therefore will never become part of the generally accepted best blockchain. Nodes that are not upgraded may refuse to relay chunks or transactions that have been or are about to be added to the best blockchain, so they provide incomplete information.

Bitcoin core consists of detecting hard forks by viewing the block chain work proof. If a non-upgraded node receives a block-chain header that shows at least 6 blocks more than the optimal chain, the node will report an error in GetInfo RPC and execute the-alertnotify command in the case of the setup. This will alert the operator that a node that has not been upgraded cannot switch to the best possible blockchain.

The full node can also check the block and the version number of the transaction. If the block or transaction version number in the current block is higher than the version number used by this node, it can be assumed that it does not use the current consensus rule. Bitcoin Core 0.10.0 If set, this condition is reported through the GetInfo RPC and-alertnotify commands.

In either case, chunks and transaction data cannot be trusted if they come from a node that clearly does not use the current consensus rule.

The SPV client connected to the full node is able to measure a possible hard fork by connecting multiple full nodes, ensuring that they have the same block height on the same chain, or adding or subtracting several chunks depending on the account transmission delay and expiration. If there are disagreements, the client can disconnect from the node using the weaker chain.

SPV clients should also monitor the increase in the version number of blocks and transactions to ensure that they process the received transactions with the current consensus rules.