16:09:06 <nervana21> #startmeeting 
16:09:06 <corebot> nervana21: Meeting started at 2026-11-05T16:09+0000
16:09:07 <corebot> nervana21: Current chairs: nervana21
16:09:08 <hebasto> hi
16:09:09 <corebot> nervana21: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:09:10 <corebot> nervana21: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:09:11 <corebot> nervana21: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:09:17 <dzxzg> ah haha
16:09:32 <dzxzg> #topic Benchmarking WG Update (l0rinc)
16:09:44 <l0rinc_> not strictly benchmarking, but pushed another step toward narrowing AssumeUTXO: #36778 replaces the loading RPC with a startup arg, so we can at least avoid all the weird corner cases of loading a UTXO set on top of an existing chainstate
16:09:45 <corebot> https://github.com/bitcoin/bitcoin/issues/36778 | assumeutxo: replace `loadtxoutset` RPC with a startup arg by l0rinc · Pull Request #36778 · bitcoin/bitcoin · GitHub
16:09:55 <l0rinc_> that's it from me
16:10:13 <dzxzg> #topic Kernel WG Update (sedited)
16:10:23 <stickies-v> hi
16:10:55 <sedited> still hunting for review on #35641
16:10:58 <corebot> https://github.com/bitcoin/bitcoin/issues/35641 | kernel: Add script evaluation tracer by sedited · Pull Request #35641 · bitcoin/bitcoin · GitHub
16:11:01 <bitcoindev1337> #topic Disk error handling inconsistencies
16:11:06 <jonatack> sorry to interject: asmap run in 6 minutes https://github.com/bitcoin-core/asmap-data/issues/79
16:11:54 <sedited> Also wanted to highlight a tracking issue for making our unit tests more declarative in style: https://github.com/bitcoin/bitcoin/issues/36692
16:12:30 <b10c> jonatack: thanks, would have forgot
16:12:47 <abubakarsadiq> time change got me, sorry. Thanks @dzxzg
16:12:48 <sedited> I think this is an interesting initiative, since we've seen other implementations port our existing unit tests with LLMs.
16:13:01 <sedited> most chaotic meeting ^^
16:13:03 <sedited> that's all.
16:13:25 <dzxzg> #topic QA WG Update (brunoerg)
16:13:36 <brunoerg> no update this week
16:14:12 <dzxzg> last of the WG's i believe is a new one
16:14:14 <dzxzg> #topic addr-relay WG update (stratospher)
16:14:48 <dzxzg> I'm not sure that stratospher is here but I can say a bit
16:15:01 <darosior> Go ahead, i'll ping her IRL
16:15:07 <b10c> she can read, but not type
16:15:55 <dzxzg> There has been ongoing spam of existing addresses with fresh timestamps, this pins addresses in the new table, some discussions were had recently about how to mitigate this, and a WG has been formed to move forward with these changes
16:16:32 <dzxzg> There are also some longstanding issues in Addrman that should be addressed, like the service flags problems, and address relay problems that exist because peers control the address timestamps
16:16:49 <darosior> Stratospher says "hi! we have an address relay WG now. feel free to ping me if you’d like to join. (getting my IRC ready)"
16:17:04 <dzxzg> cool, that's all from me as well.
16:17:06 <lightlike> see https://bnoc.xyz/t/address-relay-under-stress/163 and https://bnoc.xyz/t/address-relay-under-stress-attack-characteristics-and-measuring-its-effects/164 for some more details of current problems.
16:18:09 <dzxzg> OK i think there are no further WG's (speak up if I missed you)
16:19:02 <dzxzg> #topic Disk error handling inconsistencies
16:19:24 <stickies-v> (cc bitcoindev1337)
16:19:38 <darosior> stickies-v monitoring the situation
16:19:57 <bitcoindev1337> the way disk errors are handled is extremely inconsistent depending on the exact code path that triggers the error
16:20:42 <bitcoindev1337> for example anything that triggers inside the try/catch block in process messages will be ignored unless specifically handled, but if the exact same error is triggered in rpc it might cause the node to shutdown entirely
16:21:54 <bitcoindev1337> some of the things ignored in the try/catch should actually cause a wallet node to abort but a non-wallet node not to abort, etc etc
16:22:12 <bitcoindev1337> my point is this needs an actual plan instead of piecemeal looking at crashes
16:22:23 <bitcoindev1337> im interested in other peoples thoughts on it
16:23:14 <jonatack> bitcoindev1337: is there an RFC issue open
16:24:19 <jonatack> seems worth discussing in one
16:24:58 <sedited> there's many pull requests open addressing aspects of it, with a lot of discussions on the topic over the past years.
16:25:09 <bitcoindev1337> i dont think so and i'd open one but i got banned for a comment on 36761
16:25:44 <sedited> there's also #36101
16:25:47 <corebot> https://github.com/bitcoin/bitcoin/issues/36101 | doc: Add an error handling strategy by purpleKarrot · Pull Request #36101 · bitcoin/bitcoin · GitHub
16:25:51 <bitcoindev1337> i really dislike discussion like that in pull requests since the op often has their own ideas which push around the discussion unduly
16:26:01 <pinheadmz> bitcoindev1337 ill unblock you but please keep the quality up
16:26:09 <pinheadmz> also see #35003
16:26:12 <corebot> https://github.com/bitcoin/bitcoin/issues/35003 | validation: improve block data I/O error handling in P2P paths by furszy · Pull Request #35003 · bitcoin/bitcoin · GitHub
16:26:14 <pinheadmz> this is sounding familiar
16:27:22 <dzxzg> OK, it seems like #36101 might be the most relevant place to discuss if people have further thoughts
16:27:25 <corebot> https://github.com/bitcoin/bitcoin/issues/36101 | doc: Add an error handling strategy by purpleKarrot · Pull Request #36101 · bitcoin/bitcoin · GitHub
16:27:37 <dzxzg> #topic CVE-2026-117349 and CVE-2026-117350 followups (darosior)
16:27:57 <darosior> So we deployed patches for CVE-2026-117349 and CVE-2026-117350 last week. Thanks everyone involved in reviewing and accelerating that process. We had binaries available within about 48h of the mitigations PRs being made public, which is not bad for a first run of this new policy
16:27:59 <bitcoindev1337> i'll take a look at those and see what's already been discussed thank you
16:28:08 <darosior> Now that those were made available, i'm curious if anyone has been thinking about cleanups, as well as improving our testing / understanding there?
16:28:24 <stratospher> hi?
16:28:36 <darosior> stratospher: pong
16:28:39 <darosior> Cleanups because those were merely stopgaps, we should aim to fix those issues more fundamentally now that the dust settled down. For instance for CVE-2026-117349, the root cause is that we have unbounded growth in some p2p data structure. We fixed it with a timer to keep the growth manageable, but this is brittle, we should aim to have bounds on
16:28:39 <darosior> the memory usage peers can impose on us
16:29:51 <darosior> I've been working on this for CVE-2026-117350, hardening our tests in this area, and i opened #36761 to discuss longer term cleanups
16:29:52 <corebot> https://github.com/bitcoin/bitcoin/issues/36761 | RFC: switch from select() to poll() on all platforms · Issue #36761 · bitcoin/bitcoin · GitHub
16:30:13 <bitcoindev1337> darosior like the select/poll thing that's a surprisingly hard thing to do without accidentally disconnecting legitimate peers
16:31:03 <darosior> bitcoindev1337: i think always disconnecting on polling errors is fine, just not ideal for the http server
16:31:52 <darosior> But we should be consistent, and document our choices, and test our invariants, to prevent something similar to happen in the future because barely anyone remembers how it works in details, and then such a surprise happens
16:32:22 <eugenesiegel> are you specifically seeking feedback about poll/select or other things also related to sockets ?
16:32:44 <darosior> I am curious what everyone thinks we should do about those, and i have one more question i'm typing now
16:33:04 <darosior> Like just deploying the stopgap and forgetting about those will come back to bite us
16:34:14 <darosior> I've also been looking into post CVE-2026-117349 cleanups, and that would be some non completely trivial refactorings, but doable. However i have other things i'd like to work on that i temporarily dropped for the security releases, and these hardenings, so i'd like to know if there is any will to review such refactorings before i commit more time
16:34:14 <darosior> to implementing those
16:34:56 <sedited> what did roughly did you have in mind?
16:35:11 <darosior> For 117349?
16:35:30 <jonatack> yes
16:35:52 <sedited> ja
16:36:25 <dzxzg> I'd help review, I agree that leaving it mitigated and poorly understood leaves dangerous technical debt
16:37:08 <darosior> sedited: 1) changing the tx INVs token bucket manager to use a single, bounded queue for all peers. Each peer keeps its cursor. 2) moving the parts of SendMessages() that actually pile up messages for peers towards the end, and early return on fPauseSend to not reach those
16:37:39 <darosior> It's just incredibly surprising that fPauseSend does not pause SendMessages(), but there are good reasons for doing so currently
16:38:13 <darosior> 3) some minor cleanups for other less frequent announcements
16:39:19 <eugenesiegel> I could review as a backup if I'm able to clear some of my backlog. I think fundamentally fixing these issues is the right idea. I also think the socket code deserves more scrutiny
16:40:01 <jonatack> darosior: feel free to ping me to review the PR
16:40:28 <darosior> sedited: but it's just one half-baked idea, which is why i ask here, my thoughts have mostly been on #36761 the past couple weeks.
16:40:29 <corebot> https://github.com/bitcoin/bitcoin/issues/36761 | RFC: switch from select() to poll() on all platforms · Issue #36761 · bitcoin/bitcoin · GitHub
16:40:49 <darosior> Ok, thanks everyone. That's all i had.
16:41:15 <dzxzg> Anything else to discuss?
16:41:59 <dzxzg> #endmeeting 
16:42:14 <nervana21> #endmeeting