Which history counts?

Two DCoin participants produce a block at almost the same time. Both blocks extend the same parent. Both contain valid transactions. A peer on one side of the network receives the first block before the second; a distant peer sees them in the opposite order.

Nobody needs to be attacking the system for this to happen. Communication takes time, and “the latest block” is a local observation. If DCoin simply chooses whichever block arrives first, different peers may make different choices forever.

The previous part gave us a way to validate a branch of history. Now we need a rule for comparing branches and a reason that rewriting the selected one should be costly. We will use proof of work as our main design, then compare the assumptions behind several alternatives.

3.1 #A fork is a tree, not two independent ledgers

Each block has one parent. Across the network, known blocks form a tree rooted at genesis. The active ledger corresponds to one path through that tree. Other branches may remain known without contributing transactions to the active state.

Here the arrows show extension from parent to child, unlike the backward-pointing hash references in the previous article. The underlying relationship is the same.

If a different branch becomes preferred, the node performs a reorganization. It rolls back state changes from the old branch to the common ancestor, then applies the new branch in order. A transaction removed from the active history may become pending again, provided that it is still valid and meets the node's mempool policy. It may instead conflict with a transaction on the new branch.

Terminology matters. A block with a known parent that loses this competition is commonly called stale. A block received before its parent is known is often called an orphan. Implementations and older explanations sometimes use these words differently; the distinction we need is between a known competing branch and a missing dependency.

3.2 #Make proposing a block require work

Choose a cryptographic hash with a $b$-bit result and interpret the digest as an unsigned integer. A candidate header satisfies proof of work if

where $T$ is the target required by the protocol at that position in the history. A smaller target means fewer acceptable hashes and therefore more expected attempts.

The miner repeatedly changes allowed fields and hashes the resulting header. A nonce provides one source of variation; changing transaction data changes the Merkle root and supplies more possibilities. Verification is cheap: a receiver recomputes the hash once and checks the target. Finding a satisfactory candidate is expensive because a good hash function provides no practical shortcut better than trying possibilities.

Under the usual idealized uniform-hash model, one attempt succeeds with probability

The $+1$ includes zero, which is an acceptable result. More attempts per second increase the chance of finding a block, but do not guarantee a win in a particular interval. Mining is a probabilistic search, not a race to present the hash with the largest number of leading zeroes after a fixed deadline.

We can show the arithmetic with a deliberately tiny toy hash space. If $b=16$ and $T=255$, there are 256 acceptable values out of 65,536. The expected number of attempts is 256. That does not mean every 256th attempt succeeds: a run can be much shorter or much longer.

3.3 #Prefer accumulated work, not a head count

If anyone can create peer identities cheaply, counting votes by peer gives an attacker an equally cheap way to invent a majority. Proof of work instead weights histories by the computational difficulty represented by their blocks.

For a Bitcoin-style target $T$, a block's work contribution can be represented as

The branch score is the sum of these contributions. A node prefers the valid history with the greatest accumulated work. If all compared blocks have the same target, more blocks means more work; when targets differ, raw block count is not the general rule. Bitcoin Core computes this contribution in GetBlockProof.

Equal-work ties can temporarily persist. Nodes may continue building on the branch they currently prefer until another block breaks the tie. The protocol does not need everyone to have the same tip at every instant. It needs a way for disagreement to resolve as information and additional work arrive.

The word valid in the selection rule is essential. A branch that creates forbidden money or spends without authorization does not become acceptable by accumulating work. Full validators enforce the monetary and transaction rules independently. Hash power can influence ordering and censorship; it cannot make an honest validator accept a broken signature under unchanged rules.

An attacker can nevertheless attempt to replace recent payments by building a competing valid branch. A recipient therefore treats confirmation as accumulating confidence, rather than an absolute guarantee of permanence. The familiar security argument assumes, among other things, that honest mining has enough of the relevant work rate and that the network delivers blocks sufficiently well. A partition or a badly isolated node changes the situation.

Bitcoin adjusts the required target to keep its average block interval near its intended cadence as hash rate changes. Mainnet normally retargets every 2,016 blocks, with bounds on the adjustment; the rules are implemented in Bitcoin Core's proof-of-work code. The target is not a field a miner may freely lower in difficulty to give itself easier blocks.

3.4 #Pay for operation and define issuance

The ledger needs a rule for creating money as well as transferring it. Bitcoin places a special coinbase transaction first in each block. Its total outputs may claim at most the block subsidy plus the fees of the included transactions. Claiming less is allowed; claiming more makes the block invalid.

For a DCoin design exercise, we must specify the subsidy schedule rather than assume “mining creates coins” is a complete policy. An initial distribution, a fixed issuance per block or a decreasing schedule create different incentives and supply paths. Fees also need a defined destination. In our example, the block producer can claim them through the coinbase; they are not sent to a central system account.

Bitcoin's initial subsidy was 50 BTC. It halves every 210,000 blocks, with integer-satoshi truncation eventually making it zero. The schedule yields a maximum subsidy issuance slightly below 21 million BTC, not a promise that exactly 21 million will remain spendable: rewards can be underclaimed and keys can be lost. The schedule is defined by height, not by a calendar appointment or the number of miners. The implementation is GetBlockSubsidy in Bitcoin Core.

Rewards connect the protocol to an economic incentive, but incentives are assumptions to analyze, not proofs that nobody will attack. Mining has operating and capital costs. A participant may have objectives outside the protocol, and the value of disrupting a payment system need not equal the value of the next block reward. Reducing issuance also makes fee revenue more important to the reward budget; whether users will pay sufficient fees is an economic question, not a hash-function property.

3.5 #Other ways to make influence costly

Proof of work is one answer to the problem of cheap identities. Alternatives change the scarce resource, the trust assumptions or both. They should be evaluated as complete protocols: eligibility, proposal selection, validation, fork choice and finality all matter.

Mechanism	What gives a participant influence?	What must be examined?
Proof of work	Producing hashes below the required target	Hash-power distribution, propagation, incentives and reorganization risk
Proof of stake	Capital committed under the protocol's validator rules	Selection, penalties, withdrawal rules, finality and recovery assumptions
Proof of burn	Evidence that assets were irreversibly destroyed under specified rules	Which asset is burned, how influence decays, and how the burn is verified
Proof of elapsed time	An attested waiting interval	Who guarantees the timer and prevents many parallel identities or timers?
Proof of importance	A protocol-specific score for holdings and/or activity	How the score is computed and how cheaply apparent activity can be fabricated

Proof of stake does not universally mean “old coins get to mine.” For example, Ethereum uses rewards, penalties and slashing conditions tied to validator behavior; its protocol documentation explains those mechanisms. Different stake protocols make different choices.

Burning coins can create a verifiable cost, but it does not mathematically guarantee a higher market price for the remaining coins. A price depends on demand and market behavior too. Similarly, an activity score is useful only if manufacturing that activity does not cheaply manufacture consensus power.

Elapsed-time schemes deserve particular care. If waiting is enforced only by a local program, an attacker can modify that program or run many copies. Sawtooth's PoET-SGX design uses a trusted execution environment; its simulator has different security properties. The Sawtooth consensus FAQ makes that distinction explicit.

For DCoin we will stay with the proof-of-work model, because it lets us connect an understandable selection rule to the Bitcoin bytes in the next two parts. We now know what the header's target and nonce are for, why a block's predecessor matters, and why valid transactions are still checked after a hash wins the search. It is time to stop drawing boxes and open one.