Introduction to the

How is consensus reached in bitcoin’s PEER-to-peer network? What kind of checks do you need to make to reach a consensus? How do transactions and blocks spread across the blockchain network? You will understand after reading this article.

Consensus in Bitcoin

Earlier in my presentation on distributed systems I talked about several consensus algorithms for distributed systems, including Raft, Paxos, and Byzantine fault tolerance.

Bitcoin’s consensus is different, using a proof-of-work (POW) algorithm.

Bitcoin’s decentralized consensus is generated by the interaction of four independent processes at all network nodes:

Each global node independently verifies each transaction based on a comprehensive standard

By checking the proof-of-work algorithm, mining nodes independently package transaction records into new blocks

Each node independently verifies new blocks and assembles them into the blockchain

Each node independently selects the blockchain with the largest cumulative workload under the proof-of-work mechanism

More highlights:

• Blockchain from getting started to Giving up series tutorials – with ongoing updates covering cryptography, Hyperledger, Ethereum,Libra, Bitcoin and more
• Spring Boot 2.X Series tutorials: Learn Spring Boot from Scratch in seven days – continuous updates
• Spring 5.X Series tutorials: Everything you can think of in Spring5 – constantly updated
• Java Programmer from Handyman to Expert to God (2020 edition) – Ongoing updates with detailed articles and tutorials

Verification of transactions

In a Bitcoin network, transactions are verified independently by nodes in the network.

Each Bitcoin node receiving a transaction will verify the transaction first before it is passed on to a nearby node, ensuring that only valid transactions will be propagated across the network, while invalid transactions will be discarded at the first node.

Each node verifies each transaction against a long list of criteria:

Transaction syntax and data structure must be correct.

Input and output lists cannot be empty.

The byte size of a transaction is smaller than MAX_BLOCK_SIZE.

Each output value, as well as the total amount, must be within the specified value range (less than 21 million dollars, greater than zero).

There is no input with hash = 0 and N = -1 (Coinbase transactions should not be relayed).

NLockTime is less than or equal to INT_MAX.

The size of a transaction is 100 bytes or greater.

The number of signatures in a transaction should be smaller than the maximum number of signature operations.

The unlock script (scriptSig) can only push numbers onto the stack, and the lock script (scriptPubkey) must conform to the isStandard format, which rejects non-standard transactions.

A matching transaction must exist in a pool or in a primary branch block.

For each input, if the referenced output exists in any transaction in the pool, the transaction will be rejected.

For each input, look for referenced output transactions in the master branch and trade pool. If an output transaction is missing any of its inputs, the transaction becomes an isolated transaction. If the matching trade is not already in the pool, it will be added to the isolated trade pool.

For each input, if the referenced output transaction is a Coinbase output, the input must have at least COINBASE_MATURITY (100) confirmation.

For every input, the referenced output must exist and not be spent.

The referenced output transaction is used to obtain the input value and check whether each input value and the total value are within the specified value range (less than 21 million dollars and greater than 0 dollars).

If the total of the input values is less than the total of the output values, the transaction is suspended.

If the transaction fee is too low to enter an empty block, the transaction will be rejected.

Each input unlock script must be verified against the corresponding output lock script.

After all this long validation, the transaction is ready to be written to the block.

Block construction

After verifying the transactions, the Bitcoin node adds them to its own memory pool. A memory pool, also known as a transaction pool, is used to temporarily store transaction records that have not yet been added to a block. Like any other node, the mining node collects, validates, and relays new transactions. Unlike other nodes, mining nodes consolidate these transactions into a candidate block.

Bitcoin nodes need to assign a priority to each transaction in the memory pool and select the higher-priority transaction record to build candidate blocks. The priority of a transaction is determined by the block age of the UTXO spent for the transaction input, and transactions with high and large block age have higher priority than those with new and small input values. If there is enough space in the block, high-priority transactions will not require miner fees.

The mining node then selects those transactions with the smallest miner’s fee and sorts them by “kilobyte miner’s fee per kilobyte”, prioritiding the transactions with the highest miner’s fee to fill the remaining blocks, capped at MAX_BLOCK_SIZE.

