Bitcoin SV: the node software for the original Bitcoin protocol

A repository that presents itself as the original protocol

The README is short, and its claims are specific. Bitcoin SV, also called Satoshi Vision, is described as the original Bitcoin, and the project says it restores the original Bitcoin protocol, will keep it stable, and allow it to massively scale. It states that Bitcoin SV will maintain the vision set out by Satoshi Nakamoto's white paper in 2008, and that the repository provides open source software to enable use of Bitcoin SV.

So the positioning is a claim about protocol history, not about features. Nothing in the README describes new capabilities, and that is itself informative about what this repository is. There is no feature list to scan, no configuration tour and no quick start. What you get is the source of the node implementation and a set of policies about how people should engage with the project.

The primary language is C++, the default branch is master, and the homepage is bitcoinsv.io. The release history shows a steady line of patch releases: v1.2.1 on 2026-03-30, v1.2.2 on 2026-04-28 and v1.2.3 on 2026-10-06, with the last push to the repository on the same day as the newest tag.

For an engineer, the useful question is not whether the protocol claims are right, but what the repository contains and how it is meant to be used. The rest of the README and the file layout answer that.

The Open BSV licence, not a standard open source licence

The licensing section names something unusual. Bitcoin SV is released under the terms of the Open BSV licence, with the LICENSE file in the repository root holding the details.

That is worth pausing on, because the licence is not one of the standard open source licences that a procurement checklist will already recognise. A team that has a policy of accepting only OSI approved licences will need to read this one and reach its own conclusion, and the README does not summarise the terms, so the LICENSE file is the only source. Anyone shipping software that links against this code needs to make that decision deliberately rather than by assuming the usual permissive defaults.

The second file in the root, COPYING, sits alongside it, and the presence of a separate COPYING file next to a non standard LICENSE is a reminder that the terms here were written deliberately rather than inherited from an older codebase.

There is also a second licence artefact in the tree that is easy to overlook. At the top level sits libbitcoinconsensus.pc.in, the pkg-config template for the consensus library, which tells you the project ships a reusable library interface alongside the node. That library has its own licence considerations when you link it into a product, so the question of which terms apply to which artefact is worth answering before you build against it.

Contributions are closed, and the README says when that will change

The development process section is short and blunt. This GitHub repository contains the source code of releases, and then: at this early stage in Bitcoin SV's development, we are not accepting contributions to the project, with an expectation that this will change in the future.

That single sentence defines the relationship between the people running the project and everyone else. The repository is a source release, not a collaborative development trunk in the ordinary open source sense. A pull request would be arriving at a project that has said it does not accept them, and the phrase about the future implies the policy is considered temporary rather than permanent.

The practical effect on an adopter is that this is a codebase you consume, audit and possibly patch for yourself, not one you contribute back to. If your requirement is to influence the node's direction, this repository is the wrong place to spend that effort, and the README gives no route for it beyond waiting for the policy to change.

It also affects how you should read the absence of documentation in the README. A collaborative project usually has contributor documentation explaining how to set up a build, and here CONTRIBUTING.md is present in the tree but the README still frames the project as closed to contributions, so treat that file as secondary to the policy statement in the README.

Security disclosure has its own address and its own policy

The README gives security its own section, and it is the most operationally specific part of the document. Security is core to the values of the project, and the team says it values the input of security researchers acting in good faith to help maintain high standards of security and privacy for users and the Bitcoin SV blockchain.

To encourage ethical and responsible research, the team has instituted a Responsible Disclosure Policy, and the README asks people to send an e-mail to the security address for details. So there is a private channel, and the policy document behind that address is the thing to read before you start probing a node.

The other contact routes are separated by confidentiality. A non-confidential issue goes through the GitHub issue system, a security vulnerability goes to the security address, and anything else goes to the support address. That separation matters in practice: an off-by-one or a crash that is not a vulnerability still gets filed publicly, while an exploitable one does not.

The point for an engineer evaluating the project is that disclosure is channelled and formal, not ad hoc. If you run a node in production, that means you have a route for reporting a problem and, more importantly, a route for learning about one, since the same address is where disclosures are received.

The tree carries two build systems and a dependencies recipe set

