Running Bitcoin Core on unsupported OSes may expose users to security
issues.
macOS Monterey 12 received its final security update (12.7.6) on July
2024. Apple classifies the hardware that can run macOS 12 at most as
"obsolete worldwide".
ccd10fdb97 build: Add missing USDT header dependency to kernel (Cory Fields)
Pull request description:
Noticed while testing a branch that replaces `boost::multi_index` with a custom replacement.
Currently depends builds pick up usdt and boost from the same path, and because boost always exists, the usdt path is implicitly included. So without boost, USDT isn't found.
An alternative to this would be to disable USDT for the kernel. I'd be open to either approach.
ACKs for top commit:
hebasto:
ACK ccd10fdb97, the diff looks correct.
fanquake:
ACK ccd10fdb97
Tree-SHA512: 2f91b8d5c8b169f7b72323d9163b5201f606ccdab95de7085847d2a672d10f940f69642c2528226a5efa4c589af24ca3bb9dd909eed0993e4cecd9689b4bed2f
0b3ec8c59b clusterlin: remove Cluster type (Pieter Wuille)
1c24c62510 clusterlin: merge two DepGraph fuzz tests into simulation test (Pieter Wuille)
0606e66fdb clusterlin: add DepGraph::RemoveTransactions and support for holes in DepGraph (Pieter Wuille)
75b5d42419 clusterlin: make DepGraph::AddDependency support multiple dependencies at once (Pieter Wuille)
abf50649d1 clusterlin: simplify DepGraphFormatter::Ser (Pieter Wuille)
eaab55ffc8 clusterlin: rework DepGraphFormatter::Unser (Pieter Wuille)
5901cf7100 clusterlin: abstract out DepGraph::GetReduced{Parents,Children} (Pieter Wuille)
Pull request description:
Part of cluster mempool: #30289
This adds:
* `DepGraph::AddDependencies` to add 0 or more dependencies to a single transaction at once (identical to calling `DepGraph::AddDependency` once for each, but more efficient).
* `DepGraph::RemoveTransactions` to remove 0 or more transactions from a depgraph.
* `DepGraph::GetReducedParents` (and `DepGraph::GetReducedChildren`) to get the (reduced) direct parents and children of a transaction in a depgraph.
After which, the `Cluster` type is removed.
This is the result of fleshing out the design for the "intermediate layer" ("TxGraph", no PR yet) between the cluster linearization layer and the mempool layer. My earlier thinking was that TxGraph would store `Cluster` objects (vectors of pairs of `FeeFrac`s and sets of parents), and convert them to `DepGraph` on the fly whenever needed. However, after more consideration, it seems better to have TxGraph store `DepGraph` objects, and manipulate them directly without constantly re-creating them. This requires `DepGraph` to have some additional functionality.
The bulk of the complexity here is the addition of `DepGraph::RemoveTransactions`, which leaves the remaining transactions' positions within the `DepGraph` untouched (we want existing identifiers to remain valid), so this implies that graphs can now have "holes" (positions that are unused, but followed by positions that are used). To enable that, an extension of the fuzz/test serialization format `DepGraphFormatter` is included to deal with such holes.
ACKs for top commit:
sdaftuar:
reACK 0b3ec8c59b
instagibbs:
reACK 0b3ec8c59b
ismaelsadeeq:
reACK 0b3ec8c59b
glozow:
ACK 0b3ec8c59b, reviewed range-diff from aab53ddcd8fcbc3c0be0da9383f8e06abe5badda and `clusterlin_depgraph_sim`
Tree-SHA512: a804b7f26d544c5cb0847322e235c810525cb0607737be6116c3156d582da3ba3352af8ea48e74eed5268f9c3eca63b30181d01b23a6dd0be1b99191f81cceb0
882f736d0a doc: lint: correct outdated comment (s/Makefile.am/CMakeLists.txt/) (Sebastian Falbesoner)
1786be7b4a scripted-diff: drop config/ subdir for bitcoin-config.h, rename to bitcoin-build-config.h (Sebastian Falbesoner)
Pull request description:
This PR is a follow-up to #30856, as suggested in comment https://github.com/bitcoin/bitcoin/pull/30856#issuecomment-2356804690. With the scripted diff, review should be fairly trivial, but it could still be seen as controversial due to the large number of files (78 in total) being touched.
ACKs for top commit:
fanquake:
ACK 882f736d0a
Tree-SHA512: 2e6cae4590f660e741edf84df456168b8b1f3861d381cfebf6647bb0a303c26bf7b969a837e0058e59bf852d220990dd8f5f400d8975fd0fab106d0507a70c9b
525e9dcba0 Add submitSolution to BlockTemplate interface (Sjors Provoost)
47b4875ef0 Add getCoinbaseMerklePath() to Mining interface (Sjors Provoost)
63d6ad7c89 Move BlockMerkleBranch back to merkle.{h,cpp} (Sjors Provoost)
Pull request description:
The new `BlockTemplate` interface introduced in #30440 allows for a more efficient way for a miner to submit the block solution. Instead of having the send the full block, it only needs to provide the nonce, timestamp, version fields and coinbase transaction.
This PR introduces `submitSolution()` for that. It's currently unused.
#29432 and https://github.com/Sjors/bitcoin/pull/48 use it to process the Stratum v2 message [SubmitSolution](https://github.com/stratum-mining/sv2-spec/blob/main/07-Template-Distribution-Protocol.md#77-submitsolution-client---server). The method should be sufficiently generic to work with alternative mining protocols (none exist that I'm aware off).
This PR also introduces `getCoinbaseMerklePath()`, which is needed in Stratum v2 to construct the `merkle_path` field of the `NewTemplate` message (see [spec](https://github.com/stratum-mining/sv2-spec/blob/main/07-Template-Distribution-Protocol.md#72-newtemplate-server---client)). The coinbase merkle path is also used in Stratum "v1", see e.g. https://bitcoin.stackexchange.com/questions/109820/questions-on-merkle-root-hashing-for-stratum-pools
This last function uses `BlockMerkleBranch` which was moved to the test code in #13191. The reason back then for moving it was that it was no longer used. This PR moves it back.
This PR does not change behaviour since both methods are unused.
ACKs for top commit:
achow101:
ACK 525e9dcba0
itornaza:
Code review ACK 525e9dcba0
tdb3:
Code review and light test ACK 525e9dcba0
ryanofsky:
Code review ACK 525e9dcba0. Left minor suggestions but none are important, and looks like this could be merged as-is
Tree-SHA512: 2a6a8f5d409ff4926643193cb67702240c7c687615414371e53383d2c13c485807f65e21e8ed98515b5456eca3d9fca13cec04675814a4081467d88b849c5653
36a6d4b007 doc: update IBD requirements in doc/README.md (Mackain)
Pull request description:
A small change to the first paragraph of the Setup part of the README that has been bugging me for a while.
The disk space required for the Bitcoin transactions can no longer be described as "a few" hundred gigabytes.
So I thought it was time it was changed to "several" instead.
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improve coverage are always welcome.
* All other changes should have accompanying unit tests (see `src/test/`) or
functional tests (see `test/`). Contributors should note which tests cover
modified code. If no tests exist for a region of modified code, new tests
should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or an
explanation of the potential issue as well as reasoning for the way the bug
was fixed.
* Features are welcome, but might be rejected due to design or scope issues.
If a feature is based on a lot of dependencies, contributors should first
consider building the system outside of Bitcoin Core, if possible.
* Refactoring changes are only accepted if they are required for a feature or
bug fix or otherwise improve developer experience significantly. For example,
most "code style" refactoring changes require a thorough explanation why they
are useful, what downsides they have and why they *significantly* improve
developer experience or avoid serious programming bugs. Note that code style
is often a subjective matter. Unless they are explicitly mentioned to be
preferred in the [developer notes](/doc/developer-notes.md), stylistic code
changes are usually rejected.
-->
<!--
Bitcoin Core has a thorough review process and even the most trivial change
needs to pass a lot of eyes and requires non-zero or even substantial time
effort to review. There is a huge lack of active reviewers on the project, so
patches often sit for a long time.
-->
ACKs for top commit:
achow101:
ACK 36a6d4b007
danielabrozzoni:
ACK 36a6d4b007
jonatack:
ACK 36a6d4b007
ismaelsadeeq:
ACK 36a6d4b007
tdb3:
ACK 36a6d4b007
itornaza:
ACK 36a6d4b007
Tree-SHA512: c5b21aca526c0ebe5f3234bd72e4080dc64cbba0ccd2306397aafe8349bc3573773ee64ff31fafcf59ea1afc7527caaf6d7cd8fe798311d9dc11ad0cd539e21e
ca2e4ba352 refactor: include the proper header rather than forward-declaring RemovalReasonToString (Cory Fields)
Pull request description:
Trivial no-op fixup.
This was pointed out by #31053, which causes the include order to be shuffled around:
```
[21:49:26.130] /ci_container_base/src/validationinterface.cpp:22:13: error: redundant 'RemovalReasonToString' declaration [readability-redundant-declaration,-warnings-as-errors]
[21:49:26.130] 22 | std::string RemovalReasonToString(const MemPoolRemovalReason& r) noexcept;
[21:49:26.130] | ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[21:49:26.130] /ci_container_base/src/kernel/mempool_removal_reason.h:22:13: note: previously declared here
[21:49:26.130] 22 | std::string RemovalReasonToString(const MemPoolRemovalReason& r) noexcept;
[21:49:26.130] | ^
```
I don't see any reason why the include shouldn't just be used.
ACKs for top commit:
maflcko:
lgtm ACK ca2e4ba352
hebasto:
ACK ca2e4ba352, IWYU seems [agree](https://cirrus-ci.com/task/6170839912022016):
TheCharlatan:
ACK ca2e4ba352
Tree-SHA512: e3584cae4f50bf2bc6c824bfaddfe683ef6a17d16138d0cbcc544b98bd64d5d7353b0826b1e8cf16e12410e27b0fcedde27100d4241b7cc194cd4465c8175a5b
33381ea530 scripted-diff: Modernize nLocalServices to m_local_services (Fabian Jahr)
Pull request description:
The type of the `nLocalServices` variable was changed to `std::atomic<ServiceFlags>` in #30807 and I suggested the variable name to get updated with a scripted diff along with it. It wasn't included in the PR but I am still suggesting to do it as a follow-up since I had already prepared the commit.
ACKs for top commit:
sipa:
utACK 33381ea530
achow101:
ACK 33381ea530
furszy:
utACK 33381ea530
jonatack:
ACK 33381ea530
theStack:
ACK 33381ea530
Tree-SHA512: 407ea9eac694f079aa5b5c1611b5874d7a0897ba6bc3aa0570be94afe1bf3a826657b6890b6597c03c063e95b9dc868f0bdfbfc41e77ec7e06f5b045bf065c71
fa22e5c430 refactor: Remove dead code that assumed tip == nullptr (MarcoFalke)
fa2e443965 refactor: Replace g_genesis_wait_cv with m_tip_block_cv (MarcoFalke)
fa7f52af1a refactor: Use wait_for predicate to check for interrupt (MarcoFalke)
5ca28ef28b refactor: Split up NodeContext shutdown_signal and shutdown_request (Ryan Ofsky)
fad8e7fba7 bugfix: Mark m_tip_block_cv as guarded by m_tip_block_mutex (MarcoFalke)
fa18586c29 refactor: Add missing GUARDED_BY(m_tip_block_mutex) (MarcoFalke)
fa4c075033 doc: Clarify waitTipChanged docs (MarcoFalke)
Pull request description:
`g_genesis_wait_cv` is similar to `m_tip_block_cv` but shuffling everything through a redundant `boost::signals2`.
So remove it, along with some other dead code, as well as minor fixups.
ACKs for top commit:
ryanofsky:
Code review ACK fa22e5c430 (just rebased since last review)
Sjors:
ACK fa22e5c430
TheCharlatan:
ACK fa22e5c430
Tree-SHA512: a2cb59b651aaf85a3574723adfe403487566788ad945933b0458816ccc841fce08ca77b31afbd2d6adb5bf1deed7229c028bee74fb4bbaf6576e9edcfa0ad817
fae44c83da test: Remove 0.16.3 test from wallet_backwards_compatibility.py (MarcoFalke)
Pull request description:
The test checks that any wallet created with current master can not be loaded with `v0.16.3`. This is interesting documentation, however it is probably not something to keep as a test, because:
* It seems like an extremely unlikely (and unsupported) edge case that someone creates a wallet with master and then goes ahead to open it with a long EOL software version.
* A better test would be the inverse: Create a wallet with `v0.16.3` and open it with current master. This is already tested in `wallet_upgradewallet.py`, where I've added an additional balance check before upgrading the `v0.16.3` wallet.
* The test is intermittently failing when shutting down the `v0.16.3` node, for example in https://github.com/bitcoin/bitcoin/pull/30875#issuecomment-2357565564. The exact cause is unclear, but given that the test isn't worthy to keep, removing it will ensure that the error disappears.
ACKs for top commit:
Sjors:
utACK fae44c83da
fanquake:
ACK fae44c83da - I agree that test seems to have past it's usefulness, and the fact that it otherwise causes intemittent issues is further reason to remove it.
Tree-SHA512: 85bf428e616e0880198c1a7529936520505d7fa87c2eeb87a0457f13b50a163accaf5f80f9364dea978f6bd14b0b5350cda88f49aa7584682c8b5e0b0b117724
fa1cffacae ci: Install missing nproc in macos task (MarcoFalke)
faf7a2bccc ci: Add missing -DWERROR=ON to test-each-commit (MarcoFalke)
Pull request description:
Found by in Sjors in https://github.com/bitcoin/bitcoin/pull/27260#discussion_r1785860610 (Thanks!)
Also, includes an unrelated commit to simplify the ci scripts, by assuming nproc exists on macos as well. (Having more than one commit is also required to trigger the `test-each-commit` task)
ACKs for top commit:
theuni:
utACK fa1cffacae.
Tree-SHA512: 881df6964da31c3f7161b763bdf74029743567272c7a4db24ded10909a8cedad39b494a9f486f0b059bbeb0beb190dcd91369650d014e1fc3b5f7ae07cd54771
fa6d14eacb test: Treat exclude list warning as failure in CI (MarcoFalke)
Pull request description:
An outdated exclude list or otherwise an error in the exclude list handling is usually a bug.
So make it fatal in the CI, instead of silently ignoring it.
Fixes https://github.com/bitcoin/bitcoin/pull/30872/files#r1757015334
Can be tested with something like (with and without `--ci`):
```
./bld-cmake/test/functional/test_runner.py wallet_disable -x wallet_disablee
ACKs for top commit:
tdb3:
ACK fa6d14eacb
ismaelsadeeq:
utACK fa6d14eacb
Tree-SHA512: 03a70dff9d1272d982591d60ab764f9233d4802488bc1bad305a2755e2d7ed86e691ee94767a3bc5f68321b63214aba44e6f9edd1543dfad7a20f9397cf78734
fa5ebc9920 ci: Double ctest timeout (MarcoFalke)
Pull request description:
It looks like msan sometimes hits the timeout. So double it, which should still be useful to catch real timeouts in the wine windows-cross unit tests.
Example: https://cirrus-ci.com/task/5141974322249728
ACKs for top commit:
fanquake:
ACK fa5ebc9920
Tree-SHA512: de346f34c4d157be515706fd71c2072fb5859d50d0e8cd7e6c4637578e4dc54aa8c75b2521e7aecf679b486c4e20fd184e259ffc701b8b668d7f61abff883875
ae56b3230b depends: For mingw cross compile use -gcc-posix to prevent library conflict (laanwj)
Pull request description:
CMake parses some paths from the spec of the C compiler, assuming it will be the linker, resulting in the link to end up with `-L/usr/lib/gcc/x86_64-w64-mingw32/12-win32` on debian bookworm if both `-win32` and `-posix` variants are installed, and `-win32` is the default alternative.
This results in the wrong C++ library being linked, missing std::threads::hardware_concurrency and other threading functions.
To fix this, use the `-posix` variant of gcc as well when available. This fixes a regression compared to autotools, where this scenario worked.
ACKs for top commit:
theuni:
utACK ae56b3230b.
hebasto:
ACK ae56b3230b. I've tested on both Debian Bookworm and Ubuntu 24.04 with the `g++-mingw-w64-x86-64` package installed. The resulting CMake internal configuration appears more accurate. For instance, on Ubuntu 24.04, for the `bitcoin-tx` target, the diff in `build/src/CMakeFiles/bitcoin-tx.dir/linkLibs.rsp` looks as follows:
Tree-SHA512: f36fae50f91a29f565940494af9e46f47e219b99e329c0714ace47c516ac524602d5b6538a07488157bc2a71be7bac72176097fff3178129c5084bf6cc823167
e0287bc4b2 test: remove unused code from script_tests (fanquake)
Pull request description:
This has been unused since #29648. Noticed while running a newer version of clang-tidy (19.1.1):
```bash
[127/391][6.2s] /opt/homebrew/opt/llvm/bin/clang-tidy -p=build -quiet --config-file=/bitcoin/src/.clang-tidy /bitcoin/src/test/script_tests.cpp
bitcoin/src/test/script_tests.cpp:126:25: error: local copy 'tx2' of the variable 'tx' is never modified and never used; consider removing the statement [performance-unnecessary-copy-initialization,-warnings-as-errors]
126 | CMutableTransaction tx2 = tx;
| ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
127 | BOOST_CHECK_MESSAGE(VerifyScript(scriptSig, scriptPubKey, &scriptWitness, flags, MutableTransactionSignatureChecker(&tx, 0, txCredit.vout[0].nValue, MissingDataBehavior::ASSERT_FAIL), &err) == expect, message);
512 warnings generated.
```
ACKs for top commit:
maflcko:
review ACK e0287bc4b2
BrandonOdiwuor:
ACK e0287bc4b2
Tree-SHA512: f69513d0b898e0e9afad047bcec200707b057e3718a3d35bd479a788a1973e49ee7e5f48feadb8731ab5fdbd12a2b53b0bcf65296701e2296c3fdb67cdcabfb5
605926da0a depends: Print ready-to-use `--toolchain` option for CMake invocation (Hennadii Stepanov)
Pull request description:
Requested in https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2385057317:
> P.S. it would be nice if `make` in `depends` provides the incantation needed for the configure stage.
An example of a build log with this PR:
```
$ make --no-print-directory -C depends -j16 NO_QT=1 NO_WALLET=1 NO_UPNP=1 NO_NATPMP=1 NO_ZMQ=1 NO_USDT=1 LOG=1
Extracting boost...
/home/hebasto/git/bitcoin/depends/sources/boost_1_81_0.tar.gz: OK
Preprocessing boost...
Configuring boost...
Building boost...
Staging boost...
Postprocessing boost...
Caching boost...
Extracting libevent...
/home/hebasto/git/bitcoin/depends/sources/libevent-2.1.12-stable.tar.gz: OK
Preprocessing libevent...
Configuring libevent...
Building libevent...
Staging libevent...
Postprocessing libevent...
Caching libevent...
copying packages: boost libevent
to: /home/hebasto/git/bitcoin/depends/x86_64-pc-linux-gnu
To build Bitcoin Core with these packages, pass '--toolchain /home/hebasto/git/bitcoin/depends/x86_64-pc-linux-gnu/toolchain.cmake' to the first CMake invocation.
```
ACKs for top commit:
Sjors:
tACK 605926da0a
theuni:
ACK 605926da0a
jarolrod:
ACK 605926da0a
pablomartin4btc:
ACK 605926da0a
Tree-SHA512: 658358cb12a2409486962273d418f8cfa9609c84c6e70b426250173925c0938a6eba0dca72f43d78cc63c9cb927514c959473da04bdcda714228c5d8c248c1fe
This combines the clusterlin_add_dependency and clusterlin_cluster_serialization
fuzz tests into a single clusterlin_depgraph_sim fuzz test. This tests starts
from an empty DepGraph and performs a arbitrary number of AddTransaction,
AddDependencies, and RemoveTransactions operations on it, and compares the
resulting state with a naive reimplementation.
This commits introduces support in DepGraph for the transaction positions to be
non-continuous. Specifically, it adds:
* DepGraph::RemoveTransactions which removes 0 or more positions from a DepGraph.
* DepGraph::Positions() to get a set of which positions are in use.
* DepGraph::PositionRange() to get the highest used position in a DepGraph + 1.
In addition, it extends the DepGraphFormatter format to support holes in a
compatible way (it serializes non-holey DepGraphs identically to the old code,
and deserializes them the same way)
This changes DepGraph::AddDependency into DepGraph::AddDependencies, which takes
in a single child, but a set of parent transactions, making them all dependencies
at once.
This is important for performance. N transactions can have O(N^2) parents combined,
so constructing a full DepGraph using just AddDependency (which is O(N) on its own)
could take O(N^3) time, while doing the same with AddDependencies (also O(N) on its
own) only takes O(N^2).
Notably, this matters for DepGraphFormatter::Unser, which goes from O(N^3) to O(N^2).
Co-Authored-By: Greg Sanders <gsanders87@gmail.com>
This does not change the serialization format.
It turns out that it is unnecessary to keep track of the order of transactions
in the so-far reconstructed DepGraph to decide how far from the end to insert
a new transaction.
This commit does not change the serialization format. Its purpose is making a
few changes already in order to reduce the diff size of the later commit that
introduces support for holes in DepGraph.
The previous approach was to immediately construct a transaction as soon as its
feerate was known in a preliminary position, and then undo that, and place it
in the correct position once the position information is known (such that a
deserialization error in between would not result in an inconsistent state).
The new approach is to delay the actual transaction creation until all its
information is known, avoiding the need to undo and redo. This requires a
different means of determining whether dependencies are redundant, but that has
the advantage that a later commit can apply all dependencies at once, reducing
the complexity of deserialization.
A fuzz test already relies on these operations, and a future commit will need
the same logic too. Therefore, abstract them out into proper member functions,
with proper testing.
This has been unused since #29648.
Noticed while running a newer version of clang-tidy (19.1.1):
```bash
[127/391][6.2s] /opt/homebrew/opt/llvm/bin/clang-tidy -p=build -quiet --config-file=/bitcoin/src/.clang-tidy /bitcoin/src/test/script_tests.cpp
bitcoin/src/test/script_tests.cpp:126:25: error: local copy 'tx2' of the variable 'tx' is never modified and never used; consider removing the statement [performance-unnecessary-copy-initialization,-warnings-as-errors]
126 | CMutableTransaction tx2 = tx;
| ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
127 | BOOST_CHECK_MESSAGE(VerifyScript(scriptSig, scriptPubKey, &scriptWitness, flags, MutableTransactionSignatureChecker(&tx, 0, txCredit.vout[0].nValue, MissingDataBehavior::ASSERT_FAIL), &err) == expect, message);
512 warnings generated.
```
56aad83307 ci: set a ctest timeout of 1200 (20 minutes) (fanquake)
Pull request description:
This should be long enough (with headroom) for our longest running tests, which even under MSAN, TSAN, Valgrind, etc max out at about 800s.
i.e under Valgrind I see the longer runtimes as:
```bash
135/136 Test #8: bench_sanity_check_high_priority ..... Passed 371.19 sec
136/136 Test #122: coinselector_tests ................... Passed 343.39 sec
```
In the CI `tests` [under TSAN](https://cirrus-ci.com/task/6321297691508736?logs=ci#L2520):
```bash
tests ................................ Passed 795.20 sec
```
[and MSAN](https://cirrus-ci.com/task/4913922807955456?logs=ci#L2226):
```bash
tests ................................ Passed 658.48 sec
```
This will also prevent the current issue we are seeing of `ctest` running until it reaches the CI timeout, see #30969.
We still need to figure out what underlying issue is causing the tests to (sometimes) run for so long, but in the mean time, this will stop `ctest` wasting our CI CPU. It should also make it more clear in the logs, exactly which test is the one that is hitting the timeout.
ACKs for top commit:
maflcko:
review ACK 56aad83307
tdb3:
re ACK 56aad83307
Tree-SHA512: 43c0dc12b8b12b1d9804751a9816935e2abbe962b451e12a268f2d2c430bc568b83995dbc405f100b596dfb0f1e9f65b78074de98916592d3ae4ebc2126e3a6c
This should be long enough (with headroom) for our longest running tests,
which even under MSAN, TSAN, Valgrind, etc max out at about 800s.
i.e under Valgrind I see the longer runtimes as:
```bash
135/136 Test #8: bench_sanity_check_high_priority ..... Passed 371.19 sec
136/136 Test #122: coinselector_tests ................... Passed 343.39 sec
```
In the CI `tests` under TSAN:
```bash
tests ................................ Passed 795.20 sec
```
and MSAN:
```bash
tests ................................ Passed 658.48 sec
```
This will also prevent the current issue we are seeing of `ctest`
running until it reaches the CI timeout, see #30969.
However, we still need to figure out what underlying issue is causing
the tests to (sometimes) run for so long, but in the mean time, this
will stop `ctest` wasting our CI CPU.
80761afced qt6: Handle different signatures of `QANEF::nativeEventFilter` (Hennadii Stepanov)
Pull request description:
Split from https://github.com/bitcoin/bitcoin/pull/30997.
This PR ensures compatibility across all supported Qt versions.
For more details, please refer to 3b38c73c7f.
No behaviour change.
ACKs for top commit:
maflcko:
lgtm ACK 80761afced
promag:
Code review ACK 80761afced.
Tree-SHA512: a265e1c33cc7da37003bb0e6fd40950acb5e948ca9ec63a59a79c5e2a1894334f48d5565539c91d4d777b48a589366958df1498eaa6935e3b7fb534493adb51a
deacf3c7cd cmake: Avoid hardcoding Qt's major version in Find module (Hennadii Stepanov)
Pull request description:
This PR facilitates future migration to Qt 6 and is a prerequisite for https://github.com/bitcoin/bitcoin/pull/30997.
No behaviour change.
ACKs for top commit:
l0rinc:
utACK deacf3c7cd
promag:
Code review ACK deacf3c7cd.
maflcko:
lgtm ACK deacf3c7cd
Tree-SHA512: 6991f30e9cf6a7103bfe91f8958246b17360210bf695ab620ca1c8b59565bf6192cc366036cf54f860ccc4d782b9c28899970978de79392c88a45ef149c06a79
fee4cba484 gui: Fix proxy details display in Options Dialog (pablomartin4btc)
Pull request description:
Currently, setting up a proxy (whether SOCKS5 or Tor) with an IPv6 address works correctly via the command line or configuration file in both `bitcoind` and `bitcoin-qt` (also from the UI the ipv6 address gets saved properly in `settings.json`). However, the UI does not reflect this properly, which can create confusion. Since some ISPs and VPNs still experience issues with IPv6, users may mistakenly think there is a problem with Bitcoin Core, when in fact the proxy setup is functioning as expected.
So this PR ensures that the proxy IP is displayed correctly in the UI when using an IPv6 address.
No functionality impact; changes only affect UI display.
<details>
<summary>Click her to see <b>before</b> and <b>after</b> screenshots.</summary>
- Before:
- After:
</details>
---
<details>
<summary>Test instructions</summary>
(Ubuntu 22.04)
1. Start ssh service on localhost.
`ssh -D [::1]:1080 -f -C -q -N localhost`
2. Check that the service is up and running.
```
ps aux | grep ssh
pepe 2860289 0.0 0.0 20456 5576 ? Ss 06:59 0:00 ssh -D [::1]:1080 -f -C -q -N localhost
```
3. Check with `bitcoind` if it works correctly.
`bitcoind -onlynet=ipv6 -proxy=[::1]:1080`
4. Check for established connections.
```
netstat -natl |grep 1080
tcp6 0 0 ::1:1080 :::* LISTEN
tcp6 0 0 ::1:47610 ::1:1080 ESTABLISHED
tcp6 0 0 ::1:1080 ::1:47610 ESTABLISHED
tcp6 0 0 ::1:1080 ::1:47606 TIME_WAIT
```
```./build/src/bitcoin-cli getpeerinfo
[
{
"id": 0,
"addr": "[2a01:4f9:4a:2a07::2]:8333",
"addrbind": "[::1]:47638",
"network": "ipv6",
...
```
5. Stop `bitcoind` and run `bitcoin-qt` adding the corresponding configuration in `settings.json`.
```
{
"onlynet": "ipv6",
"proxy": "[::1]:1080",
}
```
6. Open the Peers window to check available connections or run `getpeerinfo` on the rpc-console window.
7. Same can be done for Tor setting up `tor` service (I'll add instructions later) and configuring on its default port 9050 and forcing `"onlynet": "onion"` to verify easily the net traffic.
</details>
---
Thanks jarolrod and vasild for your help on validating ipv6 was not broken.
ACKs for top commit:
vasild:
ACK fee4cba484
promag:
Code review ACK fee4cba484.
hebasto:
ACK fee4cba484, I have reviewed the code and it looks OK.
Tree-SHA512: 4be9052569ccb1e17ce94fb15691debf0651fa172ed1a83d60696d10f20d469b19d70a979b65322951f5783cd7582d55b39b669edb588e20404d8d10e767c49a
98c1536852 test: add getorphantxs tests (tdb3)
93f48fceb7 test: add tx_in_orphanage() (tdb3)
34a9c10e8c rpc: add getorphantxs (tdb3)
f511ff3654 refactor: move verbosity parsing to rpc/util (tdb3)
532491faf1 net: add GetOrphanTransactions() to PeerManager (tdb3)
91b65adff2 refactor: add OrphanTxBase for external use (tdb3)
Pull request description:
This PR adds a new hidden rpc, `getorphantxs`, that provides the caller with a list of orphan transactions. This rpc may be helpful when checking orphan behavior/scenarios (e.g. in tests like `p2p_orphan_handling`) or providing additional data for statistics/visualization.
```
getorphantxs ( verbosity )
Shows transactions in the tx orphanage.
EXPERIMENTAL warning: this call may be changed in future releases.
Arguments:
1. verbosity (numeric, optional, default=0) 0 for an array of txids (may contain duplicates), 1 for an array of objects with tx details, and 2 for details from (1) and tx hex
Result (for verbose = 0):
[ (json array)
"hex", (string) The transaction hash in hex
...
]
Result (for verbose = 1):
[ (json array)
{ (json object)
"txid" : "hex", (string) The transaction hash in hex
"wtxid" : "hex", (string) The transaction witness hash in hex
"bytes" : n, (numeric) The serialized transaction size in bytes
"vsize" : n, (numeric) The virtual transaction size as defined in BIP 141. This is different from actual serialized size for witness transactions as witness data is discounted.
"weight" : n, (numeric) The transaction weight as defined in BIP 141.
"expiration" : xxx, (numeric) The orphan expiration time expressed in UNIX epoch time
"from" : [ (json array)
n, (numeric) Peer ID
...
]
},
...
]
Result (for verbose = 2):
[ (json array)
{ (json object)
"txid" : "hex", (string) The transaction hash in hex
"wtxid" : "hex", (string) The transaction witness hash in hex
"bytes" : n, (numeric) The serialized transaction size in bytes
"vsize" : n, (numeric) The virtual transaction size as defined in BIP 141. This is different from actual serialized size for witness transactions as witness data is discounted.
"weight" : n, (numeric) The transaction weight as defined in BIP 141.
"expiration" : xxx, (numeric) The orphan expiration time expressed in UNIX epoch time
"from" : [ (json array)
n, (numeric) Peer ID
...
],
"hex" : "hex" (string) The serialized, hex-encoded transaction data
},
...
]
Examples:
> bitcoin-cli getorphantxs 2
> curl --user myusername --data-binary '{"jsonrpc": "2.0", "id": "curltest", "method": "getorphantxs", "params": [2]}' -H 'content-type: application/json' http://127.0.0.1:8332/
```
```
$ build/src/bitcoin-cli getorphantxs 2
[
{
"txid": "50128aac5deab548228d74d846675ad4def91cd92453d81a2daa778df12a63f2",
"wtxid": "bb61659336f59fcf23acb47c05dc4bbea63ab533a98c412f3a12cb813308d52c",
"bytes": 133,
"vsize": 104,
"weight": 415,
"expiration": 1725663854,
"from": [
1
],
"hex": "020000000001010b992959eaa2018bbf31a4a3f9aa30896a8144dbd5cfaf263bf07c0845a3a6620000000000000000000140fe042a010000002251202913b252fe537830f843bfdc5fa7d20ba48639a87c86ff837b92d083c55ad7c102015121c0000000000000000000000000000000000000000000000000000000000000000100000000"
},
{
"txid": "330bb7f701604a40ade20aa129e9a3eb8a7bf024e599084ca1026d3222b9f8a1",
"wtxid": "b7651f7d4c1a40c4d01f6a1e43a121967091fa0f56bb460146c1c5c068e824f6",
"bytes": 133,
"vsize": 104,
"weight": 415,
"expiration": 1725663854,
"from": [
2
],
"hex": "020000000001013600adfe41e0ebd2454838963d270916d2b47239c9eebb93a992b720d3589a080000000000000000000140fe042a010000002251202913b252fe537830f843bfdc5fa7d20ba48639a87c86ff837b92d083c55ad7c102015121c0000000000000000000000000000000000000000000000000000000000000000100000000"
}
]
```
ACKs for top commit:
glozow:
reACK 98c1536852
hodlinator:
re-ACK 98c1536852
danielabrozzoni:
ACK 98c1536852
pablomartin4btc:
tACK 98c1536852
itornaza:
reACK 98c1536852
Tree-SHA512: 66075f9faa83748350b87397302100d08af92cbef5fadb27f2b4903f028c08020bf34a23e17262b41abb3f379ca9f46cf6cd5459b8681f2b83bffbbaf3c03ff9
5be34bacf6 qt: Fix linking when configured with `-DENABLE_WALLET=OFF` (Hennadii Stepanov)
Pull request description:
Split from https://github.com/bitcoin/bitcoin/pull/30997.
When building with Qt 6 in my dev branch, I encountered a linker error when configured with `-DENABLE_WALLET=OFF`:
```
$ cmake -B build -DENABLE_WALLET=OFF -DBUILD_GUI=ON
$ cmake --build build -t bitcoin-qt
<snip>
[100%] Linking CXX executable bitcoin-qt
/usr/bin/ld: libbitcoinqt.a(rpcconsole.cpp.o): in function `QtPrivate::MetaObjectForType<WalletModel const*, void>::metaObjectFunction(QtPrivate::QMetaTypeInterface const*)':
/usr/include/x86_64-linux-gnu/qt6/QtCore/qmetatype.h:903:(.text._ZN9QtPrivate17MetaObjectForTypeIPK11WalletModelvE18metaObjectFunctionEPKNS_18QMetaTypeInterfaceE[_ZN9QtPrivate17MetaObjectForTypeIPK11WalletModelvE18metaObjectFunctionEPKNS_18QMetaTypeInterfaceE]+0x2b): undefined reference to `WalletModel::staticMetaObject'
/usr/bin/ld: libbitcoinqt.a(rpcconsole.cpp.o): in function `QMetaTypeIdQObject<WalletModel const*, 8>::qt_metatype_id()':
/usr/include/x86_64-linux-gnu/qt6/QtCore/qmetatype.h:1313:(.text._ZZN9QtPrivate16QMetaTypeForTypeIPK11WalletModelE17getLegacyRegisterEvENUlvE_4_FUNEv[_ZZN9QtPrivate16QMetaTypeForTypeIPK11WalletModelE17getLegacyRegisterEvENUlvE_4_FUNEv]+0x53): undefined reference to `WalletModel::staticMetaObject'
collect2: error: ld returned 1 exit status
gmake[3]: *** [src/qt/CMakeFiles/bitcoin-qt.dir/build.make:154: src/qt/bitcoin-qt] Error 1
gmake[2]: *** [CMakeFiles/Makefile2:2107: src/qt/CMakeFiles/bitcoin-qt.dir/all] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:2114: src/qt/CMakeFiles/bitcoin-qt.dir/rule] Error 2
gmake: *** [Makefile:998: bitcoin-qt] Error 2
```
This PR resolves the issue.
ACKs for top commit:
promag:
ACK 5be34bacf6, all other changes in 33657e1c958146312e4c68765a92871920401396 are not required, makes the code harder to read.
pablomartin4btc:
tACK 5be34bacf6
Tree-SHA512: d10da665384e6539b8e9106dc905ba30e9e57cd4603fc7e5eb893fc899f55f26889c570687fa5daf55c6fc5bf4fcfcfcd9b70822cfe637f31f9151bb653b7941
5625840c11 qt6, test: Handle deprecated `QVERIFY_EXCEPTION_THROWN` (Hennadii Stepanov)
cb750b4b40 qt6, test: Use `qWarning()` instead of `QWARN()` macro (Hennadii Stepanov)
Pull request description:
Split from https://github.com/bitcoin/bitcoin/pull/30997.
This PR ensures compatibility across all supported Qt versions.
---
This PR can be tested on macOS using the first commit from https://github.com/bitcoin/bitcoin/pull/30997 and Homebrew's `qt` package.
ACKs for top commit:
promag:
Code review ACK 5625840c11.
Sjors:
tACK 5625840c11
Tree-SHA512: e7307eaf0027c6addc9481ba91ed31b81554ffb0d2ba77938e68915c9d490a7962e55a330f97ea31d49bbfb30f92773c3af3afc867a4215d00752405d7e3bb6d
27709f51ee docs: Add instructions on how to self-sign bitcoin-core binaries for macOS (Chris Stewart)
Pull request description:
Related to #15774
This PR adds instructions to the release notes to tell users how to self sign bitcoin core binaries so they are executable on macOS.
Tested on
```
Darwin Chriss-MacBook-Pro.local 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:46 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6031 arm64
```
These commands do not appear to require 'phoning home'. I tested these commands when disconnected from a network connection and things worked.
ACKs for top commit:
andrewtoth:
reACK 27709f51ee
achow101:
ACK 27709f51ee
Tree-SHA512: db19c61577bb774420a2506d3f06bc0193116117f09ebd2d022a4524e8ca32d2cf9277a2997744ddfe8844600a569176e194aafc252dd31b48fc6e74db3c74d0
a7498cc7e2 Fix bug in p2p_headers_presync harness (marcofleon)
Pull request description:
The calculation for the test chain's work (`total_work`) should be outside of the loop. Previously, `total_work` was being miscalculated due to multiple additions of work from the same headers. Now, each header's work is only counted once, providing an accurate total.
https://github.com/bitcoin/bitcoin/pull/30918 followup
ACKs for top commit:
dergoegge:
utACK a7498cc7e2
instagibbs:
ACK a7498cc7e2
glozow:
makes sense, utACK a7498cc7e2
mzumsande:
ACK a7498cc7e2
Tree-SHA512: b95f25dcf7ace220e30f1d72f50d85ee18777467927c0cc1ed8582b390cb7185ffc0e2f127309eb083044fb41f5a13fce5ebb15b7952718a899bafff26921be8
