💬 naumenkogs commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1418656693)
>stops sampling entirely after 200 samples

perhaps record this bug in the commit message, might be useful in the future?

💬 maflcko commented on pull request "mempool: Don't sort in entryAll":
(https://github.com/bitcoin/bitcoin/pull/29019#issuecomment-1845000268)
lgtm ACK 87fa444a04854a5d3a9ff283a8b6c34587e8430f

Though, if the function will be removed either way, I wonder if this is worth it. Maybe wait for an OK by @sdaftuar to avoid a merge conflict with https://github.com/bitcoin/bitcoin/pull/28676 ?

✅ fanquake closed a pull request: "build: Require C++20 compiler"
(https://github.com/bitcoin/bitcoin/pull/28349)

🚀 fanquake merged a pull request: "build: use macOS 14 SDK (Xcode 15.0)"
(https://github.com/bitcoin/bitcoin/pull/28622)

📝 maflcko reopened a pull request: "build: Require C++20 compiler"
(https://github.com/bitcoin/bitcoin/pull/28349)
C++20 allows to write safer code, because it allows to enforce more stuff at compile time (`constinit`, `conteval`, `constexpr`, `std::span`, ...).

Also, it allows to write less verbose and easier to understand code (C++ 20 Concepts).

See https://github.com/bitcoin/bitcoin/issues/23363 and https://en.cppreference.com/w/cpp/compiler_support#cpp20

With g++-10 (https://github.com/bitcoin/bitcoin/pull/28348) and clang-13 (https://github.com/bitcoin/bitcoin/pull/28210), there is broad suppor
...

👋 maflcko's pull request is ready for review: "build: Require C++20 compiler"
(https://github.com/bitcoin/bitcoin/pull/28349)

💬 maflcko commented on pull request "build: Require C++20 compiler":
(https://github.com/bitcoin/bitcoin/pull/28349#issuecomment-1845050631)
Rebased.

Once and if this is merged, I'll follow-up with a `fs.h` cleanup.

💬 fanquake commented on pull request "guix: update time-machine":
(https://github.com/bitcoin/bitcoin/pull/28580#issuecomment-1845087846)
Does Guix work normally?
Does it work with any other build, or is it only the arm64-apple-darwin that is not working?

⚠️ maflcko opened an issue: "./contrib/guix/guix-build does not work on riscv64"
(https://github.com/bitcoin/bitcoin/issues/29020)
Steps to reproduce:

```
# dpkg --print-architecture && HOSTS="arm64-apple-darwin" V=1 VERBOSE=1 MAX_JOBS=$(nproc) ./contrib/guix/guix-build
riscv64
Found macOS SDK at '/bitcoin-core/depends/SDKs/Xcode-12.2-12B45b-extracted-SDK-with-libcxx-headers', using...
Checking that we can connect to the guix-daemon...

Hint: If this hangs, you may want to try turning your guix-daemon off and on
again.

accepted connection from pid 2870003, user root
make: Entering directory '/bitcoin-co
...

💬 maflcko commented on issue "./contrib/guix/guix-build does not work on riscv64":
(https://github.com/bitcoin/bitcoin/issues/29020#issuecomment-1845096426)
guix itself seems to be working:

```
# type rustc && rustc --version
rustc is hashed (/var/guix/profiles/per-user/root/guix-profile/bin/rustc)
rustc 1.60.0

💬 maflcko commented on pull request "guix: update time-machine":
(https://github.com/bitcoin/bitcoin/pull/28580#issuecomment-1845097342)
Yeah, it works. Let's move the discussion to https://github.com/bitcoin/bitcoin/issues/29020

👍 TheCharlatan approved a pull request: "Get rid of shutdown.cpp/shutdown.h, use SignalInterrupt directly"
(https://github.com/bitcoin/bitcoin/pull/28051#pullrequestreview-1769799324)
Re-ACK 4a3a2651420ca1808cb25aed8a33d57dfcd627f5

💬 fanquake commented on issue "./contrib/guix/guix-build does not work on riscv64":
(https://github.com/bitcoin/bitcoin/issues/29020#issuecomment-1845101692)
Is it only the apple cross-compiles that aren't working, or all builds? I assume it's only the apple cross-compiles given that is what is being shown here.

> guix itself seems to be working:

What is the Guix version?

💬 dergoegge commented on issue "fuzz: Fix stability, determinism issues":
(https://github.com/bitcoin/bitcoin/issues/29018#issuecomment-1845103910)
oss-fuzz has a table for the afl++ jobs: https://oss-fuzz.com/fuzzer-stats?group_by=by-fuzzer&date_start=2023-08-31&date_end=2023-12-06&fuzzer=afl&job=afl_asan_bitcoin-core&project=bitcoin-core

💬 Retropex commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1845105629)
> Next move?

Standardize the new spam method.

💬 maflcko commented on issue "./contrib/guix/guix-build does not work on riscv64":
(https://github.com/bitcoin/bitcoin/issues/29020#issuecomment-1845106572)
The other targets seem to be affected as well. (Tested Windows as well, so far)

The guix version is 1.4, but that shouldn't matter, because of the time-machine.

💬 dergoegge commented on pull request "wip: Split fuzz binary":
(https://github.com/bitcoin/bitcoin/pull/29010#issuecomment-1845118486)
> What does this mean? I'm seeing file sizes of 448MB (with fuzzing enabled) and 146MB (with a normal build) for test/fuzz/fuzz.

If you build this pull request you should see a binary per fuzz harness in `src/test/fuzz` (e.g. `src/test/fuzz/process_message`), as well as the usual fuzz binary `src/test/fuzz/fuzz`. If you sum up the size of the individual per harness binaries (assuming you compile with LTO) you should end up with roughly 3.6GB (maybe this depends on compiler version etc.). The
...

💬 maflcko commented on pull request "wip: Split fuzz binary":
(https://github.com/bitcoin/bitcoin/pull/29010#discussion_r1418771429)
Is the change in this header file needed for your approach? If there is only one fuzz target per file, and only one file is compiled, you wouldn't need to check whether it needs to be compiled, no?

💬 dergoegge commented on pull request "wip: Split fuzz binary":
(https://github.com/bitcoin/bitcoin/pull/29010#discussion_r1418785689)
Right, I think once building all the individual binaries is optional, this could be used to build just one of the individual binaries, e.g.:

```
CPPFLAGS="-DFUZZ_HARNESS=process_message" ./configure --enable-fuzz
make
```

which would produce `src/test/fuzz/fuzz` that only has the `process_message` harness. Building and linking just one harness is faster than all of them, maybe useful when reproducing testcases?

Maybe there is a better way of accomplishing this?

📝 maflcko opened a pull request: "refactor: rpc: Pass CBlockIndex by reference instead of pointer "
(https://github.com/bitcoin/bitcoin/pull/29021)
Follow-up to https://github.com/bitcoin/bitcoin/pull/29003#issuecomment-1841435462