Bitcoin Technology Explained Simply: How Code, Nodes, Mining, and Security Work

Bitcoin technology for beginners: What actually happens in the background when someone sends Bitcoin? Where can you find the source code? Who decides which changes are introduced? And could quantum computers one day break the entire system? This detailed guide explains the technical foundations of Bitcoin in an accessible way – without assuming that you have studied cryptography or programmed your own blockchain.

Bitcoin is much more than a digital coin or a speculative investment. Behind the network is a combination of open-source software, cryptography, decentralized data processing, economic incentives, and rules that are collectively enforced. This combination is precisely what makes Bitcoin so technically unusual.

Anyone who would first like to learn about the general principles of distributed databases can find an additional introduction in our article about blockchain technology and how it works.

Contents:

• What Bitcoin is from a technical perspective
• Where to find the Bitcoin source code
• How Bitcoin fundamentally works
• Which algorithms Bitcoin uses
• How Bitcoin Core is structured
• Who maintains the code and decides on changes
• How to compile Bitcoin Core yourself
• How to navigate the source code
• How serious the threat from quantum computers is
• Common misconceptions about Bitcoin technology

 

What Is Bitcoin from a Technical Perspective?

In everyday language, the term “Bitcoin” is used to describe several different things. It may refer to the digital unit of value BTC, the worldwide network, the technical protocol, or a specific software implementation such as Bitcoin Core. To understand the system properly, these levels should be considered separately.

Bitcoin as a Unit of Value

BTC is the accounting unit used by the system. One Bitcoin can be divided into 100 million satoshis. The term satoshi is often abbreviated as “sat.”

However, Bitcoin does not exist as files stored on a computer or smartphone. Technically, the system consists of entries in a commonly verifiable transaction history. These entries determine the conditions under which particular amounts may be spent in the future.

Bitcoin as a Network

The Bitcoin network consists of many independent computers. These so-called nodes exchange transactions and blocks through a peer-to-peer network. There is no central server that manages all balances or approves transfers.

Every fully validating node can independently verify whether a transaction complies with the Bitcoin rules. It does not have to trust a bank, exchange, mining company, or other central organization to provide correct information.

Bitcoin as a Protocol

The Bitcoin protocol is a collection of rules. These rules define, among other things:

• how transactions are structured,
• how digital signatures are verified,
• what valid new blocks may look like,
• how many new bitcoins may be created,
• what the maximum supply can be,
• how Proof of Work is verified,
• how nodes communicate with one another, and
• under which conditions a transaction output may be spent.

Bitcoin Core as Software

Bitcoin Core is the best-known and most widely used full-node implementation. The software downloads blocks and transactions from the Bitcoin network, verifies them according to the consensus rules, and manages the current state of the blockchain.

Bitcoin Core also includes an optional wallet, a graphical user interface, command-line programs, and interfaces for other applications. However, Bitcoin Core is not identical to the entire Bitcoin network. Other programs can also implement the Bitcoin protocol as long as they correctly apply the same consensus rules.

 

Where Can You Find the Bitcoin Code?

The Bitcoin Core source code is publicly accessible. The main repository is hosted on GitHub at github.com/bitcoin/bitcoin. Bitcoin Core is published under the permissive MIT License.

You may therefore view, download, examine, modify, and use the code for your own projects, provided that you comply with the license terms. Knowledge of the most important Git fundamentals for everyday development helps when checking out specific versions, tracing changes, or creating your own development branch.

Which Programming Language Does Bitcoin Core Use?

The central Bitcoin Core code is written primarily in C++. It also includes Python scripts for functional tests, C code and optimized code in cryptographic libraries, and Qt components for the graphical user interface.

The repository contains much more than the executable programs. It also includes:

• unit tests and functional tests,
• build scripts for different operating systems,
• developer documentation,
• configuration examples,
• benchmarking and fuzz-testing tools,
• release notes for older and current versions,
• the integrated library for secp256k1 cryptography, and
• source code for the node, wallet, network, RPC interfaces, and user interface.

Is the Source Code Also the Bitcoin Specification?

Not entirely. Bitcoin does not have one single document that serves as the sole and definitive official specification. Several sources complement one another:

Source	Meaning
Bitcoin whitepaper	Describes the original idea and the basic system.
Bitcoin source code	Contains the rules and functions actually implemented in a particular software version.
Bitcoin Improvement Proposals	Document technical proposals, standards, and protocol extensions.
Developer documentation	Explains data formats, interfaces, build processes, and internal structures.
Running nodes	Determine in practice which rules individual network participants accept.
Historical blockchain	Shows which transactions and blocks were actually accepted.

