ec4ec91d59 kernel: doc: explain return value for `btck_WriteBytes` callback (Sebastian Falbesoner)
Pull request description:
Note that this is the only callback type with a non-void return type. Probably it would make sense to document the parameters of callbacks as well on the long-term (Doxygen style?), but this IMHO the most critical missing documentation, where likely other bitcoinkernel users working with the C API could trip over too.
Background: I've been working on btck bindings for [Zig](https://ziglang.org/) for a while [1]. Overall I found the C API header `bitcoinkernel.h` very well-documented and to a large degree self-explanatory, but for implementing a `btck_WriteBytes` callback (needed for various `btck_..._to_bytes` serialization functions) I had to look into the [kernel implementation](e98d36715e/src/kernel/bitcoinkernel.cpp (L86)) to figure out what return value is expected.
[1] still not public and put on hold for the last few months due to lib(std)c++ build system / linking issues (needing ugly workarounds, hopefully improved with Zig's upcoming 0.16 release); now continued, hopefully ready to be published in a first presentable version soon(tm)
ACKs for top commit:
sedited:
ACK ec4ec91d59
alexanderwiederin:
ACK ec4ec91d59
stickies-v:
ACK ec4ec91d59
Tree-SHA512: aeea68474a04e0bc4d2421a0539a0bd717b0526f58c7379848a8bb8cb75a0fdf5c94bfcc226f28dd09b89c5fc368921d1d875893b86680e7c51d7b98f4ab749d
fadaa7db33 ci: Bump GHA actions versions (MarcoFalke)
Pull request description:
Looks like this was forgotten in the prior pull https://github.com/bitcoin/bitcoin/pull/34344#issuecomment-3769438233
ACKs for top commit:
fanquake:
ACK fadaa7db33
Tree-SHA512: bc3bc5b7ba275d7c48bd34fa0eaaac05942212369fc87be338b31c024ca736550a5ff64766c78912f9705e9f95ffedeae1eddfe2f95828350c7672ab2069713c
This allows external tooling (e.g. converters) to consume the output
directly, rather than having to write the dump to disk first and then
read it from there again.
Co-authored-by: Luke Dashjr <luke-jr+git@utopios.org>
4c07cf87e2 doc: document depends compiler configuration (will)
Pull request description:
Fixes: #33859
Previously one had to read the Makefile (and various *.mk configuration
files) to see how to correctly override CC and CXX when building native
depends packages.
Detail this in README.md to make it clearer.
ACKs for top commit:
maflcko:
review ACK 4c07cf87e2🛶
hebasto:
ACK 4c07cf87e2.
sedited:
ACK 4c07cf87e2
fanquake:
ACK 4c07cf87e2
Tree-SHA512: ca61087b7c232c74782602a28d914e7bb35d1469472bb7862941c0fdec2277bf1d0e6604d4058c319c6a7b2cd04a70b7f0d0afbbb847e5c3812c6afb0cf1cfb3
22335474d7 net: format peer+addr logs with `LogPeer` (Lőrinc)
e55ea534f7 test: add pre-`LogPeer` net log assertion (Lőrinc)
736b17c0f0 log: fix minor formatting in debug logs (Lőrinc)
9cf82bed32 log: show placeholders for missing peer fields (Lőrinc)
Pull request description:
This is an alternative to #34293, but aims to address the remaining logging inconsistencies more broadly.
It extends the example fixed there to every instance, restores the original separator behavior, applies it consistently via a single helper, and adds tests for `logips` (covering both current and new behavior).
### Problem
After #28521 centralized peer address logging into `CNode::LogIP()`, the original comma separator before `peeraddr=` was lost, resulting in inconsistent formatting across net (and recent private broadcast) logs.
Some lines also had double spaces, empty fields, or mismatched format specifiers.
### Fix
Introduces `CNode::LogPeer(bool)` which always emits `peer=<id>` and, when `-logips=1`, appends `, peeraddr=<addr>`. This eliminates hand-rolled separators and makes peer identification predictable.
Minor issues (double spaces, empty placeholders, format specifiers) are fixed along the way in separate commits.
### Reproducer
Run with `-debug=net -logips=1` and observe peer log lines now show `peer=<id>, peeraddr=<addr>` (comma-separated). The new assertion in `feature_logging.py` automates this check.
ACKs for top commit:
naiyoma:
ACK 22335474d7
vasild:
ACK 22335474d7
sedited:
ACK 22335474d7
Tree-SHA512: 562262a58c3042f139099ff4c41e3fc6a97505fe9603c2bf700a97fd0aa052954b47c14da0e50c1fc311db1ae6c04e6a92156c9b85e25c777a637b7766c1dafe
c6a6435ced wallet: remove `DBErrors::NEED_REWRITE` enum value (rkrux)
61039d72a5 wallet: remove unimplemented `RewriteDB` calls from SPKM (rkrux)
Pull request description:
ISTM that there is no implementation left of the `RewriteDB` method in any of the SPKMs, and thus, its call sites can be removed safely.
Also remove `DBErrors::NEED_REWRITE` enum value as its usage is outdated now.
<!--
*** 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 c6a6435ced
furszy:
ACK c6a6435ced
sedited:
ACK c6a6435ced
Tree-SHA512: 050d3115ad436eb7728716c897c8d23c6dd0c6cd7a018dc023896d301b126bae5ba89b684811226a0ca4045b393b612296aeab3b3b5dfb7ed0bf443fc1eaef41
79571b9181 threadpool: add ranged Submit overload (Andrew Toth)
Pull request description:
The current `ThreadPool::Submit` is not very efficient when we have a use case where we need to submit multiple tasks immediately. The `Submit` method must take the lock for each task, and notifies only a single worker thread. This will cause lock contention with the awakened worker thread trying to take the lock and the caller trying to submit the next task.
Introduce a `Submit` overload, which takes the lock once and submits a range of tasks, then notifies all worker threads after the lock is released.
This is needed for #31132 to be able to use `ThreadPool`.
ACKs for top commit:
l0rinc:
ACK 79571b9181
rkrux:
ACK 79571b9
sedited:
Re-ACK 79571b9181
willcl-ark:
ACK 79571b9181
Tree-SHA512: 1fbe0c150f01b9ea5be3459cd10b817045af52eaf6f14a1a298a68853890da4033c1b21bdc6f995bb55029fb4ab536e9dbf58d98e2e1e12b25298fa3470b4ba6
CC/CXX only override compilers for target (host) packages. Native
build tool packages (native_capnp, native_qt, etc.) use separate
build_CC/build_CXX variables, which default to gcc/g++ on Linux.
On systems without gcc (e.g. Nix, Chimera Linux), native package
builds fail unless build_CC/build_CXX are also set explicitly.
Document how to override both sets of compilers.
fafdb8f635 ci: Allow running iwyu ci in worktree (MarcoFalke)
fab73e213d ci: Reject unsafe execution of shell scripts (MarcoFalke)
Pull request description:
Currently, the iwyu CI fails to run in a git-worktree, or git-archive. This is due to the use of `git diff`.
Fix this by force-initializing a dummy git repo with a single dummy commit.
It may be possible to detect when `git diff` is not available in the directory, and only apply the fallback when needed, but the git history is not needed and it is easier to unconditionally apply the git init.
ACKs for top commit:
willcl-ark:
reACK fafdb8f635
hebasto:
ACK fafdb8f635, I have reviewed the code and it looks OK. Tested on Fedora 43.
sedited:
ACK fafdb8f635
Tree-SHA512: 572f1e2b9e215c2804095382498abb5b8636e3a49d5ba2a736b975e06afa2881d815b854a8a593d0f187c7c6b55034688e11f46d6814edfe7c29505197e80b18
b503768819 fuzz: register PeerManager in process_message(s) (Eugene Siegel)
Pull request description:
This lets CValidationInterface callbacks be hit (just `BlockChecked` using the corpus from qa-assets). Also remove no-op SyncWithValidationInterfaceQueue since there are no validation interfaces registered in ResetChainman.
ACKs for top commit:
marcofleon:
code review ACK b503768819
dergoegge:
utACK b503768819
Tree-SHA512: 51c0c9a3396ee898b1dce2c65c2fc7b61ea6d04342d181b1b60be1677bc0c2828b9d970673f67501e3579ae002392cd5f0e3268aae1b216ff332e2654fd1fe14
Rather than looking for /translations, which might not exist (it doesn't
in a recent brew installed qt on macOS). i.e:
```bash
ls /opt/homebrew/opt/qtbase/share/qt
doc
libexec
metatypes
mkspecs
modules
plugins
sbom
```
Calling shutil.make_archive(), does not preserve symlinks when using the
zip format, see https://github.com/python/cpython/issues/139679.
Call `zip` using subprocess instead. This code is only run when using a
macos machine, and I think it's safe to assume that zip is available, same
as codesign, and all other tools we call in this script.
02d047fd5b refactor: add overflow-safe `CeilDiv` helper (Lőrinc)
Pull request description:
### Problem
The codebase has many open-coded ceiling-division expressions (for example `(x+y-1)/y`) scattered across files.
These are less readable, duplicate logic, and can be overflow-prone in edge cases.
### Fix
Introduce a small overflow-safe integer helper, `CeilDiv()`, and use it in existing **unsigned** callsites where the conversion is straightforward and noise-free.
### What this PR does
* Adds `CeilDiv()` to `src/util/overflow.h` for unsigned integral inputs.
* Keeps the precondition check `assert(divisor > 0)`.
* Replaces selected unsigned ceiling-division expressions with `CeilDiv(...)`.
* Adds focused unit tests in `src/test/util_tests.cpp` for the migrated patterns.
---
This is a pure refactor with no intended behavioral change.
Signed arithmetic callsites are intentionally left unchanged in this PR.
This PR changed a few more things originally but based on feedback reverted to the simplest cases only.
ACKs for top commit:
rustaceanrob:
ACK 02d047fd5b
hodlinator:
ACK 02d047fd5b
sedited:
ACK 02d047fd5b
Tree-SHA512: b09336031f487e6ce289822e0ffeb8cfc8cfe8a2f4f3f49470748dfbd0a6cbab97498674cb8686dd2bd4ab6dd0b79cfdf2da00041fee12d109892e1bc5dde0ff
0ebc6891e2 depends: delete Boost extra files (fanquake)
168997e9b5 depends: disable Qt sbom generation (fanquake)
Pull request description:
1 followup to #34650, to disable sbom generation.
1 commit to Boost, to cleanup `.natvis` files that end up in share.
ACKs for top commit:
hebasto:
ACK 0ebc6891e2, tested on Ubuntu 25.10.
Tree-SHA512: 728b51d798a30c54df915564446a7a8648eb4fc27adb8c18b8202df506e2ff61e74516cfe4d6af1af72279255fc75fe14cb43403632a978637781d59eb11fc0f
af041c4057 wallet: Always rewrite tx records during migration (Ava Chow)
Pull request description:
Since loading a wallet may change some parts of tx records (e.g. adding nOrderPos), we should rewrite the records instead of copying them so that the automatic upgrade does not need to be performed again when the wallet is loaded.
This is useful for future PRs I'm working on where we need to be sure about what data exists in a tx record in descriptor wallets.
ACKs for top commit:
rkrux:
lgtm ACK af041c4057
Eunovo:
ACK af041c4057
furszy:
ACK af041c4057
Tree-SHA512: 96984e46fe110a7749495965587b88a94d1297794e5d8b632b89dcdb2ebc1cd3070cd4458cf8e1b4ec0c76c4e56994f21867c44fa74f25739cbd9c0c911732a6
d339884f1d bench: add script verification benchmark for P2TR key path spends (Sebastian Falbesoner)
dd93362a1d bench: simplify script verification benchmark, generalize signing (Sebastian Falbesoner)
Pull request description:
We currently benchmark Schnorr signature verification only in the context of block validation ([`ConectBlock*`](8bb77f348e/src/bench/connectblock.cpp (L107)) benchmarks), but not individually for single inputs [1]. This PR adds a script verification benchmark for P2TR key path spends accordingly, by generalizing the already existing one for P2WPKH spends.
This should make it easier to quantify potential performance improvements like e.g. https://github.com/bitcoin-core/secp256k1/pull/1777, which allows to plug in our HW-optimized SHA256 functions to be used in libsecp256k1 (see the linked example commit f68bef06d9). IIRC from last CoreDev, the main speedup from this is expected for ECDSA signing though (as this involves quite a lot of hashing), but it still makes sense to have verification benchmarks available for both signature types as well.
(An alternative way could be to add benchmarks for the signing/verifying member functions `CKey::Sign{,Schnorr}`, `CPubKey::Verify` and `XOnlyPubKey::VerifySchnorr` directly, if we prefer that.)
[1] this claim can be practically verified by putting an `assert(false);` into `XOnlyPubKey::VerifySchnorr`: the three benchmarks crashing are `ConnectBlockAllSchnorr`, `ConnectBlockMixedEcdsaSchnorr` and `SignTransactionSchnorr` (as signing includes verification)
ACKs for top commit:
furszy:
ACK d339884f1d
sedited:
Re-ACK d339884f1d
w0xlt:
ACK d339884f1d
Tree-SHA512: efd20444984bdf1dab4d3d876fdbe2a3a838d7cebc0e31e26683009b81afe4dab8611e2c28c87e46fe8b7e305895c93e461b7934a5aaf293f72b19488b9cec60
73e3853110 test: add test for rebroadcast of transaction received via p2p (Martin Zumsande)
Pull request description:
The wallet doesn't only rebroadcast transactions it created, but also relevant transactions received via p2p.
Since this is not self-evident, add test coverage for it.
ACKs for top commit:
maflcko:
re-ACK 73e3853110🦌
vasild:
ACK 73e3853110
furszy:
ACK 73e3853110
danielabrozzoni:
tACK 73e3853110
Tree-SHA512: b5249bb5eb6a124a98030816319aa4364d7aee9c28ee28750ebba5fc8d6bfc9d7960a97ed638611f4560e051760ec4a7a75d302a4cb106dbfadfe11adc604f22
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
Adds a special case where if the elapsed time during measurement of DKF
performance is 0, the default derive iterations are used so that
behavior is stable for testing and benchmarks.
d67c8ed788 clusterlin: update SFL comments for deterministic order (Pieter Wuille)
Pull request description:
This was missed in #34257.
ACKs for top commit:
marcofleon:
ACK d67c8ed788
achow101:
ACK d67c8ed788
Tree-SHA512: e381da09eb686e69c0fb32cc16dff7ae108f13ecb07bc1466f504a7b4c773d4557599c659f6d2e9ba0037ed89179c2e187f383a917e0242c4c795cf6e1c9cec6
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
Move the first `protected` block (struct Arg, cs_args, m_settings, and
all other member variables) to `private`. Only `ReadConfigStream` and
`ReadConfigString` remain `protected` for test access.
Changes:
- Move `ReadConfigString` from `TestArgsManager` into `ArgsManager`
itself (declared in args.h, defined in config.cpp) so tests no longer
need direct access to `cs_args` or `m_settings` for config parsing.
- Replace test-only `SetNetworkOnlyArg` helper with the existing
`NETWORK_ONLY` flag passed through `SetupArgs`/`AddArg`.
- Remove `TestArgsManager` constructor that cleared
`m_network_only_args`.
- Remove `using` declarations for `cs_args`, `m_settings`, `GetSetting`,
and `GetSettingsList` from `TestArgsManager`.
- Clear `m_config_sections` in `ClearArgs()`.
Co-authored-by: Anthony Towns <aj@erisian.com.au>
Replace the RecursiveMutex with a plain Mutex now that all recursive
lock acquisitions have been eliminated in the preceding commits.
Add EXCLUSIVE_LOCKS_REQUIRED(!cs_args) negative capability annotations
to all public and protected methods that acquire cs_args, following the
pattern established in prior RecursiveMutex conversions (e.g. CAddrMan,
CBlockPolicyEstimator).
Restructure argsman tests to use scoped LOCK(cs_args) blocks only
around direct protected member access (m_settings, m_network), keeping
public method calls outside lock scopes. This avoids recursive lock
acquisitions that would deadlock with a non-recursive Mutex.
- util_ParseParameters: scope locks around m_settings checks
- util_GetBoolArg: scope lock around m_settings size check
- util_ReadConfigStream: scope lock around m_settings checks
- util_GetArg: scope lock around m_settings writes
- util_ArgsMerge: use SelectConfigNetwork() instead of m_network
- util_ChainMerge: remove unnecessary lock
Extract GetSetting_(), GetArgFlags_(), and GetPathArg_() as private
lock-held helpers with EXCLUSIVE_LOCKS_REQUIRED(cs_args) annotations.
Public methods delegate to these after acquiring the lock.
Annotate GetDataDir() with EXCLUSIVE_LOCKS_REQUIRED(cs_args) and move
its lock acquisition into GetDataDirBase()/GetDataDirNet().
Annotate logArgsPrefix() with EXCLUSIVE_LOCKS_REQUIRED(cs_args).
This is a pure refactoring with no behavior change, preparing for
the conversion of cs_args from RecursiveMutex to Mutex.
9f3752c437 ci: use latest versions of lint deps (fanquake)
Pull request description:
Use the latest available versions, except for LIEF, which is changed with Guix.
ACKs for top commit:
hebasto:
ACK 9f3752c437, I've verified the releases against https://pypi.org and https://github.com/becheran/mlc.
Tree-SHA512: e6ed79bb7dc8601ed0708eb7b53cbf4cf843b69829c073c41e9d97be690b4b2bf9ea5ecf250e05cbacba4ad35df06aa3e2cb2ff319145a34e1a7831cf182ec21
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
