16:00:52 <achow101> #startmeeting 
16:00:52 <corebot> achow101: Meeting started at 2025-10-30T16:00+0000
16:00:53 <corebot> achow101: Current chairs: achow101
16:00:54 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:55 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:56 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:01:01 <rkrux> hi
16:01:02 <kevkevin> hi again
16:01:05 <janb84> hi
16:01:07 <stringintech> hi
16:01:07 <brunoerg> hi
16:01:18 <achow101> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs janb84 jarolrod jonatack josibake kanzure kevkevin laanwj LarryRuane lightlike l0rinc luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
16:01:29 <TheCharlatan> hi
16:01:32 <abubakarsadiq> hi
16:01:37 <stickies-v> hi
16:01:46 <fjahr> hi
16:01:53 <b10c> hi
16:01:54 <lightlike> Hi
16:02:18 <achow101> There is one preproposed meeting topic this week, any last minute ones to add?
16:02:27 <_aj_> hi
16:02:48 <eugenesiegel> hi
16:02:55 <marcofleon> hi
16:03:54 <achow101> As I mentioned last week, I will be calling on _all_ working groups on list for an update. If you don't say anything within 1 min, I'll be moving on to the next one.
16:04:17 <achow101> The list is https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Working-Groups#current-working-groups if there's a working group on it that isn't active, please edit the wiki page to remove it.
16:04:32 <dzxzg> hi
16:04:53 <achow101> (by say anything, I mean at least acknowledge if you do or don't have an update to give, so that I can give you time to type it out)
16:05:30 <achow101> #topic Erlay WG Update (sr_gi, gleb)
16:06:48 <achow101> #topic Fuzzing WG Update (dergoegge)
16:07:28 <dergoegge> no update
16:07:35 <achow101> #topic Kernel WG Update (TheCharlatan)
16:07:42 <TheCharlatan> Been getting review on #30595 and asking for even more :)
16:07:45 <corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
16:07:49 <TheCharlatan> That's all.
16:08:05 <achow101> #topic Benchmarking WG Update (l0rinc)
16:08:40 <l0rinc> I forgot about the meeting, will report at the end :)
16:08:55 <achow101> #topic Silent Payments WG Update (RubenSomsen)
16:09:12 <achow101> we may need to change who is reporting for silent payments
16:09:39 <dzxzg> I nominate josibake :D
16:09:56 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:11:32 <achow101> #topic Stratum v2 WG Update (sjors)
16:12:22 <Sjors[m]1> No news atm
16:12:30 <achow101> #topic Multiprocess WG Update (ryanofsky)
16:12:31 <instagibbs> cluster mempool is still #33629 fwiw, one thing to review
16:12:37 <corebot> instagibbs: Error: That URL raised <Connection timed out.>
16:13:04 <kevkevin> https://github.com/bitcoin/bitcoin/pull/33629
16:14:06 <achow101> #topic QML GUI WG Update (johnny9dev)
16:15:15 <achow101> #topic Script Validation WG Update (fjahr)
16:15:23 <fjahr> I’ve implemented a more convenient way to check performance across multiple thread worker configs in #33740, which will be helpful for this work. Looking for feedback if this is generally useful enough to be considered for merging. Nothing to report aside from that.
16:15:24 <corebot> https://github.com/bitcoin/bitcoin/issues/33740 | RFC: bench: Add multi thread benchmarking by fjahr · Pull Request #33740 · bitcoin/bitcoin · GitHub
16:16:01 <achow101> #topic Net Split WG Update (cfields)
16:16:11 <eugenesiegel> nothing to report yet
16:16:29 <achow101> #topic Benchmarking WG Update take 2 (l0rinc)
16:16:42 <l0rinc> We've been discussing the parallel block input fetcher with Andrew Toth, we had a lot of ideas on how to make it even better and we've achieved 25% reindex-chainstate speedup there on an Rpi5 with default 450 MB memory.
16:16:57 <l0rinc> I have investigated if sorted UTXO fetching would also be faster (like how sorted writing is also done) - and it revealed a 4-10% speedup even on a single thread. So I will try to see how this fits into the parallel fetching in general.
16:17:10 <l0rinc> I have also just checked two ideas that we've discussed with sipa:
16:17:26 <l0rinc> hiding the bip30 checks behind assumevalid, which would enable us removing the bloom filters from LevelDB since we won't need to check for missing entries anymore. This seems to shrink the on-disk UTXO size by roughly 1% (122MB smaller, see the draft here https://github.com/l0rinc/bitcoin/pull/49) while slightly speeding up IBD as well. I'd be interested in what concerns people have about this idea.
16:18:01 <l0rinc> The other idea we've discussed was to use a simpler SipHash for the volatile usages (e.g. hashmap keys) and we've both contacted the author who agreed that we don't actually need a heavyweight SipHash24 for these cases, but a Siphash13 or even a dedicated SipHasher for our use case would likely suffice. I will code these up later, but I the prototype shows measurable IBD speedup around 4%.
16:18:45 <janb84> wow
16:19:45 <l0rinc> The interesting finding about the sorting (revealed by differential flame graphs) was that IBD is actually faster because of the UTXO writing
16:20:02 <l0rinc> since after Andrew's change in 28 we have a linked list of dirty items as well
16:20:08 <l0rinc> so the fetching order matters
16:20:36 <achow101> no strong opinion on the hash funciotn, will be interested in the pr
16:20:39 <l0rinc> That's it from me, thanks
16:20:53 <johnny9dev> For gui-qml I'm working on getting depends/guix building for the project. I have a solution using patches and the submodule's depends makefile that is working for me locally. Will PR that soon. For guix, I don't have a solution yet.
16:21:11 <achow101> #topic rotating irc meeting chair (achow101)
16:21:58 <achow101> as was mentioned last week, we should have more than one person doing irc meetings
16:22:47 <achow101> since we have previously fallen into the trap of the tragedy of the commons when there wasn't anyone who was specifically suposed to do it, I think we should setup a rotation of 3 or 4 people
16:22:58 <achow101> any volunteers?
16:23:14 <fjahr> Still happy to take part in this, I’ve stepped in once or twice in the past. But the time of day recently hasn’t always been ideal for me so I will have to skip the meeting from time to time. But I should know that well in advance and so I can take some of the meetings with prior coordination.
16:23:21 <achow101> I'm still willing to run them
16:23:33 <dergoegge> i fell like a bot (with llm in hand) could do it?
16:23:48 <stickies-v> i'm happy to run a few too
16:23:55 <instagibbs> dergoegge I read this as "I feel like a bot"
16:24:25 <glozow> dergoegge are you volunteering to run them using a bot?
16:24:27 <achow101> dergoegge: for most meetings sure, but there's edge cases where the chair needs to actually cut off a discussion when it gets off topic or starts running over time
16:25:44 <dergoegge> i can prototype a bot and we can test it out?
16:25:55 <achow101> fjahr: stickies-v: great, I'll reach out privately
16:26:21 <achow101> dergoegge: go ahead
16:27:41 <achow101> Any other topics to discuss?
16:28:04 <stickies-v> should we take silent payments from the rotation until a new champion pops up?
16:28:10 <achow101> stickies-v: I think so
16:28:28 <abubakarsadiq> I would volunteer as well @achow101
16:28:35 <glozow> Think we should generally remove projects if their people don’t show up n times in a row
16:29:26 <achow101> abubakarsadiq: for irc meeting chair?
16:29:33 <abubakarsadiq> yes
16:29:43 <stickies-v> i vote n=2 (if no notice given)
16:29:52 <achow101> glozow: yes
16:29:52 <stickies-v> keeping meeting pace up is important imo
16:30:25 <_aj_> (auto-skipping wg's if none of their champions say "hi" would be good if not too much hassle imo)
16:30:37 <fjahr> what happens when the person shows up again at the next meeting after removal? is the counter reset?
16:30:47 <abubakarsadiq> _aj_ that was the previous approach I think
16:30:58 <achow101> _aj_: the idea was to encourage people to participate by making participation mandatory :)
16:31:32 <stickies-v> fjahr: yeah n in a row, that's why i'd keep n small so we don't need to hire an accountant (or have dergoegge write a bot)
16:31:33 <fjahr> n=2 feels like we will get a lot of OOO notices here soon
16:31:49 <achow101> we basically had ~half of working groups not give an update at all previously, and I think that was working counter to the whole idea
16:31:56 <_aj_> achow101: "No update from <wg> (alice, bob missing)" would work for that imo
16:32:20 <stickies-v> if wg's stop giving updates perhaps they're not active wg's anymore? no need to lengthen out the process of (temporarily) archiving that imo
16:32:21 <abubakarsadiq> It makes to just remove the wg when no notice has been given and champion is mia consecutively
16:32:40 <achow101> fjahr: i think that's fine tbh
16:32:52 <_aj_> eugenesiegel: is there a tracking issue for net split project btw?
16:33:32 <achow101> _aj_: on a sample size of n=1, we got updates from l0rinc and johnny9dev even though they did not say hi earlier in the meeting
16:33:33 <eugenesiegel> _aj_: I don't think so? might be wrong
16:34:04 <dzxzg> also if a WG sends a member as delegate e.g. eugenesiegel updating for netsplit
16:34:36 <_aj_> achow101: easy to followup to a "No update from..." message later in the meeting too though
16:35:10 <_aj_> dzxzg: insta for cluster as well
16:35:43 <_aj_> anyway, just suggesting it to save 1m of silence, if it's a hassle, no worries
16:36:08 <l0rinc> hi achow101 :)
16:36:11 <achow101> it's only a minute, which is fine as long as we don't have 60 working groups
16:36:24 <achow101> Any other topics to discuss?
16:38:27 <achow101> #endmeeting