7ebdfa2173 ci: link against -lstdc++ in native fuzz with msan job (fanquake)
ecbcef33d6 doc: remove unrelated `bitcoin-wallet` binary from `libbitcoin_ipc` description (Sebastian Falbesoner)
8c973d6614 ci: disable cirrus cache in 32bit arm job (will)
2378bbf356 ci: refactor docker action to return provider str (will)
acf7d53ace test: split out `system_ram_tests` to signal when total ram cannot be determined (Lőrinc)
ce56548c63 system: improve handling around GetTotalRAM() (Vasil Dimov)
5226a92f28 coins: warn on oversized -dbcache (Lőrinc)
49d4ebcbfe system: add helper for fetching total system memory (Lőrinc)
0a80b1ae62 doc: update manual pages for v30.0rc2 (fanquake)
b8fb918969 build: bump version to v30.0rc2 (fanquake)
792a75ac86 build(windows): Remove lingering registry entries and shortcuts upon install (Hodlinator)
1bc3be1962 p2p: Increase tx relay rate (Anthony Towns)
4b02bc1a72 test: Avoid interface_ipc.py Duplicate ID errors (Ryan Ofsky)
Pull request description:
Backports:
* #28592
* #33302
* #33333
* #33420
* #33422
* #33425
* #33435
* #33459
Finalise `v30.0rc2`
ACKs for top commit:
willcl-ark:
ACK 7ebdfa2173
hebasto:
ACK 7ebdfa2173, I applied all backports locally without conflicts and obtained a zero diff with this PR branch.
Tree-SHA512: 73d641a5d783511a959e63f240453bb020705cb620b85a5a0968b32b937ac28816ef142f78bdf41976ed1c2bee431def945c5c37da33621031e3198cfdae51f3
`bitcoin-wallet` as-is is merely an offline wallet inspection tool
(introduced more than 9 years ago in PR #13926) that doesn't have any
relation with IPC/multiprocess, so remove it from the list of binaries
that use `libbitcoin_ipc`.
Github-Pull: #33459
Rebased-From: fbde8d9a81
Co-authored-by: Max Edwards <youwontforgetthis@gmail.com>
Add an optional matrix field allowing opt-out of configuring cirrus
GHA cache when not using cirrus runners.
This is not needed for the cirruslabs/[save|restore]-cache actions, as
they automatically fallback based on runner type.
Github-Pull: #33302
Rebased-From: 00c253d494
when `GetTotalRAM` returns an `std::nullopt` now we're getting:
```
The following tests did not run:
106 - system_ram_tests (Skipped)
```
GitHub-Pull: #33435
Rebased-From: 56791b5829
Oversized allocations can cause out-of-memory errors or [heavy swapping](https://github.com/getumbrel/umbrel-os/issues/64#issuecomment-663637321), [grinding the system to a halt](https://x.com/murchandamus/status/1964432335849607224).
`LogOversizedDbCache()` now emits a startup warning if the configured `-dbcache` exceeds a cap derived from system RAM, using the same parsing/clamping as cache sizing via CalculateDbCacheBytes(). This isn't meant as a recommended setting, rather a likely upper limit.
Note that we're not modifying the set value, just issuing a warning.
Also note that the 75% calculation is rounded for the last two numbers since we have to divide first before multiplying, otherwise we wouldn't stay inside size_t on 32-bit systems - and this was simpler than casting back and forth.
We could have chosen the remaining free memory for the warning (e.g. warn if free memory is less than 1 GiB), but this is just a heuristic, we assumed that on systems with a lot of memory, other processes are also running, while memory constrained ones run only Core.
If total RAM < 2 GiB, cap is `DEFAULT_DB_CACHE` (`450 MiB`), otherwise it's 75% of total RAM.
The threshold is chosen to be close to values commonly used in [raspiblitz](https://github.com/raspiblitz/raspiblitz/blob/dev/home.admin/_provision.setup.sh#L98-L115) for common setups:
| Total RAM | `dbcache` (MiB) | raspiblitz % | proposed cap (MiB) |
|----------:|----------------:|-------------:|-------------------:|
| 1 GiB | 512 | 50.0% | 450* |
| 2 GiB | 1536 | 75.0% | 1536 |
| 4 GiB | 2560 | 62.5% | 3072 |
| 8 GiB | 4096 | 50.0% | 6144 |
| 16 GiB | 4096 | 25.0% | 12288 |
| 32 GiB | 4096 | 12.5% | 24576 |
[Umbrel issues](https://github.com/getumbrel/umbrel-os/issues/64#issuecomment-663816367) also mention 75% being the upper limit.
Starting `bitcoind` on an 8 GiB rpi4b with a dbcache of 7 GiB:
> ./build/bin/bitcoind -dbcache=7000
warns now as follows:
```
2025-09-07T17:24:29Z [warning] A 7000 MiB dbcache may be too large for a system memory of only 7800 MiB.
2025-09-07T17:24:29Z Cache configuration:
2025-09-07T17:24:29Z * Using 2.0 MiB for block index database
2025-09-07T17:24:29Z * Using 8.0 MiB for chain state database
2025-09-07T17:24:29Z * Using 6990.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
```
Besides the [godbolt](https://godbolt.org/z/EPsaE3xTj) reproducers for the new total memory method, we also tested the warnings manually on:
- [x] Apple M4 Max, macOS 15.6.1
- [x] Intel Core i9-9900K, Ubuntu 24.04.2 LTS
- [x] Raspberry Pi 4 Model B, Armbian Linux 6.12.22-current-bcm2711
- [x] Intel Xeon x64, Windows 11 Home Version 24H2, OS Build 26100.4351
Co-authored-by: stickies-v <stickies-v@protonmail.com>
Co-authored-by: Hodlinator <172445034+hodlinator@users.noreply.github.com>
Co-authored-by: w0xlt <woltx@protonmail.com>
Github-Pull: #33333
Rebased-From: 168360f4ae
Added a minimal system helper to query total physical RAM on [Linux/macOS/Windows](https://stackoverflow.com/a/2513561) (on other platforms we just return an empty optional).
The added test checks if the value is roughly correct by checking if the CI platforms are returning any value and if the value is at least 1 GiB and not more than 10 TiB.
The max value is only validated on 64 bits, since it's not unreasonable for 32 bits to have max memory, but on 64 bits it's likely an error.
https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-memorystatusex
> ullTotalPhys The amount of actual physical memory, in bytes.
https://man7.org/linux/man-pages/man3/sysconf.3.html:
> _SC_PHYS_PAGES The number of pages of physical memory. Note that it is possible for the product of this value and the value of _SC_PAGESIZE to overflow.
> _SC_PAGESIZE Size of a page in bytes. Must not be less than 1.
See https://godbolt.org/z/ec81Tjvrj for further details
Github-Pull: #33333
Rebased-From: 6c720459be
Prior releases installed using these paths. Especially annoying was that the lingering registry entry for the uninstaller would show up as "Bitcoin Core (64-bit)" besides the current "Bitcoin Core" entry in the list of installed programs, and whichever was uninstalled last would fail to work as they would default to the same install directory.
Github-Pull: #33422
Rebased-From: 79752b9c0b
In the presence of smaller transactions on the network, blocks can sustain a
higher relay rate than 7tx/second. In this event, the per-peer inventory queues
can grow too large.
This commit bumps the rate up to 14 tx/s (for inbound peers), increasing the
safety margin by a factor of 2.
Outbound peers continue to receive relayed transactions at 2.5x the rate of
inbound peers, for a rate of 35tx/second.
Co-Authored-By: Suhas Daftuar <sdaftuar@gmail.com>
Github-Pull: #28592
Rebased-From: b81f37031c
This change should fix issue https://github.com/bitcoin/bitcoin/issues/33417
reported by zaidmstrr. It's possible to reproduce the `mp/proxy.capnp:0:
failed: Duplicate ID @0xcc316e3f71a040fb` error by installing libmultiprocess
system-wide, or to one of the locations listed in the python test's `imports`
list before the local libmultiprocess subtree, and then running the test.
Github-Pull: #33420
Rebased-From: e9c52272eb
33a0d4bb5b qt: 30.0rc2 translations update (Hennadii Stepanov)
Pull request description:
This PR updates Spanish (es) and Czech (cs) translations and addresses the following comments:
- https://github.com/bitcoin/bitcoin/pull/33275#issuecomment-3315273628
- https://github.com/bitcoin/bitcoin/pull/33275#issuecomment-3316206549
Updates for other languages were skipped, as I believe the review effort would not be worthwhile at this stage of the release process.
ACKs for top commit:
fanquake:
ACK 33a0d4bb5b.
Tree-SHA512: 94c1c1fb4a0079f3e733c573ba1fddd149307ec39220e811d33f5bbfd929a634b24ef9adbe9e789bd0127539ce5e134dde3a241db0e233d53446abf96a4d49b6
c9f751090c cmake: Install `bitcoin` manpage (Hennadii Stepanov)
2327b2b0db net: Do not apply whitelist permission to onion inbounds (Martin Zumsande)
26208b3a0c test: Add submitblock test in interface_ipc (TheCharlatan)
3ae592537d test: Prevent disk space warning during node_init_tests (Ryan Ofsky)
5dbb1bae38 ci: Enable CI_LIMIT_STACK_SIZE=1 in i686_no_ipc task (MarcoFalke)
c7faf72ac6 test: Fix CLI_MAX_ARG_SIZE issues (MarcoFalke)
0a2afbeb77 cmake: Fix regression in `secp256k1.cmake` (Hennadii Stepanov)
75026cddea wallet: Add m_cached_from_me to cache "from me" status (Ava Chow)
bbb4e118f3 test: Add a test for anchor outputs in the wallet (Ava Chow)
b85dc7ed3a wallet: Throw an error in sendall if the tx size cannot be calculated (Ava Chow)
d2be9a22d8 wallet: Determine IsFromMe by checking for TXOs of inputs (Ava Chow)
ad6c13e041 test: Test wallet 'from me' status change (Ava Chow)
35038b03c9 trace: Workaround GCC bug compiling with old systemtap (Luke Dashjr)
f7eded1dca ci: always use tag for LLVM checkout (fanquake)
6b19ede1a5 gui: Avoid pathological QT text/markdown behavior... (David Gumberg)
Pull request description:
Backports:
* #33243
* #33268
* #33310
* #33364
* #33379
* #33380
* #33391
* #33407
* https://github.com/bitcoin-core/gui/pull/886
ACKs for top commit:
darosior:
utACK c9f751090c
hebasto:
ACK c9f751090c, I applied all backports locally without conflicts and obtained a zero diff with this PR branch.
Tree-SHA512: 257cc5bd0423fbf2aff62c72957faea3de8731353d809b11e18d0e5cad174c7023dca9dedd0c73e07497eb804b7c48355a055b4461db260e2f0a5712d2514ff6
Tor inbound connections do not reveal the peer's actual network address.
Therefore do not apply whitelist permissions to them.
Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
Github-Pull: #33395
Rebased-From: f563ce9081
mzumsande pointed out https://github.com/bitcoin/bitcoin/pull/32345#issuecomment-3286964369 that this test was causing a warning:
Warning: Disk space for "/tmp/test_common bitcoin/node_init_tests/init_test/bf78678cb7723a3e84b5/blocks" may not accommodate the block files. Approximately 810 GB of data will be stored in this directory.
Fix by setting regtest instead of mainnet network before running the test.
Github-Pull: #33391
Rebased-From: bdf01c6f61
m_cached_from_me is used to track whether a transaction is "from me", i.e. has
any inputs which belong to the wallet. This is held in memory only in
the same way that a transaction's balances are.
Github-Pull: #33268
Rebased-From: 113a422822
Instead of checking whether the total amount of inputs known by the
wallet is greater than 0, we should be checking for whether the input is
known by the wallet. This enables us to determine whether a transaction
spends an of output with an amount of 0, which is necessary for marking
0-value dust outputs as spent.
Github-Pull: #33268
Rebased-From: 39a7dbdd27
If something is imported into the wallet, it can change the 'from me'
status of a transaction. This status is only visible through
gettransaction's "fee" field which is only shown for transactions that
are 'from me'.
Github-Pull: #33268
Rebased-From: e76c2f7a41
Rather than trying to match the apt installed clang version, which is
prone to intermittent issues. i.e #33345.
Github-Pull: #33364
Rebased-From: b736052e39
d00b82fc96 doc: update manual pages for v30.0rc1 (fanquake)
25f699daa5 contrib: add bitcoin binary to gen-manpages (fanquake)
8578991348 doc: generate example bitcoin.conf (fanquake)
9b75222b5e doc: point to v30.0 release notes draft (fanquake)
e69aba63cd build: bump version to v30.0rc1 (fanquake)
Pull request description:
* Bumps version to `v30.0rc1`.
* Generates example bitcoin.conf.
* Generates the manpages (includes backport of f5887a8de4 from #33348).
* Points release-notes.md to the devwiki (https://github.com/bitcoin-core/bitcoin-devwiki/wiki/v30.0-Release-Notes-Draft).
ACKs for top commit:
hebasto:
ACK d00b82fc96. On Ubuntu 25.04, I've got the same generated files.
janb84:
ACK d00b82fc96
stickies-v:
ACK d00b82fc96 - getting identical manpages and bitcoin.conf output on macos 15.6. Other changes LGTM too.
Tree-SHA512: 7c1cf6442f2380c90d6395d07f75297718bc323a740209efaf2020d7c94598a28c73ab5a638e1fd4ddf2b38cc6aaebe046ea968688f695abf8735b0d9315cd68
9f744fffc3 build: bump CLIENT_VERSION_MAJOR to 30 (fanquake)
Pull request description:
Last step before branch off.
ACKs for top commit:
hebasto:
ACK 9f744fffc3.
Tree-SHA512: f8ddbaa56213707c4d1719a6ade89103bcc1142d71f47cc527a20669995c1598ddbd61a88487841aa794340219e956deed403d8a7c229fc8b526e67e07dd7d69
fa8f081af3 ci: Checkout latest merged pulls (MarcoFalke)
Pull request description:
Currently, the `actions/checkout@v5` checks out pull requests merged against master, which is what we want.
However, it checks out ancient/stale merge commits on a re-run. This is documented (https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs):
> Re-run workflows [...] will also use the same GITHUB_SHA (commit SHA) and GITHUB_REF (git ref) of the original event that triggered the workflow run.
For example:
* https://github.com/bitcoin/bitcoin/actions/runs/17458152407/job/49579638898?pr=29641#step:9:914 compiles with IPC=ON, even though latest master is at ed2ff3c63d
* https://github.com/bitcoin/bitcoin/pull/32989#issuecomment-3133536724 (example explained in comment)
This is problematic, because:
* Unrelated CI failures and intermittent issues, which are fixed or worked around in latest master can not be cleaned by re-running the task. The author has to actively go out and (force-)push the branch, invalidating review.
* It is odd to have a recent CI run, but it uses code and config from the past.
* Detecting silent merge conflicts by re-running the CI task is impossible.
Fix all issues by checking out the latest merged state of the pull request. The behavior is unchanged for non-pull-request actions. This patch changes the "re-run" default behaviour. Forcing it to use the new state instead of running the old state again.
ACKs for top commit:
janb84:
re ACK fa8f081af3
hebasto:
ACK fa8f081af3.
Tree-SHA512: c22c6f837402f61ec46be46817473e1946424b5312e36ed0e246cadb1ca89c04163bb471f71c309765a3d327f198a83cd83679d231f03828a99a97562a622fdd
5eeb2facbb ci: reduce runner sizes on various jobs (will)
Pull request description:
These jobs can likely use reduced runner sizes to avoid wasting our CPU quota, as much of the long-running part of the job is single-threaded.
This will also give us more (job) parallelisem from the same number of CPU that we are using.
Suggested in: https://github.com/bitcoin/bitcoin/pull/32989#discussion_r2321775620
ACKs for top commit:
kevkevinpal:
ACK [5eeb2fa](5eeb2facbb)
m3dwards:
ACK 5eeb2facbb
janb84:
ACK 5eeb2facbb
Tree-SHA512: 6fb0352bc40623dd63b9bd6169d753d1ec9667c272445fda7a2db8bbedfa35350a51d08c1adf3fa5e070e84855c3f491668726d3c7ded07a39f2f9c63edacefc
790b440197 Fix benchmark CSV output (Hennadii Stepanov)
Pull request description:
The `SHA256AutoDetect` return output is used, among other use cases, to name benchmarks. Using a comma breaks the `bench_bitcoin` CSV output.
This PR replaces the comma with a semicolon, which fixes https://github.com/bitcoin/bitcoin/issues/33331.
ACKs for top commit:
Raimo33:
Code Review ACK 790b440197
l0rinc:
Code review ACK 790b440197
janb84:
code review ACK 790b440197
Tree-SHA512: 096bfa29a0639a4d97d510a3e2a15f071f384148c3035e4d0fc525794682e499c45a0d0c95728d5c78010098393b2c486a7fa9c21c1e2fbb600dea7c5638a55f
3cceda9f48 guix: strip binaries in libexec (fanquake)
Pull request description:
#31679 moved some internal binaries to `libexec/`, but the Guix build wasn't updated to stip these binaries of their debug symbols.
ACKs for top commit:
achow101:
ACK 3cceda9f48
ryanofsky:
Code review ACK 3cceda9f48. Good catch and thanks for the fix
hebasto:
ACK 3cceda9f48, I've checked Guix build outputs.
Tree-SHA512: 96ad57c2d3670a9ae8c58cdb428918d1dc0fa90014bb7c6fb7a7a68b3ece3fbea9c4fac90a626a005a0edb3cca8b6a33adc9a037fe6b915319387588ffe09e7b
8b62647680 test: send duplicate blocktxn message in p2p_compactblocks.py (Eugene Siegel)
5e585a0fc4 net: check for empty header before calling FillBlock (Eugene Siegel)
Pull request description:
This avoids an Assume crash if multiple blocktxn messages are received. The first call to `FillBlock` would make the header empty via `SetNull` and the call right before the second `FillBlock` would crash [here](689a321976/src/net_processing.cpp (L3333)) since `LookupBlockIndex` won't find anything. Fix that by checking for an empty header before the Assume.
ACKs for top commit:
instagibbs:
reACK 8b62647680
fjahr:
tACK 8b62647680
achow101:
ACK 8b62647680
mzumsande:
Code Review ACK 8b62647680
Tree-SHA512: d43a6f652161d4f7e6137f207a3e95259fc51509279d20347b1698c91179c39c8fcb75d2668b13a6b220f478a03578573208a415804be1d8843acb057fa1a73a
c767974811 clang-tidy: Fix critical warnings (Fabian Jahr)
54dc34ec22 index: Remove unused coinstatsindex recovery code (Fabian Jahr)
37c4fba1f4 index: Check BIP30 blocks when rewinding Coinstatsindex (Fabian Jahr)
51df9de8e5 doc: Add release note for 30469 (Fabian Jahr)
bb8d673183 test: Add coinstatsindex compatibility test (Fabian Jahr)
b2e8b64ddc index, refactor: Append blocks to coinstatsindex without db read (Fabian Jahr)
431a076ae6 index: Fix coinstatsindex overflow issue (Fabian Jahr)
84e813a02b index, refactor: DRY coinbase check (Fabian Jahr)
fab842b324 index, refactor: Rename ReverseBlock to RevertBlock (Fabian Jahr)
Pull request description:
Closes https://github.com/bitcoin/bitcoin/issues/26362
This continues the work that was started with #26426. It fixes the overflow issue by switching the tracked values that are in danger of overflowing from `CAmount` to `arith_uint256`.
The current approach opts for a simple solution to ensure compatibility with datadirs including the previous version of the index: The new version of the index goes into a separate location in the datadir (`index/coinstatsindex/` rather than `index/coinstats/` before, the new naming is more consistent with the naming of the other indexes). There is no explicit concept of versioning of the index which earlier versions of this PR had. Having the two different versions of the index in separate places allows for downgrading of the node without having to rebuild the index. However, there will be a warning printed in the logs if the new code (v30) detects the old index still being present. A future version could delete a left-over legacy index automatically.
The PR also includes several minor improvements but most notably it lets new entries be calculated and stored without needing to read any DB records.
ACKs for top commit:
achow101:
ACK c767974811
TheCharlatan:
ACK c767974811
mzumsande:
Tested / Code Review ACK c767974811
Tree-SHA512: 3fa4a19dd1a01c1b01390247bc9daa6871eece7c1899eac976e0cc21ede09c79c65f758d14daafc46a43c4ddd7055c85fb28ff03029132d48936b248639c6ab9