The original Bitcoin whitepaper by Satoshi Nakamoto is only a few pages long. It describes the central idea with remarkable precision, but it does not include every rule and extension used by today’s implementation.

Many later features, including Segregated Witness, Taproot, hierarchical deterministic wallets, new address formats, and encrypted peer-to-peer connections, were developed only after the whitepaper had been published.

What Are Bitcoin Improvement Proposals?

Bitcoin Improvement Proposals are commonly referred to as BIPs. A BIP is a technical document that describes a new feature, standard, process change, or important design decision.

The BIPs are maintained in a separate public repository at github.com/bitcoin/bips.

It is important to understand that inclusion in the BIP repository does not automatically mean that a proposal has been accepted, activated, or supported by a majority. A BIP may be discussed for years, revised repeatedly, or remain in draft status indefinitely.

Which Bitcoin Core Version Is Current?

At the time this article was written in July 2026, Bitcoin Core 31.1 was part of the current stable release series. New versions are published regularly and include bug fixes, performance improvements, new interfaces, and occasionally larger functional changes.

Users should download the software from the official website at bitcoincore.org and, where possible, verify the published signatures or checksums.

The development branch named master on GitHub changes continuously. Although it is tested automatically, it is not intended to be treated as a stable production release. Anyone who simply wants to run Bitcoin Core should normally use an official release.

 

How Does Bitcoin Fundamentally Work?

The central problem Bitcoin solves is the prevention of double spending without centralized account management. Digital information can normally be copied without restriction. With digital money, however, the same amount must not be spent more than once.

Bitcoin solves this problem through a publicly verifiable transaction history, digital signatures, a peer-to-peer network, and Proof of Work.

1. Private Keys and Public Keys

The process begins with a randomly generated private key. In simplified terms, this is an extremely large secret number. Elliptic-curve cryptography is used to calculate a corresponding public key from it.

The private key must remain secret. It can be used to digitally sign transactions. The public key, or a value derived from it, is used to verify the signature.

Different Bitcoin address formats can be derived from a public key or a script. An address is a user-friendly encoded representation of particular spending conditions. It is not the same thing as the private key.

Safely storing these keys creates many additional security considerations. Our guide to choosing a secure cryptocurrency wallet explains the differences between software wallets, hardware wallets, and other storage methods.

2. Bitcoin Does Not Use Traditional Account Balances

Bitcoin does not operate like a bank database with one account balance for each customer. Instead, the system uses what are known as Unspent Transaction Outputs, or UTXOs.

A UTXO is an output from an earlier transaction that has not yet been spent. It contains a particular amount and a condition that must be fulfilled before it can be spent later.

If a wallet displays a balance of 0.5 BTC, that amount might, for example, consist of three separate UTXOs:

• 0.10 BTC,
• 0.15 BTC, and
• 0.25 BTC.

If you want to send 0.30 BTC, your wallet may use two or more suitable UTXOs as inputs. If the total value of the inputs is greater than the payment amount plus the transaction fee, the wallet creates a change output to a new address controlled by the same wallet.

3. A Wallet Creates a Transaction

A Bitcoin transaction includes, among other things:

• references to previous transaction outputs,
• the new outputs that are to be created,
• the respective amounts,
• unlocking data or signatures,
• a version number, and
• where applicable, time or sequence conditions.

The wallet selects suitable UTXOs, calculates a fee, creates the outputs, and signs the transaction using the private key. It then sends the transaction to a Bitcoin node.

4. Nodes Verify and Relay the Transaction

A receiving node checks, for example:

• whether the referenced UTXOs exist,
• whether they have not already been spent,
• whether the signatures are valid,
• whether the script conditions are fulfilled,
• whether no additional bitcoin value is created from nothing, and
• whether the transaction complies with the node’s local relay policies.

A valid but unconfirmed transaction may be added to the node’s mempool. The mempool is a temporary storage area for transactions that have not yet been included in a block.

Every node has its own mempool. Strictly speaking, there is therefore no single universal “Bitcoin mempool.” Different nodes may store slightly different transactions depending on their configuration, fee requirements, and the time at which they received them.

5. Miners Assemble Candidate Blocks

Miners or mining pools select transactions from their mempools and use them to assemble a possible new block. Transactions offering attractive fees are generally given priority.

The block also contains a special transaction known as the coinbase transaction. This assigns the permitted block subsidy and the transaction fees to the miner.

6. Proof of Work Secures the Order

A miner modifies particular data in the block header and repeatedly calculates a SHA-256-based hash. The result must be lower than a target value specified by the network.

Because the result of a cryptographic hash cannot be deliberately predicted, miners must perform an enormous number of attempts. A miner that finds a valid hash broadcasts the block to other nodes.

