16:00:21 <achow101> #startmeeting 
16:00:21 <corebot> achow101: Meeting started at 2025-06-26T16:00+0000
16:00:22 <corebot> achow101: Current chairs: achow101
16:00:23 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:24 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:25 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:29 <achow101> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
16:00:31 <TheCharlatan> hi
16:00:32 <hebasto> hi
16:00:35 <janb84> #here 
16:00:38 <johnny9dev> hi
16:00:39 <sipa> hi
16:00:40 <brunoerg> hi
16:00:41 <janb84> hi
16:00:46 <fjahr> hi
16:00:46 <glozow> hi
16:00:49 <willcl-ark> hi
16:00:58 <laanwj> hi
16:01:15 <achow101> There is one preproposed meeting topic this week, any last minute ones to add?
16:01:18 <stickies-v> hi
16:01:23 <pinheadmz> Hi
16:01:27 <Murch[m]> Hi
16:01:30 <instagibbs> hi
16:01:41 <sr_gi[m]1> hi
16:01:50 <darosior> hi
16:01:51 <achow101> #topic Erlay WG Update (sr_gi, gleb)
16:02:08 <furszy> hi
16:03:39 <sr_gi[m]1> I went back to look at the code and see if I could find why the propagation times were too good to be true, and I may have found the underlaying issue. Some transaction were being announced via reconciliation before those peers should have been aware of it, which may have made Erlay faster. I patched that yesterday and I'm currently working on re-simulate it to make sure
16:04:15 <sr_gi[m]1> I'll report back once I have some results
16:04:29 <Murch[m]> sr_gi: Alternatively, you should also make sure that you didn’t accidentally invent faster-than-light communication! ;)
16:04:55 <sr_gi[m]1> lol
16:05:03 <Murch[m]> j/k, makes sense
16:05:15 <sr_gi[m]1> Transaction are actually traveling back in time :P
16:06:09 <sr_gi[m]1> That's it for me, hopping to have some results by next week
16:06:14 <achow101> #topic Kernel WG Update (TheCharlatan)
16:06:39 <TheCharlatan> Been talking to some people about splitting up cs_main and allowing net_processing to call validation functions without being blocked on their return. Been trying out a few approaches for this, but I feel like this will take some time before I can share results on one approach or the other.
16:06:47 <kanzure> hi
16:06:50 <TheCharlatan> We also got another go wrapper for the library: https://github.com/stringintech/go-bitcoinkernel
16:07:05 <TheCharlatan> Looking for review on #32317
16:07:08 <corebot> https://github.com/bitcoin/bitcoin/issues/32317 | kernel: Separate UTXO set access from validation functions by TheCharlatan · Pull Request #32317 · bitcoin/bitcoin · GitHub
16:07:12 <TheCharlatan> That's all :)
16:07:19 <sipa> sr_gi[m]1: https://github.com/bitcoin/bitcoin/blob/master/src/addrman.cpp#L75
16:08:03 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:08:05 <sr_gi[m]1> sipa: basically
16:08:30 <furszy> TheCharlatan: I might have something for you. Let's talk later :).
16:08:38 <sipa> hi
16:08:45 <sipa> no updates, i think?
16:09:12 <achow101> #topic MuSig2 WG Update (achow101, rkrux)
16:09:26 <achow101> Addressed review in #31244 which I think is probably rfm. The remaining comments are nits that I think can be addressed in followups.
16:09:30 <corebot> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
16:09:47 <darosior> TheCharlatan: cool!
16:10:00 <achow101> #topic orphan resolution WG Update (glozow)
16:10:07 <glozow> #31829 is making progress, thanks for all the reviews! I’m looking at the newer comments today re benchmarking.
16:10:11 <corebot> https://github.com/bitcoin/bitcoin/issues/31829 | p2p: improve TxOrphanage denial of service bounds by glozow · Pull Request #31829 · bitcoin/bitcoin · GitHub
16:10:27 <sipa> glozow: i'm writing a simulation fuzz test for it, it almost works
16:10:32 <instagibbs> glozow ah you're doing it? I won't duplicate effort then :)
16:10:46 <sipa> (everything except LimitOrphans, which is just a minor detail right)
16:10:56 <instagibbs> sipa ez
16:10:57 <glozow> sipa: hahaha. thanks!
16:11:15 <glozow> instagibbs: just trying to decipher the description atm
16:11:24 <glozow> Do we want this bench inside the PR?
16:11:43 <sipa> i think it should be in the PR, can use bench.epochs(1) to avoid measuring the setup time
16:11:51 <glozow> I originally dropped all of them because they were just for feeling out worst cases, not for demonstrating speedups
16:12:13 <instagibbs> can drop the non-evict bench if the epochs(1) thing works
16:12:22 <sipa> not making worst cases worse is also interesting
16:12:38 <glozow> sure 👍 I can bring back the EraseForBlock ones too then
16:12:41 <instagibbs> also informs any constant changes in future
16:14:29 <sipa> glozow: the example instagibbs posted is the one we worked out when designing the dos score idea
16:14:42 <sipa> though with more concrete numbers for what is actually implemented now
16:15:14 <glozow> ah, wait how does it differ from the one I implemented?
16:15:32 <instagibbs> We can chat offline
16:15:38 <sipa> i have no idea, i did not review the benchmarks :)
16:15:59 <glozow> okok
16:16:05 <achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
16:16:30 <johnny9dev> Back from BTCPrague now. Presented a demo of the wallet during the Dev/Hack/Day and it went well. General feedback was that this seems like an obvious thing to build so that was encouraging. Currently working on getting PRs setup to update the gui-qml repo with all of the features that were added for the demo.
16:16:30 <johnny9dev> Afterwards, focus is going to be on rebase, submoduling, and figuring out what CI and release might look like for this project.
16:18:01 <achow101> #topic Script Validation WG Update (fjahr)
16:18:28 <fjahr> nothing significant to share, kind of waiting for an update on the secp batch PR and need to ask for an update there
16:19:35 <achow101> #topic mutation testing update (brunoerg)
16:19:47 <brunoerg> Hi, just a quick update! Some time ago I announced bitcoincore.space, but we just integrated mutation testing into corecheck, so I’m not going to update that anymore. You can see Core mutation testing report at corecheck.dev/mutation. This report is updated once a week. We’re working to make the whole process more efficient and soon we will expand it to more part of the codebase. Based on the last run,
16:19:47 <brunoerg> there are 326 unkilled mutants. Of course, we can ignore some of them, but there are many interesting cases that we should address in our tests. Thanks @m3dwards for making it happen.
16:21:02 <achow101> neat!
16:21:37 <achow101> Any other topics to discuss this week?
16:21:57 <stickies-v> very nice dashboard, thanks brunoerg !
16:22:01 <fjahr> Just a note that didn’t seem worth a topic: Since the embedded ASMap PR is making progress I think there is necessity to discuss the asmap org which houses the data we are using (as it is currently planned). I think there should be some access sharing just in case of emergency because I am the only owner right now. But I think this can wait until the PR is merged and I think the next in-person meeting would be good to
16:22:01 <fjahr> discuss this unless there are objections, i.e. people see this as a blocker to merging the PR.
16:23:14 <sipa> the current PR doesn't enable it by default yet, but it does incorporate the community-built asmap data into the release binary
16:23:37 <sipa> i think it may make sense to transfer the asmap-data repo at least to the bitcoin-core org
16:24:54 <fjahr> Right, happy to do that now or after the PR is merged.
16:25:58 <sipa> we can discuss on the PR i think
16:26:10 <achow101> #endmeeting