Nakamoto Consensus describes how Bitcoin arrives at a shared, valid transaction history without a central referee. A Full Node, a computer running software that verifies the rules, first rejects invalid blocks. Among valid branches it then chooses the one with the most accumulated work. Further confirmations increase confidence in a payment under certain security assumptions; they do not make it instantly irreversible.
Anna sends a payment to Peter. She could also sign another transaction spending the very same funds in Eva’s favour. Signing here means using a private key, a secret numerical value, to create verifiable proof of authorization for a payment. Others can check the signature without knowing that secret. Both signatures could be genuine, yet both payments cannot fit into one valid history. Peter and Eva might even receive the messages in opposite orders. Bitcoin therefore needs more than signature checking: a way to agree on an order and prevent double spending. Nakamoto Consensus combines rules, Proof of Work, branch selection, and miners’ rewards. Satoshi’s whitepaper, the original technical description of Bitcoin, does not use this later name. [1] [4]
Peter’s Full Node is not a ballot. A block groups transactions into a batch added to the shared history. A transaction output records an amount and the conditions for spending it later. The Full Node software checks transactions and blocks for itself: whether the outputs being spent are still unspent, whether their spending conditions are satisfied, and whether newly created bitcoins stay within the permitted amount. A miner can propose a block but cannot simply bypass these checks. An invalid block remains invalid even with enormous work behind it. Branch selection compares only valid alternatives; a shared history requires participants to follow compatible rules. [2] [3]
If each connected computer had one vote, an attacker could create many apparently independent participants. That is a Sybil Attack. Instead of counting names, Proof of Work ties a branch’s weight to demonstrable computation. Miners repeatedly calculate hashes, digital fingerprints of data, looking for a result that meets a prescribed condition. The attempts require energy and equipment, while a successful result is easy to check. Many network identities alone do not add work; this is neither identity-document verification nor a vote of all nodes. [1] [4]
A miner assembles a candidate block and varies its header, a compact summary of the block, until the header hash interpreted as a number is less than or equal to the valid target. This does not solve a useful equation or break encryption: it searches for a rare result. Two miners can succeed almost simultaneously. Some of the network sees one block first, some the other, briefly producing two valid branches. That alone is not a failure. With normal block propagation, further work lets nodes converge on the stronger branch. [1] [8]
A branch’s strength is measured by chainwork, the sum of the work assigned to its blocks from their targets. This is not an electricity meter or a record of the number of attempts actually made. One miner might get lucky immediately while another waits a long time; at the same target their valid blocks have equal weight. A Full Node chooses the available valid branch with the largest total. The shorthand “longest chain” thus means most work, not necessarily most blocks. Switching branches is a reorganization; a payment from a discarded block can be included again if it remains valid. [1] [2] [3] [7]
Once Anna’s payment is in an accepted block, it has one confirmation. Each subsequent block adds another. To replace that history, a competing branch would have to catch up with its work. Assuming an honest majority of computing power and sufficiently timely block propagation, the risk of a successful rewrite generally falls with depth. This is probabilistic finality: increasing confidence rather than mathematical impossibility of change. The number of confirmations Peter accepts also depends on the payment’s value and risk. No universal number guarantees safety in every situation. [1] [4]
If the condition stayed unchanged when faster machines arrived, blocks would come faster. Difficulty Adjustment therefore recalculates the target on the main network every 2016 blocks using earlier timestamps. It aims for an average of ten minutes per block, roughly two weeks for that interval. An individual block can arrive much sooner or later. The adjustment is triggered by a block count, not a calendar date; if much of the computing power suddenly disappears, reaching the next adjustment can take longer. It is neither an instant regulator nor an accurate clock. [2] [8]
Newly issued bitcoins, the block subsidy, and transaction fees reward miners for blocks that remain in the accepted history. This encourages them to extend it but does not replace security assumptions. Majority hash power can reorganize valid branches, omit payments, and attempt to reverse the attacker’s own spending. It cannot force a Full Node to accept an invalid signature, excess issuance, or unauthorized spending of someone else’s funds. The 50% threshold is no safety switch either: some attacks have a chance below it. Rewards alone do not create honesty. [1] [2] [3]
Return to Peter. If an attacker controls all his node’s connections, they can show him an incomplete view of events. An Eclipse Attack means this kind of network isolation; confirmation counts may then mean something different from a well-connected view of the network. Splitting the network into disconnected parts also complicates agreement. Security thus depends not just on the attacker’s share of computing power but on message propagation and honest verification. Bitcoin Backbone research explicitly models these conditions. A hash-power percentage without network assumptions is not a complete security explanation. [4]
Classical BFT (Byzantine Fault Tolerance) methods, which seek agreement despite faulty or malicious participants, often assume a group whose members are known in advance. Examples such as OM (Oral Messages) and PBFT (Practical Byzantine Fault Tolerance) have their own conditions and message-exchange rules. Bitcoin handles open participation through work and probabilistic convergence of history; it is not simply a new name for these methods. Nor does selecting a stronger valid branch change the validity rules. A rule change requires participants to adopt suitable software and compatible conditions. Miners help determine which valid history continues, not what everyone must consider valid. [5] [6] [9]
For the clearest picture, read this entry together with Bitcoin, Proof of Work, Difficulty Adjustment, Consensus Rules, Mining, Full Node. The reverse links also lead from Bit Gold, Reusable Proofs of Work, Byzantine Generals Problem, Sybil Attack.