Bitcoin Core

Pavel accepts bitcoin for books. A customer shows him a payment receipt on her phone, but he wants to know whether the payment has really arrived and is included in a valid block. He could ask a public explorer or use a wallet connected to his own node. Bitcoin Core is software for running that node. Here, a node means a computer running software that independently checks Bitcoin’s rules; a block is a batch of transactions added to the shared history. It receives data from others but judges their validity itself. Pavel is an illustrative example: the point is to replace simply trusting somebody else's report with your own verification. Installing the program does not make him a miner, award him BTC or let him reverse other people's payments. The project publishes its source code under the MIT license, allowing study, modification and redistribution under the license terms. [1] [16]

These jobs are easy to confuse because Bitcoin Core can do both. The node checks history and new blocks; the wallet tracks relevant funds, creates addresses and prepares transactions. If it holds private keys, it can also sign with them. A private key is secret data the wallet uses to create a digital signature authorizing the spending of the corresponding bitcoin. The key itself is not sent to other nodes. Yet Core can run with no wallet at all. Pavel could use another compatible application for payments and his node for verified data; some connections require additional software. Merely running Core does not redirect every other wallet to his node. A few program names help here: bitcoin-qt provides a graphical interface, bitcoind runs in the background, and bitcoin-cli sends commands to the software. [12] [17]

A new node must catch up with history. This is called Initial Block Download, or IBD. During ordinary synchronization it downloads blocks and checks their links, miners' work and transaction rules. Processing history builds its chainstate: a local record of outputs that have not yet been spent, called UTXOs. A transaction output specifies an amount and the conditions for spending it, such as a required signature. It remains in this record until another transaction spends it. This is not a list of names and bank accounts. Speed depends on the computer, storage and connection, so a slow start alone does not mean something is broken. Pavel checks that synchronization has finished before using the node to verify current payments.

There is an important qualification: under defined conditions, assumevalid can skip checks of scripts, the spending conditions, deep in history; -assumevalid=0 disables that shortcut. A different feature, AssumeUTXO, can start from a checked state snapshot while processing earlier history in the background. The snapshot is a saved UTXO record at a particular block. The software first compares its hash, a digital fingerprint, with an expected value in its code; this does not mean it has already independently verified all earlier history. They have different assumptions; neither justifies saying every installation has performed exactly the same checks from the outset. [9] [10] [12] [17]

Once synchronized, Core keeps receiving data from connected nodes, known as peers. It stores accepted unconfirmed transactions in its Mempool, a temporary waiting area. Being there does not mean a transaction has a block confirmation, and different nodes may hold different transactions. When a new block arrives, Core checks it. Among valid candidate chains it follows the greatest accumulated work, rather than counting computer votes or simply counting blocks. Pavel therefore distinguishes 'I have seen the payment' from 'the payment has a confirmation'. His own node cannot guarantee immediate inclusion and does not eliminate reorganizations, where another valid branch replaces part of the history it was following. [16]

Suppose Pavel's node refuses to admit an unconfirmed transaction to its Mempool. That does not automatically mean the transaction can never appear in a valid block. Consensus rules determine valid blocks and valid spending for that node. Local relay policy adds rules about which unconfirmed transactions it accepts and forwards, for example to protect its resources from overload. That policy is not applied in the same way to transactions inside a received block: consensus validity is what matters there. Different Mempool settings therefore do not by themselves split the network. Keeping this distinction in mind helps you read debates about Core without treating every setting as a change to Bitcoin's monetary rules. [13]

Core stores block data, node state and, optionally, wallets. Pruning saves space by deleting older block files and the data needed to undo their changes after processing. The node still verifies new blocks; it just no longer keeps the entire archive at hand. Historical queries or rescanning old payments may then require downloading data again. Indexes are supporting records that speed up lookups; txindex, for example, is incompatible with pruning. Choose them according to what your node needs to serve. Another distinction is crucial: public blocks can be downloaded again, but they cannot restore lost private keys. A Core wallet needs its own secure backup. While the software is running, use its backup function, such as backupwallet, rather than casually copying a database that is being written to. [11] [12]

Pavel starts at the official site and reads the instructions for his chosen release. A SHA-256 checksum is a fingerprint of the downloaded file: it detects a difference from the expected file. On its own, it does not tell him who published that expected fingerprint. Digital signatures and the identities of signing keys must therefore be checked too. An attacker who supplies both a program and its own checksum is not defeated merely because the two match. For deeper verification, the project uses reproducible builds: independent people can build identical files from the same source code and compare results. Guix helps provide a consistent build environment. This strengthens verification of the program's origin; it does not prove the code has no bugs. [8] [7]

Core offers JSON-RPC, an interface through which other programs can control it. It supports node queries and service integration, but depending on available wallets and permissions it can also enable operations involving funds. Its credentials are therefore not something to hand to a supposed helper. The interface does not itself encrypt network traffic and is not designed for exposure to the public internet. Ordinary connections to other Bitcoin nodes are separate from exposing these controls. For local access, Core also uses temporary credentials in a .cookie file. Remote administration requires a secured connection and restricted access, following the documentation. If you are just trying a node, there is no reason to begin by opening its administrative interface to the world. [14]

Anyone can propose a code change. Other contributors read, test and discuss it; repository maintainers can merge accepted changes. That does not give them remote control of Pavel's node. Its operator decides what software to run. Nor is that choice a ballot that lets one person rewrite everyone else's rules: an incompatible change can separate their node from the rest. Bitcoin Core is an important implementation of the rules, not a company that owns the entire network. When reading announcements, distinguish a proposal, its acceptance into the source code, a software release and actual adoption. There can be a long road between those stages. [15]

You can begin by running a node without storing private keys on it. Pavel first verifies the file and signatures, lets IBD finish and checks that his chosen wallet really obtains data from his node. He then monitors connections, block progress and free space. Before upgrading, he reads the release notes, including any migration requirements; if he uses a wallet, he checks its backup and recovery. The debug.log diagnostic file can help with problems but should not be published without thought. Pruning, indexes and RPC settings should fit his use, rather than an unfamiliar guide copied blindly. A personal node should be an understandable verification tool. It is not a prerequisite for a first small purchase, but makes sense when you want to know why you regard your payments as valid. [12] [14]