NetBSD 11.0, the latest release, ships GCC 12.5.0 as the base
system compiler, which meets the minimum version requirement in
`doc/dependencies.md`.
Github-Pull: #35908
Rebased-From: 9b85c9814d
The FreeBSD, NetBSD, and OpenBSD build guides state that ZMQ support is compiled in when the package is installed. Since WITH_ZMQ defaults to OFF, update the wording to mention the required CMake option.
Github-Pull: #35283
Rebased-From: ca93ab808c
46189fd526 doc: update http worker thread names (rkrux)
Pull request description:
After using `Threadpool` for HTTP server in PR 33689, the previously
documented HTTP worker thread names are outdated. This commit makes
the corresponding changes to document new names for the HTTP worker
threads. Below is the output from the `thead list` command after
attaching `lldb` to `bitcoind`.
```zsh
thread #3: tid = 0xfe551, 0x00007ff80e3536f6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'b-http_pool_0'
thread #4: tid = 0xfe552, 0x00007ff80e3536f6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'b-http_pool_1'
```
<!--
*** 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:
l0rinc:
ACK 46189fd526
hebasto:
ACK 46189fd526.
theStack:
ACK 46189fd526
furszy:
ACK 46189fd526
sedited:
ACK 46189fd526
Tree-SHA512: dc17dcd942a562da0e5ec9b6185db12d7e8ab8539fd6a78e944e95a723040c03c069f6806b8fc2f070839cb7012709d434b9e3e3bce08744dd818abbfe72e3ff
6b20ad84e0 doc: update build guides pre v31 (fanquake)
Pull request description:
We are testing on FreeBSD 15 (nightly) and macOS 26 (CI).
ACKs for top commit:
maflcko:
lgtm ACK 6b20ad84e0
hebasto:
ACK 6b20ad84e0.
Tree-SHA512: c97528d8db762f44d6ada064162264eedf67b154de0f357b915b14d4260b6802b099d19156ab5747120e4c632b21a8c8de92e2a903bbfcfcf4376549694eef1f
8bc62ce173 doc: Update asmap-data repository rule for file inclusion (Fabian Jahr)
Pull request description:
This updates the decision rule for file inclusion in the asmap-data repository after a collaborative run following discussion in the latest run: https://github.com/bitcoin-core/asmap-data/issues/44
The change is small but does a few things:
- No minimum number of participants recommended anymore
- Minimum number of matches set to 5 (which was previously the number of recommended min participants)
- The result that is taken does not need to see a match between the majority of participants, it only needs to have the most matches
- Participants that saw a match should sign for it
I also thought about adding an explicit tie-breaker if there are two results with the same number of matches but since both results are equally valid I think it won't be needed (?)
ACKs for top commit:
hodlinator:
ACK 8bc62ce173
luisschwab:
ACK 8bc62ce173
janb84:
Concept ACK 8bc62ce173
Tree-SHA512: 439ba1275662122e226aa472dd96fa8ed0e1af3e91d695c711e082d7ba182883e1174f954d2531cdf7e05bdbeab5ef088f8bcbd39c7124afe82baf2026ed391b
After using `Threadpool` for HTTP server in PR 33689, the previously
documented HTTP worker thread names are outdated. This commit makes
the corresponding changes to document new names for the HTTP worker
threads. Below is the output from the `thead list` command after
attaching `lldb` to `bitcoind`.
```zsh
thread #3: tid = 0xfe551, 0x00007ff80e3536f6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'b-http_pool_0'
thread #4: tid = 0xfe552, 0x00007ff80e3536f6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'b-http_pool_1'
```
a61907e5d9 doc: explain swapping in `reduce-memory.md` (Lőrinc)
Pull request description:
### Problem
Sustained [heavy swapping](https://en.wikipedia.org/wiki/Thrashing_(computer_science)) can grind execution to a halt, but today users get no direct warning from the node when this happens, and this caveat is not documented.
### Fix
We can’t easily detect heavy swap pressure in a reliable, cross-platform way, but we can document what swapping is and why it can severely degrade IBD performance.
---
Note: An earlier version of this PR attempted to detect and warn on heavy swapping (Linux-only), but it was changed to documentation based on review feedback.
ACKs for top commit:
ajtowns:
utACK a61907e5d9
sedited:
ACK a61907e5d9
Tree-SHA512: b21c40d07d78d890c19d3a17faad4ab4127688884dc433a1bdb63d18de07628c048227eba2f1258c6b542a71a986d4250f8abf8f8ffe0cda433ce0c8673978d4
fa9d0623a3 doc: Use relative markdown links (MarcoFalke)
Pull request description:
Using fully resolved links (to the `master` branch) in markdown files is problematic, because:
* When the target file is (re)moved, such a link will be a 404
* When reading docs for a previous commit/release, one is redirected to the master branch on such a link
* When the target file has been updated, it may no longer apply to the commit/release one came from (changed options, etc)
Fix all issues by using relative markdown links. Note that this only works in markdown. Also, release notes are left as-is, because they will be shared stand-alone externally, so can't use relative links.
ACKs for top commit:
kevkevinpal:
tACK [fa9d062](fa9d0623a3)
l0rinc:
code review ACK fa9d0623a3
rkrux:
tACK fa9d0623a3
sedited:
ACK fa9d0623a3
Tree-SHA512: 74cd661f20f93dc1af602ab4c6ff79673ff48fc956aca1cdd0039b127914a83fb61cff61ea92c8978c85fa500d1a1423bf9739bce261860fe037c8dfefb8acad
4ae9a10ada doc: add release notes for dbcache bump (Andrew Toth)
c510d126ef doc: update dbcache default in reduce-memory.md (Andrew Toth)
027cac8527 qt: show GetDefaultDBCache() in settings (Andrew Toth)
5b34f25184 dbcache: bump default from 450MB -> 1024MB if enough memory (Andrew Toth)
Pull request description:
Alternative to #34641
This increases the default `dbcache` value from `450MiB` to `1024MiB` if:
- `dbcache` is unset
- The system is 64 bit
- At least 4GiB of RAM is detected
Otherwise fallback to previous `450MiB` default.
This should be simple enough to get into v31. The bump to 1GiB shows significant performance increases in #34641. It also alleviates concerns of too high default for steady state, and of lowering the current dbcache for systems with less RAM.
This change only changes bitcoind behavior, while kernel still defaults to 450 MiB.
ACKs for top commit:
ajtowns:
ACK 4ae9a10ada
kevkevinpal:
reACK [4ae9a10](4ae9a10ada)
svanstaa:
ACK [4ae9a10](4ae9a10ada)
achow101:
ACK 4ae9a10ada
sipa:
ACK 4ae9a10ada
Tree-SHA512: ee3acf1fb08523ac80e37ec8f0caca226ffde6667f3a75ae6f4f4f54bc905a883ebcf1bf0e8a8a15c7cfabff96c23225825b3fff4506b9ab9936bf2c0a2c2513
0a6724aaae doc: Update Windows build notes (Hennadii Stepanov)
473e5f8efc qt: Add patch to fix SFINAE warnings in QAnyStringView with gcc16 (Hennadii Stepanov)
3cb4d6066b qt: add patches to fix SFINAE errors/warnings with gcc16 (Cory Fields)
d7e972a90d qt: add patch to fix build with gcc16 (Cory Fields)
19693a8c91 depends: Update Qt to 6.8.3 (Hennadii Stepanov)
c55584575a cmake: Fix `FindQt` module (Hennadii Stepanov)
Pull request description:
This PR updates the `qt` package in depends to the latest open-source [6.8.3](https://www.qt.io/blog/qt-6.8.3-released) LTS release.
The update includes numerous bugfixes, which allows us to drop `qtbase_plugins_windows11style.patch`.
Additionally, it includes [patches](https://github.com/bitcoin/bitcoin/issues/34569#issuecomment-3892793262) for compatibility with GCC 16 (along with one extra patch), and incorporates a [commit](8f1b55d1d5) from https://github.com/bitcoin/bitcoin/pull/32709.
Closes https://github.com/bitcoin/bitcoin/issues/34569.
ACKs for top commit:
achow101:
ACK 0a6724aaae
sedited:
ACK 0a6724aaae
Tree-SHA512: b66fe6f75bae00fb5c525c5fad56d39273f53f6bfd58206da8a55c6e41d14533137c72fb03e9537ba3a3d0b3463b6dcbef6a88ac2f4559fa6e9abf045fe1beaa
37d49f5de6 doc: mention Miniscript expressions inside reference (Pieter Wuille)
771f7642bc doc: fix typo in descriptors.md (Pieter Wuille)
708b84999b doc: reference descriptor BIPs in descriptors.md (Pieter Wuille)
8f2a869a19 doc: do not list descriptor RPCs or history (Pieter Wuille)
65a8b6c2ef doc: mention musig() in descriptors.md (Pieter Wuille)
Pull request description:
This brings doc/descriptors.md up to date:
* Stop trying to exhaustively list all RPCs that involve descriptors. They're used everywhere.
* Stop trying to give the history of descriptor support, we have release notes for that.
* Mention that wallets are now built around descriptors (especially with legacy wallets gone).
* Mention `musig()` KEY expressions in the specification part.
* Mention the miniscript expressions in the specification part.
* Reference the relevant output descriptor BIPs in the text.
ACKs for top commit:
achow101:
ACK 37d49f5de6
darosior:
utACK 37d49f5de6
Tree-SHA512: 2581be9b5d1a7099806d6f830b3a452505f8493d0e493a80b8a50e383f93f3e2c8a2d72a64fdae0adfe63d3c2eeb54a61a059108cd861e58c3d85f2bc576364b
Cross-compiling Qt 6.8 for Windows requires GCC 13.1 or newer, which
exceeds the currently documented minimum.
See https://doc.qt.io/qt-6.8/windows.html.
Improve dependencies.md to document IPC dependencies better:
- Link to native_capnp.mk file not capnp.mk file so it's possible to see what
version of Cap'n Proto is being used in release binaries. This is important
since #31895 dropped the "Version Used" column and the capnp.mk file does not
include version number.
- Indicate Capn"Proto is used for IPC and link to multiprocess.md documenting
the feature.
- Link to correct PR requiring Cap'n Proto 0.7.1. Previous link was
pointing at PR which required 0.7.0.
- Mention libmultiprocess as a dependency even though it is included as a git
subtree and can be built as a cmake subproject. Libmultiprocess still needs
to be built separately when cross compiling, and is useful to build separately
when developing, and is still a depends package.
Based on 2cf352fd8e from #33623 by willcl-ark
which made similar changes in the 29.x branch.
45133c589a doc: clarify `git range-diff` add/delete output (Lőrinc)
Pull request description:
### Problem
Range diffs in git are useful after PR rebases, but it has an easy-to-misread failure mode: if it cannot match a commit between the old and new ranges, it will show the old commit as removed (<) and the new commit as added (>), without showing any patch contents for that commit.
It can look like there were no code changes when in reality the commit was just treated as unrelated and needs full re-review.
### Example
```bash
git fetch upstream ff338fdb53a66ab40a36e1277e7371941fc89840 dd76338a57b9b1169ac27f7b783d6d0d4c6e38ab
git range-diff ff338fdb53a6...dd76338a57b9
```
This produced output like:
```patch
1: 0ca4295f2e = 93: 139aa4b27e bench: add on-disk `HaveInputs` benchmark
2: 4b32181dbb < -: ---------- test: add `HaveInputs` call-path unit tests
-: ---------- > 94: 277c57f0c5 test: add `HaveInputs` call-path unit tests
3: 8c57687f86 ! 95: c0c94ec986 dbwrapper: have `Read` and `Exists` reuse `ReadRaw`
@@ Metadata
## Commit message ##
dbwrapper: have `Read` and `Exists` reuse `ReadRaw`
- `ExistsImpl` was removed since it duplicates `CDBWrapper::ReadImpl` (except that it copies the resulting string on success, but that will be needed for caching anyway).
+ `ExistsImpl` was removed since it duplicates `CDBWrapper::ReadImpl`.
```
Even though the subject matches, there is no diff shown because the commits did not match - the reviewer could think that only the commit message was changed.
This should be treated as **unmatched** rather than **unchanged**.
If you expected a match, you can try increasing the search effort:
```bash
git range-diff --creation-factor=95 ff338fdb53a6...dd76338a57b9
```
which would show for example:
```patch
1: 0ca4295f2e = 93: 139aa4b27e bench: add on-disk `HaveInputs` benchmark
2: 4b32181dbb ! 94: 277c57f0c5 test: add `HaveInputs` call-path unit tests
@@ Commit message
The tests document that `HaveInputs()` consults the cache first and that a cache miss pulls from the backing view via `GetCoin()`.
+ Co-authored-by: Novo <eunovo9@gmail.com>
+
## src/test/coins_tests.cpp ##
@@ src/test/coins_tests.cpp: BOOST_FIXTURE_TEST_CASE(ccoins_flush_behavior, FlushTest)
}
}
-+BOOST_AUTO_TEST_CASE(ccoins_haveinputs_cache_miss_uses_base_getcoin)
++BOOST_AUTO_TEST_CASE(ccoins_cache_behavior)
```
### Fix
This PR updates `doc/productivity.md` to raise awareness and document this pitfall and mentions `--creation-factor` as a knob to try when the output seems unexpectedly empty.
ACKs for top commit:
maflcko:
review ACK 45133c589a🏦
Sjors:
ACK 45133c589a
rkrux:
crACK 45133c5
sedited:
ACK 45133c589a
Tree-SHA512: 52dcf6db51425a3ac9789627f80233fb1e3437f7a351acf4a761504d9917837aa1ff8c964605a842ee099fae9842946784f7603f9bffa7051429b2f04b7900be
When `git range-diff` cannot match a commit between two versions of a branch, it shows the old commit as removed (`<`) and the new commit as added (`>`), and it does not show the patch contents.
This output is easy to misread as "no code changes" because the diff for that commit is effectively empty.
It really means the commits were considered unrelated and the new commit should be reviewed from scratch.
This is analogous to rename detection in `git diff`: if similarity is too low, a rename shows up as delete+add.
Example (exact SHAs from PR #34320):
B=ff338fdb53a66ab40a36e1277e7371941fc89840; A=dd76338a57b9b1169ac27f7b783d6d0d4c6e38ab; git fetch upstream $B $A
git range-diff 0ca4295f2e5f4443a1f8b3bae7cba0f6c054276f..$B 139aa4b27e4839291c83a04dcd1649c5595814ca..$A
This produced output like:
1: 4b32181dbb < -: ---------- test: add `HaveInputs` call-path unit tests
-: ---------- > 1: 277c57f0c5 test: add `HaveInputs` call-path unit tests
Even though the subject matches, the first commit had no matching diff shown.
That should be treated as "unmatched" rather than "unchanged".
If you expected a match, try increasing the creation factor so `git range-diff` searches harder:
git range-diff --creation-factor=95 <old_range> <new_range>
f700609e8a doc: Release notes for mining IPC interface bump (Ryan Ofsky)
9453c15361 ipc mining: break compatibility with existing clients (version bump) (Sjors Provoost)
70de5cc2d2 ipc mining: pass missing context to BlockTemplate methods (incompatible schema change) (Sjors Provoost)
2278f017af ipc mining: remove deprecated methods (incompatible schema change) (Ryan Ofsky)
c6638fa7c5 ipc mining: provide default option values (incompatible schema change) (Ryan Ofsky)
a4603ac774 ipc mining: declare constants for default field values (Ryan Ofsky)
ff995b50cf ipc test: add workaround to block_reserved_weight exception test (Ryan Ofsky)
b970cdf20f test framework: expand expected_stderr, expected_ret_code options (Ryan Ofsky)
df53a3e5ec rpc refactor: stop using deprecated getCoinbaseCommitment method (Ryan Ofsky)
Pull request description:
This PR increments the field number of the `Init.makeMining` method and makes the old `makeMining` method return an error, so IPC mining clients not using the latest schema file will get an error and not be able to access the Mining interface.
Normally, there shouldn't be a need to break compatibility this way, but the mining interface has evolved a lot since it was first introduced, with old clients using the original methods less stable and performant than newer clients. So now is a good time to introduce a cutoff, drop deprecated methods, and stop supporting old clients which can't function as well.
Bumping the field number is also an opportunity to make other improvements that would be awkward to implement compatibly:
- Making Cap'n Proto default parameter and field values match default values of corresponding C++ methods and structs.
- Adding missing Context parameters to Mining.createNewBlock and checkBlock methods so these methods will be executed on separate execution threads and not block the Cap'n Proto event loop thread.
More details about these changes are in the commit messages.
ACKs for top commit:
Sjors:
ACK f700609e8a
enirox001:
ACK f700609e8a
ismaelsadeeq:
ACK f700609e8a
sedited:
ACK f700609e8a
Tree-SHA512: 0901886af00214c138643b33cec21647de5671dfff2021afe06d78dfd970664a844cde9a1e28f685bb27edccaf6e0c3f2d1e6bb4164bde6b84f42955946e366d