The nodes then verify the complete block. They check not only the Proof of Work but also every transaction contained in the block and all other consensus rules.

7. Additional Blocks Create Confirmations

Once a transaction has been included in a valid block, it has one confirmation. Each additional valid block built on top of that block increases the number of confirmations.

The more Proof of Work that has accumulated after a transaction, the more difficult it would be to alter the transaction history retrospectively. However, a confirmation is not the same as absolute mathematical irreversibility. Instead, the risk of a blockchain reorganization decreases sharply as additional blocks are added.

 

Which Algorithms and Technical Methods Does Bitcoin Use?

Bitcoin is not based on one secret super-algorithm. The system combines several established cryptographic and computer-science techniques.

SHA-256

SHA-256 is a cryptographic hash function. It processes data of any length and produces a 256-bit hash value.

Even a minimal change to the input data will normally result in a completely different output. In practice, the original input cannot be reconstructed from the hash.

Bitcoin uses SHA-256 for purposes including:

• Proof of Work,
• block and transaction identifiers,
• Merkle trees,
• various script operations, and
• other internal data structures.

For Proof of Work, the serialized block header is processed twice with SHA-256. This is why the procedure is often referred to as SHA-256d or Double-SHA-256.

RIPEMD-160 and HASH160

In older but still widely used constructions, a public key is first processed with SHA-256 and then with RIPEMD-160. This combination is known as HASH160.

It is used, for example, in traditional Pay-to-Public-Key-Hash and Pay-to-Witness-Public-Key-Hash outputs.

Elliptic Curves and secp256k1

Bitcoin uses the secp256k1 elliptic curve for traditional digital signatures. A public key can be calculated from a private key. With today’s classical computers, reversing this process is considered practically infeasible.

Older Bitcoin output types use ECDSA signatures. Taproot additionally introduced Schnorr signatures according to BIP 340. Both methods are based on the same elliptic curve and would, in principle, be threatened by a sufficiently powerful quantum computer.

Merkle Trees

The transactions within a block are combined in a Merkle-tree structure. Pairs of hash values are repeatedly hashed together until only a value known as the Merkle root remains.

This Merkle root is included in the block header. It allows someone to prove efficiently that a particular transaction belongs to a block without having to transfer all the other transactions for every proof.

Bitcoin Script

Bitcoin Script is a small, stack-based scripting language. It defines the conditions under which a UTXO may be spent.

Typical conditions include:

• a valid signature for a particular key,
• multiple signatures from a group of keys,
• reaching a specified block height or time,
• revealing a secret value that corresponds to a known hash, or
• a combination of several conditions.

Bitcoin Script is deliberately more restricted than many programming languages used by general-purpose smart-contract platforms. For example, it does not provide freely usable loops. This makes deterministic execution easier and limits certain classes of errors.

More information about programmable blockchain conditions can be found in our introduction to smart contracts and digital agreements. However, Bitcoin Script differs significantly from extensive smart-contract systems such as the Ethereum Virtual Machine.

Difficulty Adjustment

The Bitcoin protocol regularly adjusts the mining difficulty. The objective is for a new block to be produced approximately every ten minutes on average over the long term.

If the network’s total computing power increases, valid block hashes become correspondingly more difficult to find. If the computing power decreases, the difficulty can be reduced.

Halving and the Limited Supply

The block subsidy is halved after every 210,000 blocks. As a result, the number of newly created bitcoins gradually decreases.

The specified rules produce a long-term maximum supply of just under 21 million bitcoins. This number is not enforced by one individual database entry. Every fully validating node checks with each block whether the permitted subsidy has been respected.

 

How Is the Current Bitcoin Core Implementation Structured?

Bitcoin Core has grown over many years. The software consists of several areas that perform different tasks. More recent development work has attempted to separate the interfaces between the node, wallet, and user interface more clearly.

Peer-to-Peer Network

The networking component establishes connections to other Bitcoin nodes. It receives and sends, among other things:

• transactions,
• block headers,
• complete blocks,
• peer addresses, and
• other protocol messages.

When a node starts for the first time, it does not yet know any active peers. It can use preconfigured DNS seeds to discover initial potential peers. It then learns additional addresses directly from the network.

In addition to normal internet connections, Bitcoin Core can be used with technologies such as Tor or I2P. Newer protocol extensions also improve the protection of communications between nodes.

Validation

The validation component verifies transactions and blocks. This area is particularly security-critical because even small differences in the interpretation of consensus rules could split the network.

The checks include:

• syntax and data formats,
• block size or block weight,
• Proof of Work,
• signatures,
• script conditions,
• permitted input and output amounts,
• the block subsidy, and
• the prevention of double spending.

