✅ fanquake closed a pull request: "chore(ci): bump artifact actions to v5"
(https://github.com/bitcoin/bitcoin/pull/33726)

💬 achow101 commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457730865)
Point 0 of the policy states:

> A DNS seed operating organization or person is expected to follow good host security practices, maintain control of applicable infrastructure, and not sell or transfer control of the DNS seed. Any hosting services contracted by the operator are equally expected to uphold these expectations.

Given that Luke was hacked a couple years ago, arguably his DNS seed should have been removed at that time. Furthermore, his personal website still has the following disc
...

💬 fanquake commented on pull request "random: clarify where the environ extern is needed":
(https://github.com/bitcoin/bitcoin/pull/33714#discussion_r2470511528)
I'm not 100% sure that is the only place it's needed, however this has historically been unclear, and the only platform I'm aware of that definitely needs it, is macOS.

💬 m3dwards commented on issue "ci: Where to run heavy and high-maintenance CI tasks?":
(https://github.com/bitcoin/bitcoin/issues/33668#issuecomment-3457750787)
> I was more referring to tasks that are deterministically failing, albeit with false-positive warnings, or otherwise hard-to-understand and hard-to-act-on error messages, blocking pull requests for unrelated reasons

Ah, in that case, sounds good to run them less frequently 👍

💬 fanquake commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457764011)
If this does end up being merged, then it should be backported to all supported branches.

💬 hebasto commented on pull request "ci, iwyu: Treat warnings as errors for `src/init` and `src/policy`":
(https://github.com/bitcoin/bitcoin/pull/33725#discussion_r2470543202)
> It'd also be good if that commit message was more explanatory:
>
> > Additional header changes were required due to visibility adjustments.
>
> Which additional changes? What visibility adjustments?

The commit message has been updated. Is it clearer now?

🤔 mzumsande reviewed a pull request: "Remove unnecessary seed from chainparams.cpp"
(https://github.com/bitcoin/bitcoin/pull/33723#pullrequestreview-3390131426)
> > update: dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us is not returning v29 or v30 nodes, apparently
>
> I had 9 tries and had the same experience.

this type of thing has happened before: See [these](https://github.com/bitcoin/bitcoin/pull/29145#pullrequestreview-1797445282) [links](https://github.com/bitcoin/bitcoin/pull/29149/#issuecomment-1871717493) Maybe there is a manual process for adding newer versions.

💬 davidgumberg commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457792851)
`/contrib/seeds/README.md` should also be updated:

https://github.com/bitcoin/bitcoin/blob/5a58d4915e5ce53b922961b16840709686ce9996/contrib/seeds/README.md?plain=1#L13-L20

💬 jlopp commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457823693)
ACK

It is well known that Luke has a lengthy history of poor security practices, which is compounded by his insistence that he does NOT have poor security practices. As such, the reliability and integrity of this DNS seed is highly suspect, with evidence already being shown that it is not responding quite as one would expect.

Although the operational risk to the Bitcoin network is low, the standards for operating this part of Bitcoin's infrastructure should be extremely high.

💬 Symphonic3 commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457867080)
Concept ACK

Have independently confirmed that `dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us` is not returning any Core v30 nodes.

💬 ryanofsky commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#issuecomment-3457885805)
<!-- begin push-68 -->
Added 1 commits 90b6a005d20ee6375beea1e685c35f265f6829c1 -> 90b81a71e49c1984120e35e060e3414fa0bb7205 ([`pr/bresult2.67`](https://github.com/ryanofsky/bitcoin/commits/pr/bresult2.67) -> [`pr/bresult2.68`](https://github.com/ryanofsky/bitcoin/commits/pr/bresult2.68), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/bresult2.67...pr/bresult2.68))<!-- end --> to try to fix maybe-uninitialized errors in https://github.com/bitcoin/bitcoin/actions/runs/18881332233/job/5
...

🤔 Eunovo reviewed a pull request: "interfaces: enable cancelling running `waitNext` calls"
(https://github.com/bitcoin/bitcoin/pull/33676#pullrequestreview-3390164904)
Looks Good. I left some comments on tests.

💬 Eunovo commented on pull request "interfaces: enable cancelling running `waitNext` calls":
(https://github.com/bitcoin/bitcoin/pull/33676#discussion_r2470572182)
https://github.com/bitcoin/bitcoin/pull/33676/commits/dcb56fd4cb59e6857c110dd87019459989dc1ec3:

What's this line for?

💬 Eunovo commented on pull request "interfaces: enable cancelling running `waitNext` calls":
(https://github.com/bitcoin/bitcoin/pull/33676#discussion_r2470613219)
https://github.com/bitcoin/bitcoin/pull/33676/commits/dcb56fd4cb59e6857c110dd87019459989dc1ec3:

The test doesn't break when this line is commented out.

💬 Eunovo commented on pull request "interfaces: enable cancelling running `waitNext` calls":
(https://github.com/bitcoin/bitcoin/pull/33676#discussion_r2470618637)
https://github.com/bitcoin/bitcoin/pull/33676/commits/dcb56fd4cb59e6857c110dd87019459989dc1ec3:

You can also add a test that interrupts before calling waitNext and check that waitNext returns immediately.

💬 glozow commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457940545)
We have removed seeds in the past when they weren't functioning as expected (see #29911).

> 1. The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network

I think omitting Bitcoin Core v30 nodes definitely breaks this policy. Based on the operator's behavior I assume it is intentional, but cc @luke-jr do you plan on fixing this?

@SatsAndSports it would be helpful if you could update the PR description with some of the more speci
...

👍 andrewtoth approved a pull request: "[IBD] coins: increase default UTXO flush batch size to 32 MiB"
(https://github.com/bitcoin/bitcoin/pull/31645#pullrequestreview-3390282138)
ACK b6f8c48946cbfceb066de660c485ae1bd2c27cc1

This constant was set when the UTXO set was much smaller, so a lot less time was spent writing. It makes sense to increase this, since IBD will benefit from the increase in IO efficiency during all that writing. During steady state the dirty UTXO set is written to disk every hour which is much less than 16MB, so this limit should have no effect.

💬 polespinasa commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457972598)
Concept ACK

> update: `dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us` is not returning v29 or v30 nodes, apparently

I have also queried the seeder a few times and didn't get a single v29 or v30 node. Other seeders do respond with v29 and v30 nodes.

This [violates point 1](https://github.com/bitcoin/bitcoin/blob/master/doc/dnsseed-policy.md): "_The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operator
...

👍 davidgumberg approved a pull request: "Modernize use of UTF-8 in Windows code"
(https://github.com/bitcoin/bitcoin/pull/32380#pullrequestreview-3390035341)
untested crACK https://github.com/bitcoin/bitcoin/commit/53e4951a5b5b9d166d278db4240513d09b447f58

Don't have access to a Windows device at the moment but I'll try and test this at some point, would there be a reasonable unit/functional test that `fsbridge::fopen` and argv can still handle non-ascii stuff on Windows? Might be nice to have, but not blocking by an means.

💬 davidgumberg commented on pull request "Modernize use of UTF-8 in Windows code":
(https://github.com/bitcoin/bitcoin/pull/32380#discussion_r2470534741)
In https://github.com/bitcoin/bitcoin/pull/32380/commits/f366408492f6205ee20fe23e5104813de45dd4b1 (_cmake: Set process code page to UTF-8 on Windows_)

Just a note: this corresponds to the example provided here: https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#activecodepage ([archive](https://web.archive.org/web/20251027165207/https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#activecodepage))