e0ba6bbed9
b8d279a81cdoc: add comment to explain correctness of GatherClusters() (Suhas Daftuar)aba7500a30Fix parameter name in getmempoolcluster rpc (Suhas Daftuar)6c1325a091Rename weight -> clusterweight in RPC output, and add doc explaining mempool terminology (Suhas Daftuar)bc2eb931daRequire mempool lock to be held when invoking TRUC checks (Suhas Daftuar)957ae23241Improve comments for getTransactionAncestry to reference cluster counts instead of descendants (Suhas Daftuar)d97d6199ceFix comment to reference cluster limits, not chain limits (Suhas Daftuar)a1b341ef98Sanity check feerate diagram in CTxMemPool::check() (Suhas Daftuar)23d6f457c4rpc: improve getmempoolcluster output (Suhas Daftuar)d2dcd37aacAvoid using mapTx.modify() to update modified fees (Suhas Daftuar)d84ffc24d2doc: add release notes snippet for cluster mempool (Suhas Daftuar)b0417ba944doc: Add design notes for cluster mempool and explain new mempool limits (Suhas Daftuar)2d88966e43miner: replace "package" with "chunk" (Suhas Daftuar)6f3e8eb300Add a GetFeePerVSize() accessor to CFeeRate, and use it in the BlockAssembler (Suhas Daftuar)b5f245f6f2Remove unused DEFAULT_ANCESTOR_SIZE_LIMIT_KVB and DEFAULT_DESCENDANT_SIZE_LIMIT_KVB (Suhas Daftuar)1dac54d506Use cluster size limit instead of ancestor size limit in txpackage unit test (Suhas Daftuar)04f65488caUse cluster size limit instead of ancestor/descendant size limits when sanity checking TRUC policy limits (Suhas Daftuar)634291a7dcUse cluster limits instead of ancestor/descendant limits when sanity checking package policy limits (Suhas Daftuar)fc18ef1f3fRemove ancestor and descendant vsize limits from MemPoolLimits (Suhas Daftuar)ed8e819121Warn user if using -limitancestorsize/-limitdescendantsize that the options have no effect (Suhas Daftuar)80d8df2d47Invoke removeUnchecked() directly in removeForBlock() (Suhas Daftuar)9292570f4cRewrite GetChildren without sets (Suhas Daftuar)3e39ea8c30Rewrite removeForReorg to avoid using sets (Suhas Daftuar)a3c31dfd71scripted-diff: rename AddToMempool -> TryAddToMempool (Suhas Daftuar)a5a7905d83Simplify removeRecursive (Suhas Daftuar)01d8520038Remove unused argument to RemoveStaged (Suhas Daftuar)bc64013e6fRemove unused variable (cacheMap) in mempool (Suhas Daftuar) Pull request description: As suggested in the main cluster mempool PR (https://github.com/bitcoin/bitcoin/pull/28676#pullrequestreview-3177119367), I've pulled out some of the non-essential optimizations and cleanups into this separate PR. Will continue to add more commits here to address non-blocking suggestions/improvements as they come up. ACKs for top commit: instagibbs: ACKb8d279a81csipa: ACKb8d279a81cTree-SHA512: 1a05e99eaf8db2e274a1801307fed5d82f8f917e75ccb9ab0e1b0eb2f9672b13c79d691d78ea7cd96900d0e7d5031a3dd582ebcccc9b1d66eb7455b1d3642235
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.