Chainstate and the UTXO Database

For ongoing validation, Bitcoin Core does not have to search through all previous transactions every time. The current state of all unspent transaction outputs is stored compactly in what is known as the chainstate.

The chainstate database contains the current UTXO set. When a valid block is processed, spent UTXOs are removed and newly created UTXOs are added.

This database is essential for quickly verifying new transactions. The complete historical blocks are stored separately in block files.

Block Files and the Block Index

Bitcoin Core stores complete blocks in files such as blk00000.dat, blk00001.dat, and additional consecutively numbered files. Supplementary undo data makes it possible to reverse a block during a blockchain reorganization.

The block index contains metadata about known blocks, their predecessors, their status, and the associated Proof of Work.

A node can be operated in pruning mode. In this configuration, older block files are partially deleted after successful validation. The node still verifies the blockchain independently, but it can no longer provide the complete historical blockchain to other participants.

Mempool and Relay Policies

The mempool contains transactions that have not yet been confirmed. A distinction must be made between consensus rules and local policy rules.

Consensus rules determine whether a transaction is fundamentally valid when included in a block. Policy rules additionally determine which unconfirmed transactions a particular node accepts into its mempool or relays to other nodes.

A transaction can therefore theoretically be consensus-valid while not being automatically relayed by many nodes. Miners could still include it in a block. Once it becomes part of a valid block, fully validating nodes must accept it according to the consensus rules.

Wallet

The Bitcoin Core wallet manages keys, spending conditions, addresses, and known transactions belonging to the user. Modern wallets increasingly use what are known as output descriptors.

A descriptor does not merely describe a single key. It describes the structure of an entire group of possible output scripts. This makes wallet configurations easier to back up accurately and transparently.

The wallet is optional. Bitcoin Core can be compiled without a wallet and operated purely as a node. Conversely, external wallets can use a Bitcoin Core node for blockchain data and for broadcasting transactions.

RPC, REST, and ZMQ Interfaces

Bitcoin Core provides several interfaces for other programs:

• JSON-RPC: Controls the node and wallet using commands.
• REST: Retrieves particular blockchain and network data.
• ZMQ: Provides notifications about new blocks and transactions.
• Command line: Provides access through bitcoin-cli and newer Bitcoin subcommands.

Developers can use these interfaces to connect their own wallets, block explorers, payment systems, monitoring tools, or analytics software. General knowledge of software development and programming is helpful before working directly with Bitcoin’s internal interfaces.

Graphical User Interface

Bitcoin Core includes a user interface developed with Qt. It can either be enabled during compilation or omitted completely.

For a server or a node running on a single-board computer, only the bitcoind background service is often required. Desktop users can instead use bitcoin-qt.

Component	Purpose
bitcoind	Bitcoin node running as a background service without a graphical user interface
bitcoin-qt	Node and optional wallet with a graphical user interface
bitcoin-cli	Command-line communication with a running node
Chainstate	Stores the current set of all UTXOs
Mempool	Stores locally accepted but unconfirmed transactions
Wallet	Manages keys, descriptors, addresses, and the user’s own transactions
P2P component	Communicates with other Bitcoin nodes
Validation	Verifies transactions, blocks, and consensus rules

 

Who Maintains the Bitcoin Code?

Bitcoin Core is not backed by a conventional company with an executive team, product managers, and a binding development roadmap. The code is developed by an international open-source community.

People contributing to the project include:

• programmers,
• code reviewers,
• testers,
• cryptographers,
• documentation authors,
• translators,
• wallet and infrastructure developers, and
• researchers from different organizations.

Some developers work independently, while others are funded by companies, research organizations, or nonprofit institutions. However, this does not automatically mean that those funding organizations control the Bitcoin protocol.

What Do Bitcoin Core Maintainers Do?

Certain experienced developers have the technical authorization to merge reviewed changes into the Bitcoin Core repository. They are often referred to as merge maintainers.

A maintainer can decide whether a pull request has received sufficient review and meets the project’s quality requirements. However, a maintainer cannot single-handedly determine which Bitcoin rules apply worldwide.

When a change is included in Bitcoin Core, it initially means only that it has become part of a particular software version. Every user independently decides whether to install and run that version.

How Does a Change Enter Bitcoin Core?

In simplified form, the typical process is as follows:

1. A developer describes a problem or a new idea.
2. Larger protocol changes are often discussed publicly in advance.
3. If appropriate, a BIP containing a technical specification is created.
4. A developer programs a concrete implementation.
5. The change is submitted as a pull request on GitHub.
6. Other developers review the code, tests, security, and potential effects.
7. Automated tests run on several operating systems.
8. Open concerns and objections must be addressed.
9. If the change receives sufficient support, a maintainer may merge it.
10. The feature may appear in a later release.

