💬 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))

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

This commit should also remove the skips of manifest checks for these executables:

https://github.com/bitcoin/bitcoin/blob/5a58d4915e5ce53b922961b16840709686ce9996/.github/workflows/ci.yml#L282-L286

💬 ismaelsadeeq commented on pull request "interfaces: enable cancelling running `waitNext` calls":
(https://github.com/bitcoin/bitcoin/pull/33676#discussion_r2470677387)
which line?
you highlighted four lines.

💬 Crypt-iQ commented on pull request "p2p: reduce false-positives in addr rate-limiting":
(https://github.com/bitcoin/bitcoin/pull/33699#issuecomment-3457987486)
Ignoring self-announcements seems to occur only in the time between our inbound peer (outbound from their perspective) 1) calling `SetupAddressRelay` when receiving version, and 2) receiving verack where it will set `fSuccessfullyConnected = true` and call `SendMessages` followed by `MaybeSendAddr`. The address entries are sent in order of insert, but then shuffled before processing since https://github.com/bitcoin/bitcoin/pull/22387 ([see rationale](https://github.com/bitcoin/bitcoin/pull/22387
...

💬 ismaelsadeeq commented on pull request "interfaces: enable cancelling running `waitNext` calls":
(https://github.com/bitcoin/bitcoin/pull/33676#discussion_r2470687187)
Interesting (that should never happen), can you share the logs and steps to reproduce?
I can verify that it failed for me.

```
2025-10-28T18:42:24.302035Z TestFramework (INFO): PRNG seed is: 1841123518053179096
2025-10-28T18:42:24.302446Z TestFramework (INFO): Initializing test directory /var/folders/dj/d8p8jhd172n7wnq81ryfl6rc0000gn/T/bitcoin_func_test_kcqf80gj
2025-10-28T18:42:25.106568Z TestFramework (INFO): Running echo test
2025-10-28T18:42:25.113270Z TestFramework (INFO): Running m
...