🚀 fanquake merged a pull request: "doc: add release note for #27432 (utxo-to-sqlite tool)"
(https://github.com/bitcoin/bitcoin/pull/31879)

📝 hebasto opened a pull request: "cmake: Add optional source files to libraries directly"
(https://github.com/bitcoin/bitcoin/pull/31880)
This PR provides an extended alternative to https://github.com/bitcoin/bitcoin/pull/31268, featuring the following differences:
1. A new `TargetSourcesWithCompileOptions` module has been introduced to minimise code verbosity and enhance readability.
2. In addition to changes for `bitcoin_crypto` and `crc32c`, the build script for the `minisketch` library has been reworked. In particular, [this comment](https://github.com/bitcoin/bitcoin/pull/30911#discussion_r1953081930) has been addressed and
...

💬 hebasto commented on pull request "cmake: add optional source files to bitcoin_crypto and crc32c directly":
(https://github.com/bitcoin/bitcoin/pull/31268#issuecomment-2661419077)
https://github.com/bitcoin/bitcoin/pull/31880 provides an extended alternative to this PR.

Since this one has already been reviewed, I'm OK with merging it as is.

⚠️ hebasto opened an issue: "qa: `wallet_importdescriptors` failure "TypeError: 'bool' object is not subscriptable""
(https://github.com/bitcoin/bitcoin/issues/31881)
From https://github.com/bitcoin/bitcoin/actions/runs/13355177559/job/37296904714:
```
244/317 - wallet_importdescriptors.py --descriptors failed, Duration: 13 s

stdout:
2025-02-16T12:59:56.602000Z TestFramework (INFO): PRNG seed is: 3316204795374696824
2025-02-16T12:59:56.602000Z TestFramework (INFO): Initializing test directory /Users/runner/work/bitcoin/bitcoin/ci/scratch/test_runner/test_runner_₿_🏃_20250216_125556/wallet_importdescriptors_99
2025-02-16T12:59:57.273000Z TestFramework (INFO):
...

💬 s373nZ commented on pull request "cmake: Add `libbitcoinkernel` target":
(https://github.com/bitcoin/bitcoin/pull/31869#issuecomment-2661469280)
ACK https://github.com/bitcoin/bitcoin/commit/3a914ab96bdeb70cdf848dd74deda5a80d0a7f78

Tested compilation as per the usage example in the description with the same results -- no rebuild between targets `libbitcoinkernel` and `bitcoinkernel`. Kernel library is installable via `--component libbitcoinkernel`, but `--component bitcoinkernel` is not recognized. Works as expected.

While testing, I learned to generate with a clean `build` directory, or pass `--fresh` so that `-DBUILD_KERNEL_LIB`
...

⚠️ GregTonoski opened an issue: "bitcoind shouldn't fail to progress with synchronization: endless [leveldb] Generated table... logs"
(https://github.com/bitcoin/bitcoin/issues/31882)
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current behaviour

bitcoind doesn't progress with synchronization despite approx. 4 months lag, doesn't consume much CPU or RAM, uses disk IO, produces large amount of logs like e.g. `[leveldb] Generated table #3982690@4: 31588 keys, 2162389 bytes` for hours (there was a test for more than 8 hours).

### Expected behaviour

bitcoind finishes synchronization in an hour or so.

### Steps to reproduce

Precondi
...

⚠️ instagibbs opened an issue: "SignatureCreator should supply auxiliary data argument for additional bip340 signature security"
(https://github.com/bitcoin/bitcoin/issues/31883)
https://github.com/bitcoin/bitcoin/blob/db36a92c02b83f2e6477a5a55fc061319f7cc6a3/src/script/sign.cpp#L87

It's additive and should be a pretty easy lift?

💬 l0rinc commented on issue "bitcoind shouldn't fail to progress with synchronization: endless [leveldb] Generated table ... logs":
(https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2661499659)
> bitcoind finishes synchronization in an hour or so.

That alone would require a 1.5 Gbps download speed - and even then, we're not there yet (especially with such a resource-constrained setup).
But you could give [AssumeUTXO](https://bitcoinops.org/en/topics/assumeutxo) a try to see if it helps - this will jump the process ahead to 95% complete and validate the remaining blocks afterward.

> bitcoind doesn't progress with synchronization

The attached `iostats` and `debug.log` indicate that th
...

📝 hebasto opened a pull request: "cmake: Make implicit `libbitcoinkernel` dependencies explicit"
(https://github.com/bitcoin/bitcoin/pull/31884)
This PR fixes two regressions introduced in https://github.com/bitcoin/bitcoin/pull/30911.

For example, on the master branch @ db36a92c02b83f2e6477a5a55fc061319f7cc6a3:
- first regression:
```
$ cmake -B build -G "Ninja" -DBUILD_UTIL_CHAINSTATE=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/home/hebasto/INSTALL
$ cmake --build build -j $(nproc) -t bitcoinkernel
$ cmake --install build --component bitcoinkernel
- Install configuration: "RelWithDebInfo"
CMake Error at build/src/kerne
...

💬 l0rinc commented on pull request "util: detect and warn when using exFAT on MacOS":
(https://github.com/bitcoin/bitcoin/pull/31453#discussion_r1957361090)
Even when there isn't any corruption, maybe it would help to warn when [SD cards are used for storage](https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2661499659)

💬 GregTonoski commented on issue "bitcoind shouldn't fail to progress with synchronization: endless [leveldb] Generated table ... logs":
(https://github.com/bitcoin/bitcoin/issues/31882#issuecomment-2661517113)
> That alone would require a 1.5 Gbps download speed - and even then, we're not there yet (especially with such a resource-constrained setup).

Disagree with the 1.5 Gbps download speed requirement. There isn't initial block download scenario here. There are 4 months of blocks data that need to be downloaded here.

👍 TheCharlatan approved a pull request: "cmake: Add `libbitcoinkernel` target"
(https://github.com/bitcoin/bitcoin/pull/31869#pullrequestreview-2619681387)
ACK 3a914ab96bdeb70cdf848dd74deda5a80d0a7f78

💬 tnndbtc commented on issue "Fuzz: Runtime errors when running fuzz tests on MacOs":
(https://github.com/bitcoin/bitcoin/issues/31591#issuecomment-2661542109)
@Prabhat1308 I don't have an answer to fix the incompatibility issue between the native llvm@16 and the customized llvm@18. However, from the error message itself, it looks like the cause is the discrepancy between llvm@16 and llvm@18.

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /opt/homebrew/opt/llvm@18/bin/../include/c++/v1/variant:495:12
/Users/prabhatverma/projects/bitcoin/src/rpc/server.h:100:15: runtime error: call to function getblockchaininfo() through pointer to incorrec
...

🤔 hebasto reviewed a pull request: "multiprocess: Add libmultiprocess git subtree"
(https://github.com/bitcoin/bitcoin/pull/31741#pullrequestreview-2619682385)
96d3b2a0bb0c267569162b055ca306f709ec0b4e "cmake: Fix fuzzer "multiple definition of `main'" errors"

cc @dergoegge

💬 tnndbtc commented on issue "Fuzz: Runtime errors when running fuzz tests on MacOs":
(https://github.com/bitcoin/bitcoin/issues/31591#issuecomment-2661545962)
Also, from llvm@18, /opt/homebrew/opt/llvm@18/bin/../include/c++/v1/variant:495

struct __base {
template <class _Visitor, class... _Vs>
_LIBCPP_HIDE_FROM_ABI static constexpr decltype(auto)
__visit_alt_at(size_t __index, _Visitor&& __visitor, _Vs&&... __vs) {
constexpr auto __fdiagonal = __make_fdiagonal<_Visitor&&, decltype(std::forward<_Vs>(__vs).__as_base())...>();
return __fdiagonal[__index](**_std_**::forward<_Visitor>(__visitor), std::forward<_Vs>(__vs).__as_base()...);
}
...

📝 mabu44 opened a pull request: "test: chain reorg for coinstatsindex"
(https://github.com/bitcoin/bitcoin/pull/31885)
Improved coverage of src/index/coinstatsindex.cpp with a new unit test that simulate a reorg of the chain (one block deep).

📝 jonatack opened a pull request: "cli: return local services in -netinfo"
(https://github.com/bitcoin/bitcoin/pull/31886)
Add local services info to -netinfo dashboard that already provides this info for each of the peer connections

default report with `bitcoin-cli -netinfo`

```
Bitcoin Core client v28.99.0 - server 70016/Satoshi:28.99.0/

ipv4 ipv6 onion i2p cjdns total block manual
in 0 0 12 8 0 20
out 6 0 4 3 2 15 3 4
total 6 0 16 11 2 35

Local services: n
...

💬 hebasto commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2661571168)
> macOS intel is happy too, no more right-clickery.

`bitcoind` as well?

Files downloaded via Safari seem to inevitably receive the `com.apple.quarantine` attribute. This is easily resolved for GUI applications but can be challenging for CLI tools.

📝 jonatack opened a pull request: "refactor: CLI cleanups"
(https://github.com/bitcoin/bitcoin/pull/31887)
These are simple and have been accumulating over the past few years.

Each is described in its commit message.

💬 purpleKarrot commented on pull request "cmake: add optional source files to bitcoin_crypto and crc32c directly":
(https://github.com/bitcoin/bitcoin/pull/31268#issuecomment-2661591125)
> Agree with @hebasto that it'd be more straightforward to use `target_compile_options()`, if only for the sake of avoiding future footguns.

Very generally in software development, future footguns are avoided by **narrow contracts**.

I understand the desire of narrowing the contract between the authors and CMake. One may want to avoid advanced features like setting properties on individual source files. Applying this approach consistently, one should also avoid commands like `target_compil
...