This process can take a long time, especially for security-critical changes. Bitcoin Core explicitly notes that code review and testing are frequently the main bottlenecks in development.

Who Decides on Consensus Changes?

For normal improvements to the user interface or performance, the usual development process is sufficient. Changes to the consensus rules are considerably more complicated.

Several groups play a role:

• Developers design and implement changes.
• Reviewers assess the technical quality.
• Maintainers may merge code into a repository.
• Node operators decide which rules their nodes enforce.
• Wallets and exchanges decide which features they support.
• Miners decide which valid transactions they include in blocks.
• Economic users decide which version of Bitcoin they accept as valuable.

None of these groups can enforce every change on its own. Miners, for example, cannot create an arbitrarily high block subsidy if fully validating nodes reject the resulting blocks.

Conversely, developers can publish new code, but they cannot force anyone to install it.

Soft Forks and Hard Forks

A soft fork tightens the rules in such a way that blocks following the new rules can still generally be regarded as valid by older nodes. However, those older nodes do not fully verify the new feature.

A hard fork relaxes or changes rules in a way that causes older nodes to reject newly created blocks. Without nearly complete coordination, this can create a permanent split into two separate networks.

For this reason, fundamental changes to Bitcoin are discussed particularly carefully and are often designed so that they could be activated as a soft fork.

 

How Can You Compile Bitcoin Core Yourself?

Because the Bitcoin Core source code is openly available, you can create your own executable programs from the source files. This process is referred to as compiling or building the software.

For most ordinary Bitcoin users, this is not necessary. Official binary packages are much more convenient. Nevertheless, compiling the software yourself can be useful.

When Is It Worth Building Bitcoin Core Yourself?

• You want to understand the source code more thoroughly.
• You want to test your own changes.
• You are developing a feature or bug fix.
• You want to use a particular build configuration.
• You need a node without a wallet or user interface.
• You want to review a pull request.
• You want to examine reproducible builds.
• You want to test an unreleased feature on Regtest or Signet.

When Does Compiling It Yourself Not Make Sense?

Compiling Bitcoin Core yourself does not automatically increase security. If you do not review the code, dependencies, and build system, the additional security compared with a verified official binary is limited.

A self-built development version should also not immediately be used with a wallet containing significant funds. Initial experiments belong in an isolated test environment.

Which Requirements Do You Need?

A basic Linux build requires, among other things:

• Git,
• a modern C and C++ compiler,
• CMake,
• Python for scripts and tests,
• Boost, and
• SQLite if the wallet is enabled.

The graphical user interface additionally requires Qt 6 and other libraries. Features such as ZMQ, IPC, or QR-code generation also have optional dependencies.

Example: Compiling Bitcoin Core on Ubuntu or Debian

The following example shows a simplified build without additional special configuration. The required packages may change in later Bitcoin Core versions. You should therefore always read the build documentation for the version you are using.

sudo apt update
sudo apt install git build-essential cmake python3 libboost-dev libsqlite3-dev

git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin

git checkout v31.1

cmake -B build
cmake --build build -j 4

ctest --test-dir build

In this example, git checkout v31.1 selects a particular stable release. If you simply use master, you will compile the current development version.

The number after -j specifies how many build tasks are executed in parallel. A higher number can accelerate the build but requires more memory and processing power.

Building Bitcoin Core Without a Wallet

The wallet can be disabled for a network-only node:

cmake -B build -DENABLE_WALLET=OFF
cmake --build build -j 4

This also removes the SQLite dependency required by the wallet.

Enabling the Graphical User Interface

After the required Qt and QR-code libraries have been installed, the graphical interface can be enabled explicitly:

cmake -B build -DBUILD_GUI=ON
cmake --build build -j 4

All available configuration options can be displayed with:

cmake -B build -LH

Running Functional Tests

In addition to compiled unit tests, Bitcoin Core includes numerous functional Python tests:

build/test/functional/test_runner.py

The complete test suite may take some time to run. Individual tests can also be started when reviewing a specific change.

Starting a Local Regtest Blockchain

Regtest is a private Bitcoin test network that runs exclusively on your own computer or within your local test environment. It allows you to generate blocks immediately and test features without using real bitcoin.

./build/bin/bitcoind -regtest -daemon

./build/bin/bitcoin-cli -regtest createwallet "testwallet"

ADDRESS=$(./build/bin/bitcoin-cli -regtest getnewaddress)

./build/bin/bitcoin-cli -regtest generatetoaddress 101 "$ADDRESS"

