19:00:10 <laanwj> #startmeeting 
19:00:10 <core-meetingbot`> Meeting started Thu Feb 24 19:00:09 2022 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:10 <core-meetingbot`> Available commands: action commands idea info link nick
19:00:30 <achow101> hi
19:00:32 <jamesob> hi
19:00:33 <b10c> hi
19:00:40 <ajonas> hi
19:00:42 <sipa> hi
19:00:45 <laanwj> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball
19:00:47 <laanwj> morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:00 <kvaciral[m]> hi
19:01:18 <prayank> hi
19:01:29 <luke-jr> hi
19:01:35 <michaelfolkson> hi
19:01:38 <laanwj> one proposed meeting topic this week (you can propose meeting topics during the week with #proposedmeetingtopic): Bitcoin Core contributor survey (ajonas)
19:01:52 <laanwj> any last minute topics?
19:04:06 <laanwj> as the 23.0 branch-off is planned soon (2022-03-01, in less than a week), it probably makes sense to go over the milestone again
19:04:21 <laanwj> #topic 23.0 milestone
19:04:21 <core-meetingbot`> topic: 23.0 milestone
19:04:24 <laanwj> https://github.com/bitcoin/bitcoin/milestone/52
19:05:17 <luke-jr> idk if https://github.com/bitcoin-core/gui/pull/557 is too late or not (forgot about it I guess)
19:05:18 <laanwj> there's, some bugfixes left, as well as the usual release process items
19:06:01 <laanwj> 23.0 milestone for gui repo: https://github.com/bitcoin-core/gui/milestone/7
19:06:49 <prayank> laanwj: #23524 #22834 are important, included in 23.0 milestone and RFM
19:06:50 <gribble> https://github.com/bitcoin/bitcoin/issues/23524 | doc: Fix typos in endif header comments by MarcoFalke · Pull Request #23524 · bitcoin/bitcoin · GitHub
19:06:53 <gribble> https://github.com/bitcoin/bitcoin/issues/22834 | net: respect -onlynet= when making outbound connections by vasild · Pull Request #22834 · bitcoin/bitcoin · GitHub
19:07:05 <laanwj> luke-jr: I don't know, we already had the translations freeze
19:07:08 <luke-jr> right
19:07:25 <prayank> Sorry it was #23542
19:07:28 <luke-jr> and unfortunately one of the strings changed in between, so it's not a simple revert
19:07:30 <gribble> https://github.com/bitcoin/bitcoin/issues/23542 | net: open p2p connections to nodes that listen on non-default ports by vasild · Pull Request #23542 · bitcoin/bitcoin · GitHub
19:07:56 <laanwj> it's too bad we didn't catch it before merging bitcoin-core/gui#296
19:07:57 <gribble> https://github.com/bitcoin/bitcoin/issues/296 | HTTP Error 404: Not Found
19:08:01 <luke-jr> (simple revert would have the benefit of having already been translated)
19:08:43 <laanwj> yes, then translation memory would just pull the old message
19:09:15 <laanwj> in any case we can probably still do it it's only a few messages
19:09:31 <laanwj> although fairly important ones that appear inthe intro that we really don't want untranslated
19:09:45 <laanwj> prayank: ok, thanks
19:13:05 <laanwj> did anyone ever figure out what happens in  #24335?
19:13:06 <gribble> https://github.com/bitcoin/bitcoin/issues/24335 | Segmentation Fault in V21 and V22 releases · Issue #24335 · bitcoin/bitcoin · GitHub
19:14:05 <achow101> yes
19:14:10 <achow101> it should be fixed by #23304
19:14:13 <gribble> https://github.com/bitcoin/bitcoin/issues/23304 | wallet: Derive inactive HD chains in additional places by achow101 · Pull Request #23304 · bitcoin/bitcoin · GitHub
19:14:17 <laanwj> looks like an issue multiple people are having, so would be good to solve it for 0.23
19:14:19 <laanwj> good!
19:15:22 <laanwj> I vaguely remembered there was a fix but it wasn't linked in any way :)
19:16:24 <laanwj> ok that's covered, anything else people would like to discuss for 23.0?
19:16:45 <laanwj> #24201 is labeled WIP, I don't think it should be on the milestone
19:16:47 <gribble> https://github.com/bitcoin/bitcoin/issues/24201 | WIP: p2p: Avoid InitError when downgrading peers.dat by junderw · Pull Request #24201 · bitcoin/bitcoin · GitHub
19:18:19 <prayank> I think I can review, tACK it and WIP can be removed. Will need some clarity from PR author why is WIP mentioned. I had already commented in PR.
19:18:58 <jonatack> hi
19:19:24 <laanwj> but WIP is generally before the review phase
19:19:31 <laanwj> yeah, I'm not sure
19:20:13 <prayank> It was reviewed by multiple devs and author added WIP 5 days back
19:20:21 <laanwj> i see, weird
19:20:30 <luke-jr> laanwj: FWIW, I do have a better "translation memory" I use for Knots - but I'm not sure how easily I can send results from it back to Transifex :x
19:21:01 <michaelfolkson> Only 1 ACK and 1 utACK currently
19:21:28 <luke-jr> I think I would have to freeze all the translations, fetch, run my script on them, upload, and unfreeze - but it does take an hour or two
19:21:45 <michaelfolkson> Worth asking about the WIP regardless of milestone
19:22:22 <laanwj> yes
19:22:56 <laanwj> #topic Bitcoin Core contributor survey (ajonas)
19:22:56 <core-meetingbot`> topic: Bitcoin Core contributor survey (ajonas)
19:23:09 <ajonas> hi
19:23:23 <ajonas> I've written up a summary of the Bitcoin Core dev contributor survey at https://adamjonas.com/bitcoin/coredev/retro/coredev-2021-retro/
19:23:31 <ajonas> Thanks to those who participated and I am looking forward to bothering folks again next year
19:23:40 <ajonas> that's it
19:23:49 <laanwj> thanks ajonas!
19:24:06 <laanwj> it was interesting to read
19:25:15 <laanwj> any other topics people would like to discuss? or another short meeting :)
19:25:40 <MarcoFalke> I've created #24433 as a reply to the retro, btw
19:25:40 <jeremyrubin> oops
19:25:41 <gribble> https://github.com/bitcoin/bitcoin/issues/24433 | doc: Explain that feedback needs to be addressed by MarcoFalke · Pull Request #24433 · bitcoin/bitcoin · GitHub
19:25:44 <jeremyrubin> thanks ajonas!
19:26:27 <MarcoFalke> Section "review": https://adamjonas.com/bitcoin/coredev/retro/coredev-2021-retro/#review
19:27:05 <jeremyrubin> one little topic i'd like to discuss around signets if theres nothing else laanwj
19:27:44 <jeremyrubin> #proposedmeetingtopic : signet parameter distributions / signet data dirs improvement approach
19:27:50 <laanwj> MarcoFalke: definitely agree with that
19:28:29 <jamesob> ajonas: cool wordcloud
19:28:30 <prayank> MarcoFalke: I wanted to suggest something in that PR but that would become controversial. And I was not aware of this survey.
19:28:50 <MarcoFalke> Another point of feedback was that sometimes pull requests with ACKs aren't merged. Sometimes I see them too, but I din't feel comfortable merging them, because I am not at all familiar with that part of the codebase.
19:29:11 <laanwj> MarcoFalke: makes sense to ping another maintainer then
19:29:13 <laanwj> or just, mention it here
19:30:16 <MarcoFalke> Ok, maybe this is soemthing we might want to document as well.
19:31:07 <prayank> We can document lot of things for reviewers in which they had to ping in IRC
19:31:11 <laanwj> yes, in general, don't assume anyone has an overview of all issues and PRs, if there's something that needs to be addressed (or ready for merge) it's best to bring it up here
19:31:27 <MarcoFalke> Also, it was mentioned that there should be more domain-specific maintainers. I tend to agree, but right now we don't have enough maintainers to assign each one a single domain.
19:32:04 <laanwj> it doesn't help if the wallet maintainers keep stepping down :)
19:32:41 <laanwj> yes, that's nothing new, we've tried that since 2012 or so
19:33:04 <luke-jr> XD
19:34:28 <jeremyrubin> i think also it's helpful if current maintainers make clear areas which are more difficult to review for them -- e.g., i dont think there's that many maintainers who have deep mempool expertise (if i'm wrong here LMK), so i think things on mempool are negatively impacted by lack of reviewers who can prod along ack/merge.
19:34:38 <laanwj> we've always had, there's a lot of things people want and agree on but no one stepping up to do them, and we don't practice human sacrifice, not even by assigning people to be wallet maintainer :)
19:34:57 <jeremyrubin> Maybe current maintainers can list out what parts of the code they feel more/less confident on?
19:35:52 <ajonas> I don't think holding maintainers feet to the fire on what they know or what they don't is going to improve that
19:36:23 <luke-jr> maintainers are supposed to merge based on review ACKs, not their own personal review
19:36:27 <laanwj> right, lack of knowledgeable reviewers in certain areas of the code isn't going to be improved by slapping labels on people
19:36:33 <MarcoFalke> jeremyrubin:  Grep for ACK-comments on the commits and create a heat-map, will be less subjective
19:36:38 <prayank> luke-jr: +1
19:36:44 <luke-jr> obviously it's good if they're familiar with the scope, but it shouldn't be a barrier in itself
19:37:08 <MarcoFalke> luke-jr: Maintainers should be able to tell if something is a backdoor or not before merge
19:37:23 <luke-jr> MarcoFalke: reviewers should
19:37:42 <sipa> luke-jr: That's true, but I'm not sure it matters that much, because personal knowledge about a part of codebase also correlates with judging reviewer competence in that part.
19:37:45 <achow101> personally, I don't feel comfortable with merging something if I haven't reviewed it, and I don't feel comfortable reviewing something that I'm not familiar with
19:37:47 <laanwj> so like, the mempool is notoriously difficult to get people to review for, so, we make glozow mempool maintainer
19:37:48 <MarcoFalke> luke-jr: No one signs review comments, so a GitHub employee can hijack Bitcoin Core if maintainers blindly click the merge button without thinking
19:37:48 <luke-jr> maintainers aren't supposed to be a position of privilege
19:37:50 <jeremyrubin> i dont think i'm advocating holding feet to the fire moreso identifying where our current maintainership is stronger/weaker to aid in identifying where we might improve.
19:38:12 <michaelfolkson> It isn't just the maintainers knowledge, it is the maintainers' assessment of the reviewers' knowledge
19:38:34 <jeremyrubin> laanwj: glozow is currently one of the main people writing new mempool code, so her being a maintainer probably doesn't help much
19:38:36 <luke-jr> MarcoFalke: true, but hopefully the spoofed reviewers would notice before a release
19:38:45 <laanwj> jeremyrubin: that was exactly my point
19:38:45 <prayank> laanwj: NACK
19:38:55 <laanwj> prayank: i'm not asking you
19:39:30 <luke-jr> …
19:39:34 <prayank> laanwj: what was it?
19:39:47 <laanwj> i also don't think brining hijack-ability of github into this is useful now
19:39:50 <jeremyrubin> laanwj sorry i didn't parse the sarcasm
19:40:03 <ajonas> re the mempool - I understand the frustration but the reality is that the more sensitive the code and the fewer people understand it, the harder it will be to get in.
19:40:26 <ajonas> mempool actually has a lot more momentum than it did a year ago
19:40:36 <ajonas> so review is improving
19:40:43 <laanwj> the pr review meetings are probably helping!
19:40:51 <MarcoFalke> jeremyrubin: I don't think this is sacrasm. maintainers are naturally those that review the most. For example, I used to review every test pull request, so I became test maintainer
19:41:22 <ajonas> it's like p2p 2-3 years ago when it became more of an area of interest
19:41:31 <laanwj> MarcoFalke: it was like half sarcasm half a serious proposal
19:41:34 <jeremyrubin> i think the sarcasm was that the talent pool is shallow so right now we'd be making the person writing be in a position to not merge their own thing
19:41:34 <luke-jr> MarcoFalke: (and you do a good job at it)
19:41:54 <prayank> laanwj: changing RBF policy in core because of xyz reasons in abc project is not going to improve anything FYI and it doesn't matter who is the maintainer
19:42:12 <luke-jr> jeremyrubin: maintainers can merge their own thing if it gets reasonable review ACKs
19:42:16 <laanwj> MarcoFalke: i think it'd be a good idea but not so much to get more review, just to have someone continuously involved with it in the project
19:43:40 <laanwj> in any case, concrete proposals for maintainers would be useful
19:44:04 <jeremyrubin> laanwj: that's basically what i'm trying to point out, that it'd be good if our 'maintainership coverage' is documented so that we can better it for different areas of the code
19:44:06 <laanwj> for different areas
19:44:19 <jeremyrubin> mempool as an example, but other parts too
19:44:28 <laanwj> preferably people stepping up themselves and not being sacrificed :p
19:44:40 <luke-jr> maybe more IRC "rtm" would help
19:45:10 <laanwj> yes
19:46:08 <laanwj> more discussion here would help in any case i think
19:46:24 <ajonas> I guess it's worth recognizing in this discussion and the summary that being a maintainer is hard
19:46:37 <ajonas> thank you to those that are shouldering that load
19:47:00 <laanwj> as said, github just has too large volume of activity, no one can keep up with it, if there's anything of note it's good to bring it up here
19:47:06 <jeremyrubin> one concept: maintainers can delegate explicitly (e.g., on GH) the maintainer decision on a PR if theres not one who feels qualified
19:47:07 <laanwj> thanks ajonas
19:47:25 <jeremyrubin> sort of in-between of being a formal maintainer v.s. giving someone else the RTM call
19:48:26 <laanwj> i mean the first step is just to communicate, are you unsure, ask it, don't wait until someone gets around to your PR by accident :)
19:49:01 <michaelfolkson> Agreed. I think just more communication is the solution rather than creating new roles
19:50:19 <laanwj> any other topics?
19:50:22 <luke-jr> I wonder if that bitcoinacks website was helpful
19:50:26 <michaelfolkson> I think it is fine for a maintainer to say on a PR "I think this is ready to merge but I'm not as familiar as I'd like with this part of the codebase. Any thoughts from Person A, B, C"
19:50:27 <jeremyrubin> i did a small one ^
19:50:32 <luke-jr> is it dead now?
19:50:42 <jeremyrubin> 11:27 #proposedmeetingtopic: signet parameter distributions / signet data dirs improvement approach
19:50:59 <laanwj> #topic signet parameter distributions / signet data dirs improvement approach (jeremyrubin)
19:51:00 <core-meetingbot`> topic: signet parameter distributions / signet data dirs improvement approach (jeremyrubin)
19:51:02 <achow101> luke-jr: I tried using it a few weeks ago and it seemed to be dead
19:51:17 <laanwj> luke-jr: yes, i think so, the person maintaining it suddenly stopped doing so
19:51:21 <jeremyrubin> not much to say, but in running the ctv signet people have been having issues with datadirs because any signet goes to the same place
19:51:42 <jeremyrubin> it might be nice if signets had e.g. a per challenge chainstate directory or something
19:52:20 <jeremyrubin> or if bitcoin.conf could have multiple [signet.xyz]'s for configging different named signets
19:52:43 <jeremyrubin> dont really have any idea of how to approach that so if anyone has any thoughts would love them before i spend any time on it
19:53:12 <laanwj> luke-jr: there was some discussion about it at the time and we moved it into bitcoin-core at some point https://github.com/bitcoin-core/bitcoin-acks , but no one picked it up
19:53:51 <prayank> jeremyrubin: asking to backup old signet datadir, delete and relaunch can be workaround for now and maybe separate dir in future
19:54:08 <jeremyrubin> prayank: certainly works for now
19:54:10 <laanwj> jeremyrubin: yes, that would make sense
19:54:36 <achow101> signets could be identified by the hash of the challenge, and we make datadirs like "signet_<challenge hash>"?
19:54:41 <jeremyrubin> i will probably just make the fork that i have make a different dir by default to skirt the problem for now (going to add default params to that branch)
19:54:56 <jeremyrubin> achow101: one question I had is if challenges can change over time
19:55:01 <michaelfolkson> luke-jr: It also had the problem of people not following the review guidance (Concept ACK, Approach ACK, ACK) and using tACK, utACK, crACK etc
19:55:11 <achow101> jeremyrubin: wouldn't that break validating old blocks?
19:55:12 <sipa> could they be identified by the hash of the genesis block?
19:55:27 <sipa> jeremyrubin: Pretty sure they challenge cannot be changed
19:55:30 <jeremyrubin> achow101: depends, are the old scriptcodes covered in the sig?
19:55:58 <achow101> sipa: IIRC the genesis is shared
19:56:16 <sipa> jeremyrubin: the signet block hash covers the challenge
19:56:24 <jeremyrubin> It would also be nice if bitcoin core could have multiple signets in the chain configs
19:56:55 <sipa> (it's done using a fake transaction which creates a UTXO with scriptPubKey=challenge, and then another transaction spending that UTXO)
19:57:25 <sipa> so the prevhash of the spending input indirectly is derived from the challenge
19:57:44 <jeremyrubin> i think nicknames are a little better than hash of signetchallenge, although hash of signetchallenge does guarantee uniqueness
19:58:31 <jeremyrubin> it'd also be good if 1 bitcoin.conf could configure >1 signet so i think the [signet.xyz] format is probably right
19:59:00 <jeremyrubin> maybe we can do user configured nicknames, and the directory can be based on the challenge?
19:59:12 <sipa> i think i'd prefer that
19:59:54 <sipa> have dirname/configsection be signet_<hash(challenge)>, but then (perhaps later) add a way to configure a nickname for a signet, to allow easy selection on commandline?
20:01:18 <jeremyrubin> and i guess for backwards compat, just signet is the default one?
20:01:24 <sipa> right
20:01:28 <laanwj> right, "how to avoid collisions" and "how to configure signets user friendly" are more or less separate problems
20:01:39 <sipa> laanwj: exactly
20:01:46 <jeremyrubin> i dont think we need the signet_hashchallenge in the config section
20:01:52 <jeremyrubin> it's redundant with the signetchallenge field
20:02:11 <jeremyrubin> so maybe we can just infer it
20:02:38 <jeremyrubin> [anynameyoulike] signet=1 signetchallenge=x and infer it?
20:03:17 <jeremyrubin> i'll see if i can put something together with that
20:03:20 <laanwj> we're running out of time
20:03:27 <achow101> could be problematic if you did [test] signet=1
20:03:48 <achow101> I liked the [signet.xyz] suggestion, and just parse the xyz name from that
20:04:07 <jamesob> achow: +1
20:04:07 <jeremyrubin> thanks :)
20:04:15 <laanwj> achow101: yes, seems better to be explicit
20:04:41 <laanwj> minimize potential ambigiousness
20:05:27 <laanwj> anyhow, time to close the meeting, thanks everyone for attending
20:05:30 <laanwj> #endmeeting