c9c4e6cadda85783a005af773a683d44a208bf67 build: Do not define `PROVIDE_FUZZ_MAIN_FUNCTION` macro unconditionally (Hennadii Stepanov)
Pull request description:
No need to define the `PROVIDE_FUZZ_MAIN_FUNCTION` macro when the build system has been configured with the `--disable-fuzz-binary` option.
See https://github.com/bitcoin/bitcoin/pull/24336#pullrequestreview-881368272.
ACKs for top commit:
MarcoFalke:
Approach ACK c9c4e6cadda85783a005af773a683d44a208bf67 did not review or test 🐤
fanquake:
ACK c9c4e6cadda85783a005af773a683d44a208bf67 Checked that `PROVIDE_FUZZ_MAIN_FUNCTION` isn't defined when configuring with `--disable-fuzz-binary`.
Tree-SHA512: 54fbf02ba9f5ecc61b176b8ea7d05e308788d4de3f97ed40913e731300d9dc0edfdfcbf8e0a6e74cf1b2e2ae63f6208a34e03b9c8d203d070c457c4a7d9b5f2c
404c53062bb80853d5967187bdb7b5f7e749de7f key: use secp256k1_schnorrsig_sign32 over deprecated secp256k1_schnorrsig_sign (fanquake)
ee30bf7c01922938bcf861a57cdf2249edb36256 build: remove some no-longer-needed var unexporting from configure (fanquake)
2656629767b098d17245a66e0bfa4c2c62f20d0c build: remove --enable-experimental from libsecp256k1 configure (fanquake)
d960d4fd3a767cf5695bed96c5f329056f77d0da build: fix MSVC build after subtree update (dhruv)
afb7a6fe06a33956ef43429d31f5934448f6e671 Squashed 'src/secp256k1/' changes from 0559fc6e41..8746600eec (fanquake)
Pull request description:
The motivation for this bump is some small build cleanups, including [dropping the `--enable-experimental`](80cf4eea5f) flag from the libsecp configure invocation, as well as some [now-redundant](https://github.com/bitcoin-core/secp256k1/pull/1090) `pkg-config` variable exporting from our own configure. We also get the benefit of a slightly more efficient libsecp configure due to https://github.com/bitcoin-core/secp256k1/pull/1088.
This also includes a change in our code to migrate from using the [now deprecated](99e6568fc6) `secp256k1_schnorrsig_sign` to `secp256k1_schnorrsig_sign32`.
Guix Build (on x86_64):
```bash
b9f6ad90c75f7edd7c4444c6c3401d8b6ab29a8da22ae22ddaedd94688227b5d guix-build-404c53062bb8/output/aarch64-linux-gnu/SHA256SUMS.part
250d47ae299d8385d5590518fa2adaabde76e2566fd27e12bf36b62663d13e13 guix-build-404c53062bb8/output/aarch64-linux-gnu/bitcoin-404c53062bb8-aarch64-linux-gnu-debug.tar.gz
48d610dc6f5169f925f782571dac2f082695f89008beadad4adef4c1b583a612 guix-build-404c53062bb8/output/aarch64-linux-gnu/bitcoin-404c53062bb8-aarch64-linux-gnu.tar.gz
8f04ee26e4079719e3935bd0e4287cc11a2a16875bf01e2a63d67492a1fa5367 guix-build-404c53062bb8/output/arm-linux-gnueabihf/SHA256SUMS.part
7d7d7fcfb032bda92e53abd8d608257f0ef17b1e3e52a1414260b896786fb2dc guix-build-404c53062bb8/output/arm-linux-gnueabihf/bitcoin-404c53062bb8-arm-linux-gnueabihf-debug.tar.gz
30bae2ff3d044f4e39f992a68f6b296b7be2aea350bca4a0415c739a32c20bd9 guix-build-404c53062bb8/output/arm-linux-gnueabihf/bitcoin-404c53062bb8-arm-linux-gnueabihf.tar.gz
5f550fb0b950250eeffce3480ec6403530b0880570a5860ef6c32a3e92eac92f guix-build-404c53062bb8/output/arm64-apple-darwin/SHA256SUMS.part
c10664d13aeec8c860bf72be833c738973ae18e4d28cdf08b2f9bee960ebff1d guix-build-404c53062bb8/output/arm64-apple-darwin/bitcoin-404c53062bb8-arm64-apple-darwin-unsigned.dmg
becab75b11cf4ca6f559f8eef835f3574629f6eb932ac716ed4f8c044a85831f guix-build-404c53062bb8/output/arm64-apple-darwin/bitcoin-404c53062bb8-arm64-apple-darwin-unsigned.tar.gz
bc86433652fe3552f6a13088191364ae7514c9fe3a244da86a6db096bb4922fc guix-build-404c53062bb8/output/arm64-apple-darwin/bitcoin-404c53062bb8-arm64-apple-darwin.tar.gz
1f585cb9a1356343df4b2726ecfe2598c9903304afb047c047c2cef318555dd3 guix-build-404c53062bb8/output/dist-archive/bitcoin-404c53062bb8.tar.gz
9ede534ba2c6cecb550473eead195627327e826ebb0118e23d60ab482d40e241 guix-build-404c53062bb8/output/powerpc64-linux-gnu/SHA256SUMS.part
77ddb7d7d639b1dd4508468a8ef27e45b35c8b2f8624584a70e6b64798a4ea7a guix-build-404c53062bb8/output/powerpc64-linux-gnu/bitcoin-404c53062bb8-powerpc64-linux-gnu-debug.tar.gz
36178c1f1c12942ff05275daa3570f8b45419ee8d9f391d750afb405219986f0 guix-build-404c53062bb8/output/powerpc64-linux-gnu/bitcoin-404c53062bb8-powerpc64-linux-gnu.tar.gz
8a15a4da7a9a5e00c49d9aeedf3c6fc666c0d230be1369eac7caf4571d5905e0 guix-build-404c53062bb8/output/powerpc64le-linux-gnu/SHA256SUMS.part
400c58113f2d07c87e03c8528b292c6aca808a2bccae4b041cad3a26a05b6aad guix-build-404c53062bb8/output/powerpc64le-linux-gnu/bitcoin-404c53062bb8-powerpc64le-linux-gnu-debug.tar.gz
3b9f9d8614ac3a27416e53354b2b0a64d364f91493e9d0f41583a6f492546824 guix-build-404c53062bb8/output/powerpc64le-linux-gnu/bitcoin-404c53062bb8-powerpc64le-linux-gnu.tar.gz
98506b23ee08ad8af958f816da2e4518d661e88d5c6308de1f5e3b2fc787b86c guix-build-404c53062bb8/output/riscv64-linux-gnu/SHA256SUMS.part
c701a7b77cea4fdc2588b511f1b2c71b89c83bfba19fdb2ac113a5a4b14ac392 guix-build-404c53062bb8/output/riscv64-linux-gnu/bitcoin-404c53062bb8-riscv64-linux-gnu-debug.tar.gz
34d58e6392cd58b3c76e30cd8600c0dbefba7e9c6d5df78c3ef23e81c4e4d26a guix-build-404c53062bb8/output/riscv64-linux-gnu/bitcoin-404c53062bb8-riscv64-linux-gnu.tar.gz
92fa30e9c6d81dd1e1514b65d3e1abe68ded897237cd99f66aa760d445109c04 guix-build-404c53062bb8/output/x86_64-apple-darwin/SHA256SUMS.part
bee180b02f178ae9980ef159f65913a71cbd037c4aff5f2906af5f174a677da3 guix-build-404c53062bb8/output/x86_64-apple-darwin/bitcoin-404c53062bb8-x86_64-apple-darwin-unsigned.dmg
ad7d18d779ab7a7944817d1f368d0a6bdd174bf1211b0f90180c8ccf04ec4062 guix-build-404c53062bb8/output/x86_64-apple-darwin/bitcoin-404c53062bb8-x86_64-apple-darwin-unsigned.tar.gz
7489d1d5d48ad95cf58bb11b5fdeccadac6fa758784fb498529fca2330abe069 guix-build-404c53062bb8/output/x86_64-apple-darwin/bitcoin-404c53062bb8-x86_64-apple-darwin.tar.gz
74660fb0ebce2a08b03980a57bffcad62e078dc967a74d2395660ff51c019640 guix-build-404c53062bb8/output/x86_64-linux-gnu/SHA256SUMS.part
cd377fa6b46276c2f8a32e199e6f9adf6aa67315688656709d6dc0744d54a837 guix-build-404c53062bb8/output/x86_64-linux-gnu/bitcoin-404c53062bb8-x86_64-linux-gnu-debug.tar.gz
919c521950369d8ad46db2d15b00abb488abfb080d157a41b2db429122a428ed guix-build-404c53062bb8/output/x86_64-linux-gnu/bitcoin-404c53062bb8-x86_64-linux-gnu.tar.gz
2debca995d432965a8786b6ff74aed42e9e2f1cb0fecbe2d9fc5b850c192fcff guix-build-404c53062bb8/output/x86_64-w64-mingw32/SHA256SUMS.part
e33169f684fb031ec18ed39812617d3eb263257f6c7564b8f4c974ad05fe672c guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64-debug.zip
029d0a4180cb908d517fcf689dcf46d42fbf383e11dc609711617066ae039ab0 guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64-setup-unsigned.exe
7e349c688cac66436562c4805f420b0536db5a3b3abf54d0e8c7752f59874a5c guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64-unsigned.tar.gz
1bff98e82e95c93d6060227408502f5e2d8597d526b912cb6dc0a90ae3094a8f guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64.zip
```
ACKs for top commit:
laanwj:
Code review ACK 404c53062bb80853d5967187bdb7b5f7e749de7f, I checked the changes to our tree thoroughly but didn't review all upstream secp256k1 changes in detail.
gruve-p:
ACK 404c53062b
real-or-random:
utACK 404c53062bb80853d5967187bdb7b5f7e749de7f I reviewed the diff to Core, I'm with updating to libsecp256k1 master, but I haven't verified that the libsecp256k1 tree here has been updated correctly
Tree-SHA512: e6a6db93ea60ed500df5065178784a915da94adfa7bd45fdbd7b19d701154987ff38c1df7f318119e6c2cb98e28e1ea2eb725bef93d4088403e14537ebffb032
76c60d7b31ccc50b226cdbc5e38be0bd67603408 test: validation:block_connected tracepoint test (0xb10c)
260e28ece87ba2e732ff8d8a379c4b27e77e3c0d test: utxocache:* tracepoint tests (0xb10c)
34b27bac684f2f373c5e1d90697d6bc8a014f45a test: net:in/out_message tracepoint tests (0xb10c)
c934087b627f7d368458781944f990b0eb479634 test: checks for tracepoint tests (0xb10c)
Pull request description:
This adds functional tests for the USDT tracepoints added in https://github.com/bitcoin/bitcoin/pull/22006 and https://github.com/bitcoin/bitcoin/pull/22902. This partially fixes#23296. The tests **are probably skipped** on most systems as these tests require:
- a Linux system with a kernel that supports BPF (and available kernel headers)
- that Bitcoin Core is compiled with tracepoints for USDT support (default when compiled with depends)
- [bcc](https://github.com/iovisor/bcc) installed
- the tests are run with a privileged user that is able to e.g. do BPF syscalls and load BPF maps
The tests are not yet run in our CI as the CirrusCI containers lack the required permissions (see https://github.com/bitcoin/bitcoin/issues/23296#issuecomment-1024920845). Running the tests in a VM in the CI could work, but I haven't experimented with this yet. The priority was to get the actual tests done first to ensure the tracepoints work as intended for the v23.0 release. Running the tracepoint tests in the CI is planned as the next step to finish #23296.
The tests can, however, be run against e.g. release candidates by hand. Additionally, they provide a starting point for tests for future tracepoints. PRs adding new tracepoint should include tests. This makes reviewing these PRs easier.
The tests require privileges to execute BPF sycalls (`CAP_SYS_ADMIN` before Linux kernel 5.8 and `CAP_BPF` and `CAP_PERFMON` on 5.8+) and permissions to `/sys/kernel/debug/tracing/`. It's currently recommended to run the tests in a virtual machine (or on a VPS) where it's sensible to use the `root` user to gain these privileges. Never run python scripts you haven't carefully reviewed with `root` permissions! It's unclear if a non-root user can even gain the required privileges. This needs more experimenting.
The goal here is to test the tracepoint interface to make sure the [documented interface](https://github.com/bitcoin/bitcoin/blob/master/doc/tracing.md#tracepoint-documentation) does not break by accident. The tracepoints expose implementation details. This means we also need to rely on implementation details of Bitcoin Core in these functional tests to trigger the tracepoints. An example is the test of the `utxocache:flush` tracepoint: On Bitcoin Core shutdown, the UTXO cache is flushed twice. The corresponding tracepoint test expects two flushes, too - if not, the test fails. Changing implementation details could cause these tests to fail and the tracepoint API to break. However, we purposefully treat the tracepoints only as [**semi-stable**](https://github.com/bitcoin/bitcoin/blob/master/doc/tracing.md#semi-stable-api). The tracepoints should not block refactors or changes to other internals.
ACKs for top commit:
jb55:
tACK 76c60d7b31ccc50b226cdbc5e38be0bd67603408
laanwj:
Tested ACK 76c60d7b31ccc50b226cdbc5e38be0bd67603408
Tree-SHA512: 9a63d945c68102e59d751bd8d2805ddd7b37185408fa831d28a9cb6641b701961389b55f216c475df7d4771154e735625067ee957fc74f454ad7a7921255364c
7b00595d335915dc2bf856e3569115996381a402 build: stop overriding user CXXFLAGS (fanquake)
3e2ef23c3e838acbc2cba7d26a36a4c6008faa24 build: stop overriding user LDFLAGS (fanquake)
35c3fd43c3d5a1c7e1b32865ddc2b046ad448986 build: stop overriding user CPPFLAGS (fanquake)
bc7cc576072703e4521844b949af5ce7d7e4722a doc: explain why we clear CXXFLAGS with enable-debug (fanquake)
Pull request description:
Historically our build system has hijacked `CXXFLAGS` and friends, and this has always been a source of complaints from users and developers. With this PR, we move away from using `CXXFLAGS`, `CPPFLAGS` and `LDFLAGS`, and instead use `CORE_*FLAGS` variables for our flags / options, leaving autoconfs `FLAG` vars to the user.
Note that there are currently two cases where we will at least clear `CXXFLAGS` (if not alreaddy overridden by the user), when doing debugging or when coverage is enabled, to avoid Autoconfs `-g -O2` CXXFLAG default.
ACKs for top commit:
hebasto:
ACK 7b00595d335915dc2bf856e3569115996381a402
Tree-SHA512: bda936a7aa8f98a1bf1552306845cb4bbab54e19a7a0b9ce3210e10fef70db146e9fe42a0cc8c50b2908506771b5b96f39c334e41323b70ec878e4010373096c
0d01272cd883f4d2a53409fdc49b8732a3dbda26 build: don't use Boost multi_index serialization (fanquake)
Pull request description:
We don't use the serialization or archiving facilities of multi_index.
So globally disable support, which gives a minor improvement in build
time, i.e less preprocessing work, given we don't link any Boost libs.
See: https://www.boost.org/doc/libs/1_78_0/libs/multi_index/doc/tutorial/creation.html
> Serialization capabilities are automatically provided by just linking with the appropriate Boost.Serialization library module: it is not necessary to explicitly include any header from Boost.Serialization, apart from those declaring the type of archive used in the process. If not used, however, serialization support can be disabled by globally defining the macro BOOST_MULTI_INDEX_DISABLE_SERIALIZATION. Disabling serialization for Boost.MultiIndex can yield a small improvement in build times, and may be necessary in those defective compilers that fail to correctly process Boost.Serialization headers.
ACKs for top commit:
MarcoFalke:
cr ACK 0d01272cd883f4d2a53409fdc49b8732a3dbda26
Tree-SHA512: 87c664a2f142dc6b8f8598341f9829be3fda8cf614d73cc9a894c8033ee40c6daa9b50f4049ecb1f1e3aaf342568d9a5f5c65af1e04c36ee3a9cb46eca95767b
d4ba2b2cbc3d1ef381fbdbae88cb5b18ca53f678 compat: remove strnlen back-compat code (fanquake)
Pull request description:
This was needed for mingw (not mingw-w64), and some older versions of
macOS, which we no-longer support.
ACKs for top commit:
hebasto:
ACK d4ba2b2cbc3d1ef381fbdbae88cb5b18ca53f678
Tree-SHA512: d1beb9df58464feea3076091361d7d46e4a8901e347644a5fa6f24e052ca24ee0c7c0dd3f2a3d682b0204bf50430fa89eac62121691ea08af6dcf6b907bdec87
532c64a7264dd3c7329e8839547837c57da7dbe8 build: Fix Boost.Process test for Boost 1.78 (Hennadii Stepanov)
Pull request description:
Rebased #24415 with Luke's suggestion.
Fixes#24413.
ACKs for top commit:
hebasto:
ACK 532c64a7264dd3c7329e8839547837c57da7dbe8, tested on Mac mini (M1, 2020) + macOS Monterey 12.3 (21E230).
Tree-SHA512: 74f779695f6bbc45a2b7341a1402f747cc0d433d74825c7196cb9f156db0c0299895365f01665bd0bff12a8ebb5ea33a29b9a52f5eac0007ec35d1dca6544705
5a157eb3703e1e65ed285f13a824562ab12aa3ff Bugfix: configure: Only avoid -isystem for exact /usr/include path (Luke Dashjr)
556ee6f2fa0e2da2bb12fe05a885431f61db2e47 Bugfix: configure: Quote SUPPRESS_WARNINGS sufficiently to preserve brackets (Luke Dashjr)
Pull request description:
The regex includes `[/ ]` which is supposed to match either a forward slash or a space, but m4 treats the brackets as special characters and effectively strips them out, leading to -isystem /usr/include paths except for in the typical scenario where it is the final parameter in the flag string.
ACKs for top commit:
hebasto:
ACK 5a157eb3703e1e65ed285f13a824562ab12aa3ff, tested on Ubuntu 22.04 with clang 14.0.
vasild:
ACK 5a157eb3703e1e65ed285f13a824562ab12aa3ff
Tree-SHA512: 5c8c282b647b7853b8fad1b5b473703c4a0635073d2685a8ac984151046e2c6a859e6972465419d27356dd29a47f21a2a3a6ad402ec434fe1f9882e5a35f0749
999982b06ce1d1280e5ce48f9253c6c536f41a12 build: Add --enable-c++20 option (MarcoFalke)
fae679065e4ef0c6383bbdd1876aaed6c1e40104 Add CSerializedNetMsg::Copy() helper (MarcoFalke)
fabb7c4ba629ecdea80a23674e2659d3d391565f Make fs.h C++20 compliant (MarcoFalke)
fae2220f4e48934313389864d3d362f672627eb8 scheduler: Capture ‘this’ explicitly in lambda (MarcoFalke)
Pull request description:
This is for CI and devs only and doesn't change that C++17 is the standard we are currently using. The option `--enable-c++20` allows CI to check that the C++17 code in the repo is also valid C++20. (There are some cases where valid C++17 doesn't compile under C++20).
Also, it allows developers to easily play with C++20 in the codebase.
ACKs for top commit:
ryanofsky:
Code review ACK 999982b06ce1d1280e5ce48f9253c6c536f41a12. Since last review was rebased, and enum-conversion change was dropped, and CSerializedNetMsg copy workaround was added
fanquake:
utACK 999982b06ce1d1280e5ce48f9253c6c536f41a12
Tree-SHA512: afc95ba03ea2b937017fc8e2b1449379cd2b6f7093c430d2e344c665a00c51e402d6651cbcbd0be8118ea1e54c3a86e67d2021d19ba1d4da67168e9fcb6b6f83
The regex includes [/ ] which is supposed to match either a forward slash or a
space, but m4 treats the brackets as special characters and effectively strips
them out, leading to -isystem /usr/include paths except for in the typical
scenario where it is the final parameter in the flag string.
956f7322f60db7b8be551c9074b4c633e514079d build: Bump minimum Qt version to 5.11.3 (Hennadii Stepanov)
e22d10b936eb7563b2b6611332d9e4c73a2f59d4 ci: Switch from bionic to buster (Hennadii Stepanov)
Pull request description:
The current minimum Qt version is 5.9.5 which has been set in bitcoin/bitcoin#21286.
Distro support:
- centos 7 -- unsupported since bitcoin/bitcoin#23511
- centos 8 -- [5.15.2](http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/qt5-qtbase-5.15.2-3.el8.x86_64.rpm)
- buster -- [5.11.3](https://packages.debian.org/buster/libqt5core5a)
- bullseye -- [5.15.2](https://packages.debian.org/bullseye/libqt5core5a)
- _bionic_ -- [5.9.5](https://packages.ubuntu.com/bionic/libqt5core5a)
- focal -- [5.12.8](https://packages.ubuntu.com/focal/libqt5core5a)
As another Ubuntu LTS is coming soon, it seems unreasonable to stick to Qt 5.9 which support [ended](https://www.qt.io/blog/2017/06/07/renewed-qt-support-services) on 2020-05-31. Anyway, it's still possible to build Bitcoin Core GUI with depends on bionic system.
Bumping the minimum Qt version allows to make code safer and more reliable, e.g.:
- functor-parameter overload of [`QMetaObject::invokeMethod`](https://doc.qt.io/qt-5/qmetaobject.html#invokeMethod-4)
- fixed https://bugreports.qt.io/browse/QTBUG-10907
An example of the patch using the functor-overload of `QMetaObject::invokeMethod`:
```diff
--- a/src/qt/walletmodel.cpp
+++ b/src/qt/walletmodel.cpp
@@ -349,7 +349,7 @@ bool WalletModel::changePassphrase(const SecureString &oldPass, const SecureStri
static void NotifyUnload(WalletModel* walletModel)
{
qDebug() << "NotifyUnload";
- bool invoked = QMetaObject::invokeMethod(walletModel, "unload");
+ bool invoked = QMetaObject::invokeMethod(walletModel, &WalletModel::unload);
assert(invoked);
}
```
It uses the same new syntax as signal-slot connection with compile-time check. Also see bitcoin/bitcoin#16348.
This PR is intended to be merged early [after](https://github.com/bitcoin/bitcoin/issues/22969) branching `23.x` off.
ACKs for top commit:
MarcoFalke:
cr ACK 956f7322f60db7b8be551c9074b4c633e514079d
fanquake:
ACK 956f7322f60db7b8be551c9074b4c633e514079d
Tree-SHA512: 3d652bcdcd990ce785ad412ed70234d4f27743895e535a53ed44b35d4afc3052e066c4c84f417e30bc53d0a3dd9ebed62444c57b7c765cb1e9aa687fbf866877
2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0 ci: Build bitcoin-chainstate (Carl Dong)
095aa6ca37bf0bd5c5e221bab779978a99b2a34c build: Add example bitcoin-chainstate executable (Carl Dong)
Pull request description:
Part of: #24303
This PR introduces an example/demo `bitcoin-chainstate` executable using said library which can print out information about a datadir and take in new blocks on stdin.
Please read the commit messages for more details.
-----
#### You may ask: WTF?! Why is `index/*.cpp`, etc. being linked in?
This PR is meant only to capture the state of dependencies in our consensus engine as of right now. There are many things to decouple from consensus, which will be done in subsequent PRs. Listing the files out right now in `bitcoin_chainstate_SOURCES` is purely to give us a clear picture of the task at hand, it is **not** to say that these dependencies _belongs_ there in any way.
### TODO
1. Clean up `bitcoin-chainstate.cpp`
It is quite ugly, with a lot of comments I've left for myself, I should clean it up to the best of my abilities (the ugliness of our init/shutdown might be the upper bound on cleanliness here...)
ACKs for top commit:
ajtowns:
ACK 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0
ryanofsky:
Code review ACK 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0. Just rebase, comments, formatting change since last review
MarcoFalke:
re-ACK 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0 🏔
Tree-SHA512: 86e7fb5718caa577df8abc8288c754f4a590650d974df9d2f6476c87ed25c70f923c4db651c6963f33498fc7a3a31f6692b9a75cbc996bf4888c5dac2f34a13b
On the master branch, bump to 23.99 (pre-24.0).
Tree-SHA512: 1e3b0cee8a2b5080170b59a4c445a3c1b69b99152e8eec7eba7080ab447cc6f9c6bd8f69df2b18ee9416de44a6ed88009a200ad26e89275f6230339330d12314
774323e378acea998069980edf50e1a26f4b6b9e ci: Force `--enable-external-signer` to prevent future regressions (Hennadii Stepanov)
69978858a4d8a9c34070f96133b8f95737a6505b build: Fix Boost.Process check for Boost 1.73 and older (Hennadii Stepanov)
2199ef79cba865af7949c3a55938ad54519ca5b8 build: Fix a non-portable use of `test` (Hennadii Stepanov)
d436c488d4216298016b09f8f97e10eada489bda build, refactor: Replace tabs with spaces (Hennadii Stepanov)
Pull request description:
On master (5f44c5c428b696af4214b2519cb2bbeb0e4a1027) Boost.Process check false fails without the `-lpthread` flag.
```
$ grep -C 2 pthread_detach config.log
/usr/bin/ld: /tmp/cczCQfQv.o: in function `boost::asio::detail::posix_global_impl<boost::asio::system_context>::~posix_global_impl()':
conftest.cpp:(.text._ZN5boost4asio6detail17posix_global_implINS0_14system_contextEED2Ev[_ZN5boost4asio6detail17posix_global_implINS0_14system_contextEED5Ev]+0xa3): undefined reference to `pthread_join'
/usr/bin/ld: conftest.cpp:(.text._ZN5boost4asio6detail17posix_global_implINS0_14system_contextEED2Ev[_ZN5boost4asio6detail17posix_global_implINS0_14system_contextEED5Ev]+0xc4): undefined reference to `pthread_detach'
collect2: error: ld returned 1 exit status
configure:26674: $? = 1
```
Not required for Boost 1.74+.
ACKs for top commit:
laanwj:
Code review ACK 774323e378acea998069980edf50e1a26f4b6b9e, is a bugfix/workaround, seems fine to merge last minute for 23.0.
Tree-SHA512: 2a9d4b67fd8910e107af972d8c223286b7c933bc310616f86c8b6d8c903438916980fc76bd7e37f2698f6ce5361dc706cbf2933d1ac2c081bcabe1b83ca7d6b6
For testing the USDT tracepoint API in the functional tests we
require:
- that we are on a Linux system*
- that Bitcoin Core is compiled with tracepoints
- that bcc and the the Python bcc module [0] is installed
- that we run the tests with the required permissions**
otherwise we skip the tests.
*: We currently only support tracepoints on Linux. Tracepoints are
not compiled on other platforms.
**: Currently, we check for root permissions via getuid == 0. It's
unclear if it's even possible to run the tests a non-root user
with e.g. CAP_BPF, CAP_PERFMON, and access to /sys/kernel/debug/
tracing/. Anyone running these tests as root should carefully
review them first and then run them in a disposable VM.
[0]: https://github.com/iovisor/bcc/blob/master/INSTALL.md
faef344f84a566436ffe2a277dec2cd6c7e1664b Print enable_fuzz_binary in configure (MarcoFalke)
Pull request description:
A *disabled* `enable_fuzz` on current master does *not* mean the the fuzz binary is not compiled. This is confusion, so fix it.
* `enable_fuzz` toggles compilation flags for fuzzing and disables all other target. There is no need to print this in the configure result, because the compilation flags are already printed. Also, all other targets are already printed as `no`.
* `enable_fuzz_binary` does what it says it does and is currently not printed. So print it.
ACKs for top commit:
hebasto:
ACK faef344f84a566436ffe2a277dec2cd6c7e1664b, tested on Linux Mint 20.2 (x86_64):
Tree-SHA512: 9b02b05c4b9c5fc92cf3487497392690303c36eace5e217f18b4349f059b5a23a7c0e0d030fb6fa7bbad83e927576a5e81c00099164f9ed8e185c0969dc17689
abc057c6030b2a0ddab46835a7801054da677781 build: Add Boost.Process usage check (Hennadii Stepanov)
Pull request description:
This PR adds a check that Boost.Process can be used without linking any libraries (header-only).
Disable the functionality if that is not the case.
Fixesbitcoin/bitcoin#24314.
ACKs for top commit:
fanquake:
ACK abc057c6030b2a0ddab46835a7801054da677781
Tree-SHA512: ed2a32b1f751ec6f88cc7220766edd4cdab93c1d0515c892aa3094ee8d5b13ef569830d6e7a7a00c0197b117585dc526d00d943cc99a1f8c8a66ac4e20fe2061
aaa1d03d3acebeb44fdd40a302f086aad3d329ce Add optimized sha256d64_arm_shani::Transform_2way (Pieter Wuille)
fe0629852aaf3a26f291bfa535e7e455fe7bea06 Implement sha256_arm_shani::Transform (Pavol Rusnak)
48a72fa81f80c8a3c7c6de8339b5feb361dece1c Add sha256_arm_shani to build system (Pavol Rusnak)
c2b79342506e24e9b7100fb7a6025dc870375ef6 Rename SHANI to X86_SHANI to allow future implementation of ARM_SHANI (Pavol Rusnak)
Pull request description:
This PR adds support for ARMv8 SHA2 Intrinsics.
Fixes https://github.com/bitcoin/bitcoin/issues/13401 and https://github.com/bitcoin/bitcoin/issues/17414
* Integration part was done by me.
* The original SHA2 NI code comes from https://github.com/noloader/SHA-Intrinsics/blob/master/sha256-arm.c
* Minor optimizations from https://github.com/rollmeister/bitcoin-armv8/blob/master/src/crypto/sha256.cpp are applied too.
* The 2-way transform added by @sipa
ACKs for top commit:
laanwj:
Code review and lightly tested ACK aaa1d03d3acebeb44fdd40a302f086aad3d329ce
Tree-SHA512: 9689d6390c004269cb1ee79ed05430d7d35a6efef2554a2b6732f7258a11e7e959b3306c04b4e8637a9623fb4c12d1c1b3592da0ff0dc6d737932db302509669
The bitcoin-chainstate executable serves to surface the dependencies
required by a program wishing to use Bitcoin Core's consensus engine as
it is right now.
More broadly, the _SOURCES list serves as a guiding "North Star" for the
libbitcoinkernel project: as we decouple more and more modules of the
codebase from our consensus engine, this _SOURCES list will grow shorter
and shorter. One day, only what is critical to our consensus engine will
remain. Right now, it's "the minimal list of files to link in to even
use our consensus engine".
[META] In a future commit the libbitcoinkernel library will be extracted
from bitcoin-chainstate, and the libbitcoinkernel library's
_SOURCES list will be the list that we aim to shrink.
0c49e52b22be1baa8d51670e4f3c437fd3c0baa7 build: remove unneeded getentropy detection (HAVE_GETENTROPY) (Sebastian Falbesoner)
5cd15ffdceace3a077d4719ef7c1704336d602e1 random: use arc4random on OpenBSD (Sebastian Falbesoner)
Pull request description:
Inspired by a discussion on obtaining randomness on various OSes in a secp256k1 PR (https://github.com/bitcoin-core/secp256k1/pull/748#discussion_r524605472, see also https://bitcoincore.reviews/libsecp256k1-748), I think it makes sense to follow best practices and use `arc4random_buf` rather than `getentropy` on OpenBSD in our random module.
The [getentropy(2) man page](https://man.openbsd.org/getentropy.2) states:
```
getentropy() is not intended for regular code; please use the
arc4random(3) family of functions instead.
```
The [arc4random(3) man page](https://man.openbsd.org/arc4random.3) states:
```
Use of these functions is encouraged for almost all random number
consumption because the other interfaces are deficient in either quality,
portability, standardization, or availability.
```
On the linked PR discussion worries about using RC4 internally has been expressed (see https://security.stackexchange.com/questions/85601/is-arc4random-secure-enough/172905#172905), but this would only affect users of OpenBSD <5.5, using a version that was released more than 8 years ago.
ACKs for top commit:
laanwj:
Tested ACK 0c49e52b22be1baa8d51670e4f3c437fd3c0baa7
Tree-SHA512: b5ed3d0718962c5a3839db9a28f93d08a0ac93094cc664f83bc4cf1cfad25049e6240b7b81fe06b71e6a3a0ca24a2c337eab088abec5470ad014e10c04fdb216