./build/bin/bitcoin-cli -regtest getblockchaininfo

The first 101 blocks ensure that the generated coinbase outputs become spendable under the Regtest rules. You can then create local transactions, generate blocks, and explore RPC commands.

Compiling Bitcoin Core on Windows

There are several options on Windows:

• compiling within the Windows Subsystem for Linux,
• cross-compiling with MinGW-w64, or
• building natively with Microsoft Visual Studio and MSVC.

WSL is often convenient for beginners because many of the steps are similar to the Linux instructions. A genuine native Windows build requires additional toolchains and dependencies.

The latest official instructions can be found in the repository in the files doc/build-windows.md and doc/build-windows-msvc.md.

Compiling Bitcoin Core on macOS

On macOS, the Xcode Command Line Tools and a package manager such as Homebrew are normally used. For a basic build, the official documentation lists dependencies including CMake, Boost, and Cap’n Proto.

xcode-select --install
brew install cmake boost capnp

git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
git checkout v31.1

cmake -B build
cmake --build build
ctest --test-dir build

Qt 6 and libqrencode can additionally be installed for the graphical user interface.

 

How Can You Navigate the Bitcoin Source Code?

Bitcoin Core consists of a very large number of files. Anyone who begins directly with consensus validation can quickly lose track of the overall structure. A gradual approach is more useful.

Important Directories in the Repository

Directory or File	Contents
src/	Central source code for the Bitcoin Core programs
src/net.cpp	Basic network connections and peer management
src/net_processing.cpp	Processing of Bitcoin P2P messages
src/validation.cpp	Large parts of block and transaction validation
src/txmempool.cpp	Management of unconfirmed transactions
src/consensus/	Definitions and code related to consensus rules
src/script/	Bitcoin Script and signature verification
src/wallet/	Wallet functionality
src/qt/	Graphical user interface
src/rpc/	JSON-RPC commands
src/secp256k1/	Cryptographic library for secp256k1
test/functional/	Functional Python tests
doc/	Build, development, and interface documentation

A Useful Learning Path

1. Begin by reading the Bitcoin whitepaper.
2. Understand transactions, UTXOs, blocks, and Proof of Work.
3. Start Bitcoin Core in Regtest mode.
4. Try simple RPC commands.
5. Create and decode transactions.
6. Examine a small functional test.
7. Set breakpoints in a debug build.
8. Trace a Regtest transaction through the mempool and block validation.
9. Read the relevant BIPs for the feature you are examining.

Do Not Immediately Modify the Consensus Rules

A locally modified version of Bitcoin Core can use any alternative rules you choose. However, this does not automatically make it compatible with the public Bitcoin network.

If your program accepts a block that regular Bitcoin nodes reject, it will subsequently follow its own incompatible blockchain. A local code change therefore does not alter the rules followed by all other participants.

 

Bitcoin and Quantum Computers: How Serious Is the Threat?

Quantum computers are often portrayed either as the imminent end of Bitcoin or as completely irrelevant science fiction. Both positions are too simplistic.

A sufficiently powerful, fault-tolerant quantum computer could genuinely threaten certain cryptographic methods used today. However, such an attack would be extraordinarily demanding from a technical perspective. It is currently impossible to predict reliably when suitable systems might become available.

Which Parts of Bitcoin Cryptography Would Be Affected?

Two areas of Bitcoin must be considered separately:

• digital signatures based on elliptic curves, and
• cryptographic hash functions such as SHA-256.

Shor’s Algorithm Against ECDSA and Schnorr

A sufficiently powerful quantum computer could use Shor’s algorithm to solve the discrete logarithm problem efficiently.

In simplified terms, this means that if the public key is known, such a computer might be able to calculate the corresponding private key. It could then create valid signatures and spend the affected bitcoin.

This would affect both traditional ECDSA signatures and the Schnorr signatures used by Taproot because both are based on secp256k1.

Grover’s Algorithm Against SHA-256

The situation is less dramatic for hash functions. Grover’s algorithm can theoretically provide a quadratic speedup for an unstructured search.

Idealized 256-bit preimage security would therefore be reduced roughly to a security level of approximately 128 bits. This would still represent a very high level of security. Practical implementation would also require enormous quantum resources.

Quantum computers would therefore not make SHA-256 instantly useless.

What Would Happen to Bitcoin Mining?

Grover’s algorithm could theoretically also provide advantages in mining. However, this does not automatically mean that a single quantum computer would immediately find every block.

Practical performance depends on error correction, clock speed, parallelization, energy consumption, and the available quantum hardware. If effective mining power increased permanently, the Bitcoin network would also adjust its difficulty.

