💬 maflcko commented on issue "Networking tests fail on emulated big-endian systems":
(https://github.com/bitcoin/bitcoin/issues/31812#issuecomment-2940340520)
> > the `interface_bitcoin_cli` tests are likely also related to the IPv6 big-endian failures:
>
> What are the exact steps to reproduce? Ideally, starting from a fresh install? I guess it happens on macOS and on the Hetzner box equally?

cc @l0rinc

💬 maflcko commented on pull request "depends: drop `ltcg` for Windows Qt":
(https://github.com/bitcoin/bitcoin/pull/32496#issuecomment-2940365526)
lgtm ACK 9653ebc053602a30aee6d8676913306d615841cf

💬 maflcko commented on pull request "fuzz: Add target for coins database":
(https://github.com/bitcoin/bitcoin/pull/32602#issuecomment-2940437069)
lgtm ACK cfc42ae5b7ef6d3892907cfe36dc3ae923495d37

💬 marcofleon commented on pull request "refactor: Convert GenTxid to `std::variant`":
(https://github.com/bitcoin/bitcoin/pull/32631#issuecomment-2940454325)
Thanks for reviewing @stickies-v! I took your suggestion for mempool's `exists`, `info`, and `info_for_relay`. These are all fairly simple functions where I agree that the separate txid/wtxid overloads make the code clearer.

I looked at `txrequest` and `txdownloadman_impl` to see where txid and wtxid could be used internally in place of the variant, but it seems to be a less straightfoward refactor. Maybe `AddTxAnnouncement` could be a good candidate? If you see something that I'm missing (or
...

💬 marcofleon commented on pull request "refactor: Convert GenTxid to `std::variant`":
(https://github.com/bitcoin/bitcoin/pull/32631#discussion_r2126881339)
done

💬 marcofleon commented on pull request "refactor: Convert GenTxid to `std::variant`":
(https://github.com/bitcoin/bitcoin/pull/32631#discussion_r2126882401)
I gotchu

💬 marcofleon commented on pull request "refactor: Convert GenTxid to `std::variant`":
(https://github.com/bitcoin/bitcoin/pull/32631#discussion_r2126883263)
Thank you for the patch, it helped.

💬 RandyMcMillan commented on pull request "uint256 cxx-20 constexpr patch":
(https://github.com/bitcoin/bitcoin/pull/32663#issuecomment-2940472143)
@hebasto,

I would suggest adding tests to the MacOS cross compile and/or actually building for MacOS x86_64.
This PR actually enables compiling with:

```
$ clang -v
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
```


---
If you are confident NO
...

💬 fanquake commented on pull request "uint256 cxx-20 constexpr patch":
(https://github.com/bitcoin/bitcoin/pull/32663#issuecomment-2940488234)
> This PR actually enables compiling with:
> Apple clang version 14.0.3 (clang-1403.0.22.14.1)

Apple Clang 14.x is based on LLVM Clang 15. We currently support Clang 16 or later.

💬 RandyMcMillan commented on pull request "uint256 cxx-20 constexpr patch":
(https://github.com/bitcoin/bitcoin/pull/32663#issuecomment-2940489326)
https://github.com/bitcoincore-dev/bitcoin/tree/1944/899512/227275/515514a4e6/7c6d5aa000-uint256-cxx-20-constexpr-patch

💬 dergoegge commented on pull request "Fuzz: extend CConnman tests":
(https://github.com/bitcoin/bitcoin/pull/28584#discussion_r2126904911)
It'd be better to create a fake `NetEventsInterface` for this test, as we are testing connman not peerman. Peerman is also a global here which might have unwanted side effects.

I haven't tried running the most recent version of this test but it looks like it'll run out of memory eventually as the `Peer`s allocated in peerman are never deleted?

💬 RandyMcMillan commented on pull request "uint256 cxx-20 constexpr patch":
(https://github.com/bitcoin/bitcoin/pull/32663#issuecomment-2940501114)
> > This PR actually enables compiling with:
> > Apple clang version 14.0.3 (clang-1403.0.22.14.1)
>
> Apple Clang 14.x is based on LLVM Clang 15. We currently support Clang 16 or later.

I suggest "trusting LLVM less"

💬 ryanofsky commented on pull request "ipc: add bitcoin-mine test program":
(https://github.com/bitcoin/bitcoin/pull/30437#issuecomment-2940549074)
re: https://github.com/bitcoin/bitcoin/pull/30437#issuecomment-2939117270

> Now that #31375 landed, can you add `bitcoin mine` as a command?

Oops, somehow i thought I had already done that..

Added 1 commit 27c6576aba5c59402b8844703e04face2f41578c -> 278101f6ee723e6401ddb3e46f2fce3b60cc42ca ([`pr/mine.24`](https://github.com/ryanofsky/bitcoin/commits/pr/mine.24) -> [`pr/mine.25`](https://github.com/ryanofsky/bitcoin/commits/pr/mine.25), [compare](https://github.com/ryanofsky/bitcoin/comp
...

💬 pinheadmz commented on pull request "tests: Expand HTTP coverage to assert libevent behavior":
(https://github.com/bitcoin/bitcoin/pull/32408#discussion_r2126939031)
I don't think that's possible, the two RPCs are `getblockcount` and `waitforblockheight`, those two responses together including their HTTP overhead only total about 500 bytes so I don't think `recv(1024)` would truncate anything. If the server is extremely slow the client may even have to call `recv()` twice in the while loop, reading only about 250 bytes each time.

💬 pinheadmz commented on pull request "tests: Expand HTTP coverage to assert libevent behavior":
(https://github.com/bitcoin/bitcoin/pull/32408#discussion_r2126941493)
Good call thanks. I will do this if I retouch this PR, otherwise will add to #32061 on rebase

💬 achow101 commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2126952270)
> allow duplicate keys or more thorowly prevent them.

Yes, I've suggest to the [mailing list](https://groups.google.com/g/bitcoindev/c/SSpyvbD9CMg) that we should allow the duplicate keys. Still checking with cryptographers that that will be okay, particularly since PSBT doesn't allow duplicate participants to use different pubnonces and partial sigs.

🤔 hebasto reviewed a pull request: "guix: warn and abort when SOURCE_DATE_EPOCH is set"
(https://github.com/bitcoin/bitcoin/pull/32678#pullrequestreview-2897373309)
My Guix build:
```
aarch64
13c339d8340af9456ad236a76bdd7faaed0f694849e6ad15da328d17d0c87ede guix-build-5c4a0f8009ce/output/aarch64-linux-gnu/SHA256SUMS.part
afc24aab271148828178b89379a4e518664415163601c7628e93d9cf53616314 guix-build-5c4a0f8009ce/output/aarch64-linux-gnu/bitcoin-5c4a0f8009ce-aarch64-linux-gnu-debug.tar.gz
7bba24165e6924ec1acddb0cc4e29c708dbb1b98f2e30405d06668f1d16c71ff guix-build-5c4a0f8009ce/output/aarch64-linux-gnu/bitcoin-5c4a0f8009ce-aarch64-linux-gnu.tar.gz
0be9eb9a
...

💬 Christewart commented on pull request "[Policy] Discourage Unsigned Annexes":
(https://github.com/bitcoin/bitcoin/pull/32453#issuecomment-2940670379)
Concept ACK

>existing annex discouragement.

Could you link to these?

Else tests would be nice.

💬 l0rinc commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2940776051)
> 1) & 2)

`MAX_BLOCK_DB_CACHE` sets `block_cache` which is used to configure `leveldb::Options.block_cache` and `.write_buffer_size`. It's not strictly related to `max_file_size` - see https://github.com/bitcoin/bitcoin/blob/master/src/leveldb/db/db_impl.cc#L104-L105.

> 2 MiB is a clear winner

@andrewtoth just had a brilliant realization that I hadn't thought of: you've just switched to v29, so you will still need to convert your 2 MiB files to 32 MiB files which requires heavy compaction at
...

💬 Sjors commented on pull request "ipc: add bitcoin-mine test program":
(https://github.com/bitcoin/bitcoin/pull/30437#issuecomment-2940777552)
ACK 278101f6ee723e6401ddb3e46f2fce3b60cc42ca