💬 achow101 commented on issue "28.0rc1 synchronizes much slower on Windows":
(https://github.com/bitcoin/bitcoin/issues/30833#issuecomment-2334821947)
Only did one run of each but I have basically the opposite result: 4406 seconds for 27.1, and 2949 for 28.0rc1.

✅ jlest01 closed an issue: "Misleading index error message"
(https://github.com/bitcoin/bitcoin/issues/30836)

💬 jlest01 commented on issue "Misleading index error message":
(https://github.com/bitcoin/bitcoin/issues/30836#issuecomment-2334845889)
Indeed. Thanks.

💬 andrewtoth commented on issue "28.0rc1 synchronizes much slower on Windows":
(https://github.com/bitcoin/bitcoin/issues/30833#issuecomment-2334887290)
@vostrnad when you say synchronizes, do you mean running with `-reindex-chainstate` or are you starting with a fresh data directory and downloading blocks from peers? If the latter, are you downloading blocks from a node in your local network?

💬 vostrnad commented on issue "28.0rc1 synchronizes much slower on Windows":
(https://github.com/bitcoin/bitcoin/issues/30833#issuecomment-2334894401)
@andrewtoth I updated the OP. I'm synchronizing from a local node with a fresh datadir each time.

💬 tdb3 commented on pull request "rpc: add getorphantxs":
(https://github.com/bitcoin/bitcoin/pull/30793#discussion_r1747778418)
Thanks. Updated with three verbosity levels (0, 1, and 2).

💬 ryanofsky commented on issue "cmake: passing options from depends build to main build":
(https://github.com/bitcoin/bitcoin/issues/30813#issuecomment-2334900625)
> I don't think this describes the current behaviour precisely.

Yes this is definitely not describing current behavior, it's trying to describe how current behavior "could be changed" to avoid writing the cache. The first part of https://github.com/bitcoin/bitcoin/issues/30813#issuecomment-2329412411 describes ideal behavior and contrasts it with current behavior, and the second part describes a specific way I think ideal behavior could be implemented.

I think current behavior is ok, but i
...

💬 tdb3 commented on pull request "rpc: add getorphantxs":
(https://github.com/bitcoin/bitcoin/pull/30793#issuecomment-2334910034)
The push to f6dee50f85b2668e96e9dffd65e06d8f3d3a4da2 adds verbosity levels and more detailed information about the orphans.

💬 ryanofsky commented on issue "cmake: passing options from depends build to main build":
(https://github.com/bitcoin/bitcoin/issues/30813#issuecomment-2334911382)
> > it seems like a very clean one is to set the [`CMAKE_USER_MAKE_RULES_OVERRIDE`](https://cmake.org/cmake/help/v3.3/variable/CMAKE_USER_MAKE_RULES_OVERRIDE.html) hook
>
> FWIW, something similar was [considered](https://github.com/hebasto/bitcoin/pull/240) during work on the CMake staging branch.

Interesting! Although that PR was using CMAKE_USER_MAKE_RULES_OVERRIDE it was doing something pretty different with it. It was overriding cmake's low level compile command lines, which is defini
...

💬 ryanofsky commented on pull request "multiprocess: Add IPC wrapper for Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30510#discussion_r1747798635)
I just think if you see:

```capnp
using Mining = import "../ipc/capnp/mining.capnp";
```

it is very obvious what file is being imported while if you see

```capnp
using Mining = import "/ipc/capnp/mining.capnp"
```

it's less clear what file is being imported because you don't know what the root path is. This is also inconsistent with standard uses of the root path which have package prefixes "capnp" for "mp":

```capnp
using Cxx = import "/capnp/c++.capnp";
using Proxy = impor
...

💬 davidgumberg commented on issue "28.0rc1 synchronizes much slower on Windows":
(https://github.com/bitcoin/bitcoin/issues/30833#issuecomment-2334953579)
I'm trying to get a Windows box setup to reproduce this myself, but if you get a chance, could you do a run of both again with `-debug=bench` set, and post the final set of [bench] logs that get written to debug.log?

💬 tdb3 commented on pull request "fix: handle invalid `-rpcbind` port earlier":
(https://github.com/bitcoin/bitcoin/pull/30679#issuecomment-2334961904)
> Hey, I'm reviewing this PR, and I saw that the test `run_invalid_bind_test` you implemented in `rpc_bind.py` is not invoking without explicitly providing the `--ipv4` or `--ipv6` flags, so is there any particular reason for that?

Thank you for the review!
In `test/functional/test_runner.py`, `rpc_bind.py` is run with three variations (`--ipv4`, `--ipv6`, and `--nonloopback`), so there is coverage for parsing rpcbind with both IPv4 and IPv6 addresses/port binds (loopback).

💬 theStack commented on pull request "rpc: add getorphantxs":
(https://github.com/bitcoin/bitcoin/pull/30793#issuecomment-2335019463)
Concept ACK

📝 Monzurrz opened a pull request: "Create Satoshi diagnostics"
(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
...

✅ Monzurrz closed a pull request: "Create Satoshi diagnostics"
(https://github.com/bitcoin/bitcoin/pull/30839)

💬 Monzurrz commented on pull request "Create Satoshi diagnostics":
(https://github.com/bitcoin/bitcoin/pull/30839#issuecomment-2335037817)
Diagnostic information for administrators:

Generating server: [CH4PR16MB6697.namprd16.prod.outlook.com](http://ch4pr16mb6697.namprd16.prod.outlook.com/)
[johann_hulstrom@hotmail.com](mailto:johann_hulstrom@hotmail.com)
Remote server returned '554 5.2.2 mailbox full; STOREDRV.Deliver.Exception:QuotaExceededException.MapiExceptionShutoffQuotaExceeded; Failed to process message due to a permanent exception with message [BeginDiagnosticData]The process failed to get the correct properties. 1.84
...

💬 hebasto commented on issue "cmake: passing options from depends build to main build":
(https://github.com/bitcoin/bitcoin/issues/30813#issuecomment-2335147801)
> > I don't think this describes the current behaviour precisely.
>
> Yes this is definitely not describing current behavior, it's trying to describe how current behavior "could be changed" to avoid writing the cache.

I'm still confused. Why should we "avoid writing the cache" for variables such as `WITH_ZMQ`? Using cache variables is a standard CMake method that allows the user to set their values.

💬 hebasto commented on issue "cmake: passing options from depends build to main build":
(https://github.com/bitcoin/bitcoin/issues/30813#issuecomment-2335157778)
> For example cmake appends `-g` to `CMAKE_CXX_FLAGS_DEBUG_INIT` after the toolchain sets it

That's true. From CMake `CMAKE_<LANG>_FLAGS_<CONFIG>_INIT` variable's [docs](https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS_CONFIG_INIT.html):
> CMake may prepend or append content to the value based on the environment and target platform.

> Suggestion above is to use CMAKE_USER_MAKE_RULES_OVERRIDE only to set _INIT variables more reliably than they can be set from the toolchain fil
...

💬 hebasto commented on pull request "cmake: add `USE_SOURCE_PERMISSIONS` to all `configure_file()` usage":
(https://github.com/bitcoin/bitcoin/pull/30823#issuecomment-2335160571)
If https://github.com/bitcoin/bitcoin/pull/30838 happens to fix https://github.com/bitcoin/bitcoin/issues/30815, it seems reasonable to switch to `NO_SOURCE_PERMISSIONS` in all cases for consistency.

👍 l0rinc approved a pull request: "Remove unsafe uint256S() and test-only uint160S()"
(https://github.com/bitcoin/bitcoin/pull/30773#pullrequestreview-2287480459)
reACK 43cd83b0c7ba436b8ffc83d8a65e935714dffe70
Thanks for your perseverance!