16:00:22 <achow101> #startmeeting 
16:00:22 <corebot> achow101: Meeting started at 2025-07-10T16:00+0000
16:00:23 <corebot> achow101: Current chairs: achow101
16:00:24 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:25 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:26 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:31 <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 <janb84> #here 
16:00:34 <hebasto> hi
16:00:36 <rkrux> hi
16:00:37 <eugenesiegel> hi
16:00:38 <janb84> hi
16:00:39 <kevkevin> hi
16:00:40 <lightlike> hi
16:00:43 <furszy> hi
16:00:43 <Murch[m]> Hi
16:00:44 <stickies-v> hi
16:00:44 <sr_gi[m]1> hi
16:00:46 <cfields> hi
16:00:53 <emzy> hi
16:00:53 <achow101> There are no pre-proposed meeting topics this week. Any last minute ones to add?
16:01:23 <b10c> hi
16:01:25 <kanzure> hi
16:01:27 <jonatack> hi
16:01:29 <l0rinc> hi
16:01:35 <TheCharlatan> hi
16:01:36 <darosior> hi
16:01:41 <laanwj> hi
16:01:42 <achow101> #topic Erlay WG Update (sr_gi, gleb)
16:02:20 <sr_gi[m]1> Ok, I have some data to report. I've been running sims in networks up to 200 nodes on Warnet, and what I’ve observed is that, for these sizes, we can achieve  ~24% savings in INV messages for ~35% more latency. This is slightly better than what I saw when simulating in the actual network event simulator (the prospected was 40% more time for 21% savings), but pretty much in line.
16:02:22 <pinheadmz> hi
16:02:40 <sr_gi[m]1> Something I've noticed, however, is that the bigger the networks, the better this ratio seems to get. I haven’t been able to run reliable simulations for bigger networks, since I have been struggling with limitation in the current approach for capturing results. The biggest I've tried so far is 500 nodes, but the sims crash more often than not (or end up returning only partial data).
16:02:50 <sipa> hi
16:03:00 <sr_gi[m]1> This week I decided to change the approach for this, instead of collecting data from the node’s logs, I've implemented a small patch in Core that keeps track of when a node first hers about a transaction (first INV received) and when it first sees it, and I added it to getrawtransaction, so the Warnet scenario can just query that information as it goes. I think this would allow for bigger network to be tested.
16:03:17 <sr_gi[m]1> One thing I'm missing is running sims with more than 8 outbounds per node, to see if the expected decrease in bandwidth (with respect to the current approach) when making the network more tightly connected can be seen.
16:03:26 <sr_gi[m]1> I think this should be good as a concept to start moving forward with #30116.
16:03:28 <corebot> https://github.com/bitcoin/bitcoin/issues/30116 | p2p: Fill reconciliation sets (Erlay) attempt 2 by sr-gi · Pull Request #30116 · bitcoin/bitcoin · GitHub
16:03:37 <brunoerg> hi
16:03:38 <sr_gi[m]1> I'll be working on making the simulations easily reproducible (they are a bit clunky atm given the issues I was mentioning before) and test the new approach to gather results for bigger networks. Happy to walk through both concept and approach to anyone who’s interested in reviewing it.
16:03:39 <theStack> hi
16:03:52 <dzxzg> hi
16:04:28 <cfields> sr_gi[m]1: as I
16:05:18 <sr_gi[m]1> :tada:
16:05:31 <cfields> as I've been poking at the p2p code lately, I've noticed a likely bottlenecks wrt scaling and number of nodes being processed. I'd be interested in discussing some of that with you and looking at some data, maybe not directly related to erlay itself.
16:05:38 <sr_gi[m]1> That's it from me. Feel free to ping me if you'd like some intro to it
16:05:40 <cfields> *a few likely
16:06:14 <sr_gi[m]1> cfields: Sure, happy to looking at that with you
16:06:24 <cfields> 🚀
16:06:45 <achow101> #topic Kernel WG Update (TheCharlatan)
16:07:01 <TheCharlatan> Looking for some comments again on the approach in #30595 regarding having a C or a C++ API as a first class citizen for the library.
16:07:03 <corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
16:07:07 <jonatack> cfields: nice -- interested to hear where the bottlenecks appear to be
16:07:08 <sipa> cfields: i have thoughts too, will reach out
16:07:22 <TheCharlatan> We've had the debate for over a year now, and I implemented both variants, but people either stopped weighing in, or still seem undecided.
16:08:26 <TheCharlatan> would be good to get this rolling again, especially since more people seem to be getting interested
16:09:16 <TheCharlatan> that's all
16:09:56 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:10:03 <abubakarsadiq> hi
16:10:57 <sipa> hi, 31553 got merged, so the next PR in the TxGraph Series(tm) is #32263
16:10:59 <corebot> https://github.com/bitcoin/bitcoin/issues/32263 | cluster mempool: add TxGraph work controls by sipa · Pull Request #32263 · bitcoin/bitcoin · GitHub
16:11:25 <sipa> while 32263 isn't all that critical as it doesn't change APIs much, i think it's the best thing to look at now
16:11:42 <johnny9dev> hi
16:11:58 <sipa> the bigger plan is getting sdaftuar to rebase #28676 on top of the now-merged TxGraph stuff, and perhaps seeing if some parts of that can be split off
16:12:02 <corebot> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
16:12:33 <sipa> also, getting #30605 would be nice as i think it's very close
16:12:36 <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:13:00 <sipa> that's it from me
16:13:15 <achow101> #topic MuSig2 WG Update (achow101)
16:13:24 <achow101> No changes since last week, #31244 is still probably rfm.
16:13:28 <corebot> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
16:13:41 <achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
16:13:48 <johnny9dev> https://github.com/pinheadmz/bitcoin-core-app
16:13:59 <johnny9dev> gradually working on getting my work from the last month upstreamed.
16:13:59 <johnny9dev> pinheadmz completed a really nice proposal for using bitcoin/bitcoin as a submodule to the project. https://github.com/pinheadmz/bitcoin-core-app. I took that approach and used a git filter-branch to try and extract out all of the history for the qml folder while not burdening the repo with the entire history of bitcoin/bitcoin at https://github.com/johnny9/bitcoin-core-app. I really like this approach and it would get my vote for
16:13:59 <johnny9dev> how to move forward with the project. I think rebasing with upstream and managing the two has become too overwhelming.
16:14:25 <glozow> hi
16:14:42 <johnny9dev> I think we're interested in some opinions on moving forward on a submodule approach for the project
16:14:42 <darosior> neat
16:15:51 <johnny9dev> Possibly creating a new repo and archiving the old one.
16:15:58 <achow101> johnny9dev: would this approch result in the gui being permanently separated from the rest of the project?
16:16:09 <Murch[m]> What would you use as the steps for the submodule? Would you update it to tagged releases or just update to upstream occasionally?
16:16:16 <pinheadmz> i think thats a practical longer term goal
16:16:18 <fanquake> Would that mean you'd ultimately delete everything gui related on the bitcoin/bitcoin side, and move it into the app repo? and going forward we'd ship a gui from the app repo?
16:16:26 <pinheadmz> we still need to figure out "who" manages depends for qt
16:16:34 <fanquake> Would you make your own copies of the depends system, guix etc in that repo?
16:16:41 <pinheadmz> and right now even the qml source depends on the qt/ code in bitcoin core cirrently
16:16:53 <fanquake> same for copies of the CI system?
16:16:54 <johnny9dev> We can always collapse back I think and this is just for gui-qml
16:17:19 <pinheadmz> presumably with core as a submodule we wouldnt need to copy all the bitcoin core CI either
16:17:48 <johnny9dev> We certainly have a lot of figure out in terms of CI and deployment but at least for now it seems like it will give us more flexibility
16:18:02 <fanquake> pinheadz: that assume's that core keeps everything gui related around though?
16:18:18 <pinheadmz> no i meant like, right now qml-gui runs everything bitcoin runs
16:18:20 <pinheadmz> no need for that
16:18:30 <pinheadmz> gui repo can just test gui
16:19:08 <pinheadmz> but then yeah depends/qt, and src/qt we could eventually move to the GUI repo
16:19:46 <pinheadmz> and yes i assume ship from the gui repo
16:19:55 <pinheadmz> but also this is the QML gui only, its not the legacy gui
16:20:24 <pinheadmz> however i guess the same kind of structure might be possible  hm...
16:20:40 <achow101> pinheadmz: I guess the question is whether this is the long term organizational plan, or just temporary to avoid having to constantly rebase gui-qml
16:20:49 <achow101> I assume that's all still up in the air
16:21:14 <pinheadmz> yeah
16:21:26 <fanquake> Yea, it's not really clear if this is just useful for development, or what we actually want to do long term
16:21:31 <achow101> this might be a good topic to discuss at coredev
16:21:33 <fanquake> Longer term, I don't think submoduling makes sense
16:22:09 <johnny9dev> I'd like to at least try this as soon as possible because it gets me to cmake and qt6
16:22:46 <pinheadmz> not to mention, there are changes to bitcoin core source code in the gui-qml repo and a sumbodule just makes that not psossible
16:23:31 <johnny9dev> Anything there should be upstreamed properly, though
16:24:12 <pinheadmz> well one conflict i found was for example adding back a get-block-time interface that had been *removed* in core !
16:25:17 <achow101> johnny9dev: I think we can setup a new repo in bitcoin-core for this if you think it would be helpful with developing the new gui
16:25:45 <fanquake> is there an issue with the current repo?
16:25:57 <johnny9dev> Thank you. Might need a bit to decide what the initial instance should be.
16:26:12 <achow101> fanquake: I assume blowing away the commit history is not desirable?
16:26:13 <johnny9dev> But will let you know what is decided for sure
16:26:29 <fanquake> achow101: then just make a new branch?
16:26:33 <fanquake> Why does that need a new repo
16:26:51 <hebasto> a new branch might me default one
16:27:12 <johnny9dev> Good point. Just new default branch might do it.
16:27:27 <pinheadmz> blow away the entire history of main?
16:27:35 <achow101> fanquake: for issue and pr organzation, since the codebase is essentially entirely different
16:27:38 <pinheadmz> and johnny9dev and i can work on a PR to the new empty branch
16:27:51 <achow101> repos are cheap anyways, and we can delete/archive them when they're not needed
16:28:05 <fanquake> achow101: Isn't that already the QML repo?
16:28:32 <hebasto> pinheadmz: "main" remains; new branch, say "qt6" or " dev" will be the default one
16:28:44 <pinheadmz> yeah with no history :+1:
16:29:40 <achow101> fanquake: which currently has issues and prs that refer to code in already in the repo that has a completely different layout than what was proposed
16:30:31 <johnny9dev> I work on sorting out the PRs and migrate them to the new branch.
16:31:00 <achow101> i don't think it matters that much either way, and we can accomodate what they want/need. either way, it doesn't really effect the main project
16:32:20 <johnny9dev> Ok I think a branch makes sense and will work with hebasto and pinhead to sort it out.
16:33:01 <achow101> alright
16:33:04 <johnny9dev> That is all I think.
16:33:14 <achow101> #topic orphan resolution WG Update (glozow)
16:33:24 <glozow> #31829 is looking close-ish
16:33:27 <corebot> https://github.com/bitcoin/bitcoin/issues/31829 | p2p: improve TxOrphanage denial of service bounds by glozow · Pull Request #31829 · bitcoin/bitcoin · GitHub
16:33:33 <glozow> I have opened a followup for cleanups and optimizations
16:34:06 <glozow> Followup is #32941
16:34:07 <corebot> https://github.com/bitcoin/bitcoin/issues/32941 | p2p: TxOrphanage revamp cleanups by glozow · Pull Request #32941 · bitcoin/bitcoin · GitHub
16:34:27 <glozow> that's all from me
16:34:50 <achow101> Any other topics to discuss this week?
16:36:13 <achow101> #endmeeting