Bitcoin security is a set of boundaries, not one property. Consensus validation answers whether data obeys the rules implemented by a node. Chain selection compares valid candidates by accumulated work. Wallet controls authorize spends. Peer and host controls affect which information reaches the operator. A useful review names the asset, adversary, failure, evidence, mitigation, owner, and residual risk.
Separate the node, template, hashing, and wallet roles
| Role | What it can establish | What it cannot establish alone |
|---|---|---|
| Validating node | Checks received blocks and transactions against its implemented consensus rules and selects among valid chain candidates using accumulated work. | Does not protect signing keys, prove a remote template source is honest, or guarantee an unconfirmed transaction will be mined. |
| Block-template producer | Selects candidate transactions and constructs work under its policy. | Cannot compel independently validating nodes to accept a consensus-invalid block. |
| Proof-of-work device | Searches assigned header work and returns results to its controller. | Does not independently choose consensus rules, validate a wallet destination, or necessarily choose the template. |
| Wallet and signer | Constructs or authorizes spends according to its keys and policy. | Does not independently establish chain truth unless connected to a validating source the operator controls and verifies. |
| Operator | Chooses software, configuration, peers, signing policy, evidence and response procedures. | Cannot remove protocol, implementation, physical, legal, or human residual risks by declaration. |
Validity is different from chain selection
A node first rejects blocks that fail the rules it enforces. Among valid candidates, Bitcoin Core tracks the chain with the greatest accumulated proof of work. More hash power can produce valid competing history faster; it does not grant permission to bypass signatures, create an excessive subsidy, spend nonexistent inputs, or alter other enforced rules.
This distinction also limits slogans about “miners controlling Bitcoin.” Template producers influence ordering and inclusion in blocks they find. Nodes decide whether to accept those blocks. Wallets decide what to sign. Software and configuration determine the rules each operator actually enforces. A security review must identify the concrete role rather than treating “the network” as one actor.
Confirmations measure accumulated work, not certainty
A confirmation means a transaction is in a block on the node’s selected chain; later blocks add work above it. A reorganization replaces one valid branch with another valid branch carrying more accumulated work. The probability of an attacker catching up depends on assumptions including the attacker’s share of effective hash power, the starting work deficit, block-arrival variance, information and network advantage, and whether honest participants keep extending the observed branch.
The whitepaper models a simplified catch-up race. That model is useful for reasoning but is not a universal service-level formula: real acceptance decisions also involve transaction value, replaceability and conflicts, peer diversity, custody and counterparty controls, operational delay, and consequences of failure. Record the chosen observation and escalation policy; do not present a confirmation count as irreversible finality.
What majority hash power can and cannot do
- Can attempt: build a competing valid branch, reorganize recent history, reverse the attacker’s own earlier payment, exclude selected transactions from the attacker’s blocks, and delay confirmations while the advantage persists.
- Cannot make valid to an honest node: a bad signature, an input that does not exist, an excessive subsidy, invalid proof of work, or another violation of that node’s active consensus rules.
- Cannot obtain automatically: another party’s private keys, control of independently administered nodes, reliable censorship by every future producer, or a promise that an attack remains economically or operationally sustainable.
Attack cost is not a fixed currency number. Hardware availability, control arrangements, energy, timing, existing positions, detection, opportunity cost, coordination and response can all change. Avoid static market-size or hashrate snapshots in a durable threat model.
Threat, evidence, and mitigation matrix
| Threat | Failure to model | Evidence to collect | Mitigations to test | Residual risk |
|---|---|---|---|---|
| Reorganization or majority-hash attack | A received payment is replaced, delayed, or censored. | Node-observed chainwork and conflicts, peer and tip agreement, value at risk, counterparty context, exception log. | Risk-based confirmation policy, independent node observation, delayed delivery or limits, conflict alerts, response owner. | Settlement remains probabilistic and observation can be incomplete. |
| Eclipse or route isolation | A node sees adversary-selected peers, headers, blocks, or timing. | Peer diversity, network paths, address sources, unexpected tip lag, out-of-band comparison, firewall and resolver records. | Diverse peer and network paths, controlled static peers where justified, monitoring, authenticated administration, tested isolation alarms. | Diversity can share hidden infrastructure; the comparison channel can also fail. |
| Key theft or signing deception | An unauthorized or misdirected transaction receives a valid signature. | Key inventory, device provenance, displayed transaction review, signing policy, backup and recovery tests, access logs. | Separated keys and duties, authenticated receive data, independent destination review, appropriate multisignature, incident drills. | Collusion, coercion, compromised interfaces, physical loss and recovery mistakes remain possible. |
| Node, wallet, or dependency defect | Software validates, displays, signs, or reports incorrectly. | Exact versions and build provenance, release notes, security notices, configuration diff, reproducibility or signature evidence, test results. | Staged upgrades, least privilege, independent checks, rollback and recovery plan, monitored dependencies, prompt security review. | Unknown defects and shared dependencies remain. |
| Supply-chain compromise | Hardware, firmware, binaries, signer keys, or update channels are altered. | Source and custody records, hashes and signatures, authenticated signer fingerprints, tamper inspection, firmware and network behaviour. | Approved sources, independent fingerprint verification, reproducible-build evidence where appropriate, quarantine and acceptance tests. | Authentic components can still contain defects or malicious upstream changes. |
| Backup or recovery failure | Keys or configuration cannot be recovered, or recovery exposes them. | Documented scope, encrypted/offline copies as appropriate, restoration drill, location and access separation, destruction records. | Tested recovery, geographic and role separation, versioned procedures, inheritance or continuity plan appropriate to the owner. | Disaster correlation, stale backups, insider access and procedural error remain. |
Operational mitigations need owners and stop gates
- Do not accept value based on a block explorer alone when independent validation is required.
- Do not expose Bitcoin Core RPC to the public internet; protect the host, credentials, wallet and dependent applications as separate boundaries.
- Do not install an update until source, checksum, signer identity, release notes and recovery path are recorded.
- Do not treat network privacy tools as protection against wallet, transaction-graph, endpoint, logging or host compromise.
- Do not rely on an untested seed, descriptor, wallet file, device or configuration backup.
Threat-model decision record
- Asset and decision: transaction acceptance, keys, node truth, mining template, service availability, privacy, or software provenance.
- Adversary: capability, access, incentives, time horizon, collusion and legal or physical leverage.
- Boundary: node, wallet, signer, host, peer network, template source, build chain, backup, person or facility.
- Evidence: exact observation, source, time, reviewer and uncertainty.
- Control and owner: mitigation, acceptance test, monitoring, escalation and recovery authority.
- Residual risk: what the control does not cover and what triggers reconsideration.
For adjacent controls, use the neutral guides on node and miner roles, self-custody boundaries, and operational and cyber ownership.
Pinned primary sources and review record
Content and links reviewed 29 August 2026. Repository links are pinned to Bitcoin Core tag v31.1. Recheck later releases and security notices before acting.
- Bitcoin whitepaper, especially proof of work, network operation and the simplified catch-up analysis.
- Bitcoin Core v31.1 validation and chain-selection implementation.
- Bitcoin Core v31.1 chain parameters.
- Bitcoin Core v31.1 peer-processing implementation.
- Bitcoin Core v31.1 security policy and reporting boundary.
- Primary eclipse-attack research paper.
Frequently asked questions
Does proof of work make Bitcoin transactions final?
Proof of work supports probabilistic settlement, not an absolute technical finality rule. A transaction’s reorganization risk generally falls as valid work accumulates above its block, but the result depends on adversarial hash share, connectivity, incentives, validation and the receiver’s threat model.
Can majority hash power create bitcoins or spend someone else’s coins?
Not under rules enforced by an independently validating node. Hash power can attempt reorganizations, double-spends and censorship, but it cannot make an invalid subsidy, invalid signature or other consensus violation valid to nodes that reject it.
Does running a node replace wallet security?
No. A node independently validates chain data for its operator. It does not protect seed material, approve signing policy, secure backups or prevent a compromised wallet interface from presenting a malicious destination.
What is an eclipse attack?
An eclipse attack isolates a node behind adversary-controlled peers or network paths so the victim receives a distorted view. Diverse peer paths, careful network controls, monitoring and independent out-of-band checks reduce risk but cannot eliminate isolation risk.
How many confirmations are enough?
There is no universal count. Choose a policy from the value at risk, attacker capability, observed chain and peer health, transaction properties, operational urgency and the consequences of a reorganization. Record exceptions rather than treating a familiar number as a guarantee.
Does a valid software signature prove a Bitcoin Core release is safe?
No. Authenticated checksums and signatures help establish provenance and byte integrity. They do not prove that code is defect-free, the signer identity was correctly verified, the build environment was honest, the host is uncompromised or the configuration fits the operator’s threat model.