The file layout is the practical documentation. At the top level there is an autotools build with autogen.sh, configure.ac, Makefile.am and a build-aux directory, and a parallel CMake build with CMakeLists.txt and a cmake directory. Two build systems in one repository is a deliberate choice, and it usually means one of them is the primary for developers and the other is there for packagers and downstream distributions that prefer CMake.

The depends directory is the other key piece. It is the conventional name in the Bitcoin codebase family for a set of recipes that fetch and build the external libraries the node needs, so a build machine can be prepared from source rather than relying on system packages. For anyone building this in a reproducible way, or on a platform where those libraries are not packaged, that directory is the part to read first.

The rest of the tree follows the same conventions. There is src for the implementation, test for the test suite, doc for documentation, contrib for contributed utilities, share for shared data files, a Dockerfile-doxygen for building the API documentation in a container, INSTALL.md for installation instructions, and a setup.cfg for the Python tooling that supports linting and formatting. A .clangd file carries the language server configuration for the C++ sources, and CLAUDE.md sits in the root for tooling that reads repository conventions.

The .gitmodules file indicates that some dependencies are checked in as submodules, which matters for anyone who clones the tree shallowly or who scripts a build.

A consensus library, a shared library and a node, side by side

Three artefacts are visible from the tree, and they have different audiences.

The node is the primary product and corresponds to the release notes attached to each version tag, where v1.2.3, v1.2.2 and v1.2.1 all carry the title Bitcoin SV Version 1.2.x Release Notes. Those notes are the changelog for the implementation, and the tagging pattern shows the project ships point releases of a stable 1.2 line rather than frequent major versions, which is consistent with the README's statement that the protocol will be kept stable.

The consensus library is the one designed for reuse by other software. The pkg-config template libbitcoinconsensus.pc.in is what a consumer project would use at build time to find it, and the existence of a dedicated template rather than an ad hoc make variable indicates it is meant to be linked by third party code. That is the artefact to look at if you are building a wallet, a miner or an indexing tool that has to agree with the network on validity rules without embedding the whole node.

The shared library interface is what the rest of the tree supports, and the Dockerfile-doxygen shows that API documentation is built from the source comments rather than maintained separately, so the headers are the reference.

For an adopter, this split is the thing to plan around. The node is what you run, the consensus library is what you link, and the two move with the same release tags, so pinning one means pinning the other.

What the README does not tell you, and where to look instead

Several things a node operator would normally want are absent from the README, and naming them is more useful than guessing at them. There is no build command, no configuration file format, no description of the RPC interface, no networking defaults, and no statement of which platforms are supported. The README does not document a rollback path either, so the upgrade story for an operator is not written down in the place you would look for it.

The pointers it does give are the right ones, though. Installation instructions are in INSTALL.md in the repository root, the release notes are attached to the version tags, and the homepage is bitcoinsv.io. The source tree carries doc for the documentation and contrib for the contributed utilities, and the build-aux and cmake directories are where the build configuration lives.

The two project policies are the parts most likely to affect your plans rather than your build. The Open BSV licence is a custom set of terms that needs reading, and the closed contribution policy means the tree is a release artefact. The Responsible Disclosure Policy, on the other hand, is a positive signal for anyone running the software, because it means vulnerability reports have a defined route and a defined contact point.

Taken together, this is a repository that assumes you already know what Bitcoin SV is and want the implementation rather than an introduction to it.

Editorial conclusion

Adopt this repository if you intend to run a Bitcoin SV node, to build against its consensus library, or to audit the implementation of the protocol as the README describes it, and you are prepared for a codebase that takes no outside patches. Do not adopt it if you want to contribute upstream or need a project with a normal public contribution flow, because the README states that contributions are not being accepted at this early stage of development. Verify first that the Open BSV licence in the LICENSE file suits your use, that the build route you choose matches the release you need, autotools with autogen.sh and Makefile.am or the CMakeLists.txt, and that the dependencies directory is populated correctly for your platform, since the repository ships depend recipes rather than a single self contained setup script.

Frequently asked questions

Official sources

1. bitcoin-sv/bitcoin-sv on GitHub
2. Issues
3. Project website
4. README
5. Releases