💬 maflcko commented on pull request "ci, iwyu: Treat warnings as errors for `src/init` and `src/policy`":
(https://github.com/bitcoin/bitcoin/pull/33725#discussion_r2472147424)
Yeah, I can see it both ways. I think the possible harm from including span.h over span is limited with this trivial header. Just noting I did the same with the time.h include: https://github.com/bitcoin/bitcoin/blob/3bb30658e631ed45b6c8609292facc7ae3dd0f61/src/util/time.h#L9

Also for the validation.h include: https://github.com/bitcoin/bitcoin/blob/3bb30658e631ed45b6c8609292facc7ae3dd0f61/src/validation.h#L19. There, the harm could be larger, as the validation header is a bit larger than the
...

💬 delta1 commented on pull request "Remove unreliable seed from chainparams.cpp, and the associated README":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3460546599)
reACK https://github.com/bitcoin/bitcoin/commit/b0c706795ce6a3a00bf068a81ee99fef2ee9bf7e

👍 dergoegge approved a pull request: "Remove unreliable seed from chainparams.cpp, and the associated README"
(https://github.com/bitcoin/bitcoin/pull/33723#pullrequestreview-3392411168)
ACK b0c706795ce6a3a00bf068a81ee99fef2ee9bf7e

🚀 fanquake merged a pull request: "ci: use pycapnp 2.2.1"
(https://github.com/bitcoin/bitcoin/pull/33693)

✅ fanquake closed an issue: "ci: short read: expected xxxxxxxxx bytes but got xxxxxxxxx: unexpected EOF"
(https://github.com/bitcoin/bitcoin/issues/33640)

🚀 fanquake merged a pull request: "ci: Retry image building once on failure"
(https://github.com/bitcoin/bitcoin/pull/33677)

💬 laisial commented on pull request "Remove unreliable seed from chainparams.cpp, and the associated README":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3460745709)
> I'd highly suggest waiting until @luke-jr can comment and weigh in on this directly before even considering hastily merging this.
> https://x.com/LukeDashjr/status/1983322751747412327

he has commented in the post you shared. also, you did not provide any counterarguments. the policy is using an open standard, so any decision will be subjective and open to interpretation.

luke did say that he "Obviously" plans to add new versions in the future: https://x.com/LukeDashjr/status/1983414007
...

👍 dergoegge approved a pull request: "ci: run native fuzz with MSAN job"
(https://github.com/bitcoin/bitcoin/pull/33626#pullrequestreview-3392578649)
utACK 362587409767eb349cd4f679db71a1e5bf407bb8

👍 stickies-v approved a pull request: "Remove unreliable seed from chainparams.cpp, and the associated README"
(https://github.com/bitcoin/bitcoin/pull/33723#pullrequestreview-3392582038)
re-ACK b0c706795ce6a3a00bf068a81ee99fef2ee9bf7e

💬 TheCharlatan commented on pull request "kernel: Introduce C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#issuecomment-3460824372)
Rebased 083814948d66aac49b6995de560a48c7889896cc -> 1ea43dc365c277f519f30f55dae6b0899e611765 ([kernelApi_77](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_77) -> [kernelApi_78](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_78), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelApi_77..kernelApi_78))

* Fixed conflict with https://github.com/bitcoin/bitcoin/pull/32380
* Dropped the commit introducing utf8 string handling for windows, since that is now handled by
...

💬 fanquake commented on pull request "guix: Use UCRT runtime for Windows release binaries":
(https://github.com/bitcoin/bitcoin/pull/33593#issuecomment-3460836590)
What is the plan for adding CI, as that blocks everything here?

📝 00w1 opened a pull request: "chainparams: remove *petertodd.net "
(https://github.com/bitcoin/bitcoin/pull/33730)
**Rationale**

https://agorism.dev/petertodd-emails.txt

💬 l0rinc commented on pull request "chainparams: remove *petertodd.net":
(https://github.com/bitcoin/bitcoin/pull/33730#issuecomment-3460872871)
NACK, seems like trolling, please provide proper motivation

💬 pinheadmz commented on pull request "chainparams: remove *petertodd.net":
(https://github.com/bitcoin/bitcoin/pull/33730#issuecomment-3460874678)
This PR description is unacceptable, please expand it with technical details or references to specific, documented project policy.

💬 TheCharlatan commented on pull request "kernel: Introduce C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2472541351)
Resolved this by rebasing on the merged manifest changes and dropped the entire change.

💬 fanquake commented on pull request "[wip] [nomerge] [draft] 2510 msan zero":
(https://github.com/bitcoin/bitcoin/pull/33686#issuecomment-3460935528)
Close here now it's been added to the nightly repo (https://github.com/bitcoin/bitcoin/issues/33668#issuecomment-3458046048)?

💬 jlopp commented on pull request "chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3460938455)
> The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operator's understanding and capability.

This may be considered more of a meta comment, but the practice of a DNS seed dropping peers based upon their useragent is problematic in my view.

A useragent by no means defines how a node operates; it's trivial to set one's node to advertise any arbitrary useragent. If a DNS seed only accepts specific "approve
...

⚠️ dergoegge opened an issue: "RFC: Do we want to support fuzzing on MacOS?"
(https://github.com/bitcoin/bitcoin/issues/33731)
Fuzzing on MacOS (i.e. actual fuzzing not just running the inputs through the `fuzz` binary) is known to be brittle and we've had plenty of issues reported to us showcasing this:

- https://github.com/bitcoin/bitcoin/issues/33667
- https://github.com/bitcoin/bitcoin/issues/32089
- https://github.com/bitcoin/bitcoin/issues/31049
- https://github.com/bitcoin/bitcoin/issues/27550
- https://github.com/bitcoin/bitcoin/issues/19789

The solution usually involves something along the lines of waiting fo
...

💬 fanquake commented on issue "RFC: Do we want to support fuzzing on MacOS?":
(https://github.com/bitcoin/bitcoin/issues/33731#issuecomment-3461142954)
> 1. Keep the current approach and fix/document as issues are reported.

If we do do this, it should be clear what is supported (i.e just the latest version of LLVM/Clang shipped via brew, using `lld` to link?) , otherwise (as you metion above) we'll be documenting many different "workarounds" depending on the version of macOS, version of Apple clang/binutils install, if brew LLVM is being used, and it's version, using `ld64` to link, vs `lld`.

> I'd prefer option 2).

Concept ACK. Getting fuzz
...

💬 fanquake commented on pull request "guix: Use UCRT runtime for Windows release binaries":
(https://github.com/bitcoin/bitcoin/pull/33593#discussion_r2472734365)
> we maintain our own package

If we are going to copy-paste this from Guix, and maintain it outself, seems like we should simplify it for our usage? i.e we know we are building winpthreads.