👍 vasild approved a pull request: "txgraph: use enum Level instead of bool main_only"
(https://github.com/bitcoin/bitcoin/pull/33354#pullrequestreview-3205037327)
ACK b9af83e72c60c1ee71251cf9f3dbae0ffccbe305

Passing enum values with meaningful names seems better and more readable than passing `true` / `false` or omitting the argument.

💬 vasild commented on pull request "txgraph: use enum Level instead of bool main_only":
(https://github.com/bitcoin/bitcoin/pull/33354#discussion_r2335974694)
Can be written as:

```cpp
for (auto level : { TxGraph::Level::TOP, TxGraph::Level::MAIN }) {
```

💬 rkrux commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2336149483)
Didn't intend to suggest fixing it in this PR, instead highlighting an issue that could probably be fixed by the other PR if/when it's merged.

💬 Eunovo commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2336183930)
https://github.com/bitcoin/bitcoin/pull/33336/commits/64ba2821b5a55aa6d51fbb7a16470d4f7c41c92e:
I believe you now need to add `GUARDED_BY(::cs_main)` here to use Clang's Thread Safety Analysis

💬 fanquake commented on pull request "guix: build for Linux HOSTS with `-static-libgcc`":
(https://github.com/bitcoin/bitcoin/pull/33181#issuecomment-3274322377)
@theuni fixed the approach.

Guix Build:
```bash
5141913f22cb29c0ca33940885558eb87c97cb59a427ede1862086276934bfc4 guix-build-96917d3d2ffa/output/aarch64-linux-gnu/SHA256SUMS.part
05ea65e57ef36c7dc24c042001b297ff9a0ddf50e12da8d6f2b298cb8801725d guix-build-96917d3d2ffa/output/aarch64-linux-gnu/bitcoin-96917d3d2ffa-aarch64-linux-gnu-debug.tar.gz
0f1a7b1fcd1719b916d3527b545eb959cd909692810be29a1ae20f5e4c4834c8 guix-build-96917d3d2ffa/output/aarch64-linux-gnu/bitcoin-96917d3d2ffa-aarch64-lin
...

💬 Raimo33 commented on pull request "node: optimize CBlockIndexWorkComparator":
(https://github.com/bitcoin/bitcoin/pull/33334#discussion_r2336380536)
https://godbolt.org/z/6TjP137z1

Looks like the current version wins both on x86 and arm, but I'm no assembly expert.

👍 hebasto approved a pull request: "Avoid pathological QT text/markdown behavior..."
(https://github.com/bitcoin-core/gui/pull/886#pullrequestreview-3205692804)
ACK 6a371b70c87ad6b763c89384562fce8549f37434.

🚀 hebasto merged a pull request: "Avoid pathological QT text/markdown behavior..."
(https://github.com/bitcoin-core/gui/pull/886)

✅ hebasto closed an issue: "Copying output from console causes large mem usage/OOM"
(https://github.com/bitcoin-core/gui/issues/887)

💬 hebasto commented on pull request "Avoid pathological QT text/markdown behavior...":
(https://github.com/bitcoin-core/gui/pull/886#issuecomment-3274536092)
@fanquake

Backport to 30.x?

💬 TheCharlatan commented on pull request "multiprocess: Don't require bitcoin -m argument when IPC options are used":
(https://github.com/bitcoin/bitcoin/pull/33229#discussion_r2336447807)
I'm a bit confused about this first commit. What exactly is it supposed to fix? FWIW the `-help` for `bitcoin-node` is still:
```
./build_dev_mode_clang/bin/bitcoin-node -help | head -n 12 PIPE|0 ✔ 13:28:55
Bitcoin Core daemon version v30.99.0-2c8a478db4b8

The Bitcoin Core daemon (bitcoind) is a headless program that connects to the Bitcoin network to validate and relay transactions and blocks, as well as rela
...

💬 willcl-ark commented on issue "ci: derived LLVM version too new":
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274539118)
This appears to have been tagged 3 hours ago, so I think we can close this?

https://github.com/llvm/llvm-project/tags

💬 fanquake commented on issue "ci: derived LLVM version too new":
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274547337)
Yea tag exists, but the potential for it to be broken still the same for every new release.

💬 willcl-ark commented on issue "ci: derived LLVM version too new":
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274559080)
Because they have an apt packaged version for a while before a GH tag?

Is there anything else we can do about that, other than make sure we only run the latest (GH) tag, rather then the most bleeding-edge apt package?

💬 fanquake commented on pull request "guix: build for Linux HOSTS with `-static-libgcc`":
(https://github.com/bitcoin/bitcoin/pull/33181#issuecomment-3274577287)
Added dropping libatomic from `symbol-check.py`.

📝 fanquake opened a pull request: "[30.0] rc2 backports"
(https://github.com/bitcoin/bitcoin/pull/33356)
Backports:
* https://github.com/bitcoin-core/gui/pull/886

💬 fanquake commented on pull request "Avoid pathological QT text/markdown behavior...":
(https://github.com/bitcoin-core/gui/pull/886#issuecomment-3274585088)
Backported to 30.x in https://github.com/bitcoin/bitcoin/pull/33356.

💬 ryanofsky commented on pull request "multiprocess: Don't require bitcoin -m argument when IPC options are used":
(https://github.com/bitcoin/bitcoin/pull/33229#discussion_r2336488629)
> I'm a bit confused about this first commit. What exactly is it supposed to fix?

Just to clarify here (I can also update the commit message) this first commit adds the binary name to `-version` output (`-help` output may be different) as a way of giving the functional test an easy way to detect whether correct binary was called.

💬 fanquake commented on issue "ci: derived LLVM version too new":
(https://github.com/bitcoin/bitcoin/issues/33345#issuecomment-3274603532)
I think just using the a (recent) tag is fine, and avoids this issue entirely, rather than trying to match the `libcxx` build to whichever point release of Clang is being installed via apt.

💬 stickies-v commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336501679)
[C23 compiler support](https://en.cppreference.com/w/c/compiler_support/23.html) is still early and limited, but [typed enums](https://open-std.org/JTC1/SC22/WG14/www/docs/n3030.htm) would offer increased type safety to users that want it?

```C
/* C23-aware enum definitions */
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 202311L && !defined(__cplusplus)
/**
* For C23 and later, use a strongly-typed enum. This creates a distinct type
* which is not implicitly convert
...