6b99a3e4f0 doc: update cjdns.md for current upstream changes (w0xlt)
Pull request description:
Update `doc/cjdns.md`. Users following the current doc hit dead links when trying to set up cjdns peering. The upstream cjdns project has reorganized its README and now supports automatic peering, making most of the existing instructions obsolete.
Summary
* Remove broken links to cjdns README sections ("2. Find a friend", "3. Connect your node to your friend's node") that no longer exist upstream
* Remove reference to `hyperboria/peers` repo and `testAvailable.py` (last updated Feb 2024, likely stale)
* Add `cjdns.sh` as recommended install method alongside building from source
* Document automatic peering via DNS seeding (default since cjdns v22), which makes manual peer discovery unnecessary for most users
* Simplify manual peering instructions with a clear `connectTo` example and link to upstream `doc/peering.md`
* Add `cjdnstool peers show` as the way to verify network connectivity
The Bitcoin Core-specific sections (`-cjdnsreachable`, `-onlynet=cjdns`, admin commands, etc.) are unchanged.
ACKs for top commit:
achow101:
ACK 6b99a3e4f0
stratospher:
ACK 6b99a3e. worked on nixos.
brunoerg:
reACK 6b99a3e4f0
naiyoma:
TestedACK 6b99a3e4f0
Tree-SHA512: 00a703a788e96af4fd9456246644c3047b1d5cbed41d97f4f4f64f60b34cd6ffbf052d5e8f32365e65fd09a44fd0e16dd0dd45f6c75563f18075414f9b3eb1e7
25f69d970a release note (Pol Espinasa)
af629821cf test: add background validation test for getblockchaininfo (Pol Espinasa)
a3d6f32a39 rpc, log: add backgroundvalidation to getblockchaininfo (Pol Espinasa)
5b2e4c4a88 log: update progress calculations for background validation (Pol Espinasa)
Pull request description:
`getblockchaininfo` returns `verificationprogress=1` and `initialblockdownload=false` even if there's background validation.
This PR adds information about background validation to rpc `getblockchaininfo` in a similar way to `validationprogress` does.
If assume utxo was used the output of a "sync" node performing background validation:
```
$ ./build/bin/bitcoin-cli getblockchaininfo
...
"mediantime": 1756933740,
"verificationprogress": 1,
"initialblockdownload": false,
"backgroundvalidation": {
"snapshotheight": 880000,
"blocks": 527589,
"bestblockhash": "0000000000000000002326308420fa5ccd28a9155217f4d1896ab443d84148fa",
"mediantime": 1529076654,
"chainwork": "0000000000000000000000000000000000000000020c92fab9e5e1d8ed2d8dbc",
"verificationprogress": 0.2815790617966284
},
"chainwork": "0000000000000000000000000000000000000000df97866c410b0302954919d2",
"size_on_disk": 61198817285,
...
```
If assume utxo was not used the progress is hidden:
```
$ ./build/bin/bitcoin-cli getblockchaininfo
...
"mediantime": 1756245700,
"verificationprogress": 1,
"initialblockdownload": false,
"chainwork": "00000000000000000000000000000000000000000000000000000656d6bb052b",
"size_on_disk": 3964972194,
...
```
The PR also updates the way we estimate the verification progress returning a 100% on the snapshot block and not on the tip as we will stop doing background validation when reaching it.
ACKs for top commit:
fjahr:
ACK 25f69d970a
danielabrozzoni:
ACK 25f69d970a
achow101:
ACK 25f69d970a
sedited:
ACK 25f69d970a
Tree-SHA512: 5e5e08fd39af5f764962b862bc6d8257b0d2175fe920d4b79dc5105578fd4ebe08aee2fe9bfa5c9cad5d7610197a435ebaac0de23e7a5efa740dfea031a8a9d4
c68e3d2c57 doc: add release notes for Tor PoW defenses (Vasil Dimov)
4bae84c94a doc: add a hint to enable PoW defenses to manual hidden services (Vasil Dimov)
4c6798a3d3 tor: enable PoW defenses for automatically created hidden services (Vasil Dimov)
fb993f7604 tor, fuzz: reuse constants instead of duplicating (Vasil Dimov)
Pull request description:
Enable [PoW defenses](https://tpo.pages.torproject.net/onion-services/ecosystem/technology/security/pow/) for hidden services that we create via Tor Control using the [`ADD_ONION` command](https://spec.torproject.org/control-spec/commands.html#add_onion).
The ability to do that has been added in [tor-0.4.9.2-alpha](02c1804446). Previous versions return a syntax error to the `ADD_ONION` command with `PoWDefensesEnabled=1`, so the approach here is to try with PoW and if we get syntax error, then retry without PoW.
Also update `doc/tor.md` with a hint on enabling PoW on manually configured Tor hidden services.
ACKs for top commit:
willcl-ark:
ACK c68e3d2c57
fjahr:
tACK c68e3d2c57
sedited:
ACK c68e3d2c57
Tree-SHA512: 56f57bc770b89389c35a4c0bc2a28804d17b1479ecd4d9b764695d6c9d2994425aee759e71658d7b57088bbe43ce90b94fb972f66d79ef903e0c1a4d6c4562f3
0fe6fccec2 doc: Document rationale for using `IWYU pragma: export` (Hennadii Stepanov)
cfa3b10d50 iwyu, doc: Document `IWYU pragma: export` for `<logging/categories.h>` (Hennadii Stepanov)
015bea05e6 iwyu, doc: Document `IWYU pragma: export` for `<chrono>` (Hennadii Stepanov)
48bfcfedec iwyu, doc: Document `IWYU pragma: export` for `<threadsafety.h>` (Hennadii Stepanov)
179abb387f refactor: Move `StdMutex` to its own header (Hennadii Stepanov)
6d2952c3c3 serialize: Add missing `<span>` header (Hennadii Stepanov)
Pull request description:
This PR is a prerequisite for https://github.com/bitcoin/bitcoin/pull/34448. It was split into a separate PR to limit the scope and minimize potential merge conflicts.
The first commit improves the accuracy of IWYU suggestions within our heavily templated code. Note that, for now, the `serialize.h` header itself is excluded from IWYU inspection because it lacks a corresponding source file.
The remaining commits follow the Developer Notes [guidance](https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#using-iwyu):
> Use `IWYU pragma: export` very sparingly, as this enforces transitive inclusion of headers and undermines the specific purpose of IWYU.
ACKs for top commit:
maflcko:
review ACK 0fe6fccec2👤
ajtowns:
utACK 0fe6fccec2
Tree-SHA512: dc2d4e3ff78b9707a1a26cb9b1c0a456de0d33c59e773bbf692344c2fceaff8936317479c5e898038f29134bc0e5d9d1ef7350e53512dd8e262f46ede578c4f9
74f71c5054 Remove Taproot activation height (Sjors Provoost)
Pull request description:
Drop `DEPLOYMENT_TAPROOT` from `consensus.vDeployments`.
Now that the commit (7c08d81e11) which changes taproot to be enforced for all blocks is included in v24.0, it seems a good time to remove no longer needed non-consensus code.
Clarify what is considered a `BuriedDeployment`.
We drop taproot from `getdeploymentinfo` RPC, rather than mark it as `buried`, because this is not a buried deployment in the sense of [BIP 90](https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki). This is because the activation height has been completely removed from the code, unlike the hardcoded `DEPLOYMENT_SEGWIT` height which is still relied on.[^1]
See discussion in #24737 and #26162.
[^1]: `DEPLOYMENT_SEGWIT` is used in `IsBlockMutated` to determine if witness data is allowed, it's used for [BIP147](https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki), to trigger `NeedsRedownload()` for users who upgraded after a decade, and for a few other things.
ACKs for top commit:
ajtowns:
reACK 74f71c5054
achow101:
ACK 74f71c5054
sedited:
Re-ACK 74f71c5054
darosior:
utACK 74f71c5054
Tree-SHA512: 217e0ee2e144ccfb04cf012f45b75d08f8541287a5531bd18aa81e38bad2f38d28b772137f471c46b63875840ec044cb61a2a832e3a9e89a6183e8ab36b1b9c9
d8f4e7caf0 doc: add release notes (ismaelsadeeq)
248c175e3d test: ensure `ValidateInputsStandardness` optionally returns debug string (ismaelsadeeq)
d2716e9e5b policy: update `AreInputsStandard` to return error string (ismaelsadeeq)
Pull request description:
This PR is another attempt at #13525.
Transactions that fail `PreChecks` Validation due to non-standard inputs now returns invalid validation state`TxValidationResult::TX_INPUTS_NOT_STANDARD` along with a debug error message.
Previously, the debug error message for non-standard inputs do not specify why the inputs were considered non-standard.
Instead, the same error string, `bad-txns-nonstandard-inputs`, used for all types of non-standard input scriptSigs.
This PR updates the `AreInputsStandard` to include the reason why inputs are non-standard in the debug message.
This improves the `Precheck` debug message to be more descriptive.
Furthermore, I have addressed all remaining comments from #13525 in this PR.
ACKs for top commit:
instagibbs:
ACK d8f4e7caf0
achow101:
ACK d8f4e7caf0
sedited:
Re-ACK d8f4e7caf0
Tree-SHA512: 19b1a73c68584522f863b9ee2c8d3a735348667f3628dc51e36be3ba59158509509fcc1ffc5683555112c09c8b14da3ad140bb879eac629b6f60b8313cfd8b91
fa4ec13b44 build: Enable -Wcovered-switch-default (MarcoFalke)
fa2670bd4b refactor: Enable -Wswitch in exhaustive switch (MarcoFalke)
Pull request description:
The compiler flag `-Wswitch` is enabled. However, it can not fire when a `default:` case exists. Fix that by removing the default case where a switch is already handling all cases exhaustively.
Also, enable `-Wcovered-switch-default` to catch those cases at compile time in the future.
Also, apply the comment according to the dev notes.
Can be reviewed via `--ignore-all-space`
ACKs for top commit:
stickies-v:
re-ACK fa4ec13b44, no changes except for addressing silent merge conflict from d339884f1d
l0rinc:
ACK fa4ec13b44
achow101:
ACK fa4ec13b44
sedited:
ACK fa4ec13b44
Tree-SHA512: 8dd9e71a8cd338255f43448a59a1a4d40a9fc16e19a707cc10fb71442d4df9f82a0e5fae77868ef49cd0ea27fdd972687572c1a50b6aba7e08c6ce87576afc6a
d62f46eed4 doc: Add `INSTALL.md` to Linux release tarballs (Hennadii Stepanov)
Pull request description:
Closes https://github.com/bitcoin/bitcoin/issues/32097:
> Better I think would be to add instructions for the most popular desktop distros.
ACKs for top commit:
willcl-ark:
utACK d62f46eed4
achow101:
ACK d62f46eed4
janb84:
re ACK d62f46eed4
w0xlt:
ACK d62f46eed4
sedited:
ACK d62f46eed4
Tree-SHA512: eab6904b6acc63eaf0e13112f52d856ee630ce4110fb368f4f5f170655def91706bb7c7f70c123186a51461ea3d48ef026a4e026d665675f1fd76f2d0bbca68c
Also, apply the comment according to the dev notes.
Also, modify the dev notes to give a lambda-wrapped example.
Can be reviewed via --ignore-all-space
Co-authored-by: Lőrinc <pap.lorinc@gmail.com>
c2732146d1 doc: fix process name typo in multiprocess.md (ViniciusCestarii)
Pull request description:
In this [flow](https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md#example-use-cases-and-flows), the bitcoin-wallet process acts as the client initiating the RPC request, while the bitcoin-node process acts as the server receiving it. So at "The `getBlockHash` method of the generated `Chain` server subclass in `bitcoin-wallet` receives a Cap’n Proto request object with the `height` parameter, and calls the `getBlockHash` method on its local `Chain` object with the provided `height`." it should say bitcoin-node not bitcoin-wallet.
This PR fix this typo.
ACKs for top commit:
ryanofsky:
Code review ACK c2732146d1. Nice catch!
Tree-SHA512: 7227dc96e556ad36f1f39cc1033d80c92e8c6a47cf61ab68401122b1ef8075068224494e4ffb7094eca8dc325294cb96e561d3e997af7d434158031485f92677
b19caeea09 doc: add release note for #31560 (named pipe support for `dumptxoutset` RPC) (Sebastian Falbesoner)
61a5460d0d test: add test for utxo-to-sqlite conversion using named pipe (Sebastian Falbesoner)
2e8072edbe rpc: support writing UTXO set dump (`dumptxoutset`) to a named pipe (Sebastian Falbesoner)
Pull request description:
This PR slightly modifies the `dumptxoutset` RPC to allow writing the UTXO set dump into a [named pipe](https://askubuntu.com/a/449192), so that the output data can be consumed by another process, see #31373. Taking use of this with the utxo-to-sqlite.py tool (introduced in #27432), creating an UTXO set in SQLite3 format is possible on the fly. E.g. for signet:
```
$ mkfifo /tmp/utxo_fifo && ./build/bin/bitcoin-cli -signet dumptxoutset /tmp/utxo_fifo latest &
$ ./contrib/utxo-tools/utxo_to_sqlite.py /tmp/utxo_fifo ./utxo.sqlite
UTXO Snapshot for Signet at block hash 000000012711f0a4e741be4a22792982..., contains 61848352 coins
1048576 coins converted [1.70%], 2.800s passed since start
....
....
60817408 coins converted [98.33%], 159.598s passed since start
{
"coins_written": 61848352,
"base_hash": "000000012711f0a4e741be4a22792982370f51326db20fca955c7d45da97f768",
"base_height": 294305,
"path": "/tmp/utxo_fifo",
"txoutset_hash": "34ae7fe7af33f58d4b83e00ecfc3b9605d927f154e7a94401226922f8e3f534e",
"nchaintx": 28760852
}
TOTAL: 61848352 coins written to ./utxo.sqlite, snapshot height is 294305.
```
Note that the `dumptxoutset` RPC calculates an UTXO set hash as a first step before any data is emitted, so especially on mainnet it takes quite a while until the conversion starts and something is happening visibly.
ACKs for top commit:
ajtowns:
utACK b19caeea09
sedited:
Re-ACK b19caeea09
Tree-SHA512: 7101563d0dba15439cdef8c8fb535f8593d5a779ff04208e2d72382a3f99072db8eac3651d1b3fe72c5e1f03e164efb281c3030d45d0723b943ebbbcf2a841d6
b3046cca71 doc: add release notes for #26988 (stratospher)
675be93024 cli: modify -addrinfo to use getaddrmaninfo RPC endpoint (stratospher)
Pull request description:
Rework of `-addrinfo` CLI is done using `getaddrmaninfo` RPC proposed in https://github.com/bitcoin/bitcoin/pull/27511. This would be useful for users who want to know the total number of addresses the node knows about and can make connections to.
Currently, `-addrinfo` returns total number of addresses the node knows about after filtering them for quality + recency using [`isTerrible`](4b51290f71/src/addrman.cpp (L808)). However `isTerrible`addresses [don't matter](https://github.com/bitcoin/bitcoin/pull/26988#discussion_r1147725684) when selecting outbound peers to connect to. Total number of addresses the node knows about could be higher than what `-addrinfo` currently displays. See https://github.com/bitcoin/bitcoin/pull/24370.
ACKs for top commit:
ajtowns:
ACK b3046cca71
pablomartin4btc:
re-ACK b3046cca71
vasild:
ACK b3046cca71
sr-gi:
tACK b3046cca71
Tree-SHA512: 764b74f9e0e28a65f8644a31228ca70f6e2cd4c6a93d8f29093ed7a241cd20a81e24b4babace170d945fb28078793d52ec1f4bce898a6d478950fb29ce54af91
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
Drop DEPLOYMENT_TAPROOT from consensus.vDeployments.
Bump MinBIP9WarningHeight.
Clarify what is considered a BuriedDeployment and
drop taproot from getdeploymentinfo RPC.
Add a test to getblocktemplate to ensure the taproot
rule is still set.
Co-Authored-By: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
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>
