a33f240524
d2d04864ef Merge bitcoin-core/secp256k1#1765: Add "silentpayments" module implementing BIP352 (take 4, limited to full-node scanning) 9e4ec507e9 Merge bitcoin-core/secp256k1#1890: nonce: terminate RFC6979 loop at UINT_MAX afff8cba00 Merge bitcoin-core/secp256k1#1894: extrakeys: check invariant that x-only pubkeys have even Y b1bc6f3e0c nonce: terminate RFC6979 loop at UINT_MAX 89a54b5aaf extrakeys: check invariant that x-only pubkeys have even Y cea6d11410 silentpayments: drop "shuffle outputs" recommendation from API docs 1ae90bde8b silentpayments: flush labels before direct match 84a02fa989 silentpayments: extract label batch checker 8c3e6e6d99 Merge bitcoin-core/secp256k1#1889: field: serialize elements by word 11dad6d06c Merge bitcoin-core/secp256k1#1887: Make theStack a maintainer and a security contact 4aa16704ce silentpayments: skip slow benchmarks for low iters count (<= 2) 7e4b313cd5 docs: update README f27a29687d ci: enable silentpayments module 4f7a578d4b tests: add sha256 tag test 936907b03f tests: add constant time tests b608a9d91b tests: add BIP-352 test vectors ca0136dcd5 silentpayments: optimize scanning by using batch inversion 7ae555c524 silentpayments: add benchmarks for scanning f0fdd99d31 silentpayments: add examples/silentpayments.c 1c1b2753f4 silentpayments: respect per-group recipients protocol limit (K_max=2323) d72a743273 silentpayments: receiving c83b6783b8 silentpayments: recipient label support b30ea3ebe4 silentpayments: sending a93e696a17 build: add skeleton for new silentpayments (BIP352) module e217ead5c4 field: serialize elements by word d5c64bafc7 SECURITY.md: Align the table 9bd50f0cef SECURITY.md: Add theStack's key ebf594320d Merge bitcoin-core/secp256k1#1884: SECURITY.md: remove Jonas Nick from trusted keys 21645c03a2 SECURITY.md: remove Jonas Nick from trusted keys b90075a074 Merge bitcoin-core/secp256k1#1882: scalar: correct `_scalar_get_bits_{limb32,var}` input condition docs 5a8a411425 Merge bitcoin-core/secp256k1#1877: field: correct `fe_equal` magnitude bound for `b` 6a599a4428 scalar: correct `_scalar_get_bits_{limb32,var}` input condition docs 994b35010d field: correct fe_equal's b magnitude bound 2ce4f71dc5 Merge bitcoin-core/secp256k1#1845: Improve checks for scalar _get_bits methods 68b45fd4e2 Merge bitcoin-core/secp256k1#1881: tests: Fix GCC 17 snapshot warning 9d75769dec tests: Fix GCC 17 snapshot warning 9e3a165ad0 Merge bitcoin-core/secp256k1#1879: ci: add 'brew trust' invocation to macOS CI 66260b78a2 ci: add 'brew trust' invocation to macOS CI 0cad3df503 Improve checks for scalar _get_bits methods git-subtree-dir: src/secp256k1 git-subtree-split: d2d04864ef9b056151603a3ced7980958b058028
3.4 KiB
Bitcoin Core integration/staging tree
For an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/.
What is Bitcoin Core?
Bitcoin Core connects to the Bitcoin peer-to-peer network to download and fully validate blocks and transactions. It also includes a wallet and graphical user interface, which can be optionally built.
Further information about Bitcoin Core is available in the doc folder.
License
Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/license/MIT.
Development Process
The master branch is regularly built (see doc/build-*.md for instructions) 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.
The https://github.com/bitcoin-core/gui repository is used exclusively for the development of the GUI. Its master branch is identical in all monotree repositories. Release branches and tags do not exist, so please do not fork that repository unless it is for development reasons.
The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.
Testing
Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.
Automated Testing
Developers are strongly encouraged to write unit tests for new code, and to
submit new unit tests for old code. Unit tests can be compiled and run
(assuming they weren't disabled during the generation of the build system) with: ctest. Further details on running
and extending unit tests can be found in /src/test/README.md.
There are also regression and integration tests, written
in Python.
These tests can be run (if the test dependencies are installed) with: build/test/functional/test_runner.py
(assuming build is your build directory).
The CI (Continuous Integration) systems make sure that every pull request is tested on Windows, Linux, and macOS. The CI must pass on all commits before merge to avoid unrelated CI failures on new pull requests.
Manual Quality Assurance (QA) Testing
Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.
Translations
Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.
Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.
Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.