16:00:27 <achow101> #startmeeting 
16:00:27 <corebot> achow101: Meeting started at 2025-08-07T16:00+0000
16:00:28 <corebot> achow101: Current chairs: achow101
16:00:29 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:30 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:31 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:33 <darosior> hi
16:00:35 <TheCharlatan> hi
16:00:36 <jon_atack> hi
16:00:38 <glozow> hi (btw orphan reso can be removed from WGs)
16:00:39 <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:39 <kevkevin> hi
16:00:42 <hebasto> hi
16:00:43 <willcl-ark> Hi
16:00:44 <Murch[m]> hi
16:00:45 <eugenesiegel> hi
16:00:46 <pinheadmz> Wassup
16:00:46 <lightlike> hi
16:00:49 <abubakarsadiq> hi
16:01:08 <achow101> There are no pre-proposed meeting topics this week. Any last minute ones to add?
16:01:11 <purpleKarrot> hi
16:01:14 <stickies-v> hi
16:01:15 <hodlinator> hi
16:01:48 <darosior> achow101: i'm curious if people believe whether the minrelaytxfee PR should be backported before 29.1 is released
16:02:08 <darosior> that was not quite english, but close
16:02:16 <sipa> hi
16:02:31 <cfields> hi
16:02:41 <achow101> #topic Kernel WG Update (TheCharlatan)
16:03:42 <TheCharlatan> I'll pass this week
16:04:00 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:04:37 <sipa> getting close!
16:04:59 <kanzure> hi
16:05:04 <sipa> (to the start of the actual race, getting #28676 in)
16:05:08 <corebot> https://github.com/bitcoin/bitcoin/issues/28676 | Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
16:05:46 <sipa> i'm working on a small PR to improve/control/observe memory usage in TxGraph, but review can shift to sdaftuar's PR now
16:06:25 <sipa> i had a few ideas on improving SFL too during my offline vacation too, will post about in due time, nothing urgent about that
16:06:33 <sipa> that's it for me
16:06:51 <achow101> #topic MuSig2 WG Update (achow101)
16:07:02 <achow101> #29675 is the final PR and is ready to be reviewed. I've addressed the current comments as well as pulling in several of the followup suggestions from #31244.
16:07:04 <corebot> https://github.com/bitcoin/bitcoin/issues/29675 | wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101 · Pull Request #29675 · bitcoin/bitcoin · GitHub
16:07:08 <corebot> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
16:07:54 <achow101> #topic v30.0 feature freeze
16:08:09 <achow101> feature freeze is in 2 weeks
16:08:30 <sipa> 2 weeks (tm)
16:08:37 <achow101> Anything to add or remove from the milestone? https://github.com/bitcoin/bitcoin/milestone/72
16:08:50 <achow101> and please review things that are in the milestone
16:09:07 <darosior> i'd really like to have #33050  and #32473 in for 30
16:09:09 <corebot> https://github.com/bitcoin/bitcoin/issues/33050 | net, validation: don't punish peers for consensus-invalid txs by ajtowns · Pull Request #33050 · bitcoin/bitcoin · GitHub
16:09:11 <corebot> https://github.com/bitcoin/bitcoin/issues/32473 | Introduce per-txin sighash midstate cache for legacy/p2sh/segwitv0 scripts by sipa · Pull Request #32473 · bitcoin/bitcoin · GitHub
16:09:27 <hodlinator> #32579 would be nice, but far from critical.
16:09:32 <corebot> https://github.com/bitcoin/bitcoin/issues/32579 | headerssync: Preempt unrealistic unit test behavior by hodlinator · Pull Request #32579 · bitcoin/bitcoin · GitHub
16:10:02 <l0rinc> I'd like to include #33021 and #32975, if possible
16:10:04 <corebot> https://github.com/bitcoin/bitcoin/issues/33021 | test: revive test verifying that `GetCoinsCacheSizeState` switches from OK→LARGE→CRITICAL by l0rinc · Pull Request #33021 · bitcoin/bitcoin · GitHub
16:10:05 <corebot> https://github.com/bitcoin/bitcoin/issues/32975 | assumevalid: log every script validation state change by l0rinc · Pull Request #32975 · bitcoin/bitcoin · GitHub
16:10:21 <darosior> Will re-review #32473 today after the latest update. #33050 has been waiting on _aj_ to address comments there but it shouldn't be long
16:10:23 <corebot> https://github.com/bitcoin/bitcoin/issues/32473 | Introduce per-txin sighash midstate cache for legacy/p2sh/segwitv0 scripts by sipa · Pull Request #32473 · bitcoin/bitcoin · GitHub
16:10:24 <corebot> https://github.com/bitcoin/bitcoin/issues/33050 | net, validation: don't punish peers for consensus-invalid txs by ajtowns · Pull Request #33050 · bitcoin/bitcoin · GitHub
16:10:36 <dergoegge> probably #33106 ?
16:10:37 <lightlike> should #33106 be in the milestone?
16:10:38 <corebot> https://github.com/bitcoin/bitcoin/issues/33106 | policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee by glozow · Pull Request #33106 · bitcoin/bitcoin · GitHub
16:10:39 <corebot> https://github.com/bitcoin/bitcoin/issues/33106 | policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee by glozow · Pull Request #33106 · bitcoin/bitcoin · GitHub
16:10:46 <TheCharlatan> ^^
16:10:56 <darosior> Yeah clearly
16:11:12 <achow101> darosior, dergoegge, lightlike: added
16:12:03 <achow101> hodlinator: l0rinc: added
16:12:55 <fanquake> i don't see what is relevant to 30 about #33021 or #32975 ? Seems general, and will distract review from more important things?
16:12:56 <corebot> https://github.com/bitcoin/bitcoin/issues/33021 | test: revive test verifying that `GetCoinsCacheSizeState` switches from OK→LARGE→CRITICAL by l0rinc · Pull Request #33021 · bitcoin/bitcoin · GitHub
16:12:58 <corebot> https://github.com/bitcoin/bitcoin/issues/32975 | assumevalid: log every script validation state change by l0rinc · Pull Request #32975 · bitcoin/bitcoin · GitHub
16:13:07 <sipa> darosior: i have a very last minute, possible-even-simpler idea for getting rid of WITNESS_STRIPPED, will either open a PR in the next hour or so, or review #33105
16:13:09 <corebot> https://github.com/bitcoin/bitcoin/issues/33105 | validation: detect witness stripping without re-running Script checks by darosior · Pull Request #33105 · bitcoin/bitcoin · GitHub
16:13:43 <fanquake> would be good if it's clearer why #32579 needs to go into 30, or not
16:13:47 <corebot> https://github.com/bitcoin/bitcoin/issues/32579 | headerssync: Preempt unrealistic unit test behavior by hodlinator · Pull Request #32579 · bitcoin/bitcoin · GitHub
16:13:57 <darosior> darosior: nice. Feel free to ping me, i'm reviewing stuff for feature freeze today
16:14:10 <darosior> s/darosior/sipa
16:14:14 <sipa> haha
16:15:06 <l0rinc> fanquake: first is a test that was dead for some time and we've modified related code in this release; second is a very common complaint for people that they don't know why IBD is suddenly getting slow.
16:16:30 <hodlinator> fanquake: Will look into making it more clear. But essentially the release process will probably bump some values which will make tests cover less realistic behavior. Sorry for the redundancy.
16:18:15 <achow101> #topic should #33106 be backported before 29.1 is released (darosior)
16:18:18 <corebot> https://github.com/bitcoin/bitcoin/issues/33106 | policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee by glozow · Pull Request #33106 · bitcoin/bitcoin · GitHub
16:18:47 <darosior> So it seems like we agree it should be on the milestone for 30, but what do people think of backporting it to 29.1 (currently in rc1)?
16:19:06 <glozow> There will be an rc2 fosho
16:19:18 <TheCharlatan> makes sense imo
16:19:49 <Murch[m]> with such a big portion of transactions being below 1 s/vB it seems reasonable to me
16:19:51 <darosior> I initially thought it was too late for .1 and it'd have to go in .2, but maybe that's too much churn for release managers? What do maintainers say
16:20:08 <glozow> ^that was me saying it can go in .1
16:20:11 <Murch[m]> Should be tested a bit more, though, especially if we not just roll it out to the new release but also backport it
16:20:32 <darosior> (I also think it should be backported, that's what i'm bringing it up)
16:21:01 <glozow> It doesn't seem like something we'd normally backport
16:21:15 <darosior> Murch[m]: yeah, still no review. I've been going through it this morning but definitely needs more eyes to be sneaked into post rc1
16:21:26 <sipa> i was trying to measure how much memory cluster mempool uses per transaction... "getmempoolinfo" -> "usage": 6217176... that can't be right?!
16:21:42 <achow101> we don't usually backport features
16:21:54 <fanquake> this isn't a feature though?
16:21:59 <fanquake> it's fixing compact block relay
16:22:13 <fanquake> if we do backport it to 29, then it should also go to 28
16:22:15 <dergoegge> since block relay is degraded, it makes sense to backport
16:22:23 <glozow> I agree it's closer to a bug fix than a feature
16:22:24 <lightlike> yes, an adaptation to changed fee condition, so it's a fix
16:22:26 <sipa> we have treated softfork activations as "bug fixes", which is why they tend to be in .1 releases... in the sense that network conditions have changed, and bitcoin core needs to adapt to those
16:22:40 <darosior> I guess this boils down to "how much would backporting it in 29.1 provide a relief for the current network conditions?" which i gets boils down to whether we expect 29.1 to be out before 30.
16:23:11 <achow101> uptake of minor releases after a major release is made is usually not that high
16:23:18 <fanquake> if this pr hadn't come up, 29.1 likely would have been out within a week or so
16:23:36 <fanquake> and I'd say adoptoin of 29 is currently blocked somewhat, on the existence of the .1
16:24:00 <Murch[m]> Also, just a few nodes rolling out with the new mempool policy will probably drastically alleviate the issue for any nodes that upgrade
16:24:04 <sipa> and 29.2, if any, likely comes after 30.0?
16:24:19 <fanquake> likely
16:24:19 <achow101> sipa: yeah
16:25:56 <fanquake> has anyone found any issues with the rc1, in their testing so far?
16:26:15 <sipa> i think it's not unreasonable to backport a change like this given the network conditions, but whether it's worth doing does seem to depend on the realistic timing of getting the release out
16:26:23 <darosior> fanquake: i haven't, but haven't gone out of my way to try and test edge cases either
16:27:46 <jon_atack> i'll see about updating https://github.com/bitcoin/bitcoin/pull/32051, potentially by reducing scope to ibd only, where it was a real issue in my experience, tbc
16:28:03 <fanquake> sipa: I'd think ~4-7 days post backporting it
16:28:04 <achow101> at best 29.1 will be out 2 months before 30, i guess that's not too bad
16:28:37 <jon_atack> 29.1 inclusion seems based on review/testing then
16:28:41 <darosior> re rc1: it's also not like there is new features to exercise, and i don't run a mining pool to just be able to say "didn't break my operations" 🤷
16:28:48 <achow101> probably more like 1 month though
16:29:23 <darosior> achow101: 2 months (or even a bit less) seems like a win
16:29:33 <fanquake> why 1 month?
16:29:48 <fanquake> That'd mean it takes a month to review this PR, and run an rc2
16:30:17 <achow101> v30 is targeted for Oct 3. reviewing, merging, and backporting 33106, then rc that, then release in 3 weeks?
16:30:26 <achow101> s/in/within
16:30:34 <fanquake> Why would that take 3 weeks though?
16:30:36 <achow101> seems actually a bit tight with the way we usually do things
16:31:53 <darosior> Seems like it's highly dependent on the time it'll take to get it reviewed. Should we try to coordinate to get it properly reviewed within the next week?
16:31:55 <achow101> anyways, i don't feel that strongly about it
16:32:13 <sipa> yeah let's first try to get it in master
16:34:01 <jon_atack> yes
16:34:08 <achow101> Any other topics to discuss?
16:34:20 <fanquake> rc1 testing
16:34:35 <achow101> #topic v29.1rc1 testing (fanquake)
16:34:38 <fanquake> Curious to hear what testing has happend etc, amongst core contributors
16:34:44 <fanquake> Given rc1 has been out for a week or so
16:35:08 <dergoegge> haven't tested it at all
16:35:45 <sipa> i was unaware :s
16:36:17 <darosior> Not much. Been running it on one of my nodes (where i was manually looking at reconstructions before b10c rolled into the thread with proper stats). It's also the binary i used to generate the stats i shared on the minrelaytxfee PR.
16:37:52 <achow101> have it on one of my nodes, but that's all
16:38:10 <darosior> I could test it with downstream software (like running functional tests of wallets). But that would only reveal things like RPC breakage which would be very unlikely for a point release. I think my time is better spent elsewhere
16:39:48 <dergoegge> looks like lnd is using it in CI
16:40:09 <darosior> oh nice
16:40:46 <dergoegge> nvm they use .0 (got confused by a comment saying rc1 can be good for testing)
16:41:48 <eugenesiegel> I heard that the change does not break things in lnd
16:42:01 <sipa> it'd be very surprising if it did, i think
16:42:08 <sipa> but still, good to know
16:43:57 <achow101> Anything else to discuss?
16:44:24 <l0rinc> yes, I've investigated the excessive header hash calculations
16:44:29 <l0rinc> phantomcircuit: I've removed almost all header hashing duplication logic, but it doesn't seem to result in any IBD or reindex speedup - guess hashing is just really fast.
16:44:30 <l0rinc> There is a tiny speedup for headers sync and a few places where it's trivial to deduplicate, I might push a PR for that later.
16:45:18 <sipa> l0rinc: are you on hardware with sha256 hw acceleration? since we do care about validation time on hardware without, it may make sense to disable that if you are
16:45:42 <l0rinc> good point, will benchmark without shani
16:45:43 <achow101> #topic excessive header hashing (l0rinc)
16:46:17 <darosior> l0rinc: how did you remove the duplicate hashing? Caching? What's the excess memory usage?
16:47:14 <l0rinc> just local caching usually, e.g. instead of iterating the headers twice, getting the hashes each time, I've merged the loop
16:47:52 <l0rinc> and in other cases just passing them along with the block in a new parameter - not the pretties solution, but wanted to see first if there's any difference
16:48:04 <l0rinc> *merged the two loops
16:48:06 <achow101> l0rinc: were you able to find what the cause was? iirc we found it was being bounded by the block download window
16:49:07 <l0rinc> yes, the max was around 1000 recalculations because of the loop in https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3498 indeed, bounded by BLOCK_DOWNLOAD_WINDOW - hence the ~1000 worst case
16:50:15 <l0rinc> which only happens during IBD as far as I can tell, it's why we didn't see them during reindexes
16:51:36 <l0rinc> that's it from me, thanks
16:51:44 <achow101> Any other topics?
16:55:16 <achow101> #endmeeting