14:00:14 <achow101> #startmeeting 14:00:18 <hebasto> hi 14:00:27 <Murch[m]> hi 14:00:29 <ajonas> hi 14:00:33 <willcl-ark> Hi 14:00:45 <stickies-v> hi 14:00:49 <maxedw> hi 14:00:49 <Chris_Stewart_5> hi 14:00:56 <gleb> hi 14:00:58 <josie> hi 14:01:04 <achow101> There are 2 preproposed meeting topics this week. Any last minute ones to add? 14:01:30 <achow101> #topic priority project reflections and working groups (ajonas) 14:01:32 <dzxzg> hi 14:01:43 <ajonas> I promised last week IâÂÂd have a write up on priority projects and the evolution to working groups. Here it is: https://gist.github.com/adamjonas/aa5e7a46bff8111a1b41285a195c0937 14:01:47 <sipa> hi 14:02:07 <ajonas> I know jonatack had particular interest 14:02:15 <jonatack> hi 14:02:25 <cfields> hi 14:02:27 <kevkevin_> hi 14:02:33 <tdb3> hi 14:03:01 <pinheadmz> hi 14:03:05 <kevkevin_> hi 14:03:20 <marcofleon> hi 14:03:26 <ajonas> As part of this, I've reached out to some working groups to report this week and that schedule is posted at https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Working-Groups 14:03:44 <kevkevin> hi 14:03:47 <sipa> unsure if this is the place/time to bring this up, but i wonder if it would be useful to have a list of workgroup membership (which would be informal, anyone can join/leave), as a signal to indicate what is worth participating in? 14:04:28 <ajonas> sipa: maybe adding one's name to the wiki would be a place to keep track of that? 14:04:37 <achow101> in terms of logistics, I think we can try having 3 groups report each week. There are 11 working groups so far, so that would be each group reports ~once per month 14:04:38 <sipa> yeah, that's what i'd suggest 14:05:03 <ajonas> that would match something we tried in the first round -https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Priorities 14:05:12 <josie> achow101: ack, also some groups might not have something every week 14:05:37 <stickies-v> I don't think we should necessarily put a number of the # of groups reporting each week. If groups have something to share, I'd want to hear, no matter the count. If they don't, just skip. If groups have nothing to say for weeks on end, perhaps good to just check in on why that is? 14:05:56 <stickies-v> (of course we can revisit if meetings start to take too long but I don't expect that to be an issue) 14:06:05 <emzy> hi 14:06:12 <Murch[m]> The priority project reports were usually pretty quick, I donâÂÂt expect that it would be much longer with Working Groups 14:06:15 <josie> stickies-v: also fair, because i have some big updates for both groups im involved with this week haha 14:06:29 <achow101> stickies-v: I think there are too many groups for every group to report and that will take too long/dominate the meeting 14:06:35 <ajonas> this was an attempt to control the feast/famine nature of the IRC meetings 14:06:53 <Murch[m]> achow101: ItâÂÂs not like there are a ton of other topics usually 14:07:11 <sipa> i think it's fine to go over all WGs every time, if they don't have anything, that's alright 14:07:13 <stickies-v> achow101: oh, yeah last week i suggested leads flag ahead of time to you that they have something to share to avoid that waiting problem 14:07:18 <josie> what about the suggestion where if a champion doesnt say hi at the beginning, just skip that group? seems like a low effort way to start? 14:07:18 <achow101> Murch[m]: but it's important to leave space for them 14:07:20 <sipa> if things take too long, we can revisit 14:07:25 <sdaftuar> hi 14:07:42 <josie> sdaftuar: *woops better say hi!* 14:07:43 <achow101> josie: that makes reporting optional, and I suspect that if it were optional, people would simply stop reporting 14:07:58 <josie> i mean, id prefer it be optional? 14:08:08 <josie> if youre not motivated to join and report, why force you? 14:08:14 <stickies-v> +1 josie 14:08:24 <josie> i certainly wont stop joining and reporting :) 14:08:44 <glozow> +1 to no restrictions on updates at the meetings. I donâÂÂt think weâÂÂre anywhere close to it taking too much time. on the contrary we should sync here more 14:08:57 <josie> glozow: +1 14:08:59 <dergoegge> hi 14:09:04 <sipa> part of this i think is to make the IRC meeting more interesting, i think just more people giving updates about things is a good thing 14:09:07 <Murch[m]> glozow: +1 14:09:20 <josie> make irc noisy again 14:09:35 <sipa> welcome to zombocom 14:09:53 <josie> lol 14:10:21 <sipa> this meta-topic is also not worth spending too much time on 14:10:29 <sipa> we can see what works 14:10:36 <jonatack> ajonas: thank you for the useful write-up. i have feedback, not sure when/where best to give it 14:10:36 <achow101> ok, hope everyone's ready 14:11:05 <achow101> I'll do the same as last week, if you don't say anything in one minute, i'm moving on 14:11:11 <achow101> #topic Erlay WG Update (sr_gi, naumenkogs, marcofleon) 14:11:13 <jonatack> ajonas: maybe i'll write to you directly 14:11:13 <ajonas> jonatack: you can leave comments on the doc unless you think it needs to be done here 14:11:21 <gleb> hi! it's me reporting on erlay this time 14:11:42 <cfields> better than reporting ltae :) 14:11:46 <gleb> Making progress on #30116, although for now it's mostly me and sergi, and bruno. There are pending comments the author intends to address asap. Nothing breaking. 14:11:49 <gribble> https://github.com/bitcoin/bitcoin/issues/30116 | p2p: Fill reconciliation sets (Erlay) attempt 2 by sr-gi ÷ Pull Request #30116 ÷ bitcoin/bitcoin ÷ GitHub 14:12:04 <gleb> Sergi continues his work on simulator. It's more efficient now. If Erlay coefficients is something you've been interested in âÂÂàworth taking a look here 14:12:13 <gleb> https://github.com/sr-gi/hyperion/pull/25 14:12:26 <josie> gleb: hyperion is an awesome name 14:12:36 <sipa> also, let's revive this: we've had some discussions that led up to sergi's simulator in #minisketch on this IRC network 14:12:43 <sipa> i can share history 14:12:49 <gleb> I had some one-to-one calls with WG members to bootstrap review. Different shapes of it, but mostly answering design questions. 14:13:14 <gleb> People are back from travel next week and i hope we see more in-pr involvement by then :) 14:13:32 <gleb> Promising so far. Let me know if you're willing to join, we have a signal chat. 14:13:45 <sipa> gleb: i'd like to join 14:14:05 <gleb> That's it. I'll answer quick questions here, otherwise we can move on 14:14:08 <gleb> sipa: will add 14:14:19 <sipa> thanks! 14:14:34 <achow101> #topic Fuzzing WG Update (dergoegge) 14:14:59 <dergoegge> No real update today but i've created a irc channel: #bitcoin-core-fuzzing 14:15:22 <achow101> #topic Kernel WG Update (TheCharlatan) 14:15:22 <dergoegge> There is also a signal group, let me know if you want to join 14:15:52 <TheCharlatan> yes, same for the kernel 14:16:11 <sipa> dergoegge: i'd like to join (i promise i will not be joining every WG) 14:16:33 <achow101> #topic Benchmarking WG Update (josibake, l0rinc) 14:16:42 <josie> had a lot of great discussions at the recent core dev around benchmarking (transcripts should be posted at some point), and one of the key takeways was building better infrastructure is the best next step 14:16:52 <josie> so this past week and going into next week, thats going to be our focus. i started a high level design doc here (https://gist.github.com/josibake/185f913d8b6b1d8d5bdcc4abd2017784) 14:17:01 <josie> our initial approach is to fork our current CI infra and see how we can modify that for the "long running benchmark" usecase. ill be purchasing some dedicated boxes for that and willcl-ark is experimenting with some nix stuff to help us better manage the environments 14:17:10 <josie> if we end up finding things that are generally useful for our existing CI setup, we will port those over 14:17:17 <josie> the main focus for us will be reproducibility, auditability, and determinism. once we have that nailed down, we will actually start using this to benchmark some existing PRs in bitcoin core 14:17:27 <josie> theres also been a lot of work from l0rinc and andrewtoth on specific improvements for core, motivated by some of the ad hoc benching thats been going on, but i think its premature to talk about that until we have some more solid tooling and reporting in place 14:17:51 <josie> we also have a WG signal chat , let me know if youre interested (gonna be a bit hurt if this is the only one sipa doesnt ask to join) 14:18:02 <sipa> *crickets* 14:18:18 <josie> altho if youre only interested in following along with the work, we will be giving detailed updates here in IRC. if you join the WG we will try to get you to do work / review :) 14:18:24 <josie> thats all for me 14:18:31 <achow101> #topic Silent Payments WG Update (josibake, RubenSomsen) 14:18:36 <achow101> josie: go again 14:18:43 <josie> for silent payments, the focus is still the libsecp256k1 PR (bitcoin-core/secp256k1#1519) 14:18:44 <gribble> https://github.com/bitcoin/bitcoin/issues/1519 | GUI: change language selection format to "language - country (locale name)" by Diapolo ÷ Pull Request #1519 ÷ bitcoin/bitcoin ÷ GitHub 14:18:50 <josie> ill be working on updating that before the next meeting with some feedback we got at coredev. also a big thanks to nickler for helping thestack and i get ctime tests in place! 14:18:58 <josie> after that, ill be working on rebasing all of the bitcoin core PRs with help from novo__ (hes been working on a receiving PR with labels support for the bitcoin core wallet) 14:19:02 <gleb> bad gribble 14:19:05 <josie> on the bip side, we reviewed the silent payments psbt bip from andrewtoth and he recently posted that to the mailling list (https://gnusha.org/pi/bitcoindev/cde77c84-b576-4d66-aa80-efaf4e50468fn@googlegroups.com/T/#) 14:19:13 <josie> he also posted a bip proposal for DLEQ proofs, which are relevant for silent payments sending (https://gnusha.org/pi/bitcoindev/b0f40eab-42f3-4153-8083-b455fbd17e19n@googlegroups.com/T/#) 14:19:20 <josie> (i posted the gnusha links instead of the google group ones just for you vasild) 14:19:27 <josie> theres also a lot of interest outside of bitcoin core in implementing silent payments so we'll also be running a discord (ew) for other dev teams (bdk, ledger, rust-bitcoin, bitshala, electrs, etc) with the help of some folks from the bitcoin design community 14:19:37 <josie> this to help coordinate work across projects, if anyone is interested in joining / helping out 14:19:41 <cfields> josie: are you planning on using rented machines? Or looking to source self-hosted hardware/bandwidth? 14:19:43 <josie> same comment re: working group signal chat 14:19:48 <pinheadmz> josie add me to the discord 14:20:04 <josie> cfields: hetzner boxes for now, since weve all been buying our own in that group the last month or so 14:20:27 <josie> pinheadmz: will do! 14:20:38 <Murch[m]> Ugh discord. :( 14:20:51 <josie> cfields: if you have sauce on someone with self hosted stuff.. lemme know :) 14:21:09 <josie> Murch[m]: i know :( but it seems to work well for the bdk/bitshala folks! 14:21:25 <josie> the actual core related work we are discussing in signal tho 14:21:29 <Murch[m]> Matrix 2.0 was announced just recently! ^^ 14:21:33 <josie> discord is for external project coordination 14:21:44 <josie> anywho, thats all from me 14:21:46 <achow101> #topic Cluster Mempool WG Update (sdaftuar) 14:21:55 <sdaftuar> hi 14:22:02 <sdaftuar> sipa, let me know if you want to join this working group too 14:22:09 <Murch[m]> haha 14:22:13 <sipa> sdaftuar: hmmm, tempting 14:22:15 <sipa> i shall join 14:22:20 <josie> sipa: wooooow 14:22:25 <cfields> josie: I might, will dm. 14:22:34 <sdaftuar> anyway, #31122 is the PR to review 14:22:38 <gribble> https://github.com/bitcoin/bitcoin/issues/31122 | cluster mempool: Implement changeset interface for mempool by sdaftuar ÷ Pull Request #31122 ÷ bitcoin/bitcoin ÷ GitHub 14:23:15 <sdaftuar> i think it's making good progress 14:23:32 <sdaftuar> sipa continues to work on txgraph, so will let him update on that-- 14:23:38 <sipa> txgraph will be ready for review in Two Weeks(tm) 14:23:44 <sdaftuar> sweet :) 14:24:09 <achow101> sdaftuar: do you think end of year for all of cluster mempool to be merged to still be doable? 14:24:10 <sipa> i have addtx/removetx working in a fuzz test, working on adddependency; no mining/eviction/staging/... yet 14:24:57 <sdaftuar> achow101: really depends on txgraph timing i think. i'm working in parallel on getting all the non-txgraph dependencies i can think of out of my big PR for review at the same time 14:25:15 <sdaftuar> but i'm workign towards that goal, if that's what you're asking 14:26:14 <achow101> #topic Stratum v2 WG Update (sjors) 14:26:47 <Murch[m]> I think Sjors may be traveling 14:27:10 <josie> +1 , no hi from him at the beginning 14:27:15 <achow101> #topic MuSig2 WG Update (achow101) 14:27:33 <achow101> have yet to actually form a wg, but if anyone would like to join me, let me know 14:27:53 <achow101> otherwise, waiting for libsecp to do a release 14:28:10 <pinheadmz> re: Sv2 #30988 by vasild is the one to review, I need that as well for HTTP, will prob join the Sv2 wg just to stay in that loop 14:28:13 <gribble> https://github.com/bitcoin/bitcoin/issues/30988 | Split CConnman by vasild ÷ Pull Request #30988 ÷ bitcoin/bitcoin ÷ GitHub 14:28:19 <achow101> and I've updated the pr to fix the linking issue 14:28:22 <josie> achow101: interested! (also did a lot of review of the musig2 libsecp module) 14:29:01 <achow101> #topic Legacy Wallet Removal WG Update (achow101) 14:29:12 <achow101> also no group yet, but lmk if you want to join 14:29:22 <achow101> Waiting for review on #30328 14:29:24 <gribble> https://github.com/bitcoin/bitcoin/issues/30328 | wallet: Remove IsMine from migration code by achow101 ÷ Pull Request #30328 ÷ bitcoin/bitcoin ÷ GitHub 14:29:44 <achow101> and #28710 is constantly being rebased 14:29:45 <gribble> https://github.com/bitcoin/bitcoin/issues/28710 | Remove the legacy wallet and BDB dependency by achow101 ÷ Pull Request #28710 ÷ bitcoin/bitcoin ÷ GitHub 14:29:45 <Murch[m]> âÂÂ︠I want to join the Legacy Wallet Removal WG 14:29:57 <dzxzg> I would like to join 14:30:15 <achow101> Murch[m]: dzxzg: will add / dm 14:30:16 <achow101> #topic Multiprocess WG Update (ryanofsky) 14:30:58 <ajonas> hold on... 14:31:20 <josie> not sure if this has been discussed, but might be a lot of overlap between the sv2 / mp working groups, given the recent mining interface that was merged for mp 14:31:32 <josie> at least in the short term 14:31:39 <ryanofsky> Sorry wasn't ready for this, just several PRs out for review and working on wrapper binary implementation 14:32:01 <fanquake> pinheadmz: I thought that PR would no-longer be relevant for SV2 ? 14:32:19 <pinheadmz> fanquake oh. (....oh?) 14:32:20 <TheCharlatan> ryanofsky when do you think we can add libmultiprocess as a subtree? 14:32:24 <josie> ryanofsky: if you have a signal group or place you are discussing mp stuff, id like to join (planning to spend a lot of review time on mp) 14:33:04 <hebasto> ^ so do I 14:33:10 <fanquake> It would also be good to get an issue or similar open for your http re-writing, as it's not entirely clear of the direction, or what is actually happening there 14:33:14 <ryanofsky> I don't think anything is blockign libmultiprocess as a subtree, just needs a PR 14:33:28 <pinheadmz> fanquake ok 14:33:36 <fanquake> as I don't think there is general buy in to refactoring cconman to be more "general" 14:34:39 <pinheadmz> fanquake ok that makes a big difference then bc I have a branch with my own sockman and im in progress of rebasing that on the general sockman 14:35:11 <cfields> pinheadmz: I definitely have my thoughts on that PR as well, just haven't had time to chime in yet. 14:35:31 <pinheadmz> so a new http will have a lot of duplicate code (GenerateWaitSockets, BindAndListen blah blah blah) 14:35:46 <pinheadmz> ok ill formalize an issue with links to my WIP stuff 14:35:50 <sipa> i think this very much depends on what the refactoring looks like 14:36:47 <pinheadmz> sipa looks like #30988 ? 14:36:49 <gribble> https://github.com/bitcoin/bitcoin/issues/30988 | Split CConnman by vasild ÷ Pull Request #30988 ÷ bitcoin/bitcoin ÷ GitHub 14:36:55 <sipa> oh, there is a PR 14:37:23 <sipa> will try to give a conceptual review 14:37:40 <achow101> this discussion is slightly off topic, going to move on 14:37:44 <achow101> #topic Monitoring WG Update (b10c) 14:38:00 <b10c> hi 14:38:47 <b10c> I've updated the nodes to a recent master, enabled ABORT_ON_FAILED_ASSUME (i.e. treating `Assume` as asserts as we do during fuzzing too) on all, and now run a node with ASan and USan enabled. Might enable LSan and/or TSan soon too 14:38:59 <b10c> that's it 14:39:58 <achow101> #topic package relay WG Update (glozow) 14:40:31 <glozow> hi 14:40:37 <glozow> so package relay is the name, but the actual âÂÂfeature milestoneâ we are working towards now is a proper orphan resolution module with reliable orphan protections. This is to prevent package censorship. 14:40:59 <josie> glozow: and the clever acronym you have decided on for this is..? 14:41:38 <glozow> Since #30110 was merged (yay!), I've opened a followup at #31190. The next PRs will be one_honest_peer fuzzer (ensure we can always download), orphan resolution tracker (rebase of #28031 which will look quite different), and making the module internally thread-safe (not started). 14:41:41 <gribble> https://github.com/bitcoin/bitcoin/issues/30110 | refactor: TxDownloadManager + fuzzing by glozow ÷ Pull Request #30110 ÷ bitcoin/bitcoin ÷ GitHub 14:41:42 <gribble> https://github.com/bitcoin/bitcoin/issues/31190 | TxDownloadManager followups by glozow ÷ Pull Request #31190 ÷ bitcoin/bitcoin ÷ GitHub 14:41:45 <gribble> https://github.com/bitcoin/bitcoin/issues/28031 | Package Relay 1/3: Introduce TxDownloadManager and improve orphan-handling by glozow ÷ Pull Request #28031 ÷ bitcoin/bitcoin ÷ GitHub 14:42:17 <sdaftuar> so we're trying to Save the Children now? 14:42:26 <glozow> Oh no ð 14:42:42 <josie> introducing BIP: Save the Children 14:43:03 <glozow> better than sibling eviction i guess 14:43:16 <jonatack> :D 14:43:55 <glozow> IâÂÂm not sure what order IâÂÂll do the next things / may find tasks to give out if people are looking for work. I need time to think about what to do next, so likely itâÂÂll just be the 30110 followups for a few weeks. ItâÂÂs been a lot of sprinting this year ð 14:44:00 <sipa> i remember the time when the "top" manpage listed for the -S option something about "Count parents together with dead children". 14:44:20 <stickies-v> glozow: perhaps this is drifting off-topic, but i thought using the orphanage for package relay was just a temporary/duct-tape approach to have opportunistic package relay until the p2p stuff is done and we don't need the orphanage for this anymore, right? 14:45:07 <glozow> No. It is still used in the BIP 331 implementation 14:45:46 <stickies-v> okay thanks will need to refresh my reading then 14:46:27 <achow101> #topic Ad-hoc high priority for review 14:46:27 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4 14:46:38 <achow101> (maybe we should kill this too?) 14:46:42 <jonatack> A question on my mind is, if one is interested in reviewing, do they need to / should they join the related WG? 14:47:09 <glozow> Obviously not. They just leave a review on the PR 14:47:09 <achow101> jonatack: need to - no. should they - depends on how involved they want to be 14:47:36 <achow101> certainly I intend on reviewing prs from all working groups, but i'm not going to join every single one 14:47:46 <sipa> my thinking is that if you're planning to keep track of all the things the WG is working on, it makes sense to review - but obviously there can't be a requirement 14:47:47 <josie> jonatack: if just casually interested in reviewing, pinging here seems fine too! can always ping the wg champions 14:47:56 <sipa> eh, makes sense to join 14:49:02 <jonatack> ok 14:49:06 <jonatack> Question 2 14:49:19 <sdaftuar> regarding the cluster mempool working group specifically, feel free to let me know if you want to be pinged for review on PRs as they come up, or if you have questions that woudl be helpful for me to answer. or just review PRs as you see fit, that works too :) 14:49:57 <jonatack> by dint of the bips work, am spending a fair amount of time on keeping up with the new opcodes / covenants / (centralized) MEV discussions 14:50:41 <jonatack> idk how much bandwidth and creedance people here are giving to those topics, but if there is a WG on that I'd be interested to join 14:51:13 <achow101> i don't think anyone here is working on those currently 14:51:19 <sipa> that also seems like something that deserves discussion from a wider group than just bitcoin core contributors 14:51:32 <josie> personally, i think there should be an important distinction between BIPs (broader bitcoin ecosystem) and bitcoin core (implementation). if you are interested in running a bips irc channel / or a wg, id be happy to join tho, as im interested in both 14:51:39 <cfields> jonatack: the wgs are for Bitcoin Core the software project. Those are a different thing... 14:51:50 <cfields> right ^^ 14:51:55 <jonatack> yes. i see discussions happenng, but with few people from here (?) though did see josie post about it recently 14:52:30 <jonatack> cfields: yes, am thinking about the implementations aspects 14:52:52 <jonatack> just throwing that out there. josie: cool 14:53:01 <glozow> fwiw I think it would be great for people working on those things to talk about their ideas and progress here (unless itâÂÂs about activation/politics) 14:53:12 <achow101> Anything else to discuss? 14:53:31 <josie> glozow: +1 14:53:40 <jonatack> glozow: it's more about the trade-offs/risks/benefits of the options,afaict 14:53:57 <sipa> also, people can bring up meeting topics/updates here when they have interesting news to share, even if it's not part of a WG 14:54:01 <jonatack> am trying to be able to evaluate objectively without getting too close to any 14:54:47 <jonatack> sipa: sgtm 14:55:07 <achow101> #endmeeting