For long-term security, digital signatures are therefore likely to be the more urgent quantum concern than SHA-256 Proof of Work itself.

When Is a Bitcoin Public Key Visible?

Whether a quantum attack would be possible depends partly on whether the public key is already known.

Output Type	Public Key Visible Before Spending?	Simplified Quantum Assessment
P2PK	Yes	Directly vulnerable in the long term once a suitable quantum computer exists
P2PKH	Normally only when spent	Partially protected by the hash before the first spend
P2WPKH	Normally only when spent	Partially protected by the hash before the first spend
P2SH or P2WSH	Depends on the script being used	Protection depends on the particular construction
P2TR or Taproot	Yes, the output contains a public key	Vulnerable in the long term if a sufficiently powerful quantum computer exists

With a P2PKH or P2WPKH output, only a hash of the public key is initially stored on the blockchain. The complete public key is revealed only when the output is spent.

However, this protection does not apply reliably if the same keys or addresses have been reused or if the public key has already become known by another means.

Taproot outputs, by contrast, contain a public key directly in the output. They offer many advantages in terms of efficiency, privacy, and complex spending conditions, but they must be assessed differently in relation to a hypothetical long-term quantum attack.

Long-Exposure and Short-Exposure Attacks

Current discussions often distinguish between two scenarios.

Long exposure: The public key has already been visible on the blockchain for a long time. A quantum attacker would have sufficient time to derive the private key.

Short exposure: The public key is revealed only when a transaction is sent. The attacker would have to calculate the private key and publish a competing transaction before the original transaction received sufficient confirmations.

An early quantum computer might initially threaten keys that have been visible for a long time, while a successful short-exposure attack would require considerably greater speed.

What Is the Current State of Quantum Computing?

As of July 2026, no publicly known quantum computer is capable of breaking secp256k1 quickly enough to perform a practical Bitcoin attack.

Current systems still operate with limited and error-prone physical qubits. Large fault-tolerant systems with quantum error correction would be required for extensive cryptographic calculations.

Predictions range from a few years to several decades. Such estimates involve considerable uncertainty. Improvements in algorithms could reduce the required resources, while building stable and scalable hardware remains a major challenge.

Post-Quantum Cryptography Already Exists

Post-quantum cryptography refers to classical algorithms designed to resist attacks from powerful quantum computers. They run on ordinary computers and do not themselves require a quantum computer.

The United States National Institute of Standards and Technology published its first post-quantum standards in 2024. For digital signatures, ML-DSA and the hash-based SLH-DSA are particularly relevant.

However, these signatures have different properties from the signatures currently used by Bitcoin. Public keys and signatures may be considerably larger. In a blockchain, this directly affects storage requirements, bandwidth, fees, and verification times.

Bitcoin therefore cannot simply replace an existing signature with an arbitrary post-quantum algorithm. Any introduction would have to be carefully coordinated with the consensus rules, block capacity, hardware wallets, multisignature methods, and long-term security requirements.

BIP 360: Pay-to-Merkle-Root

BIP 360 is a current draft for a new output type named Pay-to-Merkle-Root, or P2MR. It is based on concepts used by Taproot but removes the elliptic-curve-protected key path.

A P2MR output would instead be committed directly to the root of a script tree. This is intended to avoid exposing a long-lived output key protected by elliptic-curve cryptography.

BIP 360 does not, by itself, introduce a complete post-quantum signature scheme into Bitcoin. Instead, the proposal is intended to provide a structure into which quantum-resistant script conditions could later be incorporated.

As of July 2026, BIP 360 remains in draft status. It is not an activated Bitcoin consensus rule.

BIP 361: Migrating Legacy Signatures

BIP 361 considers a possible migration from today’s ECDSA and Schnorr outputs to future post-quantum output types.

The draft proposes long-term phases in which new payments to quantum-vulnerable output types could initially be restricted and older signature methods could later be gradually removed from the active system.

Such a step would have extremely far-reaching economic, technical, and political consequences. Bitcoin that was not migrated in time might eventually become impossible to spend under the previous conditions.

BIP 361 is also only a draft. There is currently no consensus on whether, when, or in what form such a procedure should be implemented.

Possible Bitcoin Strategies Against Quantum Computers

A future quantum strategy could include several steps:

1. Selecting and thoroughly reviewing suitable post-quantum signatures.
2. Introducing a new optional output type.
3. Adding support in Bitcoin Core, software wallets, and hardware wallets.
4. Providing a long voluntary migration period.
5. Monitoring actual developments in quantum computing.
6. If necessary, restricting the creation of new quantum-vulnerable outputs.
7. Deciding how to handle funds that are never migrated.

