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
Contents
This directory contains tools for developers working on this repository.
clang-format-diff.py
A script to format unified git diffs according to .clang-format.
Requires clang-format
, installed e.g. via brew install clang-format
on macOS,
or sudo apt install clang-format
on Debian/Ubuntu.
For instance, to format the last commit with 0 lines of context, the script should be called from the git root folder as follows.
git diff -U0 HEAD~1.. | ./contrib/devtools/clang-format-diff.py -p1 -i -v
copyright_header.py
Provides utilities for managing copyright headers of The Bitcoin Core developers
in repository source files. It has three subcommands:
$ ./copyright_header.py report <base_directory> [verbose]
$ ./copyright_header.py update <base_directory>
$ ./copyright_header.py insert <file>
Running these subcommands without arguments displays a usage string.
copyright_header.py report <base_directory> [verbose]
Produces a report of all copyright header notices found inside the source files
of a repository. Useful to quickly visualize the state of the headers.
Specifying verbose
will list the full filenames of files of each category.
copyright_header.py update <base_directory> [verbose]
Updates all the copyright headers of The Bitcoin Core developers
which were
changed in a year more recent than is listed. For example:
// Copyright (c) <firstYear>-<lastYear> The Bitcoin Core developers
will be updated to:
// Copyright (c) <firstYear>-<lastModifiedYear> The Bitcoin Core developers
where <lastModifiedYear>
is obtained from the git log
history.
This subcommand also handles copyright headers that have only a single year. In those cases:
// Copyright (c) <year> The Bitcoin Core developers
will be updated to:
// Copyright (c) <year>-<lastModifiedYear> The Bitcoin Core developers
where the update is appropriate.
copyright_header.py insert <file>
Inserts a copyright header for The Bitcoin Core developers
at the top of the
file in either Python or C++ style as determined by the file extension. If the
file is a Python file and it has #!
starting the first line, the header is
inserted in the line below it.
The copyright dates will be set to be <year_introduced>-<current_year>
where
<year_introduced>
is according to the git log
history. If
<year_introduced>
is equal to <current_year>
, it will be set as a single
year rather than two hyphenated years.
If the file already has a copyright for The Bitcoin Core developers
, the
script will exit.
gen-manpages.py
A small script to automatically create manpages in ../../doc/man by running the release binaries with the -help option. This requires help2man which can be found at: https://www.gnu.org/software/help2man/
With in-tree builds this tool can be run from any directory within the
repository. To use this tool with out-of-tree builds set BUILDDIR
. For
example:
BUILDDIR=$PWD/build contrib/devtools/gen-manpages.py
headerssync-params.py
A script to generate optimal parameters for the headerssync module (src/headerssync.cpp). It takes no command-line options, as all its configuration is set at the top of the file. It runs many times faster inside PyPy. Invocation:
pypy3 contrib/devtools/headerssync-params.py
gen-bitcoin-conf.sh
Generates a bitcoin.conf file in share/examples/
by parsing the output from bitcoind --help
. This script is run during the
release process to include a bitcoin.conf with the release binaries and can also be run by users to generate a file locally.
When generating a file as part of the release process, make sure to commit the changes after running the script.
With in-tree builds this tool can be run from any directory within the
repository. To use this tool with out-of-tree builds set BUILDDIR
. For
example:
BUILDDIR=$PWD/build contrib/devtools/gen-bitcoin-conf.sh
security-check.py and test-security-check.py
Perform basic security checks on a series of executables.
symbol-check.py
A script to check that release executables only contain certain symbols and are only linked against allowed libraries.
For Linux this means checking for allowed gcc, glibc and libstdc++ version symbols. This makes sure they are still compatible with the minimum supported distribution versions.
For macOS and Windows we check that the executables are only linked against libraries we allow.
Example usage:
find ../path/to/executables -type f -executable | xargs python3 contrib/devtools/symbol-check.py
If no errors occur the return value will be 0 and the output will be empty.
If there are any errors the return value will be 1 and output like this will be printed:
.../64/test_bitcoin: symbol memcpy from unsupported version GLIBC_2.14
.../64/test_bitcoin: symbol __fdelt_chk from unsupported version GLIBC_2.15
.../64/test_bitcoin: symbol std::out_of_range::~out_of_range() from unsupported version GLIBCXX_3.4.15
.../64/test_bitcoin: symbol _ZNSt8__detail15_List_nod from unsupported version GLIBCXX_3.4.15
circular-dependencies.py
Run this script from the root of the source tree (src/
) to find circular dependencies in the source code.
This looks only at which files include other files, treating the .cpp
and .h
file as one unit.
Example usage:
cd .../src
../contrib/devtools/circular-dependencies.py {*,*/*,*/*/*}.{h,cpp}