16:00:09 <achow101> #startmeeting 
16:00:09 <corebot`> achow101: Meeting started at 2025-06-19T16:00+0000
16:00:10 <corebot`> achow101: Current chairs: achow101
16:00:11 <corebot`> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:12 <corebot`> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:13 <corebot`> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:22 <TheCharlatan> hi
16:00:23 <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:01:00 <darosior> hi
16:01:12 <pinheadmz> Hi from AA3058 to PHX
16:01:19 <willcl-ark> hi
16:01:27 <sipa> hi
16:01:29 <achow101> there is one preproposed meeting topics this week. Any last minute ones to add?
16:01:45 <stickies-v> hi
16:01:57 <theStack> hi
16:02:11 <lightlike> hi
16:02:24 <achow101> #topic Kernel WG Update (TheCharlatan)
16:02:31 <TheCharlatan> Looking for review on #32317
16:02:33 <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:02:36 <TheCharlatan> ...and some more conceptual feedback on #32427
16:02:38 <corebot`> https://github.com/bitcoin/bitcoin/issues/32427 | (RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store by TheCharlatan · Pull Request #32427 · bitcoin/bitcoin · GitHub
16:02:54 <sr_gi[m]1> hi
16:03:02 <TheCharlatan> I'm still not convinced by the counter proposal of writing single block files and getting rid of the block index altogether, but there have also has not been complete suggestions yet. I might try to write something up for that.
16:03:25 <TheCharlatan> that's all
16:03:38 <achow101> #topic Erlay WG Update (sr_gi, gleb)
16:05:36 <sr_gi[m]1> I've been focusing on an issue with measuring the propagation time of the warnet simulations for the last few weeks, but I think I'm hitting a wall. The results I'm getting from simulations are promising regarding bandwidth, but the times seem too good to be true. I think something may be wrong with the way I'm testing for times, or there is a bug in the implementation that makes transactions propagate faster than they should
16:06:06 <sr_gi[m]1> I think I may need some extra set of eyes here, since I haven't been able to figure it out myself
16:06:47 <sr_gi[m]1> I'm currently writing this down and making it easily reproducible in case someone wants to give it a go, whether it is checking the code or the sims
16:07:02 <achow101> is there a branch to look at?
16:07:04 <pinheadmz> sr_gi[m]1 is your warnet project repo up to date?
16:07:54 <sr_gi[m]1> achow101: yes, the full implementation branch is up to date as of yesterday. #30277
16:07:56 <corebot`> https://github.com/bitcoin/bitcoin/issues/30277 | [DO NOT MERGE] Erlay: bandwidth-efficient transaction relay protocol (Full implementation) by sr-gi · Pull Request #30277 · bitcoin/bitcoin · GitHub
16:08:59 <sr_gi[m]1> The warnet repo is not, I'll update it today. The branch I'm using for the warnet tests is tho: https://github.com/sr-gi/bitcoin/tree/202406-erlay-full-draft-warnet
16:09:11 <sr_gi[m]1> But I'll get all cleaned up and ready today
16:09:47 <sr_gi[m]1> That's it from me. Happy to get anyone how's interested up to speed
16:10:21 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:11:51 <sipa> priority for review remains #31553, which got some recent review that led to discovering a bug in it (the eviction heuristic just wasn't as good as intended, fixed now, and contributed tests added)
16:11:54 <corebot`> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
16:12:28 <sipa> #30605 is not urgent, but pretty close to merge, i think; it's just test / comment improvements
16:12:30 <corebot`> https://github.com/bitcoin/bitcoin/issues/30605 | Cluster linearization: separate tests from tests-of-tests by sipa · Pull Request #30605 · bitcoin/bitcoin · GitHub
16:12:52 <sipa> it also includes a fancy ascii-art diagram
16:14:08 <sipa> i have rebased #32545 on top of 30605, as there was some overlap, and it can wait
16:14:10 <corebot`> https://github.com/bitcoin/bitcoin/issues/32545 | Replace cluster linearization algorithm with SFL by sipa · Pull Request #32545 · bitcoin/bitcoin · GitHub
16:14:24 <sipa> that's it for me, unless someone has questions/comments
16:14:55 <achow101> #topic MuSig2 WG Update (achow101, rkrux)
16:15:07 <achow101> bips#1867 was merged. #31244 is updated to allow duplicate participant keys, and all review has been addressed.
16:15:09 <corebot`> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
16:15:11 <corebot`> https://github.com/bitcoin/bips/issues/1867 | 390: Allow repeated participant pubkeys and disallow ranged participants with aggregate derivation. by achow101 · Pull Request #1867 · bitcoin/bips · GitHub
16:15:17 <achow101> 31244 is still the pr to review
16:15:48 <achow101> #topic move the repo to bitcoin-core (achow101)
16:16:19 <achow101> wanted to bring this up again since there's some talk about changing CI, and having everything in one org would make that easier
16:16:34 <sipa> can you link to CI changing discussions?
16:17:09 <achow101> There was some discussion in #31965, but afaict, most is happening in signal
16:17:10 <corebot`> https://github.com/bitcoin/bitcoin/issues/31965 | Revisiting us self-hosting parts of our CI · Issue #31965 · bitcoin/bitcoin · GitHub
16:17:22 <maflcko> I brought it up, but the general idea is that having two orgs will have to duplicate everything that is org-specific, not just org-teams
16:17:41 <sipa> right, of course
16:17:42 <achow101> same org lets us also share caches
16:18:32 <dergoegge> I still don't think the potential downsides are worth the minor improvements
16:18:32 <maflcko> Currently the two worker pools are set up manually to share the cache
16:19:25 <maflcko> dergoegge: Are there any specific technical downsides that I missed?
16:19:49 <dergoegge> technical no, but the main motivation afaiu was always non-technical
16:20:28 <sipa> for me the main motivation is non-technical; i don't know if that's the case for everyone
16:20:48 <darosior> This is how i understand it as well, and i tend to agree with dergoegge.
16:21:44 <sr_gi[m]1> That's also how I see it, but I won't be blocking this if there is consensus to move forward with it
16:22:18 <fanquake> Me too. (happy to take any and all of the other team/org actions, if needed. Should only be a handful extra a year)
16:22:27 <willcl-ark> Is there a problem with the status quo that is solved by moving?
16:23:15 <sipa> people thinking that BIPs are bitcoin core thing
16:23:20 <maflcko> willcl-ark: All the technical stuff that involves doing stuff twice (CI worker pools, CI settings, CI subscriptions, org-teams, ...)
16:23:59 <fanquake> To be clear, again, that duplicated technical stuff is trivial in number compared to all other actions needed to maintain the repo
16:23:59 <achow101> maflcko: would have the ci in both orgs also cost us double since that would be 2 subscriptions?
16:24:16 <maflcko> achow101: Not sure, but I'd assume so
16:24:49 <dergoegge> what is the cost of the CI now?
16:25:15 <maflcko> dergoegge: Well, it is self-hosted right now
16:25:26 <maflcko> But there was discussion to change that (for various reasons)
16:26:43 <dergoegge> Right ok, I think the cost argument only makes sense if we know what it would actually be
16:28:18 <darosior> dergoegge: and if it's substantially higher than the cost of engineering hours spent in moving the repo and associated infrastructure
16:28:57 <achow101> I think the current plan is the new cirrus runners, which is $75/mo per machine (assuming we get the nonprofit discount)
16:29:34 <darosior> How many machines we need?
16:30:46 <maflcko> darosior: You could probably do with a single machine (everything will just be slower) for that org. Not sure if devs will be happy with that
16:31:12 <darosior> At "feature parity" with today, how many machines we need? 2?
16:31:28 <willcl-ark> Reall cirrus machines are "16 cpu", so you can split even one machine into eg 8 x 2cpu jobs.
16:31:46 <fanquake> Things being slower in the GUI repo, doesn’t really seem like an issue? Given it’s running at a PR or two a week?
16:31:59 <fanquake> Probably not even that many actually
16:32:13 <maflcko> fanquake: Also, qa-assets and secp (aarch64)
16:32:56 <fanquake> Sure, qa-assets is less than that even, I guess secp256k1 slightly over gui
16:34:13 <dergoegge> secp Ci looks much less intense, e.g. the last arm64 cirrus jobs were 8 min each
16:35:11 <sipa> secp CI has a ton of CI jobs, but all fairly short
16:35:25 <maflcko> yeah, i think two runners (aarch64 + x86_64) would be enough. So that is 2k-4k per year, i'd guess
16:35:33 <achow101> I think it's probably at least 3 machines, 2 x86, 1 arm. that at least matches the current setup
16:35:40 <sipa> i can't imagine money being the problem with those numbers
16:35:42 <achow101> and per org
16:36:06 <darosior> achow101: ok thanks
16:36:09 <darosior> sipa: yeah
16:36:20 <maflcko> sipa: Yeah, it should be 10% of the other CI subscription, so money itself shouldn't be an issue
16:38:35 <maflcko> My thinking is that moving the repo should be mostly hassle free (obviously I can't promise it) and has been discussed for years, so doing it now to save some hassle when setting up the CI or in the future when handling teams seems fine.
16:40:32 <sipa> it makes sense to me, i remain of the opinion that it's just a confusing historical artifact how the orgs/repos are organized, and it's been discussed long enough to address it
16:40:32 <achow101> i expect that making sure ci is setup correctly twice will cause more issues than moving the repo
16:40:42 <darosior> I think moving the repo is a consequential decision which comports risk. Doing so today seems unnecessary and pretty bad timing.
16:40:49 <achow101> but i'm okay with revisiting this later. we previously discussed revisting during coredev
16:40:58 <sipa> but if too many people are skeptical, i'm not going to push it
16:41:27 <fanquake> Regardless of any technical reasons, personally, I don’t think anything is gained by us trying to create some perception that doesn’t currently reflect reality. I think this is also undermined by the fact that we are just going to redirect to ourselves anyways (so where is the separation?) If we did drop an org level readme in /bitcoin, would we also be listing/linking to every other implementation in there? If not, that’d seem to
16:41:27 <fanquake> undermine the premise as well. If the plan was to move everything out, except kernel, that would be more interesting to me.
16:41:40 <maflcko> yeah, I don't want to rush or push it. Just wondering why it is bad timing
16:42:43 <sipa> fanquake: ideally there'd be a bitcoin-bips/bips and a bitcoin-core/bitcoin etc, and the bitcoin/ org remains vestigial just to avoid name squatting and for redirect
16:42:50 <darosior> I think it would be highly inadvisable for us to link people to alternate implementations that are not consensus-compatible with what 99% of the Bitcoin network runs.
16:43:20 <maflcko> yeah, the readme should just briefly say a redirect exists
16:43:24 <achow101> fanquake: ideally we wouldn't need to have redirects, but there's way too many links to bitcoin/bitcoin that breaking them would be a bad idea
16:43:47 <sipa> fanquake: i strongly disagree with the notion that kernel somehow deserves to be treated differently - it's a still just one implementation, and people can choose to use it or not
16:45:29 <achow101> the point of having a redirect or links in a readme is purely to not break all existing documentation and habits, of which there are many. it's not to be an exhaustive list of implementations.
16:45:38 <sipa> achow101: +1
16:45:56 <fanquake> my point is that if /bitcoin is now meant to be neutral, why wouldn’t people ask for that?
16:45:57 <darosior> sipa: i think it is an overstatement to say "it is just one implementation". Kernel de facto defines what the network today will accept.
16:46:24 <sipa> darosior: no it doesn't, bitcoin core de facto does
16:46:36 <darosior> It's what i meant
16:46:47 <sipa> people can choose to use bitcoin core or not
16:46:50 <achow101> fanquake: it's not meant to be neutral, it's meant to not exist. obviously it has to exist to not break anything existing
16:47:08 <fanquake> well /bitcoin does need to exist, to host the bips repo
16:47:25 <achow101> bips can also move
16:47:25 <sipa> fanquake: well all of this would be much more meaningful if bips moves too
16:48:02 <fanquake> Is it going to?
16:48:44 <darosior> sipa: of course but i don't think it is related
16:48:52 <achow101> no idea. I think opinions are split there as well
16:49:50 <maflcko> I'd say bips moving (or not) shouldn't affect or concern whether to move /bitcoin
16:50:09 <darosior> To be honest i feel like we are discussing whether to take a decision that could have nefarious real-world consequences just to make a philosophical point
16:50:34 <achow101> darosior: what "nefarious real-world consequences"?
16:51:00 <sipa> darosior: i understand the concern of "people who aren't familiar will search for bitcoin and be confused when they don't find a reference implementation under bitcoin/" i guess, but really, i find it categorically wrong for bitcoin core (or kernel, or any of its related projects) to somehow present itself as being "bitcoin", even though today - and hopefully for long in the future - it remains de
16:51:06 <sipa> facto what users use and thus defines the network
16:51:12 <darosior> achow101: confusing people and effectively leading them to run lower quality software to validate their money.
16:52:10 <willcl-ark> It might be good to also have a concrete answer to whether setting up and maintaining CI twice is hard/too much work, or not? Or if it's cost constraints, or something else. I've now heard that it both isn't (last year), and now that it is (so much so that it's a contributing factor for moving the r
16:52:10 <willcl-ark> epo). If it is, and we move to hosted runners, and don't move the repo then we will indeed need "double CI", but it's also unclear to me if even this is a problem (cost wise).
16:52:36 <sipa> darosior: TBH, i think it's more confusing the other direction
16:52:59 <achow101> darosior: I don't see at all how that is a possibility. links to bitcoin/bitcoin will redirect. when you go to the bitcoin org profile, there won't be a "bitcoin" repository under there. I highly doubt any new person is going to github.com/bitcoin and looking for the "bitcoin" repo when they want to start using Bitcoin
16:53:38 <dergoegge> where is the perception of separation we'd be aiming for if the redirect exists?
16:53:49 <achow101> the redirect will be permanent, and the bitcoin org owners aren't going to change in order to ensure that no new bitcoin/bitcoin that breaks the redirect
16:54:00 <sipa> darosior, achow101: yeah, this argument applies far more to bitcoin.org vs bitcoincore.org, but there the naming is already correct
16:54:23 <sipa> dergoegge: that seems like a strawman to me; over time, people will start using the bitcoin-core repo
16:55:03 <sipa> the bitcoin/ repo isn't there to to direct people (as repos won't even show up under it) to a specific implementation, it's to redirect old historical usage that hasn't updated
16:55:07 <achow101> dergoegge: any new links people generate will be the new repo. when you go to the old link, it automatically redirects you to the new repo which says "bitcoin-core/bitcoin-core" or whatever
16:55:18 <dergoegge> ok so the hope is we'd be able to remove the redirect in time?
16:55:31 <achow101> dergoegge: I'd love to be able to do that
16:55:49 <achow101> it'll probably take more than our lifetimes though
16:56:11 <Murch[m]> dergoegge, I mean, you would not be looking at the bitcoin org anymore when browsing the repository, even if you got there originally by calling up the bitcoin org
16:56:23 <maflcko> I don't think it is possible to remove a redirect (other than to create a repo on top). Personally I think it is fine to leave the redirect
16:56:24 <janb84> There is currently a view of certain people that "bitcoin-core" is trying to capture bitcoin, wouldn't moving the repo now bolster that viewpoint and give extra negative backlash ?
16:56:45 <sipa> janb84: i'd say it would do the exact opposite?
16:57:03 <Murch[m]> janb84: Could you explain why you think that, it seems like the opposite to me, too.
16:57:26 <sipa> who knows how things can be misinterpreted, of course, but logically, this is exactly moving away from the (understandable) misdirection someone might take from bitcoin core being under the bitcoin/ org
16:58:19 <achow101> anyways, we're near the end of the meeting. if there are opinions, maybe they would be best expressed in #32340
16:58:20 <corebot`> https://github.com/bitcoin/bitcoin/issues/32340 | Moving this repo to bitcoin-core · Issue #32340 · bitcoin/bitcoin · GitHub
16:58:24 <janb84> it's a delicate topic ofc. again the good intentions are easily misinterpreted, "look they are now 100% trying to gain control"  etc
16:58:36 <darosior> I understand many (including me) are concerned with the confusion of Bitcoin and Bitcoin Core. However i don't think this means we should ignore the fact that anybody serious who wants to use Bitcoin today with real money on the line will want to use Bitcoin Core. Moving the repository is not going to change this reality.
16:59:06 <Murch[m]> At this point, anything we do seems to be represented in pretty much every possible way as there are a substantial number of Bitcoin geeks producing podcasts and blog posts that are overinvested in the OP_RETURN thing…
16:59:07 <achow101> darosior: no one claimed it would change that reality?
16:59:09 <sipa> darosior: i certainly hope it doesn't!
16:59:11 <abubakarsadiq> the redirect from /bitcoin/bitcoin indicates that Bitcoin core is the dominant implementation :P
16:59:26 <darosior> sipa: :)
17:00:04 <sipa> but i don't see how bitcoin core not being under bitcoin/ would somehow mean we don't think people should use bitcoin core
17:00:06 <achow101> #endmeeting