16:00:06 <achow101> #startmeeting 
16:00:21 <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:23 <TheCharlatan> hi
16:00:26 <dzxzg> hi
16:00:27 <l0rinc> hi
16:00:28 <sipa> hi
16:00:29 <hebasto> hi
16:00:31 <furszy> hi
16:00:38 <b10c> hi
16:00:41 <sliv3r__> hi
16:00:41 <lightlike> hi
16:00:45 <pinheadmz> 🎸
16:00:49 <eugenesiegel> hi
16:01:15 <theStack> hi
16:01:27 <johnny9dev> hi
16:01:33 <janb84> hi
16:01:45 <brunoerg> hi
16:01:48 <Emzy> hi
16:01:48 <achow101> There are 2 preproposed meeting topics this week, any last minute ones to add?
16:02:04 <stickies-v> hi
16:02:26 <achow101> #topic Kernel WG Update (TheCharlatan)
16:02:43 <TheCharlatan> aj left some interesting comments in #32317. The conversation there binds into the larger discussion of how many changes to the kernel motivated by external users the project can stomach.
16:02:46 <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:03:22 <cfields_> hi
16:03:43 <hodlinator> hi
16:04:28 <TheCharlatan> no concrete outcome from that yet, but it is probably a theme that will be repeated a few times still.
16:05:08 <ryanofsky> no informed opinion but my initial thought on 32317 was it make code nicer by splitting up a big function
16:05:32 <TheCharlatan> other than that, others in the workgroup have been adapting their respective language bindings to the latest proposed C header api.
16:05:34 <TheCharlatan> that's all
16:06:34 <achow101> #topic Benchmarking WG Update (josie, l0rinc)
16:06:52 <l0rinc> It's not about benchmarking, but the v3 release. People are scared for V30 and I think we could make a few changes that might help in calming the spirits:
16:06:58 <l0rinc> * people complain the new versions have become slower, one of the reasons is signature verification is enabled sooner with older versions. Some logging was already added, but there are leftover corner cases covered here: #33336
16:07:01 <corebot> https://github.com/bitcoin/bitcoin/issues/33336 | log: always print initial signature verification state by l0rinc · Pull Request #33336 · bitcoin/bitcoin · GitHub
16:07:05 <l0rinc> * another reason for the slowdowns seems to be that the recently unbounded dbcache values are set too high and the node is swapping heavily - added a warning log for that case in this beautiful pr number #33333
16:07:06 <corebot> https://github.com/bitcoin/bitcoin/issues/33333 | RFC: coins: warn on oversized `-dbcache` by l0rinc · Pull Request #33333 · bitcoin/bitcoin · GitHub
16:07:10 <l0rinc> * lastly a lot of people fear that their cloud node will get banned because of the block content - older nodes don't have block obfuscation enabled, added #33324
16:07:13 <corebot> https://github.com/bitcoin/bitcoin/issues/33324 | RFC: blocks: add `-reobfuscate-blocks` arg to xor existing blk/rev on startup by l0rinc · Pull Request #33324 · bitcoin/bitcoin · GitHub
16:07:45 <achow101> l0rinc: we will have a v30 specific topic
16:07:47 <l0rinc> Thank for for the reviews and comments so far - what's the overall sentiment, could we include any of these in v30?
16:08:09 <l0rinc> my mistake, nothing from my side
16:08:40 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:09:12 <sipa> good progress, i've changed the main PR to review to sdaftuar's #28676
16:09:18 <corebot> sipa: Error: That URL raised <Connection timed out.>
16:09:49 <achow101> #28676 
16:09:53 <corebot> https://github.com/bitcoin/bitcoin/issues/28676 | Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
16:10:17 <sipa> there are a number of txgraph PRs, but they're not on the critical path
16:10:38 <sipa> i think sdaftuar's is working on addressing review comments
16:11:09 <sipa> that's it from me
16:11:40 <achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
16:12:22 <johnny9dev> Not much at the moment. Working on adding QML testing on top of the unit test I added to get coverage on the views.
16:12:45 <johnny9dev> thats all
16:12:55 <achow101> #topic MuSig2 WG Update (achow101)
16:13:26 <achow101> pr to review is still #29675, which has been getting some review that i've addressed
16:13:30 <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:13:51 <achow101> #topic v30.0rc1
16:14:13 <achow101> The rc1 has been tagged, although bins not uploaded yet. Any issues that people have noticed in testing?
16:14:52 <achow101> There's a couple things in the milestone too https://github.com/bitcoin/bitcoin/milestone/72
16:15:44 <hebasto> I think I could fix cmake issue from it shortly
16:15:56 <achow101> l0rinc: are those issues regressions?
16:16:32 <l0rinc> not exactly, but one is an incomplete implementation - not logging signature verification in some cases
16:17:13 <sipa> in what way are new versions slower?
16:17:32 <sipa> i'd expect each new version to be observably faster, with the assumevalid point moved forward
16:18:42 <l0rinc> Yeah, I should have made that clearer: fetching the blockchain has become slower with the older node versions
16:18:56 <sipa> older?
16:19:26 <achow101> I think it might be a bit late to be adding draft PRs during the RCs, #33324 seems to have a number of open questions
16:19:26 <l0rinc> having assumevalid for lower block heights enables script verification sooner
16:19:28 <corebot> https://github.com/bitcoin/bitcoin/issues/33324 | RFC: blocks: add `-reobfuscate-blocks` arg to xor existing blk/rev on startup by l0rinc · Pull Request #33324 · bitcoin/bitcoin · GitHub
16:20:09 <l0rinc> achow101: that's why I'm asking, there's Andre Toth's alternative for reobfuscation
16:20:14 <l0rinc> *andrew
16:20:27 <sipa> l0rinc: you mean just that old versions gradually become slower as the chain grows? that seems... inevitable and obvious?
16:21:11 <l0rinc> somewhat yes, but instead of explaining it every time I thought it would be more helpful to show related logs
16:21:35 <achow101> l0rinc: I don't disagree with the premise, I'm just not sure that the pr can be sufficiently reviewed for the release, considering that we have now entered the rc phase
16:21:52 <l0rinc> got it - what about the two logging PRs?
16:21:54 <achow101> in particular, because it is a draft, and there are a number of open questions
16:22:00 <sipa> seems like a nice feature, but i don't think it's related to v30 or deserves special treatment
16:22:42 <achow101> the other two seem fine to me
16:22:45 <l0rinc> thanks for the feedback
16:23:31 <darosior> I plan on testing rc1 in the coming week.
16:23:36 <darosior> Haven't yet.
16:24:59 <achow101> Any other topics to discuss?
16:25:19 <TheCharlatan> would be interesting to test the mining interface a bit. maybe through Sjors client?
16:26:29 <sipa> we have python functional tests too, they can be expanded
16:27:25 <achow101> #topic Drop support for Ubuntu 22.04 LTS as a build platform (hebasto)
16:27:30 <hebasto> purpleKarrot asked me to postpone this topic until later, as he is unable to attend today's meeting
16:27:36 <achow101> ok
16:27:39 <hebasto> so let's skip it
16:27:44 <achow101> Anything else to discuss?
16:27:47 <hebasto> my apologies to all
16:29:46 <achow101> #endmeeting