00:18 <bitcoin-git> [bitcoin] hebasto opened pull request #32383: util: Remove `fsbridge::get_filesystem_error_message()` (master...250429-fs-error) https://github.com/bitcoin/bitcoin/pull/32383

00:27 <bitcoin-git> [bitcoin] w0xlt closed pull request #32382: Make `cs_db` mutex non-recursive (master...cs_db) https://github.com/bitcoin/bitcoin/pull/32382

06:31 <bitcoin-git> [bitcoin] w0xlt opened pull request #32384: Make `cs_db` mutex non-recursive (master...cs_db) https://github.com/bitcoin/bitcoin/pull/32384

08:04 <hebasto> sipa:https://x.com/NicolasDorier/status/1917370497001742660

08:15 <bitcoin-git> [bitcoin] stratospher opened pull request #32385: test: add test for malleated transaction with valid witness (master...2025_04_tx_malleate) https://github.com/bitcoin/bitcoin/pull/32385

12:01 <bitcoin-git> [bitcoin] Sjors opened pull request #32386: mining: rename gbt_force and gbt_force_name (master...2025/04/gbt) https://github.com/bitcoin/bitcoin/pull/32386

12:43 <bitcoin-git> [bitcoin] ryanofsky opened pull request #32387: [DRAFT] ipc: add windows support (master...pr/ipc-win) https://github.com/bitcoin/bitcoin/pull/32387

13:54 <bitcoin-git> [bitcoin] w0xlt closed pull request #32384: Make `cs_db` mutex non-recursive (master...cs_db) https://github.com/bitcoin/bitcoin/pull/32384

14:14 <bitcoin-git> [bitcoincore.org] fanquake opened pull request #1129: blog: ammend date of latest advisory (master...fixup_postdate) https://github.com/bitcoin-core/bitcoincore.org/pull/1129

14:38 <bitcoin-git> [bitcoincore.org] fanquake pushed 2 commits to master: https://github.com/bitcoin-core/bitcoincore.org/compare/bfe173782999...c88f668c15b2

14:38 <bitcoin-git> bitcoincore.org/master bc98e70 fanquake: blog: ammend date of latest advisory

14:38 <bitcoin-git> bitcoincore.org/master c88f668 merge-script: Merge bitcoin-core/bitcoincore.org#1129: blog: ammend date of latest advis...

14:38 <bitcoin-git> [bitcoincore.org] fanquake merged pull request #1129: blog: ammend date of latest advisory (master...fixup_postdate) https://github.com/bitcoin-core/bitcoincore.org/pull/1129

15:19 <bitcoin-git> [gui] D33r-Gee opened pull request #870: [DRAFT] Expose AssumeUTXO Load Snapshot Functionality To The GUI (master...2025_gui_interfaces_loadsnapshot_poc) https://github.com/bitcoin-core/gui/pull/870

15:23 <bitcoin-git> [gui] D33r-Gee closed pull request #869: interface: Expose load utxo snapshot functionality (master...2025_gui_interfaces_loadsnapshot) https://github.com/bitcoin-core/gui/pull/869

17:56 <bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/14b8dfb2bd5e...68ac9f116c02

17:56 <bitcoin-git> bitcoin/master 97eaadc Hennadii Stepanov: util: Remove `fsbridge::get_filesystem_error_message()`

17:56 <bitcoin-git> bitcoin/master 68ac9f1 Ava Chow: Merge bitcoin/bitcoin#32383: util: Remove `fsbridge::get_filesystem_error_...

17:56 <bitcoin-git> [bitcoin] achow101 merged pull request #32383: util: Remove `fsbridge::get_filesystem_error_message()` (master...250429-fs-error) https://github.com/bitcoin/bitcoin/pull/32383

17:58 <bitcoin-git> [bitcoin] maflcko opened pull request #32388: fuzz: Remove unused TimeoutExpired catch in fuzz runner (master...2504-fuzz-timeout) https://github.com/bitcoin/bitcoin/pull/32388

17:59 <bitcoin-git> [bitcoin] maflcko closed pull request #32339: ci: Merge fuzz task for macOS (master...2504-ci-merge) https://github.com/bitcoin/bitcoin/pull/32339

19:12 <bitcoin-git> [bitcoin] darosior closed pull request #32381: policy: allow more than one OP_RETURN outputs per tx (master...2504_fixthefiltersyo) https://github.com/bitcoin/bitcoin/pull/32381

22:35 <fjahr> pinheadmz: Not sure if the ML is the right place for that bitcoin core meta discussion, so writing it here instead: Agree that it would be good to split conceptual and technical review but also skeptical the discussion post would get traction. And even if it did, people could still copy+paste their messages into the PR later.

22:35 <fjahr> A more strict approach would be to open the PR right away but lock it to org members, so the PR is only reserved for technical review. Then there could be an issue that is linked to the PR (via closes #XXX) and that is where the conceptual discussion takes place. This is a bit backwards compared to what we often do: first open an issue, discuss the idea there, then open a PR. But if the PR is the only thing that triggers

22:35 <fjahr> people to jump into action, then maybe this is worth a shot.

22:36 <fjahr> I wouldn't want to do this for policy changes in general, though. Only in the very rare occasions where we know there will be these emotional discussions.

22:40 <Murch[m]> Unfortunately, it’s not possible to lock individual PRs and Issues only to org members, according to achow101 here: https://github.com/bitcoin-core/meta/issues/19#issuecomment-2839879023

22:40 <fjahr> Ah, ok, I thought we had done this before :/

22:40 <achow101> we can only lock to people with write permission, i.e. maintainers

22:45 <fjahr> So just make everyone maintainer while we have a controversial PR open? :p

22:47 <Murch[m]> haha

22:49 <achow101> hmm, I think it actually may be possible to give frequent contributors the write permission, while restricting the ability to actually push any commits to the branches

22:49 <achow101> but there might be some other side effects with that

22:50 <achow101> probably need to play around with these settings somewhere else first

22:54 <achow101> there's a lot of branch protection rules that we haven't really explored

23:21 <lightlike> I don't think there is an actual problem if all we want is separation: just have a maintainer announce "this is the issue / thread where all the conceptual discussion goes, this is the PR for technical review. They belong together and will be evaluated together, but please post in the correct one" and then delete posts (from regulars and drive-by accounts alike) if they are in the wrong one.

23:42 <jonatack> lightlike: sgtm. perhaps a moderator or even the pull author can announce that as well

23:46 <achow101> it's actually unclear to me whether regular contributors would have anything to say when a pr is locked?

23:47 <achow101> and it would definitely piss off more people if the "in group" can comment but no one else can. that feeds into the perception of being a cabal