01:00 <bitcoin-git> [bitcoin] davidgumberg opened pull request #32400: random: Use modern Windows randomness functions (master...5-1-25-winbcrypt) https://github.com/bitcoin/bitcoin/pull/32400

05:29 <vasild> Technically, I am in favor of "3) Remove limits entirely (~Peter Todd's PR)". IMO that is the correct technical decision. However this has become political now. Enforcing the correct technical decision on disagreeing people is not politically correct. Now, if those disagreeing are a loud minority, what would making this configurable do? I guess it would make them happy and wouldn't have an impact

05:29 <vasild> network-wide. That sounds technically and politically correct to me.

06:23 <Murch[m]> Giving people a knob to turn that doesn't do anything useful and just harms them is kinda wrong

06:35 <_aj_> Murch[m]: does the person turning the knob get a say in whether they consider it to be harming them?

07:45 <vasild> "doesn't do anything useful and just harms them" According to who? According to you. And according to me too. But apparently some people disagree with us. And then we are headed towards enforcing our opinion (which is correct according to us) over disagreeing people.

07:50 <_aj_> to some extent i think that's okay: it's "our" software, so its design should reflect "our" judgement/opinions on what makes sense. but if the idea is to be global and decentralised, you want the "us" there to be a pretty broad group, which might include people who want to do things that seem a bit stupid. for me, i guess the border line is more about how much complexity letting people "be a bit

07:50 <_aj_> stupid" requires; if it's not much, then be a broad church. if it's a lot, then let them maintain a fork.

07:50 <_aj_> (well, all that assumes they're not being completely obnoxious about it; if they are, that's a whole other story)

07:53 <vasild> yeah, I was just thinking about that - if Bitcoin Core is a typical software project, then its developers are dictators and do as they see fit. Disagreeing people are free to fork it and change it according to their taste.

07:54 <vasild> That's how it is with typical open source projects.

10:04 <bitcoin-git> [bitcoin] fanquake opened pull request #32403: test: remove Boost SIGCHLD workaround. (master...drop_boost_signal) https://github.com/bitcoin/bitcoin/pull/32403

14:27 <bitcoin-git> [bitcoin] l0rinc opened pull request #32404: fuzz: assert FastRandomContext range boundaries (master...l0rinc/hourly-write-followup) https://github.com/bitcoin/bitcoin/pull/32404

14:58 <bitcoin-git> [bitcoin] hebasto closed pull request #31394: [POC] cmake: Introduce LLVM's Source-based Code Coverage reports (master...241129-llvm-coverage) https://github.com/bitcoin/bitcoin/pull/31394

15:26 <bitcoin-git> [bitcoin] mzumsande closed pull request #32399: cli: add -usefile option (master...202505_cli_loadfile) https://github.com/bitcoin/bitcoin/pull/32399

15:31 <bitcoin-git> [bitcoin] fanquake opened pull request #32405: build: replace header checks with `__has_include` (master...use_has_include) https://github.com/bitcoin/bitcoin/pull/32405

15:41 <bitcoin-git> [bitcoin] instagibbs opened pull request #32406: policy: uncap datacarrier by default (master...2025-05-uncap_datacarrier) https://github.com/bitcoin/bitcoin/pull/32406

15:41 <instagibbs> fanquake please lock for now ^

15:42 <instagibbs> dank

15:44 <instagibbs> oof I can't even edit the OP, github so good

15:44 <instagibbs> (fine for now)

15:57 <_aj_> haha, i can add a label despite the lock! now i just need to publish a way of inscribing comments via github label edits

16:32 <Sjors[m]> instagibbs: maybe add a warning that this setting can slow down block propagation. And not just deprecated, but not recommended.

16:35 <Sjors[m]> It allows for the same test simplifications as the original PR, so that's nice.

16:37 <Sjors[m]> I'm not a political analyst so no strong opinion on whether this is a wise way to handle brigading. But it fixes the original problem and, with those warnings, makes it clear enough that we don't recommend using this.

17:27 <dzxzg> I agree with #32406 and think it's a much less incendiary solution than #32359, and all of the technical merits that I see weigh on the side of removing OP_RETURN standardness limits. Decisions must be guided by the conclusions of the people that spend their time thinking about and working on the project, not whether or not those decisions incite vocal subcultures to brigade.

17:27 <corebot> https://github.com/bitcoin/bitcoin/issues/32406 | policy: uncap datacarrier by default by instagibbs · Pull Request #32406 · bitcoin/bitcoin · GitHub

17:27 <corebot> https://github.com/bitcoin/bitcoin/issues/32359 | Remove arbitrary limits on OP_Return (datacarrier) outputs by petertodd · Pull Request #32359 · bitcoin/bitcoin · GitHub

17:27 <dzxzg> I agree with #32406 and think it's a much less incendiary solution than #32359, and all of the technical merits that I see weigh on the side of removing OP_RETURN standardness limits. Decisions must be guided by the conclusions of the people that spend their time thinking about and working on the project, not whether or not those decisions incite vocal subcultures to brigade.

17:27 <corebot> https://github.com/bitcoin/bitcoin/issues/32406 | policy: uncap datacarrier by default by instagibbs · Pull Request #32406 · bitcoin/bitcoin · GitHub

17:27 <corebot> https://github.com/bitcoin/bitcoin/issues/32359 | Remove arbitrary limits on OP_Return (datacarrier) outputs by petertodd · Pull Request #32359 · bitcoin/bitcoin · GitHub

17:27 <dzxzg> But, I want to raise a tiny flag of caution, not necessarily for this case but in general, just as there is a cost in giving in to every raging faction that bursts in screaming, there is a risk in ignoring every such faction. While irrelevant to the technical merits of a proposal, I believe those risks should be measured against the tangible benefits of action/inaction. I think it is critical that if there is something important, the project should

17:27 <dzxzg> stand it's ground, but I don't think being right for the sake of being right is an important enough reason.

17:27 <dzxzg> (Sorry for double-pasting)

17:43 <instagibbs> in the functional tests looks like tests fail if an InitWarning is triggered, is that something we don't want to happen in a test?

17:44 <instagibbs> I guess the other stuff just LogInfo's, I'll do that...

18:10 <bitcoin-git> [bitcoin] AlnetharyT opened pull request #32407: النظاري (#1) (master...master) https://github.com/bitcoin/bitcoin/pull/32407

18:12 <bitcoin-git> [bitcoin] fanquake closed pull request #32407: النظاري (#1) (master...master) https://github.com/bitcoin/bitcoin/pull/32407

18:56 <bitcoin-git> [bitcoin] pinheadmz opened pull request #32408: tests: Expand HTTP coverage to assert libevent behavior (master...http-tests) https://github.com/bitcoin/bitcoin/pull/32408

19:45 <bitcoin-git> [bitcoin] hebasto opened pull request #32409: fuzz: Suppress abort message on Windows (master...250502-fuzz-abort) https://github.com/bitcoin/bitcoin/pull/32409

21:10 <bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5b8046a6e893...eba5f9c4b63f

21:10 <bitcoin-git> bitcoin/master 3add6ab fanquake: test: remove Boost SIGCHLD workaround.

21:10 <bitcoin-git> bitcoin/master eba5f9c Ava Chow: Merge bitcoin/bitcoin#32403: test: remove Boost SIGCHLD workaround.

21:10 <bitcoin-git> [bitcoin] achow101 merged pull request #32403: test: remove Boost SIGCHLD workaround. (master...drop_boost_signal) https://github.com/bitcoin/bitcoin/pull/32403