14:00:13 <achow101> #startmeeting 
14:00:29 <pinheadmz> hi
14:00:32 <brunoerg> hi
14:00:32 <achow101> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard aureleoules b10c BlueMatt brunoerg cfields darosior dergoegge dongcarl fanquake fjahr furszy gleb glozow hebasto instagibbs jamesob jarolrod jonatack josibake kallewoof kanzure kouloumos kvaciral laanwj LarryRuane lightlike luke-jr MacroFake Murch phantomcircuit pinheadmz promag provoostenator ryanofsky sdaftuar S3RK stickies-v sipa theStack TheCharlatan vasild
14:00:37 <instagibbs> hi
14:00:40 <darosior> hi
14:00:45 <josie> hi
14:00:47 <glozow> hi
14:00:48 <dergoegge> hi
14:00:51 <achow101> There are no preproposed meeting topics this week. Any last minute ones to add
14:00:57 <stickies-v> hi
14:01:06 <gleb> hi
14:01:35 <lightlike> hi
14:01:36 <ajonas> hi
14:01:46 <achow101> #topic package relay updates (glozow)
14:01:52 <hebasto> hi
14:02:08 <glozow> #28450 was merged (yay) so #26711 is now ready for review!
14:02:12 <gribble> https://github.com/bitcoin/bitcoin/issues/28450 | Add package evaluation fuzzer by instagibbs · Pull Request #28450 · bitcoin/bitcoin · GitHub
14:02:14 <gribble> https://github.com/bitcoin/bitcoin/issues/26711 | validate package transactions with their in-package ancestor sets by glozow · Pull Request #26711 · bitcoin/bitcoin · GitHub
14:02:35 <glozow> As discussed last week, I've put all of the p2p PRs in draft to focus review attention on the validation stuff for now. I'll continue working on them.
14:02:43 <instagibbs> achow101 proposed topic: voting/signaling for priority projects?
14:03:15 <glozow> instagibbs and I had a conversation yesterday about re-opening #27609 now that we have fuzzing / it feels a bit safer
14:03:17 <gribble> https://github.com/bitcoin/bitcoin/issues/27609 | rpc: allow submitpackage to be called outside of regtest by glozow · Pull Request #27609 · bitcoin/bitcoin · GitHub
14:03:37 <glozow> unsure if that's something people want
14:03:40 <_aj_> do it
14:03:45 <instagibbs> there's at least one project which would use submitpackage, in a limited way, to avoid a song and dance
14:03:54 <darosior> Yeah
14:04:22 <fjahr> hi
14:04:23 <instagibbs> ldk-node, which does a song and dance, then hopes a miner with a large mempool sees it, essentially
14:04:26 <glozow> I remember speaking about it with sdaftuar, mostly concerned about encouraging direct-submits to miners. Not really what we'd want but maybe the lesser of evils for now?
14:04:53 <instagibbs> They're doing... interesting stuff without our help, so I'm less and less persuaded myself that we shouldn't open it up
14:05:11 <sdaftuar> hi
14:05:14 <glozow> hi!
14:05:18 <instagibbs> !!! welcome
14:05:18 <lightningbot> instagibbs: Error: "!" is not a valid command.
14:05:18 <gribble> Error: "!!" is not a valid command.
14:05:29 <dergoegge> good bots
14:05:29 <glozow> lol
14:05:43 <josie> instagibbs has angered all the bots
14:05:45 <achow101> perhaps reopen the pr and have the discussion there?
14:05:46 <sdaftuar> sorry i'm not up to speed at all on where the package relay/package acceptance logic is these days. i think one of our concerns was whether there were dos vectors in submitpackage that we didn't want to leave open for exploitation?
14:06:04 <sdaftuar> if those have been closed off (enough), then i think i would not be opposed
14:06:51 <glozow> We've fixed a lot of bugs in the last month or so (yay) and it would be through rpc so hopefully trusted clients only. can have loud warnings in release notes
14:07:04 <sdaftuar> cool, sounds good
14:07:20 <instagibbs> I'm working on more fuzzing stuff, will just have glozow pick up what she wants to get 26711 pristine
14:07:29 <glozow> Agree with moving discussion to PR. We have a really small window before feature freeze (assuming people want this for 26) so please leave your comments asap if y'all have opinions
14:08:04 <glozow> achow101: we can move on, thanks
14:08:11 <b10c> hi
14:08:11 <achow101> #topic BIP 324 updates (sipa)
14:09:20 <achow101> perhaps sipa is not here
14:09:27 <dergoegge> i think we're just waiting for review on the integration PR
14:09:42 <_aj_> there's the breaking protocol change
14:09:44 <achow101> #28331 is the main pr, but I think #28525 is probably next for priority?
14:09:46 <gribble> https://github.com/bitcoin/bitcoin/issues/28331 | BIP324 integration by sipa · Pull Request #28331 · bitcoin/bitcoin · GitHub
14:09:48 <gribble> https://github.com/bitcoin/bitcoin/issues/28525 | net: Drop v2 garbage authentication packet by real-or-random · Pull Request #28525 · bitcoin/bitcoin · GitHub
14:09:48 <achow101> since it's a breaking protocol change
14:09:55 <dergoegge> ah right
14:10:06 <_aj_> yeah; it seems just about RFM though
14:10:07 <achow101> there's the corresponding bips pr for that: https://github.com/bitcoin/bips/pull/1498
14:10:20 <achow101> it looks ready, but I'd prefer to wait for the bip change to go in first
14:10:27 <_aj_> +1
14:10:33 <achow101> cc luke-jr
14:11:05 <instagibbs> I don't think it's required to miss an entire release cycle... but give it a shot
14:11:12 <sipa> hi
14:12:00 <sipa> not much to say in addition to what was mentioned
14:12:39 <achow101> #topic assumeutxo updates (jamesob)
14:12:47 <_aj_> the bip pr could probably do with an explicit "merge me" from an author
14:13:15 <instagibbs> _aj_ +1
14:13:27 <sipa> _aj_: will do
14:14:09 <achow101> #27596 looks like it's probably rfm?
14:14:13 <fjahr> I guess James is not here. #27596 has received more review.
14:14:13 <gribble> https://github.com/bitcoin/bitcoin/issues/27596 | assumeutxo (2) by jamesob · Pull Request #27596 · bitcoin/bitcoin · GitHub
14:14:18 <gribble> https://github.com/bitcoin/bitcoin/issues/27596 | assumeutxo (2) by jamesob · Pull Request #27596 · bitcoin/bitcoin · GitHub
14:14:31 <fjahr> The chain params question was opened as a follow-up by sjors
14:14:52 <fjahr> #28516 
14:14:54 <gribble> https://github.com/bitcoin/bitcoin/issues/28516 | validation: assumeutxo params for testnet and signet by Sjors · Pull Request #28516 · bitcoin/bitcoin · GitHub
14:15:09 <fjahr> So might be rfm
14:16:26 <achow101> #topic libbitcoinkernel updates (TheCharlatan)
14:16:50 <achow101> TheCharlatan informed me that he won't be able to make the meeting this week. he wants #28051 to be the next priority
14:16:52 <gribble> https://github.com/bitcoin/bitcoin/issues/28051 | Get rid of shutdown.cpp/shutdown.h, use SignalInterrupt directly by ryanofsky · Pull Request #28051 · bitcoin/bitcoin · GitHub
14:17:31 <achow101> #topic Ad-hoc high priority for review
14:17:47 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4 ?
14:18:20 <josie> #27827 is closed in favor of a tracking issue
14:18:20 <achow101> josie: removing #27827 since it's closed, and silent payments seems to have concept acks
14:18:22 <gribble> https://github.com/bitcoin/bitcoin/issues/27827 | Silent Payments: send and receive by josibake · Pull Request #27827 · bitcoin/bitcoin · GitHub
14:18:22 <gribble> https://github.com/bitcoin/bitcoin/issues/27827 | Silent Payments: send and receive by josibake · Pull Request #27827 · bitcoin/bitcoin · GitHub
14:18:30 <josie> achow101: jinx
14:19:44 <josie> would be really nice to get #25273 in
14:19:47 <gribble> https://github.com/bitcoin/bitcoin/issues/25273 | wallet: Pass through transaction locktime and preset input sequences and scripts to CreateTransaction by achow101 · Pull Request #25273 · bitcoin/bitcoin · GitHub
14:20:24 <josie> I need it for the silent payments sending PR, will be reviewing it over the next few days
14:21:49 <achow101> #topic 26.0 feature freeze
14:22:11 <achow101> According to the release schedule for 26.0 (#27758), feature freeze is on this sunday
14:22:13 <gribble> https://github.com/bitcoin/bitcoin/issues/27758 | Release schedule for 26.0 · Issue #27758 · bitcoin/bitcoin · GitHub
14:22:33 <achow101> but with 2 priority projects so close to the finish line, I think we could move it back another week so we can have those for this release?
14:22:55 <glozow> concept ACK
14:22:56 <achow101> (not that priority projects are intended to go in for the next release, but it'd be cool to have these in)
14:22:57 <lightlike> makes sense to me
14:22:59 <fjahr> +1
14:23:03 <hebasto> agree
14:23:03 <sipa> that (obviously) sounds reasonable to me
14:23:11 <darosior> Sounds good to me.
14:23:24 <dergoegge> +1
14:23:47 <josie> +1
14:24:00 <_aj_> *2
14:24:57 <achow101> #topic voting/signaling for priority projects
14:25:34 <achow101> we discussed this at coredev and for the next round of priority projects we're going to try to do the voting online
14:25:38 <darosior> I need to bounce but if we are doing the prio projects thing, just letting people know i'll personally try to carve out some time to help package relay move forward. No promise though.
14:25:55 <darosior> (if that counts as a vote)
14:26:41 <_aj_> (have priority projects been successful in minimising how much unwanted rebasing those projects have had to do?)
14:26:55 <achow101> my thoughts were that after feature freeze, i'll open an issue to gather possible projects (seeded with the list from coredev). then a week later, we can vote by posting comments in an (new?) issue.
14:27:02 <instagibbs> _aj_ there was pretty good consensus on a strong "yes" there
14:27:09 <achow101> _aj_: the general sentiment was that they were successful
14:27:20 <stickies-v> _aj_: I have seen at least a few instances of PRs getting closed/drafted because of priority conflicts. Could probably be more though.
14:27:56 <achow101> voting would be open for a week. then we'd have our votes done by branching
14:28:26 <_aj_> achow101: there's https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Priorities ; if we do it via issues instead, probably should kill that page
14:28:36 <josie> achow101: sounds good, but I do think its important to limit voting to people who are actively contributing/reviewing in the project. this isnt a vote of "what would you like to see in bitcoin core" and more signaling "i will prioritise working on and reviewing x"
14:29:23 <achow101> there's a bit of an open question of whether it should be anonymous or not. doing it in an issue would be inherently public, unless everyone pgp encrypts their votes or something like that
14:29:51 <_aj_> achow101: if voting == "i'm aiming to review", then anonymity doesn't seem needed
14:30:03 <fanquake> who are they encrypting to?
14:30:05 <instagibbs> "I want to not make them rebase" + "I will review"
14:30:08 <fanquake> the maintainer group?
14:30:19 <achow101> fanquake: the maintainers? or perhaps just me?
14:30:33 <stickies-v> +1 on limiting the vote. i don't mind doing it in public
14:31:20 <stickies-v> also liked josie's idea of having two votes: one being "what should be priority" and another being "what will i actively contribute to" because the two don't always have to overlap because of e.g. skillsets, experience, ...
14:31:22 <achow101> I think the only votes that will be counted are from those that are in the github org(s)
14:31:25 <stickies-v> but that may overly complicate the system
14:31:53 <_aj_> imo, it's not really a "vote", it's "which projects have the most reviewer interest, so are likely to make the most progress, and are least likely to spend a long time unmerged, and hence will only cause minimal rebasing in conflicting PRs"
14:32:04 <josie> if votes will only be counted from within the github org, then i dont see the point of anonymous?
14:32:13 <sipa> i don't think anonymity is necessary
14:32:18 <instagibbs> anon seems like overhead for no purpose
14:32:19 <josie> _aj_: +1
14:32:44 <fanquake> isn’t the whole reason we skipped the vote before because people complained about posting their votes publicly last time
14:32:55 <fanquake> or am I misremembering
14:33:04 <_aj_> i thought it was "sounds good, let's just do it" ?
14:33:24 <achow101> fanquake: no, it was that some people were anon and others were not. the complain was that everyone should have the option for anon, or no one should
14:33:34 <sipa> really the priority projects help break the cyclic dependency in decisions of the form "i'd like to work/help on X, but only if sufficient other people think the same"
14:33:35 <glozow> yeah I think we didn't vote last week because people said it was unfair to the people who weren't there, i.e. because no anon
14:33:52 <_aj_> oh, before = 6 months ago, or last week?
14:34:06 <fjahr> fanquake: i think it would have been possible to vote for a week but nobody did 6 months ago
14:34:58 <achow101> I think we can just try it non-anon on github this time, and if people complain or there are less votes this time, we can try something else next time?
14:35:09 <glozow> ACK
14:35:11 <instagibbs> whatever is simplest, thanks
14:35:15 <josie> worth making the distinction: voting in person requires doxxing meatspace identity, voting on github does not. so in that sense, yeah voting on github does allow people to vote
14:35:17 <instagibbs> keep forward momentum folks
14:35:38 <josie> ACK
14:35:39 <stickies-v> +1 keep it simple, github works
14:35:54 <sipa> yeah
14:36:31 <lightlike> should we have a phase for assembling / completing the list of candidates (before the voting starts)?
14:36:54 <achow101> lightlike: yes "i'll open an issue to gather possible projects (seeded with the list from coredev)."
14:37:16 <lightlike> ah thx, missed this
14:37:35 <stickies-v> can't we just do that here? if no one here brings up a certain topic, it's probably not gonna make it into the top anyway?
14:37:46 <_aj_> https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2023/bitcoin-core-dev.2023-05-04-19.00.log.html -- was the discussion last time around fwiw
14:37:56 <achow101> re the 2 votes idea, I'm not sure that's useful?
14:38:04 <_aj_> stickies-v: not everyone is available at this particular hour
14:38:07 <fjahr> last time we each had 3...
14:38:38 <achow101> sorry, meant the two different votes thing of "priority" and "review".
14:38:58 <achow101> for deciding the actual priority, I think having each person vote for 3 is still good
14:39:02 <sipa> the consensus at coredev was that the concept of priority projects was a success, so we don't *need* to change anything
14:39:10 <fjahr> I think nobody will check later if people actually reviewed so I think it doesn't matter
14:39:16 <sipa> except of course the fact that the voting was not done in person
14:39:39 <josie> sipa: +1
14:39:49 <glozow> I like the 2 votes idea, but agree with not hindering the process by talking about potential improvements
14:39:52 <instagibbs> signaling you'll review doesn't procedurally change anything, just nice
14:40:00 <instagibbs> so stick with what worked
14:40:33 <achow101> any other topics to discuss?
14:41:02 <fjahr> so what are the next steps?
14:41:24 <_aj_> achow101 will open an issue
14:41:41 <fjahr> And there will be one week to add topics?
14:41:51 <sipa> an issue, or an org discussion?
14:41:53 <achow101> fjahr: after feature freeze (in one week): open an issue for projects gathering. one week after that: voting in another issue, open for 1 week
14:42:14 <fjahr> ok, thanks
14:43:35 <achow101> #endmeeting