f34fe0806a
5736d1ddactracing: pass if replaced by tx/pkg to tracepoint (0xb10c)a4ec07f194doc: add comments for CTxMemPool::ChangeSet (Suhas Daftuar)83f814b1d1Remove m_all_conflicts from SubPackageState (Suhas Daftuar)d3c8e7dfb6Ensure that we don't add duplicate transactions in rbf fuzz tests (Suhas Daftuar)d7dc9fd2f7Move CalculateChunksForRBF() to the mempool changeset (Suhas Daftuar)284a1d33f1Move prioritisation into changeset (Suhas Daftuar)446b08b599Don't distinguish between direct conflicts and all conflicts when doing cluster-size-2-rbf checks (Suhas Daftuar)b53041021aDuplicate transactions are not permitted within a changeset (Suhas Daftuar)b447416fddPublic mempool removal methods Assume() no changeset is outstanding (Suhas Daftuar)2b30f4d36cMake RemoveStaged() private (Suhas Daftuar)18829194caEnforce that there is only one changeset at a time (Suhas Daftuar)7fb62f7db6Apply mempool changeset transactions directly into the mempool (Suhas Daftuar)34b6c5833dClean up FinalizeSubpackage to avoid workspace-specific information (Suhas Daftuar)57983b8addMove LimitMempoolSize to take place outside FinalizeSubpackage (Suhas Daftuar)01e145b975Move changeset from workspace to subpackage (Suhas Daftuar)802214c083Introduce mempool changesets (Suhas Daftuar)87d92fa340test: Add unit test coverage of package rbf + prioritisetransaction (Suhas Daftuar)15d982f91eAdd package hash to package-rbf log message (Suhas Daftuar) Pull request description: part of cluster mempool: #30289 It became clear while working on cluster mempool that it would be helpful for transaction validation if we could consider a full set of proposed changes to the mempool -- consisting of a set of transactions to add, and a set of transactions (ie conflicts) to simultaneously remove -- and perform calculations on what the mempool would look like if the proposed changes were to be applied. Two specific examples of where we'd like to do this: - Determining if ancestor/descendant/TRUC limits would be violated (in the future, cluster limits) if either a single transaction or a package of transactions were to be accepted - Determining if an RBF would make the mempool "better", however that idea is defined, both in the single transaction and package of transaction cases In preparation for cluster mempool, I have pulled this reworking of the mempool interface out of #28676 so it can be reviewed on its own. I have not re-implemented ancestor/descendant limits to be run through the changeset, since with cluster mempool those limits will be going away, so this seems like wasted effort. However, I have rebased #28676 on top of this branch so reviewers can see what the new mempool interface could look like in the cluster mempool setting. There are some minor behavior changes here, which I believe are inconsequential: - In the package validation setting, transactions would be added to the mempool before the `ConsensusScriptChecks()` are run. In theory, `ConsensusScriptChecks()` should always pass if the `PolicyScriptChecks()` have passed and it's just a belt-and-suspenders for us, but if somehow they were to diverge then there could be some small behavior change from adding transactions and then removing them, versus never adding them at all. - The error reporting on `CheckConflictTopology()` has slightly changed due to no longer distinguishing between direct conflicts and indirect conflicts. I believe this should be entirely inconsequential because there shouldn't be a logical difference between those two ideas from the perspective of this function, but I did have to update some error strings in some tests. - Because, in a package setting, RBFs now happen as part of the entire package being accepted, the logging has changed slightly because we do not know which transaction specifically evicted a given removed transaction. - Specifically, the "package hash" is now used to reference the set of transactions that are being accepted, rather than any single txid. The log message relating to package RBF that happen in the `TXPACKAGES` category has been updated as well to include the package hash, so that it's possible to see which specific set of transactions are being referenced by that package hash. - Relatedly, the tracepoint logging in the package rbf case has been updated as well to reference the package hash, rather than a transaction hash. ACKs for top commit: naumenkogs: ACK5736d1ddacinstagibbs: ACK5736d1ddacismaelsadeeq: reACK5736d1ddacglozow: ACK5736d1ddacTree-SHA512: 21810872e082920d337c89ac406085aa71c5f8e5151ab07aedf41e6601f60a909b22fbf462ef3b735d5d5881e9b76142c53957158e674dd5dfe6f6aabbdf630b
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/licenses/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 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 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.