💬 vasild commented on pull request "rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats'":
(https://github.com/bitcoin/bitcoin/pull/29418#issuecomment-3273777995)
`87d3d640e6...7d4e82c0bb`: remove leading `\n` from RPC help

💬 fanquake commented on pull request "guix: update time-machine to 5cb84f2013c5b1e48a7d0e617032266f1e6059e2":
(https://github.com/bitcoin/bitcoin/pull/33185#issuecomment-3273948331)
Guix Build:
```bash
52029a242fe86a7fdb513a98a9337bb7b0637d6bf4a768b6545e31b0c461ba43 guix-build-ee66bfacf03e/output/aarch64-linux-gnu/SHA256SUMS.part
de6039a3f5a361d2ddd199a1dc29180bb6806107f6bc1e0e2eff31f1a0695705 guix-build-ee66bfacf03e/output/aarch64-linux-gnu/bitcoin-ee66bfacf03e-aarch64-linux-gnu-debug.tar.gz
05ebf22be33a9ae38a736b7470bf344689909c3f8a64fb201995f98906eb0e92 guix-build-ee66bfacf03e/output/aarch64-linux-gnu/bitcoin-ee66bfacf03e-aarch64-linux-gnu.tar.gz
6d5022485d0c4546
...

💬 TheCharlatan commented on pull request "kernel: Separate UTXO set access from validation functions":
(https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-3273948882)
My hesitation was mostly about re-using the coins cache as is. In my opinion it is the wrong data structure to use in this case. Potential clients of the kernel are often capable of supplying the coins in order as consumed by a transaction's inputs. Requiring these to be stored in a map seems wrong. I.e. if a utreexo client has all the leaf data to go with a transaction, it should not have to use a less efficient data structure that consumes more memory to pass in the coins. But maybe we have to
...

💬 stickies-v commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336038391)
> How is the typedef used?

As in the diff I shared (https://github.com/stickies-v/bitcoin/commit/1880fba34c32ee4b9fe350f062dfbc27aa3db181), everything else stays the same:
- consumers use the typedef to define the size of enums, e.g. `enum class ChainType : btck_ChainType {`
- API only deals with the typedefs, e.g. `btck_ChainParameters* btck_chain_parameters_create(const btck_ChainType chain_type)`, so even though the user _can_ abuse the `Value` enum, they would be going against the int
...

💬 stickies-v commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336084393)
Actually, anonymous enums would make more sense than named ones:

```cpp
typedef uint8_t btck_ChainType;
enum {
btck_ChainType_MAINNET = 0,
btck_ChainType_TESTNET = 1,
btck_ChainType_TESTNET_4 = 2,
btck_ChainType_SIGNET = 3,
btck_ChainType_REGTEST = 4
};
```

💬 purpleKarrot commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2336089748)
@stickies-v, this is how I currently implement the python bindings for flags: https://github.com/purpleKarrot/btck/blob/master/bindings/python/src/verification_flags.c

This is how they are combined: https://github.com/purpleKarrot/btck/blob/master/test/python/test_script.py#L18

How do you make sure that only binary operators can be used on flags when you bind them with ctypes/clang2py? If the answer is "not", then I would stay away from binding generators and stick to handwritten language
...

👍 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?