<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?
<ajonas>
sipa: maybe adding one's name to the wiki would be a place to keep track of that?
<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
<josie>
achow101: ack, also some groups might not have something every week
<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?
<stickies-v>
(of course we can revisit if meetings start to take too long but I don't expect that to be an issue)
<emzy>
hi
<Murch[m]>
The priority project reports were usually pretty quick, I don’t expect that it would be much longer with Working Groups
<josie>
stickies-v: also fair, because i have some big updates for both groups im involved with this week haha
<achow101>
stickies-v: I think there are too many groups for every group to report and that will take too long/dominate the meeting
<ajonas>
this was an attempt to control the feast/famine nature of the IRC meetings
<Murch[m]>
achow101: It’s not like there are a ton of other topics usually
<sipa>
i think it's fine to go over all WGs every time, if they don't have anything, that's alright
<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
<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?
<achow101>
Murch[m]: but it's important to leave space for them
<sipa>
if things take too long, we can revisit
<sdaftuar>
hi
<josie>
sdaftuar: *woops better say hi!*
<achow101>
josie: that makes reporting optional, and I suspect that if it were optional, people would simply stop reporting
<josie>
i mean, id prefer it be optional?
<josie>
if youre not motivated to join and report, why force you?
<stickies-v>
+1 josie
<josie>
i certainly wont stop joining and reporting :)
<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
<josie>
glozow: +1
<dergoegge>
hi
<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
<Murch[m]>
glozow: +1
<josie>
make irc noisy again
<sipa>
welcome to zombocom
<josie>
lol
<sipa>
this meta-topic is also not worth spending too much time on
<sipa>
we can see what works
<jonatack>
ajonas: thank you for the useful write-up. i have feedback, not sure when/where best to give it
<achow101>
ok, hope everyone's ready
<achow101>
I'll do the same as last week, if you don't say anything in one minute, i'm moving on
<achow101>
#topic Erlay WG Update (sr_gi, naumenkogs, marcofleon)
<jonatack>
ajonas: maybe i'll write to you directly
<ajonas>
jonatack: you can leave comments on the doc unless you think it needs to be done here
<gleb>
hi! it's me reporting on erlay this time
<cfields>
better than reporting ltae :)
<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.
<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
<sipa>
also, let's revive this: we've had some discussions that led up to sergi's simulator in #minisketch on this IRC network
<sipa>
i can share history
<gleb>
I had some one-to-one calls with WG members to bootstrap review. Different shapes of it, but mostly answering design questions.
<gleb>
People are back from travel next week and i hope we see more in-pr involvement by then :)
<gleb>
Promising so far. Let me know if you're willing to join, we have a signal chat.
<sipa>
gleb: i'd like to join
<gleb>
That's it. I'll answer quick questions here, otherwise we can move on
<gleb>
sipa: will add
<sipa>
thanks!
<achow101>
#topic Fuzzing WG Update (dergoegge)
<dergoegge>
No real update today but i've created a irc channel: #bitcoin-core-fuzzing
<achow101>
#topic Kernel WG Update (TheCharlatan)
<dergoegge>
There is also a signal group, let me know if you want to join
<TheCharlatan>
yes, same for the kernel
marcofleon has joined #bitcoin-core-dev
<sipa>
dergoegge: i'd like to join (i promise i will not be joining every WG)
<achow101>
#topic Benchmarking WG Update (josibake, l0rinc)
John123 has quit [Quit: Client closed]
<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
<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
<josie>
if we end up finding things that are generally useful for our existing CI setup, we will port those over
<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
<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
<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)
<sipa>
*crickets*
<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 :)
<josie>
thats all for me
<achow101>
#topic Silent Payments WG Update (josibake, RubenSomsen)
<achow101>
josie: go again
<josie>
for silent payments, the focus is still the libsecp256k1 PR (bitcoin-core/secp256k1#1519)
<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
<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!
<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)
<josie>
(i posted the gnusha links instead of the google group ones just for you vasild)
<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
<josie>
this to help coordinate work across projects, if anyone is interested in joining / helping out
<cfields>
josie: are you planning on using rented machines? Or looking to source self-hosted hardware/bandwidth?
<josie>
same comment re: working group signal chat
<pinheadmz>
josie add me to the discord
<josie>
cfields: hetzner boxes for now, since weve all been buying our own in that group the last month or so
<josie>
pinheadmz: will do!
<Murch[m]>
Ugh discord. :(
John123 has joined #bitcoin-core-dev
<josie>
cfields: if you have sauce on someone with self hosted stuff.. lemme know :)
<josie>
Murch[m]: i know :( but it seems to work well for the bdk/bitshala folks!
<josie>
the actual core related work we are discussing in signal tho
<Murch[m]>
Matrix 2.0 was announced just recently! ^^
<josie>
discord is for external project coordination
<josie>
anywho, thats all from me
<achow101>
#topic Cluster Mempool WG Update (sdaftuar)
<sdaftuar>
hi
<sdaftuar>
sipa, let me know if you want to join this working group too
<sdaftuar>
sipa continues to work on txgraph, so will let him update on that--
<sipa>
txgraph will be ready for review in Two Weeks(tm)
<sdaftuar>
sweet :)
<achow101>
sdaftuar: do you think end of year for all of cluster mempool to be merged to still be doable?
<sipa>
i have addtx/removetx working in a fuzz test, working on adddependency; no mining/eviction/staging/... yet
<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
<sdaftuar>
but i'm workign towards that goal, if that's what you're asking
<achow101>
#topic Stratum v2 WG Update (sjors)
<Murch[m]>
I think Sjors may be traveling
<josie>
+1 , no hi from him at the beginning
<achow101>
#topic MuSig2 WG Update (achow101)
<achow101>
have yet to actually form a wg, but if anyone would like to join me, let me know
<achow101>
otherwise, waiting for libsecp to do a release
<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
<Murch[m]>
✋️ I want to join the Legacy Wallet Removal WG
<dzxzg>
I would like to join
<achow101>
Murch[m]: dzxzg: will add / dm
<achow101>
#topic Multiprocess WG Update (ryanofsky)
<ajonas>
hold on...
<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
<josie>
at least in the short term
<ryanofsky>
Sorry wasn't ready for this, just several PRs out for review and working on wrapper binary implementation
<fanquake>
pinheadmz: I thought that PR would no-longer be relevant for SV2 ?
<pinheadmz>
fanquake oh. (....oh?)
<TheCharlatan>
ryanofsky when do you think we can add libmultiprocess as a subtree?
<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)
<hebasto>
^ so do I
<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
<ryanofsky>
I don't think anything is blockign libmultiprocess as a subtree, just needs a PR
<pinheadmz>
fanquake ok
<fanquake>
as I don't think there is general buy in to refactoring cconman to be more "general"
<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
<cfields>
pinheadmz: I definitely have my thoughts on that PR as well, just haven't had time to chime in yet.
<pinheadmz>
so a new http will have a lot of duplicate code (GenerateWaitSockets, BindAndListen blah blah blah)
<pinheadmz>
ok ill formalize an issue with links to my WIP stuff
<sipa>
i think this very much depends on what the refactoring looks like
<achow101>
this discussion is slightly off topic, going to move on
<achow101>
#topic Monitoring WG Update (b10c)
<b10c>
hi
<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
<b10c>
that's it
<achow101>
#topic package relay WG Update (glozow)
<glozow>
hi
<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.
<josie>
glozow: and the clever acronym you have decided on for this is..?
<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).
<sdaftuar>
so we're trying to Save the Children now?
<glozow>
Oh no 😂
<josie>
introducing BIP: Save the Children
<glozow>
better than sibling eviction i guess
<jonatack>
:D
<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 😅
<sipa>
i remember the time when the "top" manpage listed for the -S option something about "Count parents together with dead children".
<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?
<glozow>
No. It is still used in the BIP 331 implementation
<stickies-v>
okay thanks will need to refresh my reading then
<jonatack>
A question on my mind is, if one is interested in reviewing, do they need to / should they join the related WG?
<glozow>
Obviously not. They just leave a review on the PR
<achow101>
jonatack: need to - no. should they - depends on how involved they want to be
<achow101>
certainly I intend on reviewing prs from all working groups, but i'm not going to join every single one
<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
<josie>
jonatack: if just casually interested in reviewing, pinging here seems fine too! can always ping the wg champions
<sipa>
eh, makes sense to join
<jonatack>
ok
<jonatack>
Question 2
<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 :)
<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
<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
<achow101>
i don't think anyone here is working on those currently
<sipa>
that also seems like something that deserves discussion from a wider group than just bitcoin core contributors
<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
<cfields>
jonatack: the wgs are for Bitcoin Core the software project. Those are a different thing...
<cfields>
right ^^
<jonatack>
yes. i see discussions happenng, but with few people from here (?) though did see josie post about it recently
<jonatack>
cfields: yes, am thinking about the implementations aspects
<jonatack>
just throwing that out there. josie: cool
<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)
<achow101>
Anything else to discuss?
<josie>
glozow: +1
<jonatack>
glozow: it's more about the trade-offs/risks/benefits of the options,afaict
<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
<jonatack>
am trying to be able to evaluate objectively without getting too close to any
vysn has joined #bitcoin-core-dev
<jonatack>
sipa: sgtm
<achow101>
#endmeeting
<dzxzg>
thanks
<hebasto>
could repo owners look into #31176 and enable two additional github actions, if that's okay?
<josie>
greating meeting everyone, really cool to get insights into what everyone is working on
<fanquake>
hebasto: i think that needs some more concpetual discussion first. will leave a comment
<hebasto>
okay
marcofleon has quit [Quit: Client closed]
Emc99 has joined #bitcoin-core-dev
Emc99 has quit [Client Quit]
Guyver2 has joined #bitcoin-core-dev
<glozow>
jonatack: fwiw as someone who also wasn’t part of the WG discussion, my view is that it’s a way to continue working in the open while acknowledging that large projects require people to continuously work directly together. People naturally form groups based on their interests, and leave/join them over time. Sometimes it’s hard to jump in to a project because there’s a lot of context. I think it’s great that everybody is trying to do
<glozow>
as much as possible in the open by making room for updates at this meeting, posting groups publicly, and always inviting people to join.
bugs_ has joined #bitcoin-core-dev
<jonatack>
glozow: yes, agree, and +1 on the open aspects. will join some of the signal groups and see
dzxzg has quit [Quit: Client closed]
<lightlike>
also worth noting that people who wanted to work together on something have always done so, just in private. It's just more open and transparent now.
<lightlike>
However, given that now anyone can open a WG (no more voting), I think that PRs from a WG should no longer automatically get merge priority automatically over other PRs.
John123 has quit [Quit: Client closed]
<sdaftuar>
lightlike: i agree but i'd just add that i think maintainers should use their judgement on that point (as they always have)
jonatack has quit [Read error: Connection reset by peer]
John123 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] darosior opened pull request #31198: init: warn, don't error, when '-upnp' is set (master...2024_upnp_unbreak_gui) https://github.com/bitcoin/bitcoin/pull/31198
jonatack has joined #bitcoin-core-dev
juleeho has joined #bitcoin-core-dev
juleeho has quit [Remote host closed the connection]