The final point is particularly difficult. If old outputs remained valid indefinitely, a quantum attacker might steal them. If they were disabled, legitimate owners could also lose access.

What Can Ordinary Bitcoin Users Do Today?

• Use current and reputable wallet software.
• Avoid reusing Bitcoin addresses unnecessarily.
• Store private keys and seed phrases securely.
• Do not make rushed transactions because of speculative quantum-computing reports.
• Monitor technical developments and future wallet updates.
• Migrate to new output types in good time if a future transition becomes necessary.

Address reuse is already problematic for privacy and security reasons, regardless of quantum computers. Our article about common Bitcoin risks and ways to avoid problems describes additional practical dangers.

 

Common Misconceptions About Bitcoin Technology

“The Bitcoin Is Stored in My Wallet”

A wallet primarily contains or manages the keys and information required to spend the corresponding UTXOs. The actual transaction data is maintained by the Bitcoin network and recorded in the blockchain.

“Miners Decide All the Bitcoin Rules”

Miners decide which valid transactions they want to include and which valid candidate block they want to build. However, they cannot force fully validating nodes to accept invalid blocks.

“GitHub Controls Bitcoin”

GitHub provides infrastructure for the public management of the code. The Bitcoin network would continue to operate independently of it. Copies of the source code are stored on many computers and could be moved to other platforms if necessary.

“Bitcoin Core Maintainers Can Change People’s Balances”

Maintainers can merge changes into a software repository. This does not give them the private keys belonging to other wallets, nor can they arbitrarily move existing bitcoin.

A software change intended to redistribute someone else’s funds would also have to be voluntarily installed and accepted by the network participants.

“Compiling Bitcoin Core Creates Bitcoin”

Compiling the code merely creates executable software. New bitcoin is created only within valid blocks according to the specified rules for the block subsidy.

“Every Node Always Stores the Complete Blockchain”

A normal archival node stores all complete blocks. A pruned node also validates the blockchain independently but subsequently deletes older block files while retaining a configured minimum amount of data.

“Bitcoin Is Completely Anonymous”

Bitcoin is pseudonymous. Addresses do not automatically contain a person’s name, but all transactions are publicly traceable. Connections can be established through exchange data, address reuse, and blockchain analysis.

“Quantum Computers Can Already Break Bitcoin”

There is no reliable evidence that this is currently possible. The theoretical risk is real, but the powerful, fault-tolerant quantum hardware required for such an attack is not yet available.

“Bitcoin Can Never Be Updated”

Bitcoin has already been developed and improved in many ways. However, changes must be compatible, secure, thoroughly reviewed, and accepted by a sufficient number of participants. This high barrier is not a flaw but an important part of the security model.

 

Conclusion: Bitcoin Is Software, a Network, and a Shared Set of Rules

Bitcoin does not work because a central organization controls every transaction. It works because thousands of independent participants can verify the same transparent rules for themselves.

The public Bitcoin Core code is an important part of this infrastructure. It manages network connections, verifies signatures, processes blocks, maintains the UTXO set, and provides interfaces for wallets and other applications.

Changes emerge through an open and often slow development process. Developers can program proposals, and maintainers can merge code. However, which rules ultimately become meaningful depends on which software is run and economically accepted by nodes, companies, miners, and users.

The issue of quantum computers demonstrates particularly clearly why this cautious process is necessary. Today’s elliptic-curve cryptography could become vulnerable in the long term. At the same time, specific timelines remain uncertain, and replacing existing signatures too quickly could create new risks.

Bitcoin is therefore neither technically immutable nor arbitrarily changeable. It is a living open-source system in which compatibility, decentralization, and verifiable consensus are more important than rapid product development.

Anyone interested not only in the technology but also in buying, trading, and financial risks can find further information in our articles about how cryptocurrency exchange trading works and how to invest in cryptocurrencies.

 

Official Technical Sources and Further Documentation

• Bitcoin Core source code on GitHub
• Official Bitcoin Core downloads
• Bitcoin Core developer documentation
• Guidelines for contributing to Bitcoin Core
• Bitcoin Improvement Proposals
• Bitcoin whitepaper
• Bitcoin Developer Documentation
• Official build instructions for Linux and Unix
• Official build instructions for Windows
• Official build instructions for macOS
• BIP 360: Pay-to-Merkle-Root
• BIP 361: Post-Quantum Migration and Legacy Signature Sunset
• NIST information about post-quantum cryptography

Technical status: July 2026. Bitcoin Core, BIPs, and post-quantum methods are continuously being developed. Before compiling or testing the software, always consult the documentation and release notes for the specific version being used.

Comments 0