📝 fanquake locked a pull request: "."
(https://github.com/bitcoin/bitcoin/pull/30839)
Looking for additional support. I can provide the original diagnostics helping build a better tomorrow today please provide additional support and guidance for and easier user friendly environent

<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please pro
...

📝 itornaza opened a pull request: "docs: Updated debug build instructions for cmake"
(https://github.com/bitcoin/bitcoin/pull/30840)
In the [developer notes](https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md) the section on [compiling for debug](https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#compiling-for-debugging) displays outdated instructions that were applicable before the move to cmake build system.

This PR just gives instructions on how to build for debugging in the context of cmake.

💬 l0rinc commented on pull request "refactor: Generalize `CScript`'s `std::vector` push to accept `std::array`, too":
(https://github.com/bitcoin/bitcoin/pull/30765#discussion_r1748069155)
Seems we're [getting an error on Windows](
In https://github.com/bitcoin/bitcoin/pull/30765/checks?check_run_id=29792259962) around `genesisOutputScript`, where `prevector#fill` is trying to write 65 bytes of data into a 32-byte buffer.
I can't reproduce it locally, any help would be appreciated.

💬 vostrnad commented on issue "28.0rc1 synchronizes much slower on Windows":
(https://github.com/bitcoin/bitcoin/issues/30833#issuecomment-2335184072)
I've bisected this down to #28052. From the benchmark results it appears to be solely responsible for the slowdown between 27.0 and 28.0rc1 (so #30326 should be fine @andrewtoth).

@davidgumberg Please let me know if you still need those bench logs.

💬 sipa commented on issue "28.0rc1 synchronizes much slower on Windows":
(https://github.com/bitcoin/bitcoin/issues/30833#issuecomment-2335186082)
@vostrnad Does the performance on Windows recover if you run with the `-blocksxor=0` option?

📝 hebasto opened a pull request: "ci: Post CMake-migration fixes and amendments"
(https://github.com/bitcoin/bitcoin/pull/30841)
This PR addresses the change in logging that [happened](https://cmake.org/cmake/help/latest/release/3.26.html#configure-log) in CMake 3.26.

Additionally, the `make` invocation replaced with `cmake --build`.

💬 vostrnad commented on issue "28.0rc1 synchronizes much slower on Windows":
(https://github.com/bitcoin/bitcoin/issues/30833#issuecomment-2335190583)
@sipa No, it's exactly the same with `-blocksxor=0`.

📝 hebasto opened a pull request: "build: Minimize I/O operations in `GenerateHeaderFrom{Json,Raw}.cmake`"
(https://github.com/bitcoin/bitcoin/pull/30842)
This PR aims to reduce the build time.

💬 hebasto commented on issue "guix: Build fails for `x86_64-apple-darwin`":
(https://github.com/bitcoin/bitcoin/issues/30810#issuecomment-2335384269)
```
$ uname -m
riscv64
$ guix shell --container --pure hello
$ hello
Hello, world!
$ exit
exit
```

The issue happens when switch to/form Darwin host. For both invocations
```
$ env SDK_PATH=/home/hebasto HOSTS="x86_64-w64-mingw32 x86_64-apple-darwin" ./contrib/guix/guix-build
```
and
```
$ env SDK_PATH=/home/hebasto HOSTS="x86_64-apple-darwin x86_64-w64-mingw32" ./contrib/guix/guix-build
```
build for the former host succeeds, then the error happens:
```
guix shell: error: c
...

💬 fanquake commented on issue "guix: Build fails for `x86_64-apple-darwin`":
(https://github.com/bitcoin/bitcoin/issues/30810#issuecomment-2335396254)
You'll need to try with all the options we pass to shell/container.

💬 furszy commented on pull request "interfaces: #30697 follow ups":
(https://github.com/bitcoin/bitcoin/pull/30828#discussion_r1748270119)
In case we add another action in the future, this should be:
```suggestion
return action != interfaces::SettingsAction::WRITE || args().WriteSettingsFile();
```

💬 furszy commented on pull request "interfaces: #30697 follow ups":
(https://github.com/bitcoin/bitcoin/pull/30828#discussion_r1748327016)
> Setting a null setting should just delete a setting consistently and not have different behavior for different functions.

I would rather fail when a null setting is provided to any of the update or overwrite functions. I believe the intent to delete should be explicit, at least within this settings layer. That's why the `deleteRwSettings` function was introduced. It seems inconsistent to have two different methods for deleting a value - one embedded within the update function and another ex
...

⚠️ Graysonbarton opened an issue: "Backwards compatibility to the Genesis block."
(https://github.com/bitcoin/bitcoin/issues/30843)
https://github.com/devcontainers/templates/pull/286

✅ achow101 closed an issue: "Backwards compatibility to the Genesis block."
(https://github.com/bitcoin/bitcoin/issues/30843)

:lock: achow101 locked an issue: "."
(https://github.com/bitcoin/bitcoin/issues/30843)

💬 TheCharlatan commented on pull request "build: Minimize I/O operations in `GenerateHeaderFrom{Json,Raw}.cmake`":
(https://github.com/bitcoin/bitcoin/pull/30842#issuecomment-2335516571)
I don't really see a difference in performance to be honest.

💬 hebasto commented on pull request "build: Minimize I/O operations in `GenerateHeaderFrom{Json,Raw}.cmake`":
(https://github.com/bitcoin/bitcoin/pull/30842#issuecomment-2335656672)
> I am not measuring a difference in performance in the generation of the headers between master and this PR.

Building on Windows benefits most.

🤔 zaidmstrr reviewed a pull request: "fix: handle invalid `-rpcbind` port earlier"
(https://github.com/bitcoin/bitcoin/pull/30679#pullrequestreview-2287939990)
ACK [590d2fb](https://github.com/bitcoin/bitcoin/pull/30679/commits/590d2fb0d8548d6d55fd1c738c8bcbe71a57aaf2)
I have reviewed and tested by manual and dry running the code to detect any edge cases and coding related erros. I also performed manual fuzzing by passing arguments in the CLI using bitcoind to check for any unexpected behaviours and to check whether the new code giving the updated results without any bypass or failure. 

📝 furszy opened a pull request: "RPC: improve SFFO arg parsing, error catching and coverage"
(https://github.com/bitcoin/bitcoin/pull/30844)
Following changes were made:

1) Catch and signal error for duplicate string destinations.
2) Catch and signal error for invalid value type.
3) Catch and signal error for string destination not found in tx outputs.
4) Improved `InterpretSubtractFeeFromOutputInstructions()` code organization.
5) Added test coverage for all possible error failures.

Also, fixed two PEP 8 warnings at the 'wallet_sendmany.py' file:
- PEP 8: E302 expected 2 blank lines, found 1 at the SendmanyTest class decl
...

💬 ryanofsky commented on pull request "interfaces: #30697 follow ups":
(https://github.com/bitcoin/bitcoin/pull/30828#discussion_r1748697758)
So we both agree it is bad for overwrite function to reject null values and update function to accept them, but I would prefer both functions to accept them and you want both functions to reject them.

Here are the reason I think it is better to accept them:

- I think it is generally bad practice to accept nullable values and then handle them with runtime errors. If you want to write API's that don't accept null values I think you should use non-nullable types.

- I think in this specific
...