16:00:32 <achow101> #startmeeting 
16:00:32 <corebot> achow101: Meeting started at 2025-09-18T16:00+0000
16:00:33 <corebot> achow101: Current chairs: achow101
16:00:34 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:35 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:36 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:39 <Sjors[m]1> hi
16:00:40 <darosior> hi
16:00:41 <janb84> hi
16:00:42 <hebasto> hi
16:00:45 <dzxzg> hi hi
16:00:47 <sipa> hi
16:00:50 <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:51 <instagibbs> hi
16:00:51 <hodlinator> hi
16:01:00 <QUBIT_ABHAY> hi
16:01:00 <pinheadmz> 🪇
16:01:00 <TheCharlatan> hi
16:01:00 <abubakarsadiq> hi
16:01:03 <alvroble> hi
16:01:07 <Murch[m]> hi
16:01:09 <achow101> There is 1 preproposed meeting topic this week, any last minute ones to add?
16:01:20 <brunoerg_> hi
16:01:20 <QUBIT_ABHAY> #here 
16:01:21 <lightlike> hi
16:01:49 <laanwj> hi
16:02:02 <achow101> #topic Kernel WG Update (TheCharlatan)
16:02:59 <kanzure> hi
16:03:00 <TheCharlatan> not much to share this week besides wanting to ask for review on the API PR #30595
16:03:03 <corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
16:03:18 <eugenesiegel> hi
16:03:27 <l0rinc> hi
16:03:48 <TheCharlatan> a bunch of people and teams are building on top of it now, which led to a bunch of improvements on it the past few months.
16:04:39 <TheCharlatan> that's all
16:04:46 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:05:03 <sipa> main PR to review remains sdaftuar's #28676
16:05:06 <corebot> https://github.com/bitcoin/bitcoin/issues/28676 | Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
16:05:18 <sipa> which has been rebased and is getting reviews addressed
16:06:03 <sipa> in parallel, i have a few other PRs; i think #33157 is close (28676 is rebased on top of that one, so it's a dependency)
16:06:05 <corebot> https://github.com/bitcoin/bitcoin/issues/33157 | cluster mempool: control/optimize TxGraph memory usage by sipa · Pull Request #33157 · bitcoin/bitcoin · GitHub
16:07:05 <sipa> we've been talking with glozow and sdaftuar about package RBF, for after cluster mempool
16:07:09 <jonatack> hi
16:07:36 <sipa> that's it from me, i think
16:07:43 <instagibbs> sipa I wouldnt mind being included
16:08:02 <sipa> #include "instagibbs.h"
16:08:02 <corebot> sipa: Unknown command: #include
16:08:20 <glozow> from gibbs import insta
16:08:44 <achow101> #topic Stratum v2 WG Update (sjors)
16:08:46 <Sjors[m]1> Review welcome on #33374. Would be nice to get in v30, but no need to delay the release for it.
16:08:46 <Sjors[m]1> There's also a bunch of fixes that have been backported, not sure when we want to cut rc2?
16:08:46 <Sjors[m]1> ryanofsky anything you need? Just a subtree update or more?
16:08:48 <corebot> https://github.com/bitcoin/bitcoin/issues/33374 | mining: add applySolution() to interface by Sjors · Pull Request #33374 · bitcoin/bitcoin · GitHub
16:09:18 <fanquake> sjors: how are you planning to handle version in the multiprocess subtree going forward?
16:09:23 <fanquake> *versioning
16:09:45 <Sjors[m]1> fanquake: do you mean versioning of the interface or of the multiprocess dependency?
16:10:04 <fanquake> I'm guessing release branches to match Core? Otherwise I'm wondering what the plan is if you need to land bugfixes from multiprocess that wont apply to release branches, due to api changes or similar
16:10:06 <Sjors[m]1> For the latter we should probably tag whatever is in v30
16:10:26 <fanquake> We also don't generally backport subtree updates, so this would also be new for multiprocess
16:10:49 <sipa> if a subtree has a bugfix that matters, it does seem reasonable to backport it
16:11:21 <fanquake> Sure, but that might have to be selective, rather than a full pull
16:11:27 <sipa> yeah, makes sense
16:11:28 <fanquake> so by default isn't a clean backport
16:12:07 <fanquake> so just wondering what the plan is there, and if anything is going to be done to track things upstream in the multiproess repo
16:12:53 <Sjors[m]1> Maybe ryanofsky has a specific plan. I would imagine indeed having a seperate branch to track minimal changes if anything needs to be backported to v30.1+
16:13:28 <fanquake> Ok, can leave it up to you and him to figure out going forward
16:14:33 <achow101> #topic MuSig2 WG Update (achow101)
16:14:54 <achow101> No major updates. PR to review is #29675 and I've been addressing comments.
16:14:57 <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:15:29 <achow101> #topic v30.0
16:16:22 <achow101> Any new issues found in testing rc1?
16:17:09 <darosior> I think we backported a few issues we found already, any plans on an rc2?
16:17:15 <achow101> Anything to add or remove from the milestone? https://github.com/bitcoin/bitcoin/milestone/72
16:17:33 <fanquake> rc2 changes in https://github.com/bitcoin/bitcoin/pull/33424
16:17:42 <hodlinator> #32132 causes an issue on master and probably rc1 with an extra uninstall entry on Windows.
16:17:44 <corebot> https://github.com/bitcoin/bitcoin/issues/32132 | build: Remove bitness suffix from Windows installer by hebasto · Pull Request #32132 · bitcoin/bitcoin · GitHub
16:18:07 <fanquake> rc2 backports done so far https://github.com/bitcoin/bitcoin/pull/33356
16:18:41 <darosior> hodlinator: so should #33422 be added to the milestone?
16:18:42 <corebot> https://github.com/bitcoin/bitcoin/issues/33422 | build: Remove lingering Windows registry & shortcuts (#32132 follow-up) by hodlinator · Pull Request #33422 · bitcoin/bitcoin · GitHub
16:18:43 <achow101> added #33422 to the milestone
16:18:44 <corebot> https://github.com/bitcoin/bitcoin/issues/33422 | build: Remove lingering Windows registry & shortcuts (#32132 follow-up) by hodlinator · Pull Request #33422 · bitcoin/bitcoin · GitHub
16:18:49 <darosior> 🤝
16:19:34 <fanquake> we are so going to be cutting 29.2, 28.3 & maybe 27.3 releases in the near future
16:20:06 <darosior> 🚢
16:20:15 <hodlinator> Thanks! That or reverting the one-line change which introduced the issue, could get it in the next release.
16:21:01 <l0rinc_> Thanks for the reviews of the 2 PRs mentioned last week (#33333 and #33336)
16:21:04 <corebot> https://github.com/bitcoin/bitcoin/issues/33333 | coins: warn on oversized `-dbcache` by l0rinc · Pull Request #33333 · bitcoin/bitcoin · GitHub
16:21:08 <corebot> https://github.com/bitcoin/bitcoin/issues/33336 | log: always print initial signature verification state by l0rinc · Pull Request #33336 · bitcoin/bitcoin · GitHub
16:21:33 <l0rinc_> for the record, I've compared V30 to previous releases (23-29) and it seems V30 is exactly 2x faster than v25 thanks to all the optimization efforts in the past releases, see https://x.com/L0RINC/status/1968392472717033927
16:23:26 <achow101> #topic Support for Ubuntu 22.04 LTS as a build platform (hebasto)
16:23:32 <hebasto> Ubuntu 22.04 reaches end of standard support in April 2027. See: https://ubuntu.com/about/release-cycle
16:23:40 <hebasto> By the time Bitcoin Core v31.0 is released, Ubuntu 26.04 LTS will be available.
16:24:10 <hebasto> Ubuntu 22.04’s default repositories provide dependency packages that are outdated and problematic to maintain, such as: CMake 3.22.1, Qt 6.2.4, Cap'n Proto 0.8.0
16:24:18 <hebasto> Furthermore, Ubuntu 22.04’s default repositories do not provide the minimum required Clang version.
16:24:27 <hebasto> My initial proposed action was to stop considering Ubuntu 22.04 as a build platform starting from the v31 release cycle.
16:24:36 <hebasto> However, during conversation on IRC on 2025-09-09, sipa argued that we may end "in a situation where some important user chooses not to upgrade because they want to build from source, and they're stuck on an older platform"
16:24:42 <hebasto> And fanquake pointed on such real world case where "a lot of Armory users are stuck on v27 branch".
16:24:51 <sipa> do we actually have a "list of build platforms we support"?
16:25:03 <hebasto> nope, I guess
16:25:03 <fanquake> we've also since heard that a bunch of nodl (box?) users are also stuck on 27.x
16:25:20 <achow101> why are they stuck?
16:25:25 <hebasto> Considering, that every problematic dependency package can be build by our own depends build subsystem, the remaining issue boils down to the minimum supported CMake version, which is 3.22 now.
16:25:28 <sipa> my impression is more that for individual upgrades/dependency requirements, we have an ad-hoc discussion for benefits vs. which use/build platforms those would drop
16:25:49 <hebasto> The question for my fellow collegues is can we ask users who will build Bitcoin Core v31+ from source on Ubuntu 22.04 to install newer CMake from https://cmake.org/download/ or from some other package manager?
16:26:03 <hebasto> If so, we can bump the minimum supported CMake version in the v31 release cycle up to 3.25, same as in Debian Bookworm (oldstable).
16:26:03 <darosior> Tangentially, i've had report of people stuck on  27 because of our glibc bump. fanquake also had some. I would suspect there is more. It probably means a lot of people that won't upgrade in case of vulnerability disclosures. I don't know the upsides to breaking support for some platform in this instance, but i'd like to underline there are
16:26:03 <darosior> substantial downsides to doing so.
16:26:20 <sipa> fanquake, darosior: but that's due to runtime requirements, not build time?
16:26:25 <fanquake> Why do we need to bump the minimum required CMake version?
16:26:30 <hebasto> This gives us a few useful features such as (1) file sets; (2) `COMPILE_WARNING_AS_ERROR`; (3) better support for IPO/LTO; (4) scope management
16:26:51 <sipa> hebasto: can we use those feature optionally?
16:26:54 <darosior> achow101: the nodl boxes are stuck because of our glibc bump in 28
16:26:58 <hebasto> Very useful for ongoing libkernel development
16:26:59 <sipa> (i'm guessing no from 1 and 4, yes for 2 and 3)
16:27:08 <fanquake> These seem like things that might be mostly nice for cmake devs/
16:27:14 <fanquake> *?
16:27:44 <achow101> I would prefer that we support platforms that are still in use and supported by upstream
16:27:47 <hebasto> sipa: some of them, yes
16:28:08 <achow101> if ubuntu 22.04 is supported until 2027, i'd rather not drop support for it until it is eol
16:28:17 <darosior> sipa: yes, my examples are runtime, that's why i said it's only tangentially related
16:28:46 <sipa> achow101: agreed
16:28:57 <darosior> achow101: +1
16:29:02 <hebasto> achow101: users still able build on ubuntu 22.04; they will need to install newer cmake
16:29:04 <fanquake> It'd atleast be good to see an example of changes that could be made after dropping. Hard to infer the benefits from that list
16:29:45 <fanquake> Also, what version are you trying to bump the minimum to?
16:29:46 <achow101> hebasto: I don't think asking users to update a dependency from external sources is a reasonable ask
16:29:59 <hebasto> fair
16:30:05 <sipa> specifically for (2), i think it's not unreasonable to enable it whenever cmake is recent enough, and not otherwise - which will give the benefit for most people who compile, but not break compatibility?
16:30:06 <fanquake> Oh, I see 3.25
16:30:32 <fanquake> sipa: not that we already also have that feature
16:30:35 <fanquake> *note
16:30:46 <fanquake> We just aren't using the CMake *thing*
16:30:55 <sipa> fanquake: sure, but we can simplify the cmake code with that feature, i assume - which is still possible by using it optionally
16:31:28 <fanquake> I'd think that'd be more code, if we retain the old way, and add the new way
16:31:37 <hebasto> ^ true
16:31:39 <fanquake> unless you mean drop support of the feature for older users
16:31:41 <sipa> fanquake: no, i mean use the new way, drop the old way
16:32:08 <hebasto> that needs bump the minimum supported version
16:32:08 <sipa> because people who care about the feature will almost certainly be on a new platform anyway (they're developers, not builders-on-old-platform-who-just-want-it-to-work)
16:32:32 <sipa> hebasto: can you not enable it optionally?
16:33:07 <hebasto> features that depends on cmake policy can be enabled optionally
16:33:12 <dzxzg> Won't the flag just be ignored if used in a cmake version below 3.24?
16:33:34 <hebasto> but also there are language features
16:33:52 <l0rinc_> do we need to add a separate CI build with an old cmake version in that case?
16:33:54 <hebasto> yes; with more coding
16:34:38 <sipa> (if we're done with this topic, i'd like to also discuss the possibility of bringing back runtime compatibility with glibc 2.28 (or whatever it is that causes the reports of people unable to upgrade))
16:35:59 <achow101> how difficult would it be to do that?
16:36:23 <fanquake> Have to look at undoing a number of changes in Guix
16:36:43 <fanquake> If people are trying to run on glibc < 2.28, I'm guessing this is on Ubuntu Bionic. Which shipped with 2.27
16:36:45 <hebasto> if I recall correctly, there were issues with qt as well
16:37:07 <darosior> One thing they could do to have new-bitcoind compatibility in their old machines would be to dockerize it. It's not impossible, but a bunch more work for them and therefore they're not doing it.
16:37:10 <fanquake> Bionic went EOL sometime in 2023 I think
16:37:11 <achow101> The bump was #29987
16:37:14 <corebot> https://github.com/bitcoin/bitcoin/issues/29987 | guix: build with glibc 2.31 by fanquake · Pull Request #29987 · bitcoin/bitcoin · GitHub
16:38:12 <fanquake> Would have to check if our current GCC would compile 2.27
16:38:48 <sipa> hebasto: i'm less concerned about that, i assume people stuck on old platforms tend to use bitcoind as a backend, not the gui
16:39:38 <fanquake> darosior: or we start shipping a flavour of static musl rel builds
16:39:40 <hebasto> I agree, than gui probably should excluded from guix script for that purpose
16:40:05 <darosior> fanquake: 👁️
16:40:25 <fanquake> rebased my old branch for doing that earlier today: https://github.com/fanquake/bitcoin/tree/depends_musl_cross_make
16:40:38 <fanquake> Athough not sure we'd take that approach
16:40:53 <sipa> fanquake: what are the downsides, besides it being less well tested?
16:41:29 <fanquake> Less tested, would need to check if all the targets we support would work
16:41:40 <darosior> sipa: might not be consensus compatible
16:41:41 <fanquake> Although I guess if we ship x86_64 and aarch64, that'd probably cover most users
16:41:46 <darosior> hides
16:41:51 <sipa> darosior: only if there are bugs in it :p
16:42:30 <sipa> another possibility is having separate static-linux and modern-linux release builds
16:42:37 <darosior> Differential fuzzing across libc's is something that came up recently when chatting with external people looking into fuzzing Core
16:42:38 <fanquake> would also mean splitting the guix build in two, either to do a lts & the current build, or some sort of static bitcoind + utils & gui separate
16:42:44 <sipa> i'm less a fan of that due to splitting testing, though
16:42:56 <sipa> fanquake: multiprocess gui lalala
16:43:05 <fanquake> we are already shipping releases built against different libc++ flavours
16:43:38 <darosior> fanquake: for MacOS, right?
16:43:44 <fanquake> I will do a POC in any case
16:43:54 <sipa> fanquake: cool, curious about what you find
16:44:02 <fanquake> darosior: yea, clang & libc++ for macOS, gcc & libstdc++ for linux
16:44:18 <sipa> does libc++ have its own libc?
16:44:22 <darosior> im sure nobody mines on macos :p
16:44:22 <sipa> or does it use glibc
16:44:24 <fanquake> they are working on it
16:44:31 <fanquake> https://libc.llvm.org/
16:44:39 <sipa> of course they are
16:44:45 <sipa> what's next, their own kernel?
16:44:45 <fanquake> It's getting close to the point where you can bootstrap libc++ against it
16:45:08 <fanquake> we'll ship an LLVM OS container with bitcoind entrypoint
16:45:30 <darosior> compatibility: solved
16:46:58 <achow101> Any other topics to discuss?
16:49:14 <achow101> #endmeeting