Bitcoin Core: what the integration/staging tree actually ships

What Bitcoin Core is, and who the repository is for

The README opens with a one-line description: Bitcoin Core connects to the Bitcoin peer-to-peer network to download and fully validate blocks and transactions. It also includes a wallet and a graphical user interface, which can be optionally built. That sentence is the whole scope. The program is a validating node first, a wallet second, and the GUI is a build option rather than a default component.

The audience follows from that. If you want to check the chain against the consensus rules yourself instead of trusting someone else's server, this is the reference implementation of those rules. If you want a wallet where the keys never leave your machine, the wallet is in the same binary. If you are writing software that needs a node, the repository ships libbitcoinkernel.pc.in, which means the kernel is exposed as a library with a pkg-config file. Anyone looking for a price feed, an account, a login, or a mobile app is in the wrong repository, and the related searches around bitcoin price, bitcoin etf and Bitcoin login have nothing to do with what is here.

The project is written in C++ and released under the MIT license. The GitHub repository is described as an integration/staging tree, which is the maintainers' way of saying that the branch you see on GitHub is where work is integrated before it becomes a tagged release.

The master branch is not the product, tags are

The README is unusually blunt about this: the master branch is regularly built and tested, but it is not guaranteed to be completely stable. Tags are created regularly from release branches to indicate new official, stable release versions of Bitcoin Core. So there are two different things in one repository, and they carry different expectations. Master is the integration point. A tag such as v29.4, v30.3 or v31.1 is what you run if you want a release.

The release numbering is worth reading carefully. The recent tags include v29.4, v30.3 and v31.1, which means three maintenance lines are alive at once, each receiving patch releases. A node operator does not have to jump to the newest major version to stay current. That is a deliberate policy choice, and it is the reason the tags list is not a single ascending line.

This split also explains the contribution rules. The README says testing and code review is the bottleneck for development, and that the project gets more pull requests than it can review and test on short notice. For a security-critical codebase where a mistake can cost people money, slow review is the design, not a failure of process.

Building from source: CMake, depends, and the build docs

The repository root holds CMakeLists.txt, CMakePresets.json, CTestConfig.cmake, vcpkg.json and a depends/ directory. That layout tells you the build system is CMake with presets, that tests are wired through CTest, and that depends/ is the path for building dependencies from source rather than using the system's copies. The README does not restate the build steps; it points at doc/build-*.md for instructions, so the exact commands depend on your platform and the file you read.

The README does give one concrete test command. Unit tests can be compiled and run, assuming they were not disabled when the build system was generated, with ctest:

ctest

For the Python-based regression and integration tests under test/, the README gives this command, assuming build is your build directory and the test dependencies are installed:

build/test/functional/test_runner.py

If you only want a working node, the README's first line of practical advice is to skip all of this: for an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/. Building from source is for people who want to inspect, modify, or package the code.

Translations go through Transifex, not pull requests

One rule in the README catches people out. Translation changes and new translations are submitted to Bitcoin Core's Transifex page, and translations are periodically pulled from Transifex and merged into the git repository. The README then states, in bold, that translation changes are not accepted as GitHub pull requests, because the next pull from Transifex would overwrite them.

This is a small but real constraint. If you fix a string in a .ts file and open a pull request, the work is discarded at the next sync. The .tx/ directory in the repository root is the local side of that pipeline. For a translator, the correct entry point is Transifex; for a developer changing user-facing strings, the change lands in the source and the translation follows separately. The translation process document under doc/ describes how the sync works.

Where Bitcoin Core is the wrong tool

The README describes a node that downloads and fully validates blocks and transactions. That is a commitment of bandwidth, disk and time, and the repository does not pretend otherwise. If you want to check a balance or send a payment once, running a full node is not the shortest path, and the README offers no light-client mode to fall back on. The optional wallet is a full node wallet, not a hosted account.

The GUI is a second boundary. It can be optionally built, and its development lives in a separate repository, bitcoin-core/gui. The README says that repository's master branch is identical in all monotree repositories, that release branches and tags do not exist there, and that you should not fork it unless it is for development reasons. So if your interest is the interface rather than the node, the code you want is not in this tree, and the tags you would normally pin to do not exist over there.

Finally, master itself is a poor deployment target for the reason already quoted: it is not guaranteed to be completely stable. Running master in production is a choice to absorb that risk, and the README does not soften it.

How Bitcoin Core differs from an SPV or hosted wallet

The real alternative for most people is a light client or a hosted wallet, and the difference is architectural rather than cosmetic. A hosted wallet holds your balance on someone else's server and asks that server what the chain looks like. A light client verifies a chain of block headers and trusts that the longest chain it hears about is the real one. Bitcoin Core does neither: it downloads the blocks and validates them against the consensus rules, which is what the README means by fully validate.

That changes what you can conclude from your own machine. A hosted wallet tells you what its operator believes. A validating node tells you what the rules allow, using data it checked itself. The cost is the download and the storage, and the benefit is that no third party's answer is required. The README frames the whole project around that trade, and the wallet and GUI are additions to it rather than the point of it.

Maintenance, releases and the MIT license

The last push to the repository was on 2026-07-10, and the most recent tags in the release list are v29.4 and v30.3, both dated 2026-07-10, with v31.1 on 2026-07-08. The pattern shows parallel maintenance lines rather than a single moving target, so an upgrade is a decision about which line to follow, not simply a matter of taking the newest number.

Upgrade cost is not documented in the README. There is no rollback procedure, no downgrade note and no migration guide in the text; the README defers to doc/build-*.md for building and to the doc folder generally for further information. If you need to know what a version bump does to an existing data directory, the README is silent and you have to look elsewhere in the repository.

The license is MIT. The README states that Bitcoin Core is released under the terms of the MIT license and points to the COPYING file. MIT is permissive, which matters if you plan to redistribute a build or link against the kernel library described by libbitcoinkernel.pc.in. This is a description of the license text, not legal advice; read COPYING before you ship anything.

Editorial conclusion

Adopt Bitcoin Core if you need to validate the chain yourself, run a wallet you control, or build on the node through libbitcoinkernel; the README points to doc/build-*.md for build instructions and to bitcoincore.org/en/download for binaries. Do not adopt it if you want price data, an exchange account, or a hosted wallet, and do not run master expecting stability, because the README states it is not guaranteed to be completely stable. Verify first that your platform has a build guide under doc/, that your machine can hold the full chain, and that you can run ctest and build/test/functional/test_runner.py before you depend on the build.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes