💬 1440000bytes commented on issue "Distribute darknet node addresses via DNS seeds using AAAA records":
(https://github.com/bitcoin/bitcoin/issues/31062#issuecomment-2406707660)
Concept NACK

Onion and i2p nodes not dependent on DNS seeds is a feature. It's better if only IPv4 and IPv6 nodes use it.

Maybe we could experiment with [GNS](https://www.gnunet.org/en/gns.html)? Or use this approach for IPv4 nodes with non default port? https://github.com/bitcoin/bitcoin/issues/30900

💬 maflcko commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#issuecomment-2406773729)
I still wonder how useful this is overall. I understand that it is adding a bunch of test-framework code to mimic the functional tests at a lower level and offers a way to write tests this way in C++. However, developers may still prefer to write the tests in Python going forward, because they are used to it, and because it is more flexible, albeit a bit more expensive, because full processes need to be spun up each time. If this is merged, it will add a few redundant test cases (redundant in th
...

📝 omahs opened a pull request: "Fix typos in check-deps.sh"
(https://github.com/bitcoin/bitcoin/pull/31070)
Fix typos in check-deps.sh

🤔 hebasto reviewed a pull request: "test: Print CompletedProcess object on error"
(https://github.com/bitcoin/bitcoin/pull/31067#pullrequestreview-2362251258)
Concept ACK, it seems quite [useful](https://github.com/bitcoin/bitcoin/issues/30792#issuecomment-2406589710).

💬 Julietnacy commented on issue "Bitcoin Core "not opened" after software update to macOS Sequoia 15.0.1 (24A348)":
(https://github.com/bitcoin/bitcoin/issues/31069#issuecomment-2406897332)
@diivvy If your Bitcoin Core wallet is still taking up space but isn’t showing up,Try downloading and reinstalling Bitcoin Core from the official site. It might detect your existing data.

💬 hebasto commented on issue "Bitcoin Core "not opened" after software update to macOS Sequoia 15.0.1 (24A348)":
(https://github.com/bitcoin/bitcoin/issues/31069#issuecomment-2406917157)
@diivvy

Before taking any further action, ensure that your wallet file(s) are properly backed up. If you were using the default settings, they reside in the [data directory](https://github.com/bitcoin/bitcoin/blob/master/doc/files.md#data-directory-location).

💬 maflcko commented on pull request "Fix typos in check-deps.sh":
(https://github.com/bitcoin/bitcoin/pull/31070#issuecomment-2406919296)
lgtm ACK da8824ba301c783fe9b600df8521fe1beb65f1f2

Please add `contrib: ` prefix to the pull title.

⚠️ maflcko opened an issue: "ci: Replace wine tests with real tests on Windows?"
(https://github.com/bitcoin/bitcoin/issues/31071)
The Wine tests are annoying, because they frequently fail (for more than a decade now), with no fix in sight.

Also, they are less useful than running on a real Windows.

My suggestion would be to replace the win64-cross CI task with one on GitHub Actions, using a real Windows. The cross compilation would still be done normally (to mimic guix), inside WSL. However, the unit tests would be run on the real Windows.

I won't be working on this myself, but I am happy to answer any questions on
...

💬 maflcko commented on issue "ci: failure in win64 unit tests `err:virtual:virtual_alloc_first_teb wine: failed to map the shared user data: c0000018\n0444:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.\n0444:err:winediag:nodrv_CreateWindow L"Make sure that your X server is running and that $DISPLAY is set correctly."`)":
(https://github.com/bitcoin/bitcoin/issues/30792#issuecomment-2406934000)
No idea how to fix this. I'd say to just replace the Wine tests finally: https://github.com/bitcoin/bitcoin/issues/31071

💬 maflcko commented on issue "win64-cross CI timeout: `wine: chdir to /tmp/wine-JFrcnM/server-30-e86edd : No such file or directory`; `01e0:err:module:relocate_ntdll ntdll could not be mapped at preferred address (0x320000), expect trouble`":
(https://github.com/bitcoin/bitcoin/issues/30969#issuecomment-2406934179)
No idea how to fix this. I'd say to just replace the Wine tests finally: https://github.com/bitcoin/bitcoin/issues/31071

💬 maflcko commented on issue "ci: Replace wine tests with real tests on Windows?":
(https://github.com/bitcoin/bitcoin/issues/31071#issuecomment-2406942992)
Ugh, this may require WSL2, which isn't yet available on GHA?

💬 fjahr commented on pull request "init: Correct coins db cache size setting":
(https://github.com/bitcoin/bitcoin/pull/31064#issuecomment-2406943239)
utACK 3a4a788ee0db83d20607f14801dbed2ee932943c

💬 willcl-ark commented on issue "ci: Replace wine tests with real tests on Windows?":
(https://github.com/bitcoin/bitcoin/issues/31071#issuecomment-2406956133)
I'm presuming that it may need WSL2 for the build, not the test stage?

If so, we could consider using two GH jobs to split/run this test in two stages; one which does the cross-compile on ubuntu and [saves the build artefacts](https://github.com/actions/upload-artifact), which, if successful, are then [restored](https://github.com/actions/download-artifact) by the second (native windows) job to be executed natively under Windows.

This could prove more tricky to actually execute in practice
...

🚀 fanquake merged a pull request: "contrib: fix typos in check-deps.sh"
(https://github.com/bitcoin/bitcoin/pull/31070)

💬 hebasto commented on issue "ci: Replace wine tests with real tests on Windows?":
(https://github.com/bitcoin/bitcoin/issues/31071#issuecomment-2406960015)
> Ugh, this may require WSL2, which isn't yet available on GHA?

The recent discussion is [here](https://github.com/actions/runner-images/issues/5920).

💬 maflcko commented on pull request "fuzz: fuzz connman with non-empty addrman + ASMap":
(https://github.com/bitcoin/bitcoin/pull/29536#issuecomment-2406968222)
cc @vasild Looks like this conflicts with one of your pulls, so you may be qualified to ack/nack this?

💬 willcl-ark commented on issue "Consider making 27.x Long-Term Support (LTS)":
(https://github.com/bitcoin/bitcoin/issues/31068#issuecomment-2407002453)
> RHEL 8 and the RHELatives that base off of this, such as AlmaLinux 8 and Rocky Linux 8.

> I would not be surprised if more than half of Bitcoin Core installations that run on dedicated Linux servers will not be able to update to 28.x as a result of this, without first updating to a new OS.

Do you have any further information on how you conclude that more than half of Bitcoin Core installations run on these OSes (and their derivatives)? This number doesn't feel right to me, even as a (hig
...

💬 l0rinc commented on pull request "Don't zero-after-free `DataStream`: Faster IBD on some configurations":
(https://github.com/bitcoin/bitcoin/pull/30987#issuecomment-2407036182)
I have compared the full IBD speed of
* 0449a22bc0: test: avoid BOOST_CHECK_EQUAL for complex types
* 5cf2fefd33: refactor: Drop unused `zero_after_free_allocator`

The added test served as a baseline, dropping the zero fee allocator as the purpose of this PR (I know you've added new commits since, let me know if you think that changes the landscape).

I've used a low, but reasonable 2GB dbcache for the first 800k blocks to measure the underlying database instead of a single final dump wit
...

📝 hebasto converted_to_draft a pull request: "build: Rename `PACKAGE_*` variables to `CLIENT_*`"
(https://github.com/bitcoin/bitcoin/pull/31042)
The use of `PACKAGE_NAME` for the project's variable name is problematic, as this name is commonly used in CMake's [interface variables](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-version-selection). If third-party CMake code handles with scopes improperly, our `PACKAGE_NAME` variable could end up with an unexpected value.

This PR avoids such conflicts by renaming all `PACKAGE_*` variables to `CLIENT_*`.

The code in the master branch works correctly only inci
...

💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#issuecomment-2407144282)
> developers may still prefer to write the tests in Python going forward, because they are used to it, and because it is more flexible

I agree. This PR does not intend to replace the functional testing framework, but complement it. For example, from C++ one has greater control and observability - the test can read any global or member variable and can call arbitrary functions (repeating https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1068176623).

Also, when used from within C++ o
...