Bitcoin Core is an open-source Bitcoin node implementation with peer-to-peer networking, independent block and transaction validation, an optional wallet and programmatic interfaces. It is widely used, but it is not Bitcoin itself, not a constitution, and not an authority that can unilaterally change the rules accepted by users.
What Bitcoin Core does, and what it does not do
| Capability | Bitcoin Core role | Boundary |
|---|---|---|
| Block validation | Checks candidate blocks against the rules implemented by the running software and tracks the valid chain with the most accumulated proof of work. | A node does not make an invalid block valid merely because miners extend it. |
| Transaction handling | Validates transactions in blocks and may accept and relay unconfirmed transactions under local mempool policy. | Mempool acceptance or relay is not a promise of confirmation and is not identical to consensus validity. |
| Peer networking | Requests, announces and relays data with peers according to configuration and local policy. | A reachable listening node is not required for self-validation; opening inbound access creates another operational boundary. |
| Wallet | Can create and load wallets when the wallet component is available and enabled. | A node can run without a loaded wallet. Node validation does not by itself back up keys or make wallet use private. |
| Mining interface | Offers mining RPCs such as block-template creation and block submission. | It does not turn general-purpose hardware into proof-of-work equipment or give a pooled worker template control. |
Consensus rules are not relay policy
Consensus rules determine whether a block is accepted by the node. Policy controls local treatment of unconfirmed transactions: mempool admission, relay and template selection defaults. Policy can differ between nodes without splitting the confirmed chain. A consensus incompatibility can produce divergent accepted chains, so upgrades that affect consensus require exceptional review and coordination.
| Question | Consensus | Policy |
|---|---|---|
| What object is judged? | Blocks and their transactions in chain context. | Usually unconfirmed transactions, peer messages and local candidate templates. |
| What happens on failure? | The node rejects the block as invalid. | The node may decline mempool admission or relay even though a future block containing the transaction could still be valid. |
| Can settings differ? | Incompatible active rules risk a chain split. | Local policies routinely differ; propagation and miner selection can therefore differ. |
| Who chooses? | Each operator chooses and runs software that enforces rules for that operator. | Each node operator and block-template producer controls its applicable local policy. |
Developers propose and review code; operators decide what to run; block-template producers select and order candidate transactions; proof-of-work devices search assigned work; nodes independently validate received blocks. None of those roles alone is a universal governance switch.
Archival, pruned and service modes
“Full node” describes validation, not permanent storage of every raw block. An archival node retains historical block data. A pruned node validates during initial synchronization and then deletes older raw block and undo files to stay within its configured storage target. Pruning limits historical serving, rescans and some indexes; changing a pruned installation to needs that require discarded data can require downloading or rebuilding data again.
| Mode or option | What it provides | Constraint to test |
|---|---|---|
| Archival | Validates and retains raw historical block data. | Storage, backup assumptions, indexes and dependent applications need separate capacity planning. |
| Pruned | Validates, retains chainstate and a configured window of block data, and removes older raw data. | Cannot serve discarded blocks; wallet rescans and indexes can be constrained. Confirm exact v31.1 option help before enabling. |
| Blocks-only | Reduces most mempool and transaction-relay activity. | Changes unconfirmed-transaction behaviour and can harm privacy if the same node broadcasts wallet transactions without a deliberate design. |
| Non-listening | Makes outbound peer connections without accepting ordinary inbound peers. | Still validates for its operator but does not offer the same inbound network service. |
| Wallet disabled or unloaded | Runs node functions without a loaded signing wallet. | Applications needing wallet RPCs must use a separately designed wallet path. |
Do not copy fixed storage, memory, bandwidth or synchronization-time numbers from a dated article. Measure the selected release, indexes, pruning target, wallet needs, platform, peer configuration and available resources. The v31.1 option help and pinned memory guide are the control.
Initial block download and the assumevalid boundary
- Headers and proof of work: the node obtains headers, checks header-level rules and compares valid chain candidates by accumulated chainwork, not merely block count.
- Block and state processing: it obtains blocks, checks transaction and block rules and builds its local unspent-output state.
- Historical script optimization: the v31.1 default assumevalid setting can skip some signature-script checks for ancestors of a configured block only when implementation conditions are met and the chain is sufficiently buried.
- Recent validation: assumevalid is not a blanket exemption for recent blocks, proof of work, transaction structure, amounts or chain selection. Setting assumevalid to zero disables this historical script-check optimization, but operators must consult the exact version help and source.
Dated release review: Bitcoin Core 31.1
Verify an official release before execution
- Start from the official download and verification instructions, not a copied binary or an unverified search result.
- Download the package for the intended platform plus the release’s checksum list and signatures from the official version directory.
- Check that the package’s SHA-256 digest matches the signed checksum list.
- Verify signatures on that checksum list and independently authenticate the fingerprints of the signer keys you choose to trust. A “good signature” without a trusted fingerprint is incomplete identity evidence.
- Record the URL, filename, digest, signer fingerprints, result, date and reviewer before installation. Keep the prior recovery plan and data backup appropriate to the wallet and node configuration.
A digest verifies bytes against a list; a signature links that list to a key. Neither proves the code is defect-free, the host is uncompromised or the configuration is safe. The official process also documents stronger reproducible-build verification for operators who require it.
Wallet, RPC and host security
| Boundary | Minimum question | Stop condition |
|---|---|---|
| Host and executable | Are package signatures verified, updates controlled, privileges limited and host access monitored? | Do not use a shared or untrusted host for security-sensitive operations. |
| Wallet and backups | Is a wallet actually needed, who controls keys, and has a tested recovery method been documented offline? | Do not treat blockchain data, a copied data directory or wallet encryption alone as a complete recovery plan. |
| RPC | Is RPC limited to authorized local or secured private clients using appropriate authentication and system isolation? | Do not expose RPC to the public internet. Treat anyone with valid RPC credentials as having powerful node and loaded-wallet capabilities; protect the host as a separate boundary. |
| Dependent applications | Are versions, RPC permissions, wallet endpoints, parsing, logging and failure behaviour reviewed? | Do not assume an RPC whitelist is a complete security boundary or that RPC compatibility is evergreen. |
| Inbound P2P | Does the firewall expose only the intended peer interface, and are ownership, monitoring and patching assigned? | Do not confuse P2P access with RPC access or expose an administrative service while opening peer connectivity. |
The pinned v31.1 JSON-RPC security documentation prefers local cookie authentication and warns that RPC is unencrypted and not hardened for arbitrary internet traffic. Remote administration needs a separately secured private path and system-level isolation. Configuration snippets copied from another version or packaged stack are not authoritative for v31.1.
Privacy is a system property
Self-validation prevents a third-party wallet backend from being the sole source of chain information, but it does not guarantee anonymity. Peers can observe network timing and addresses; transaction structure and address reuse can reveal links; DNS, logs, wallets, plugins and the host can leak data. Tor or I2P can change network-path exposure, but each has configuration and availability boundaries. Review the pinned v31.1 Tor documentation and threat-model the entire transaction path.
Blocks-only mode is not automatically a privacy mode. The v31.1 memory guide warns that broadcasting from a blocks-only client can make a transaction stand out and documents related wallet settings and the need for another broadcast mechanism. Do not promise that one option makes a node private.
How Bitcoin Core relates to mining
An ASIC searches proof-of-work nonces. A block-template producer selects candidate transactions and constructs work. A pool can coordinate work and payouts. Bitcoin Core can validate the chain and expose mining RPCs used by solo or template-producing software. These are separate roles.
Running a validating node lets an operator independently reject invalid blocks and verify chain state, but it does not prove what template a remote pool gave a worker, guarantee transaction selection, create payout evidence or improve expected mining revenue. The nodes-versus-miners guide maps security roles, while the payout accounting guide covers contractual and custody evidence.
Bitcoin Core’s getblocktemplate and submitblock interfaces support block construction and submission workflows; the pinned BIP 22 specification snapshot describes that protocol. Actual mining software, pool policy and template authority must be verified separately.
Operator decision record
- Purpose: validation, wallet backend, archival service, application index, mining template source, or a documented combination.
- Release: exact version, source URL, checksum, trusted signer fingerprints, review date, lifecycle and security-notice check.
- Mode: archival or pruned, indexes, blocks-only choice, inbound P2P, wallet state and dependent-service data needs.
- Threat model: host administrators, RPC clients, wallet keys, backups, network observers, logs, physical access and recovery.
- Acceptance: synchronized state, peer and chain checks, application tests, backup recovery evidence, alerts and named update owner.
- Change triggers: release notice, end-of-life status, configuration change, new application, wallet use, suspected compromise or storage failure.
Pinned primary sources and revision record
Content and links reviewed 29 August 2026. Version-pinned repository links below refer to tag v31.1; the BIP link is pinned to commit 7fe0b034ec967b52a5a28276419117326df93263. Recheck official release, lifecycle and security information before acting.
- Bitcoin Core v31.1 release notes.
- Bitcoin Core download and signature-verification procedure.
- Bitcoin Core software lifecycle.
- Bitcoin Core security advisories and disclosure policy.
- Bitcoin Core v31.1 chain parameters, including the assumevalid value.
- Bitcoin Core v31.1 validation implementation, including the assumevalid conditions.
- Bitcoin Core v31.1 memory and blocks-only guidance.
- Bitcoin Core v31.1 JSON-RPC interface and security boundary.
- Bitcoin Core v31.1 Tor documentation.
- BIP 22 getblocktemplate specification, revision-pinned snapshot.
Frequently asked questions
Is Bitcoin Core the Bitcoin network or protocol?
No. Bitcoin Core is one open-source implementation of a Bitcoin node and optional wallet. It implements consensus rules and networking behaviour, but the software project is not the network, the asset or a governance authority.
Does a pruned Bitcoin Core node still validate blocks?
Yes. A pruned node validates the chain it processes and then deletes older raw block and undo data according to its configuration. It cannot later serve or rescan data it no longer stores, so archival and application requirements must be decided before pruning.
Does assumevalid make Bitcoin Core trust an unverified chain?
It introduces a bounded assumption about historical script validity: in the reviewed v31.1 implementation, qualifying ancestors of the configured block can skip signature-script checks when the chainwork and burial conditions are met. Proof of work, chain selection and other validation still apply, and recent blocks are not exempt. Set assumevalid to zero to perform those historical script checks; exact behaviour is version-specific.
Is the release named on this page always the latest Bitcoin Core release?
No. Version 31.1 is a dated review snapshot checked on 29 August 2026. Before downloading or upgrading, recheck the official releases, download, lifecycle and security-notice pages.
What does verifying a Bitcoin Core download prove?
A matching checksum shows the file matches the checksums list, and valid signatures show that trusted signer keys attested to that list. Operators must independently authenticate signer fingerprints. These checks do not prove that software is bug-free or appropriate for a particular system.
Should Bitcoin Core RPC be exposed to the public internet?
No. The v31.1 RPC security documentation says not to expose RPC to the public internet. Treat valid RPC credentials as powerful node and loaded-wallet access, prefer local cookie authentication, and use system-level isolation and a secured private path for authorized remote clients.
Does running Bitcoin Core make wallet activity anonymous?
No. Self-validation removes reliance on another wallet backend, but peer observation, transaction graph analysis, wallet behaviour, address reuse, DNS, logs and host compromise can still reveal information. Tor or I2P changes network paths but does not erase every privacy risk.
Does an ASIC miner replace a Bitcoin Core node?
No. An ASIC performs proof-of-work hashing. A node validates blocks and transactions; mining software or a pool coordinates work and templates. Solo template construction can use Bitcoin Core mining RPCs, while a pooled miner may not control the pool template.