If there is still space left in the block, the mining node can select those transactions that do not include the miner’s fee. Some miners will struggle to integrate deals that do not include miners’ fees into their blocks, while others may choose to ignore them.

After the block is filled, the remaining transactions in the memory pool become candidate transactions for the next block. Because these transactions remain in the memory pool, as new blocks are added to the chain, the depth of the UTXO referenced when these transactions are entered (the “block age” of the transaction) increases. Since the priority value of a transaction depends on the “block age” of its transaction input, the priority value of the transaction increases accordingly. Finally, the priority value of a zero miner’s fee transaction may meet the high priority threshold and be packaged into the block for free.

Block check

After a transaction is packaged in a block, the block is broadcast and the receiving node verifies the block.

When a node receives a new block, it validates the block against a long list of criteria, failing which the block is rejected.

These standards are available in the Bitcoin core client’s CheckBlock and CheckBlockHead functions, which include:

Block data structures are grammatically valid

The hash value of the block header is less than the target difficulty (confirm that sufficient proof of work is included)

The block timestamp is two hours ahead of the validation time (time error allowed)

The block size is within the length limit

The first (and only the first) transaction was the Coinbase transaction

Check lists are used to verify transactions within blocks and ensure their validity

The fork of blockchain

Because blockchains are decentralized data structures, different copies cannot always be consistent. Blocks may arrive at different nodes at different times, resulting in nodes having different blockchain perspectives. The solution is that each node always selects and tries to extend the blockchain that represents the most accumulated proof of work, that is, the chain with the longest or greatest accumulated difficulty.

In the first diagram, the network has a unified blockchain view, with blue blocks at the “apex” of the main chain

A fork event occurs when there are two candidate blocks that simultaneously want to extend the longest blockchain. Normally, forking occurs when two miners have worked out the proof-of-work solution in a short period of time.

As soon as the two miners found solutions in their respective candidate blocks, they propagated their “winning” blocks to the network, first to neighboring nodes and then to the entire network.

Each node that receives a valid block will merge it and extend the blockchain. If the node subsequently receives another candidate block that has the same parent block, the node will connect that block to the candidate chain.

As a result, some nodes receive one candidate block, while others receive another, and two different versions of the blockchain emerge.

If miners working on a “green” block find a “pink” block that extends the blockchain (blue-green-pink), they will immediately broadcast the new block and the entire network will assume that the block is valid.

All nodes that chose the “green” block as the winner in the previous round will simply extend the chain by one block.

However, those nodes that chose the “red” block as the winner will now see two chains: “blue-green-pink” and “blue-red”.

As shown in the figure, these nodes will set the “blue-green-pink” chain as the primary chain and the “blue-red” chain as the standby chain based on the results. These nodes accept new, longer chains and are forced to change their view of blockchain, which is called chain reconsensus.

Any miner who wanted to extend the chain on the “blue-red” chain will now stop because the “red” block is no longer on the longest chain as the parent block, resulting in their candidate block becoming the “lone block”.

The whole network will identify the “blue-green-pink” chain as the main chain, and the “pink” block is the last block of the chain. All miners immediately switched the parent block of the candidate block they generated to “pink” to extend the “blue-green-pink” chain.

Types of blockchain forks

Generally speaking, blockchain forks can be divided into two types:

A hard fork is when a bitcoin protocol rule changes and the old node refuses to accept a block created by the new node. Blocks that violate the rules will be ignored and miners will create blocks after the last blocks they witnessed according to their rule set.

A soft fork is when the rules of the Bitcoin protocol change and the old nodes do not realize that the rules are different, they will follow the changed rule set and continue to accept blocks created by the new nodes. Miners may be working on blocks they have no understanding of or validation of.

With a hard fork, the blockchain is no longer the same blockchain.

As you can see from the chart above, bitcoin has developed many forks since the original version, and they are all the same in nature. The question is which chain you agree with.

conclusion

This paper introduces the consensus mechanism of blockchain, and the verification steps of transactions, and finally explains the bifurcation of blockchain. I hope you enjoy it.

Author: Flydean program stuff

Link to this article: www.flydean.com/bitcoin-con…

Source: Flydean’s blog

Welcome to pay attention to my public number: procedures those things, more wonderful waiting for you!