fa5fc71199
94b0adcc371540732453d70309c4083d4bd9cd6b rpc, refactor: Prevent potential race conditions in dumptxoutset (Fabian Jahr)
e868a6e070a91c00555e72181f9b14bbf0373fdc doc: Improve assumeutxo guide and add more docs/comments (Fabian Jahr)
b29c21fc92dcc3da95bd032ba41675a8b9a0a24b assumeutxo: Remove devtools/utxo_snapshot.sh (Fabian Jahr)
20a1c77aa7dec2449071187a439d17f7aeaee648 contrib: Remove test_utxo_snapshots.sh (Fabian Jahr)
842685035244e151f4a10019af2dfe0563f11a82 test: Test for dumptxoutset at specific height (Fabian Jahr)
993cafe7e45ab0af1e862c7def3de688f47c0443 RPC: Add type parameter to dumptxoutset (Fabian Jahr)
fccf4f91d21c351d742943d35476f53d40963b8b RPC: Extract ReconsiderBlock helper (Fabian Jahr)
446ce51c21cd2466cb12fa0166fd069d42b603bf RPC: Extract InvalidateBlock helper (Fabian Jahr)
Pull request description:
This adds a height parameter to the `dumptxoutset` RPC. This internalizes the workflow that was previously done by scripts: roll back the chain to the height we actually want the snapshot from, create the snapshot, roll forward to the real tip again.
The nice thing about internalizing this functionality is that we can write tests for the code and it gives us more options to make the functionality robust. The shell scripts we have so far will be more cumbersome to maintain in the long run, especially since we will only notice later when we have broken them. I think it's safe to remove these `test_utxo_snapshots.sh` as well when we have this option in `dumptxoutset` because we have also added some good additional functional test coverage for this functionality.
ACKs for top commit:
Sjors:
re-utACK 94b0adcc371540732453d70309c4083d4bd9cd6b
achow101:
ACK 94b0adcc371540732453d70309c4083d4bd9cd6b
mzumsande:
ACK 94b0adcc371540732453d70309c4083d4bd9cd6b
pablomartin4btc:
re-ACK 94b0adcc371540732453d70309c4083d4bd9cd6b
Tree-SHA512: a4c9af5f687d1ca7bfb579a36f363882823386b5fa80c05de531b05a2782b5da6ff5baf3ada4bca8f32f63975d86f1948175abed9affe51fc958472b5f838dab
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: test/functional/test_runner.py
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.