Bitcoin is an experimental digital currency that enables instant payments toanyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operatewith no central authority: managing transactions and issuing money are carriedout collectively by the network. Bitcoin Core is the name of open sourcesoftware which enables the use of this currency.
For more information, as well as an immediately usable, binary version ofthe Bitcoin Core software, see https://bitcoincore.org/en/download/, or read theoriginal whitepaper.
Bitcoin Core is released under the terms of the MIT license. See COPYING for moreinformation or see https://opensource.org/licenses/MIT.
The master branch is regularly built (see doc/build-*.md for instructions) and tested, but it is not guaranteed to becompletely stable. Tags are createdregularly from release branches to indicate new official, stable release versions of Bitcoin Core.
The https://github.com/bitcoin-core/gui repository is used exclusively for thedevelopment of the GUI. Its master branch is identical in all monotreerepositories. Release branches and tags do not exist, so please do not forkthat repository unless it is for development reasons.
Testing and code review is the bottleneck for development; we get more pullrequests than we can review and test on short notice. Please be patient and help out by testingother people's pull requests, and remember this is a security-critical project where any mistake might cost peoplelots of money.
Developers are strongly encouraged to write unit tests for new code, and tosubmit new unit tests for old code. Unit tests can be compiled and run(assuming they weren't disabled in configure) with: make check. Further details on runningand extending unit tests can be found in /src/test/README.md.
The CI (Continuous Integration) systems make sure that every pull request is built for Windows, Linux, and macOS,and that unit/sanity tests are run automatically.
Manual Quality Assurance (QA) Testing
Changes should be tested by somebody other than the developer who wrote thecode. This is especially important for large or high-risk changes. It is usefulto add a test plan to the pull request description if testing the changes isnot straightforward.