Bitcoin in Practice: Mining Valid Blocks

Mining software, what it does and how it plugs into a node

Mining can be run as a single server farm or as a mining pool, depending on how the hardware is set up.

Even though mining is one of the critical pieces of a blockchain, the mining process itself is fairly decoupled from the rest of the node’s work. The connection point is the block assembler, which builds a candidate block and its block header, then hands that “mining candidate” off to the mining pool software.

Mining pools and ASICs

Mining pool software controls ASIC machines, either in one data center or spread out over the internet. Once the pool receives the mining candidate, it begins the proof of work process, trying to find the next valid block hash.

Modern mining uses ASICs, purpose built chips that do one job extremely well: compute SHA256 hashes for a proposed block header. The work is brute force-like, the machines keep trying slightly different inputs until they hit a valid result.

The hashing loop, target, and nonce

Here is the loop described in the source, stated plainly:

• Take the candidate block header.

• Hash it using double SHA256 (SHA256D).

• Compare the resulting number to a target.

• If the hash result is less than the target, that is a valid proof of work solution.

• If the hash result is greater than the target, change the input and try again.

The main knob that gets changed over and over is the nonce, a number inside the header. Increment nonce, hash again, compare again. Repeat constantly at high speed.

Once a solution is found, the mining software returns it to the block assembler. From there, the node notifies its internal tracking components and the network messaging system so the new block can be propagated to other nodes.

What other nodes do when you announce a new block

When other nodes hear that you found a block, they do not just “take your word for it.” They trigger their own block validation process to check whether the proposed block is valid.

If the block validates, they update their view of the chain tip, treat that block as the most recent accepted block, and immediately begin building and mining the next block on top of it.

This cycle is continuous. The network is always racing forward, block by block, which makes history time-bound and difficult to reverse.

Staying in sync, what happens if you go offline

Mining is not something you can pause and resume without consequences.

If a node goes offline even briefly, the network keeps moving. When that node comes back, it will be behind. It has to download the blocks that were mined while it was offline, update its chain tip, and only then start mining again on the current tip.

Orphan blocks, when two miners win at nearly the same time

Sometimes two or more nodes find valid solutions around the same time. That creates a temporary fork, where different parts of the network see different tips as “the” current tip and start building on them.

The situation resolves itself when the next block is found on one of those competing tips. The chain that gets extended becomes the longest chain, and the other competing tip loses.

A block that was valid but ends up on the losing branch becomes an orphan block. In the description provided, it is later abandoned by the network and deleted from active consideration.

Invalid blocks, when a proposed block fails validation

A different scenario is when a node proposes a block that fails validation. In that case, the block is ignored, and everyone continues trying to find a valid block that builds on the previous valid block.

The source gives examples of why a block might be considered invalid:

• It fails a consensus rule, like being oversized.

• It awards the miner too many bitcoins.

• It includes an invalid transaction.

• It does not include a valid proof of work or timestamp.

If a node repeatedly sends invalid blocks, other nodes may take additional steps such as refusing to share network information with that node, including blocking the node’s IP for a period like 24 to 48 hours. Each node can set its own policy here.

Acceptance is a choice, and nodes must track the majority chain

One key point in the source is that nodes are free to accept or reject blocks from any party for any reason. Because of that, it is on each node operator to keep track of what the majority of the network has accepted as the valid chain of events.

Practically, this matters for efficiency. If you build on a chain the network refuses to accept, you waste resources. The goal is to keep mining on the longest valid chain.

ELI15(ish...)

Picture a giant timed puzzle competition where everyone is trying to add the next page to a public notebook.

• The block assembler writes a draft page, a candidate block, with a summary at the top called the header.

• The miners are like fast lottery machines. They keep tweaking one number, the nonce, and re-checking the header over and over.

• The rule is simple: find a hash result that is below a target number. If you hit it, you win this round and you get to publish the next page.

When you publish your page, everyone else checks it. If it is valid, they all start working on the next page using your page as the new starting point.

Sometimes two people publish a valid page almost simultaneously. The notebook briefly has two competing “latest pages.” Whichever one gets the next page added on top becomes the winner, and the other valid but unlucky page becomes an orphan.

If someone publishes a page that breaks the rules, like it is too big or tries to create too many coins, the network ignores it and keeps working off the last valid page.