⚠️ fanquake opened an issue: "lint: Qt exclusions are missing files"
(https://github.com/bitcoin/bitcoin/issues/31801)
The `tidy` job is meant to skip linting autogenerated Qt files:

https://github.com/bitcoin/bitcoin/blob/b9c241804c0726737a0eb80f6f27e94ef341b42e/ci/test/03_test_script.sh#L173-L174

however it is currently linting and include checking CMake generated files. i.e (https://cirrus-ci.com/task/5702771191578624?logs=ci#L3386):
```bash
[09:40:22.499] [ 20/666][2.6s] clang-tidy-19 -p=/ci_container_base/ci/scratch/build-x86_64-pc-linux-gnu -quiet -load=/tidy-build/libbitcoin-tidy.so /ci_container_base/c
...

💬 ryanofsky commented on pull request "multiprocess: Add libmultiprocess git subtree":
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2637172003)
@luke-jr Can you say why you think manually cloning the repository might be better? I can't see any upsides to that, and the problem with just cloning it is it would put everybody at risk because arbitrary changes could be pushed to the external repository and we don't want anybody to run arbitrary code, only code that we have reviewed and pinned at a specific git revision.

Right now we are pinning this revision with the depends system, and this PR is just moving the pinning from the depends
...

💬 fjahr commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1943154676)
Ok, granted I didn't study the whole fuzz test before I wrote this. I think it can still be done but I will try to address this in a small follow-up so this doesn't hold up this PR.

💬 fjahr commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#issuecomment-2637222454)
Code review ACK 386eecff5f14d508688e6e7374b67cb54aaa7249

Further editing of the release notes can be done as part of the actual release process.

💬 fanquake commented on pull request "tracing: network connection tracepoints":
(https://github.com/bitcoin/bitcoin/pull/25832#discussion_r1943167490)
I think this can be fixed in a follow up pre 29.x.

💬 murchandamus commented on pull request "test: Add expected result assertions":
(https://github.com/bitcoin/bitcoin/pull/31656#issuecomment-2637229838)
ACK 1801e6520569b8c7b1129cdc8467682a4b8e601c

Sure, this doesn’t hurt and might make it more obvious what CoinGrinder does here. It might be good to also adjust the title of this test for CoinGrinder to "3) Test selection when some selections with sufficient funds would exceed the maximum allowed weight" or similar.

> The goal of the test is to show that a minimal weight selection of UTXOs is returned by coin-grinder.

Not really. The weight-optimality of CoinGrinder solutions is shown pe
...

👋 hebasto's pull request is ready for review: "depends: Avoid using the `-ffile-prefix-map` compiler option"
(https://github.com/bitcoin/bitcoin/pull/31800)

💬 hebasto commented on pull request "depends: Override default build type for `libevent`":
(https://github.com/bitcoin/bitcoin/pull/31661#discussion_r1943172637)
> Something that should probably be followed up with, given that most coverage builds are using depends, is the fact that `-ffile-prefix-map` keeps being hardcoded into depends, while CMakelists.txt says:
>
> ```shell
> # Avoiding the `-ffile-prefix-map` compiler option because it implies
> # `-fcoverage-prefix-map` on Clang or `-fprofile-prefix-map` on GCC,
> # which can cause issues with coverage builds,
> ```
>
> Might be less of an issue given these are deps but it's at least incon
...

💬 Sjors commented on pull request "multiprocess: Add libmultiprocess git subtree":
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2637244937)
Unless I'm missing something, I don't think @luke-jr's critique is specific to libmultiprocess, but rather his consistent position on including libraries.

I think we should subtree libmultiprocess the same way we do with the other subtrees (to the extend possible). We can revisit that entire process later imo.

🚀 fanquake merged a pull request: "tracing: network connection tracepoints"
(https://github.com/bitcoin/bitcoin/pull/25832)

💬 maflcko commented on issue "lint: Qt exclusions are missing files":
(https://github.com/bitcoin/bitcoin/issues/31801#issuecomment-2637274149)
I guess longer term this may be fixed by https://github.com/bitcoin/bitcoin/pull/31308 , but I haven't confirmed this.

💬 Sjors commented on pull request "wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases":
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1943202181)
The solvables wallet itself is watch-only, so I think `iswatchonly` should be `true`?

💬 maflcko commented on issue "build: compiler flags in linker flags output":
(https://github.com/bitcoin/bitcoin/issues/31487#issuecomment-2637285799)
Maybe this can be closed, per https://github.com/bitcoin/bitcoin/pull/31726#issuecomment-2611841905 ? In any case, a debug output shouldn't be a blocker for the 29.x milestone.

💬 maflcko commented on pull request "ci: Replace `CMAKE_CXX_FLAGS` with `APPEND_CXXFLAGS`":
(https://github.com/bitcoin/bitcoin/pull/31726#discussion_r1943212167)
thx, could submit as a fresh pull?

✅ fanquake closed an issue: "build: compiler flags in linker flags output"
(https://github.com/bitcoin/bitcoin/issues/31487)

💬 fanquake commented on issue "build: compiler flags in linker flags output":
(https://github.com/bitcoin/bitcoin/issues/31487#issuecomment-2637302626)
Yea I think this is just going to be the new normal.

💬 Sjors commented on pull request "wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases":
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1943215423)
I think there was an earlier bugfix PR / issue around this, but I can't find it.

💬 ajtowns commented on pull request "rpc, logging: return "verificationprogress" of 1 when up to date":
(https://github.com/bitcoin/bitcoin/pull/31177#issuecomment-2637310051)
Given that we do headers sync first these days, would it make sense to switch to reporting:

* verificationprogress = just blocks/headers
* headerrecency = max(0, now() - timestamp of best header)

Normally, verificationprogress will be 1.0; dropping to ~0.9999988 briefly when a new header comes in, and headerrecency will tend to be in the ~10 minute range. OTOH, if you're in IBD, then verificationprogress will report how far through validating the blocks you have headers for; and if you'
...

💬 ryanofsky commented on pull request "multiprocess: Add libmultiprocess git subtree":
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2637351868)
> Unless I'm missing something, I don't think @luke-jr's critique is specific to libmultiprocess, but rather his consistent position on including libraries.

I see this but I think I actually agree with (or at least sympathize with) Luke's position on libraries, and am trying to ensure more clean integration with this library than other libraries that we depend on like leveldb, univalue, libevent. This PR is not forking the ilbrary or make making local changes to it. It is not replacing its bu
...

📝 Sjors opened a pull request: "Add bitcoin-{node,gui} to release binaries for IPC"
(https://github.com/bitcoin/bitcoin/pull/31802)
Have depends make libmultiprocess by default, which has the effect of including it in the release binaries. Except for Windows and OpenBSD which are not supported yet, the latter due to a fairly trivial upstream issue.

The initial main use case is to enable experimental support for the Mining IPC interface. A working example of a Stratum v2 Template Provider client using this interface can be found here: https://github.com/Sjors/bitcoin/pull/48.

Additionally the `bitcoin-node` and `bitcoi
...